Configuration réseau pour un bon fonctionnement pair à pair

Networks ĞDev
1

Observation du pairage sur la gdev

On commence à avoir assez de nœuds sur le réseau gdev pour pouvoir s’intéresser à la configuration réseau pour maintenir un bon nombre de pairs. Merci à tous les testeurs !! Voici une capture de la télémétrie, on s’intéresse ici à la colonne “peer count” :

image
image1920×831 228 KB

Voilà les nombres de pairs observés :
20, 10, 12, 11, 12, 9, 22, 0, 24, 26, 10, 11, 22, 21, 25, 12, 25, 11, 10, 8, 19, 8, 10, 21, 9, 7, 23, 8
image

On voit deux groupes:

Établissement d’une connexion : émetteur vs récepteur

Dans un fonctionnement pair à pair, une fois la connexion établie, elle est symétrique et utilisable dans les deux sens. Mais pour que cette connexion s’établisse, il faut que l’un des deux pairs l’initie et l’autre la réceptionne. Il y a rarement des problèmes du côté de l’émetteur parce que peu de gens utilisent des pare-feu sortants (sauf @aya qui est très prudent là dessus) et plus souvent des problèmes du côté du récepteur.

Les problèmes côté récepteur peuvent être dus à :

  • une mauvaise configuration du pare-feu qui ne laisse pas passer les connexions
  • en auto-hébergement une mauvaise configuration de la box qui ne redirige pas les connexions entrantes vers la bonne machine

Voici pour illustrer le docker-compose.yml d’exemple :

ports:
  # public p2p endpoint
  - 30333:30333
environment:
  DUNITER_PUBLIC_ADDR: /dns/your.domain.name/tcp/30333
  DUNITER_LISTEN_ADDR: /ip4/0.0.0.0/tcp/30333

En déclarant DUNITER_PUBLIC_ADDR, il faut s’assurer que les autres nœuds vont bien pouvoir se connecter en utilisant cette adresse.

Actions à réaliser

Pour les nœuds “bien connectés”, pouvez-vous compléter ce tableau si vous voulez être ajoutés aux bootnodes ?

pseudo nom du noeud addresse
@HugoTrentesaux HugoTrentesaux-smith /dns/gdev.trentesaux.fr/tcp/30333
@Pini pini-gdev-smith /dns/gdev-smith.pini.fr/tcp/443
ben-mirror ``
@HugoTrentesaux hugo-gyroide-archive /dns/gdev.gyroi.de/tcp/30333
@HugoTrentesaux hugo-coindufeu-archive [ne pas ajouter, sera supprimé]
@tatinetteb tatinetteb-gdev-mirror ``
@joss.rendall rendall-gdev-mirror ``
Jef-Gdev-Mirror ``
@BulmAnanaBelle Bulmanabelle-Docker-OVM-Gdev-Mirror ``
@d0p1 d0p1-abrahel-mirror /dns/gdev.abrahel.d0p1.eu/tcp/30333
@Pini pini-gdev-mirror /dns/gdev.pini.fr/tcp/443
@tuxmain tuxmain-polux-smith-gdev /dns/gdev.txmn.tk/tcp/30333
@moul moul-smith /dns/gdev.moul.re/tcp/30333

Pour les nœuds “moins bien connectés”, pouvez-vous vérifier que votre nœud est bien joignable depuis l’extérieur ?
:uk: please check that your node p2p endpoint can actually be reached from outside network

Pour les personnes qui n’ont pas activé la télémétrie comme @tuxmain, est-ce que vous pouvez indiquer ici votre nombre de pairs ? Par exemple avec l’appel rpc unsafe system.peers(), le menu de l’app polkadotjs “réseau > explorateur > infos du nœud”, ou en utilisant le monitoring prometheus ?

6 Likes
2

Mon nœud validateur gdev.txmn.tk:30333 a 26 pairs.

1 Like
3

pour mon nœud: /dns/gdev.abrahel.d0p1.eu/tcp/30333

1 Like
4 
ports:
  # public p2p endpoint
  - 30333:30333
environment:
  - DUNITER_PUBLIC_ADDR=/dns/your.domain.name/tcp/30333
  - DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333

