Nouvelle API : WS2P

API WS2P
, ,
21

Ah non, regardes Galuel n’expose pas son nœud et calcule quand il le veut. C’est possible parce que le nœud Duniter pull également, ce qui est juste l’ancêtre HTTP de WS2P.

22

Dans ce cas autant pour moi, cette asymétrie existe déjà.

23

Après, même si l’on “force” la main, l’UPnP même aujourd’hui est toujours temporaire, je fais bien attention à ça.

De même, le logiciel peut avertir l’utilisateur de ce comportement, il n’y a pas à lui cacher. Enfin bon, Duniter est annoncé comme un logiciel réseau P2P aussi, donc ça devrait pas être une surprise non plus :slight_smile:

2 Likes
24

Première proposition :

  • Noeuds connectés en entrée et en sortie : Hubs Nodes
  • Noudes connectés en sortie uniquement : Peripheral nodes

Hésitez pas à relancer d’autres idées qui vous paraîtrait mieux :slight_smile:

25

cgeek

tu peux developper ce a quoi tu pense quand tu souhaite une communication “bidirectionnelle” dans ce dernier post ?
.Protocole d’API gRPC pour l’api WS2P?

On a toujours le meme modele,
Couche TCP
un client qui instancie une requete sur un serveur.
Tant que ni l’un ni l’autre ne rompt cette communication, elle est “bidirectionnelle”.

ex du réseau internet et les navigateurs web.
client instancie une requete. Le serveur répond est clos aussi tôt la connexion.
D’où, les websockets, au dela d’une consideration de sécurité en +:
client instancie une requete, le serveur maintient la connection.

la connection se faisant de point à point, TCP assure la négociation à contrario de la couche UDP
qui n’assure pas “ce deal” de la connectivité. Faut l’implementer, ce qui n’est pas forcement mauvais puisqu’il faut se faire un petit protocol de la trame de donnée, qui plus est tu peux gérer (+ ou -) cette notion de bande passante que l’on souligné précédemment.
Cependant UDP permet le broadcast et donc de transmettre les datas a plusieurs points simultanement.

C’est pourquoi je m’interroge sur ce que tu as besoin comme type de connexions ?
Si je comprends bien, c’est pour communiquer une liste -publiquement - d’adresse (les noeuds duniter)
à partir des quels l’on peut se connecter ?

J’ai pas encore la vision en tête globale et de proposition a faire,
je me demande si la capacité de pouvoir broadcaster les infos peut être envisagé ?

26

Oui, mais dans le sujet gRPC celui-ci est construit sur un mode client/serveur, et donc ne permet pas de pousser de données depuis le serveur vers le client. A fortiori si ledit client est derrière un NAT+firewall.

edit : je sais bien, en théorie gRPC peut le faire. Mais ils ne l’ont pas fait, ça ne fonctionne pas, faut patcher gRPC pour ça.

J’ai besoin d’une communication bidirectionnelle, type serveur/serveur, même si l’un des 2 est derrière un NAT+firewall avec tous ses ports fermés. Qui plus est, je ne veux pas réimplémenter une couche réseau mais me servir de technos déjà éprouvées.

Le WebSocket remplit pleinement cet objectif aujourd’hui, en plus d’être largement adopté.

Auxquels se connecter, oui.

En théorie oui, mais ça ne me paraît pas indiqué pour toutes les situations. Un simple multicast (les WebSocket) avec rebond suffit.

27

Autre terminologie que j’aimerais adopter : parler de « document pool » ou « docpool » pour signifier piscine en anglais.

C’est pas mieux ?

3 Likes
28

A propos des noeuds ou des piscines ? Je ne suis pas sur de comprendre.

29

À propos des piscines. Dire sandbox me paraît moyen.

Je disais ça vu que tu parlais terminologie.

30

Ok, je suis d’accord que sandbox ça n’a… Aucun rapport avec ce qu’on souhaite exprimer :smiley:

31

  1. pool = piscine

  2. sandbox = bac a sable

pool, un ensemble d’elements en traitement – peu importe les données, donc faut se mettre d’accord sur quels sont les éléments traiter.

sandbox pour effectuer des tests, on joue dans le bac :slight_smile:

3 Likes
32

cgeek

As-tu prévu un financement participatif pour ceux qui souhaitent rémunérer ton travail sur cette nouvelle API ?

1 Like
33

Non, on va dire que c’est “cadeau” pour celle-là.

La v1.6 est la dernière version que je ferai gratuitement, ensuite je laisserai ma place à d’autres pour les développements de nouvelles fonctions.

Il faut savoir passer la main :slight_smile:

4 Likes
34

En fait je compte introduire la syntaxe suivante dans la fiche de pair :

WS2P [identifiant] [hôte] [port]

Où :

  • identifiant est une chaîne de 8 caractères hexadécimaux
  • hôte est une chaîne caractères (non limitée)
  • port est un nombre (non limité)

Je ne mets pas de limite de taille pour 2 des champs car quoi qu’il en soit on peut fixer une limite de taille totale par endpoint (je vais mettre 255 caractères arbitrairement, je remarque que ce n’est pas fait).

Par exemple :

WS2P f8e637ba0 duniter.org 443