Je viens de l’ajouter à mon compose en y mettant mon domaine et mon ip.

Comment le vérifier?

Voici mon adresse:
/dns/duniterv2.shainajabu1.fr/tcp/30333

1 Like
5

Apparemment, ça n’a pas aidé puisque tu es retombée à 8 pairs :sob:
La configuration par défaut avec l’auto-découverte de l’adresse avait plus de succès. En démarrant sans config, on peut regarder l’adresse dans les logs :

🔍 Discovered new external address for our node: /ip4/78.199.27.8/tcp/30333/ws/p2p/12D3KooWBcWNStGCq1WwWCsfTYKcc76CQ94FYUwbcsPzDWFWToub

Pour tester, j’utilise les commandes réseau d’IPFS (mais il y a peut-être plus simple) :

$ ipfs swarm connect /dns/duniterv2.shainajabu1.fr/tcp/30333/p2p/12D3KooWFcw7dmhYu2fKbCUgz1RgiqihDSxLgv4YgDMVbtkMASTg
Error: connect 12D3KooWFcw7dmhYu2fKbCUgz1RgiqihDSxLgv4YgDMVbtkMASTg failure: failed to dial: failed to dial 12D3KooWFcw7dmhYu2fKbCUgz1RgiqihDSxLgv4YgDMVbtkMASTg: all dials failed
  * [/ip4/78.197.228.115/tcp/30333] dial tcp4 78.197.228.115:30333: connect: connection refused
6

Je l’ai remis d’origine, je ne vois que 8 paires.

7

je pense que le problème c’est DUNITER_LISTEN_ADDR si tu a mis ton IP au lieu de 0.0.0.0

8

Merci, je viens de le refaire en laissant 0.0.0.0 toujours 8 paires.

image
image1736×189 15.7 KB

9

@HugoTrentesaux , n’ayant pas assez de Level dans le Forum je ne peux modifier directement le tableau (pas possible de nommer + de 10 utilisateurs)…

Je n’ai pas de DNS de configurés en V2S pour ces 2 VPS :

  • Rendall-gdev-mirror : /ip4/193.168.145.31/tcp/30333
  • Rendall-gdev-smith : /ip4/193.168.145.31/tcp/30334
  • Jef-Gdev-Mirror : /ip4/193.168.145.216/tcp/30333

Edit : J’ai l’impression que c’est juste les SMITHs qui ont moins de Pairs…

10

Mine should be working better now:

$ ipfs swarm connect /dns/duniter-v2-vjrj-gdev.comunes.net/tcp/30333/p2p/12D3KooWGL7SZ3ewQdfPh3FaQ23Cg15AePyBusLwFAYNU4oLKbsR 
connect 12D3KooWGL7SZ3ewQdfPh3FaQ23Cg15AePyBusLwFAYNU4oLKbsR success

although it’s currently only with 11 pairs.

1 Like
11

Il doit surement y avoir une autre méthode pour tester la connexion à une adresse/endpoint libp2p, il y a des bibliothèques dans beaucoup de langues, par contre je n’ai pas trouvé d’outil CLI, il faut développer dans la langue :

Kubo (alias ipfs) utilise la bibliothèque libp2p en Go.

1 Like
12

Ah bien vu ! Je n’avais pas imaginé que tu puisses mettre ton ip à cet endroit. En fait, ça correspond à une adresse d’écoute. Tu peux soit écouter en local uniquement avec 127.0.0.1 soit écouter à l’extérieur avec 0.0.0.0. Mais je ne sais pas ce que pourrait signifier de n’écouter que sur une ip publique.

@joss.rendall Merci pour les ip, je n’ai toujours pas réussi à trouver les fiches de pair pour les avoir toutes. Et non, certains forgerons ont plein de pairs, ça n’a pas l’air corrélé.

1 Like
13

Update for --name Bulmananabelle-Docker-OMV-Gdev-Mirror

2024-10-09 18:20:12 🔍 Discovered new external address for our node: /ip4/82.65.248.169/tcp/30333/p2p/12D3KooWB2de56jzZ7q5Qc4YAB6rUUiAoPxbMcaYAtwXR5j59D2Q    