Je rajoute donc un champ d’identifiant de nœud, car sinon est en cas de multiples nœuds avec la même clé publique ça devient vraiment galère de savoir quel endpoint nous appartient ou pas, et donc de savoir si on peut le retirer de la fiche ou pas.

J’avais réussi avec BMA mais c’est vraiment compliqué et implique un surcoût réseau (échanges pour savoir qui est qui, si le endpoint a toujours quelqu’un en face, etc). Donc je préfère améliorer cette situation avec un identifiant.

3 Likes
35

Bon, je ne vais malheureusement pas pouvoir développer les points suivants par manque de temps :

Connexion en priorité aux membres calculants

Je comptais faire en sorte qu’un nœud se connecte prioritairement auprès des nœuds calculant des blocs. Je vais finalement faire plus simple : se connecter en priorité aux nœuds membres.

Les connexions de Niveau 3 « Invitation »

Je ne vais pas développer la couche automatisant ce travail : on pourra quand même configurer des nœuds auxquels se connecter soi-même et configurer des nœuds invités pour lesquels on accepte systématiquement la connexion. Mais il n’y aura pas de message réseau demandant aux nœuds invités de se connecter : il faudra que les 2 administrateurs aient conclu cela de façon manuelle en dehors du réseau, et adapté leurs configurations pour que ça fonctionne.

État du consensus réseau de façon optimisée

Comme l’accès à BMA sera désactivé par défaut, les clients comme Sakia / Silkaj / Cesium ne pourront plus connaître l’état du HEAD de chaque nœud en leur demandant directement. Il faut donc un autre mécanisme indiquant l’état du réseau. Je vais réaliser ce mécanisme, mais dans une version très basique et largement optimisable.

36

Petits exemples suite à mes essais.

Depuis BMA, il est possible de connaître le nombre de nœuds connectés à soi et vers soi :

/network/ws2p/info

{
  "peers": {
    "level1": 0,
    "level2": 1
  }
}

Il est également possible d’obtenir une vue du réseau :

/network/ws2p/heads


{
  "heads": [
    {
      "message": "WS2P:HEAD:HVbVWiHyjCr9KNQfPXT2qXzck4xoShEggckGGtNN7JFq:52718-000004EDF7A41D7BC8CBA6426968AB750377FB698403E827D4838FA1E29F8874",
      "sig": "xV2jIgV7y9UkE2+9I9bRdsvSgLdaEPKNGfAkQdPniylrqJ2cyzVS9i97J72Ic5B8vBbvq3x4+acpq7W+jdXxBA=="
    },
    {
      "message": "WS2P:HEAD:5PQ7ZyBUCNpE4Atf4nyzN3614Tc8zQzKkrjPqFR4cUMt:52718-000004EDF7A41D7BC8CBA6426968AB750377FB698403E827D4838FA1E29F8874",
      "sig": "5z7T9rUwfXcnYf96Gjk4RJ0i1UANFVeiC1PTVHc0lamC1EcLix3PThdx8UzNragam1HGuwl0SzQ6jc2nWFu/CA=="
    }
  ]
}

Ces vues seront également disponible dans l’UI de Duniter, dans un nouvel onglet de l’écran d’accueil.

En tout cas, j’ai là 2 nœuds parfaitement connectés en WS2P et dont l’un a BMA totalement désactivé. Et pourtant il est au courant de toutes les infos passant par le réseau !

La semaine prochaine, nous pourrons faire des tests grandeur nature :slight_smile: (notamment derrière des routeurs 4G)

2 Likes
37

Dites moi si je vous saoul avec mes protocoles, mais sur une API, j’aime bien utiliser quelque chose avec des specs publiques et pas un truc maison.

C’est plus facile pour d’autres contributeurs d’étendre l’api, puisqu’elle est cohérente et standard avec d’autres applications.

Pour les requêtes JSON dans les websockets, que diriez-vous d’utiliser GraphQL ?

Un article très alléchant pour NodeJs

Ce n’est peut-être pas nécessaire pour un dialogue inter-noeuds, à voir…

Mais je pense en tout cas que ce serait vraiment efficace pour un dialogue client-noeud (en web socket ou non).

  • Un seul endpoint
  • Indépendant du protocole réseau (http, websockets)
  • Typage fort
  • Introspection
  • Le client choisit le format de sa réponse, donc peut réduire le nombre de données demandées

Qu’en pensez vous ?

1 Like
38

J’ai pas compris la formulation de ta phrase. Est-ce que ça signifie la phrase suivante ?

car, si on est dans le cas de multiples nœuds ?

39

oui c’est ça :slight_smile:

40

C’est ce que je me dis, oui. Pour le coup, je préfère qu’on maîtrise parfaitement le flux de données possible pour la communication inter-nœuds.

Par contre pour ce qui est d’une API client/nœud qui remplacerait BMA, vous avez quartier libre :slight_smile: et même, je serais heureux qu’une bien meilleure API voit le jour !

Je pourrais d’ailleurs vous montrer quoi modifier dans Duniter à l’occasion des RML10, car finalement une API n’est qu’un module. Vous pouvez donc la développer totalement indépendamment de Duniter et l’installer sur votre nœud dès aujourd’hui !

3 Likes