2024-10-09 18:20:14 🔍 Discovered new external address for our node: /dns/bulmagdev.sleoconnect.fr/tcp/30333/p2p/12D3KooWB2de56jzZ7q5Qc4YAB6rUUiAoPxbMcaYAtwXR5j59D2Q
2 Likes
14

Tested successfully

ipfs swarm connect /dns/gdev.cuates.net/tcp/30333/p2p/12D3KooWN5BBZuMraywLWApFVNYg5FUu3fhvy2vDYdSXsGuZ3zu8
connect 12D3KooWN5BBZuMraywLWApFVNYg5FUu3fhvy2vDYdSXsGuZ3zu8 success
1 Like
15

8 peers, ça veut dire qu’on n’accepte pas les peerings entrants :

  --out-peers <COUNT>
      Number of outgoing connections we're trying to maintain [default: 8]
  --in-peers <COUNT>
      Maximum number of inbound full nodes peers [default: 32]
  --in-peers-light <COUNT>
      Maximum number of inbound light nodes peers [default: 100]

ouverture du port 30333

modification de DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333/ws en DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333 → passage à 9 peers (à retester)

modification en DUNITER_LISTEN_ADDR=/ip6/::/tcp/30333 → 8 peers

ajout de DUNITER_PUBLIC_ADDR=/dns/gdev.matograine.fr/tcp/30333 → 8 peers (DUNITER_PUBLIC_ADDR n’est pas présent dans le env_file du paquet debian)

j’ai testé : la connexion p2p se fait bien (fait sur mon PC, mon noeud est distant)

ipfs swarm connect /dns/gdev.matograine.fr/tcp/30333/p2p/12D3KooWGwcpvdCYXHt89Tc2M5xbhzq4T7DrLKgYHPCBozzEkM2W
> connect 12D3KooWGwcpvdCYXHt89Tc2M5xbhzq4T7DrLKgYHPCBozzEkM2W success

@tatinetteb disait hier qu’elle était à 8 peers, elle est à 10 maintenant, il y a du mieux, il faut sans doute laisser passer du temps.

4 Likes
16

Que vaut-il mieux utliser comme bootnode ?
Un noeud mirroir
Un noeud forgeron
Peu importe

1 Like
17

Je dirais peu importe, mais plutôt un forgeron, puisque les bootnodes sont critiques (si tous les bootnodes sont down, on ne peut plus connecter un nouveau nœud aisément). Comme les forgerons sont déjà un peu critiques (ils sont censés maximiser leur uptime synchronisé), autant en profiter et ne pas augmenter inutilement la criticité des miroirs.

2 Likes
18

Oui, je suppose que quand un nœud a appris qu’un endpoint annoncé ne répondait pas, il met un certain temps avant de retenter sa chance. J’ai tenté un docker compose restart sur mon nœud archive et j’ai vu pas mal de nœuds qui étaient à 8 pairs passer à 9. Donc on dirait qu’au démarrage, le nœud réessaye quand même de se connecter aux pairs connus. Est-ce que quelques autres personnes peuvent essayer un restart pour voir si ça change quelque chose ?

Je dirais qu’il faut mettre comme bootnode des choses que l’on peut conserver dans le temps. Donc un dns ou une ip fixe et un peer id qu’on ne perd pas (comme c’est arrivé pour mon nœud qui est dans les bootnodes et dont j’ai effacé le peer id). Après, que ce soit un forgeron ou un miroir ça change rien à mon avis. Ça peut même évoluer dans le temps.

1 Like
19

@HugoTrentesaux suite à ce message, j’ai un doute concernant les paramètres DUNITER_LISTEN_ADDR et DUNITER_PUBLIC_ADDR .

Dans le paquet .deb, le env_file contient ces lignes :

# Defines the address and port for node communication.
# The format is /ip4/[IP address]/tcp/[port]/[protocol].
# If SMITH NODE: `/ip4/0.0.0.0/tcp/<port>` and `/ip6/[::]/tcp/<port>`. Otherwise: `/ip4/0.0.0.0/tcp/<port>/ws` and `/ip6/[::]/tcp/<port>/ws`.
DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/9944/ws

et aucune ligne concernant DUNITER_PUBLIC_ADDR.

De ce que je comprends :

  • DUNITER_LISTEN_ADDR est l’adresse pour la communication rpc, donc :
    • l’IP est ip4/0.0.0.0 ou ip6/:: dans le cas général (j’imagine qu’il y a des configs spéciales)
    • <port> est le port rpc (9944 par défaut)
    • le chemin doit se terminer par /ws pour les noeuds qui exposent l’API rpc (donc le protocole n’est pas indiqué pour les noeuds smith)
  • DUNITER_PUBLIC_ADDR est l’adresse pour la communication p2p, donc
    • on utilise ip4/<ip_publique_v4>, soit ip6/<ip_publique_v6>, soit dns/<domain_name>
    • <port> est le port p2p (30333 par défaut)
    • pas de protocole à indiquer

J’ai bon ?

1 Like
20

Oh, bien vu, 9944 c’est la convention pour le port rpc, pas p2p, ça embrouille de les mélanger ><
[edit]

Ça doit être une vieille version désolé, puisque le fichier est comme ça maintenant. resources/debian/env_file · master · nodes / rust / Duniter v2S · GitLab. Il faudrait qu’on fasse une release propre parce que le paquet debian n’est pas encore intégré à la page de release Releases · nodes / rust / Duniter v2S · GitLab.

Donc non, DUNITER_LISTEN_ADDR et DUNITER_PUBLIC_ADDR mappent vers la config p2p uniquement : (cf duniter --help)

--public-addr <PUBLIC_ADDR>...
    Public address that other nodes will use to connect to this node.
    This can be used if there's a proxy in front of this node.

--listen-addr <LISTEN_ADDR>...
    Listen on this multiaddress.
    By default: If `--validator` is passed: `/ip4/0.0.0.0/tcp/<port>` and `/ip6/[::]/tcp/<port>`. Otherwise:
    `/ip4/0.0.0.0/tcp/<port>/ws` and `/ip6/[::]/tcp/<port>/ws`.

Pour rpc, c’est juste

--rpc-port <PORT>
    Specify JSON-RPC server TCP port

Là où c’est déroutant, c’est que les connexions p2p peuvent se faire à travers websocket, pas nécessairement directement sur tcp. J’ai creusé ces questions dans le contexte ipfs qui documente beaucoup mieux les différents types de connexions (tcp, webtransport, webrtc, websocket…). Dans le contexte substrate c’est moins clair et moins documenté. Je ne retrouve plus les discussions que j’avais lues à ce sujet mais en gros c’est un choix historique pour faciliter la configuration des light client qui s’exécutent potentiellement dans un contexte limite (type navigateur). Ça avait été désactivé pour les nœuds forgeron par crainte d’une perte de perf mais s’est avéré négligeable et n’a jamais été rétabli.

Voici donc mes définitions :

  • DUNITER_LISTEN_ADDR est l’adresse d’écoute pour les communications p2p. Ça dit comment duniter doit écouter. C’est l’équivalent de “bind” dans python -m http.server --bind 0.0.0.0 si on veut. Mettre 127.0.0.1 permet de n’écouter qu’en local. Quand on est dans un conteneur docker ça ne change rien puisque c’est géré par les réseaux docker. Et on écoute à la fois en tcp et websocket sur le même port, sauf pour les nœuds forgeron qui ne font que tcp.
  • DUNITER_PUBLIC_ADDR est l’adresse publique pour la communication p2p. Ça permet de donner des informations sur la manière dont on veut être contacté par les autres nœuds. Si on ne met rien, il va demander aux autres nœuds l’adresse sous laquelle ils le voient, d’où les “🔍 Discovered new external address for our node”. Mais si on met en place un proxy websocket, il faut préciser, par exemple /ip4/<ip>/tcp/80/ws ou /dns/<domain>/tcp/443/ws.

Le format multiaddress a l’avantage d’être plus explicite que le format url. Par exemple, quand on dit https://example.org/ on sous-entend le port 443, et on ne précise pas ipv4 ou ipv6. De plus, il se lit de gauche à droite avec un ordre logique (on fait la résolution dns avant de considérer http).

1 Like