Question concernant mapping P2P pour serveur Duniter

Nodes Duniter-v2s
1

Je viens de me renseigner un peu plus sur le fonctionnement de libp2p; et il semblerait que la recommandation serait de faire le mapping tcp “brut” (moins lourd qu’avec l’ajout d’un reverse proxy avec WebSocketSecure).

Et j’ai testé le fait qu’il est possible de mapper la partie P2P des serveurs Duniter des 2 manières en même temps; en utilisant les arguments de commande --listen-addr et --public-addr qui peuvent être répétés, pour avoir:

  • en TCP « brut » sur un port dédié (ex. mapping 30335→30333), et
  • en WSS via un reverse proxy (port 443/wss) qui forward vers le port interne 30334 définis avec /ws

Mon docker compose.yaml pour mon cas de test sur mon bootnode mirror en gtest:

#
# Telemetry link GTest:
#https://telemetry.polkadot.io/#list/0xaf71369c9be6ab6abf3e342890ca1685a48e1e500a2ee9d38a5ae1f7d685fd7f
#
services:
  duniter-gtest-mirror-bn:
    image: duniter/duniter-v2s-gtest-1100:latest
    command:
      # Necessary to prevent IP ban of the reverse proxy server for RPC access
      - "--rpc-rate-limit-trust-proxy-headers"
      # Temporary params to force sync with own SMITH node
      # "--reserved-nodes /dns/smith.gtest.fr.brussels.ovh/tcp/443/wss/p2p/12D3KooWF4rQUkmpcedfLfYJUXYAEfxNc2wvUjsiyJRjZfLKDZRg"
      # The TCP p2p connection
      - "--listen-addr=/ip4/0.0.0.0/tcp/30333"
      - "--public-addr=/dns/mirror.gtest-bn.brussels.ovh/tcp/30335"
      # The WSS p2p connection
      - "--listen-addr=/ip4/0.0.0.0/tcp/30334/ws"
      - "--public-addr=/dns/mirror.gtest-bn.brussels.ovh/tcp/443/wss"
      # DEBUG extra argument to be able to see the proxy_ip= values in logs needs to be an ip in /32 CIDR (any ip?)
      #  also needs "RUST_LOG=rpc=debug" environment variable and "--rpc-rate-limit-trust-proxy-headers" command argument !
      # Forum post: https://forum.duniter.org/t/configurez-votre-reverse-proxy-sinon-votre-rpc-devient-injoignable/13660/9?u=nicolas80
      # RelevantCode: https://github.com/paritytech/polkadot-sdk/blob/stable2512/substrate/client/rpc-servers/src/lib.rs#L236
      #- "--rpc-rate-limit-whitelisted-ips 192.168.1.10/32"
    platform: linux/arm64/v8
    container_name: duniter-gtest-mirror-bn
    restart: unless-stopped
    ports:
      #  # (Private) Prometheus (for monitoring)
      #  # can't seem to add it as a data source in grafana :-/
      #  - 127.0.0.1:9617:9615
      - 127.0.0.1:9935:9944
      # Needs to be mapped PUBLICLY for direct p2p tcp connection
      - 0.0.0.0:30335:30333
      # WS only access through reverse proxy no need to declare
      #- 127.0.0.1:30336:30334
    volumes:
      - data-mirror:/var/lib/duniter/
      #- ./tmp-build-spec/:/tmp/build-spec/
    environment:
      # gdev, gtest or g1
      - DUNITER_CHAIN_NAME=gtest
      - DUNITER_VALIDATOR=false
      # default / archive= all blocks / light= +-24hours
      - DUNITER_PRUNING_PROFILE=light # <--- To be used for BootNode
      - DUNITER_NODE_NAME=Nicolas80-GTest-mirror-bootnode
      - DUNITER_PUBLIC_RPC=wss://mirror-rpc.gtest-bn.brussels.ovh/

      # Defined within command with --listen-addr & --public-addr
      #- DUNITER_PUBLIC_ADDR=/dns/mirror.gtest-bn.brussels.ovh/tcp/443/wss
      #- DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333/ws

      #- DUNITER_PUBLIC_SQUID=https://squid.gtest.brussels.ovh/v1/graphql
      # Path to a json file containing public endpoints to gossip on the network
      #- DUNITER_PUBLIC_ENDPOINTS=

      # Activate DEBUG for rpc, to be able to verify proxy_ip= values
      #  also needs "--rpc-rate-limit-whitelisted-ips=..." and "--rpc-rate-limit-trust-proxy-headers" command arguments !
      #- RUST_LOG=rpc=debug
    networks:
      dockge_dockge_net: null
volumes:
  data-mirror: null
networks:
  dockge_dockge_net:
    external: true

Et je peux vérifier que les 2 méthodes d’accès fonctionnent :

ipfs swarm connect /dns/mirror.gtest-bn.brussels.ovh/tcp/443/wss/p2p/12D3KooWD1mp5M1CsZnVuPWQBHs5PhGZfhSEtm6gh6UvypcVrpjh
connect 12D3KooWD1mp5M1CsZnVuPWQBHs5PhGZfhSEtm6gh6UvypcVrpjh success

ipfs swarm connect /dns/mirror.gtest-bn.brussels.ovh/tcp/30335/p2p/12D3KooWD1mp5M1CsZnVuPWQBHs5PhGZfhSEtm6gh6UvypcVrpjh
connect 12D3KooWD1mp5M1CsZnVuPWQBHs5PhGZfhSEtm6gh6UvypcVrpjh success

Du coup la question: est‑ce qu’exposer les deux accès vous paraît utile/pratique pour le réseau :red_question_mark:

Et sinon, quelle méthode de mapping est préférée ?
Plutôt en TCP brut :red_question_mark:

3 Likes
2

Oui, en théorie, TCP brut est légèrement plus efficace. En pratique, la différence est totalement négligeable. Même en production, pour de grosses blockchain substrate, personne ne s’embête avec ça.

Ma recommandation est de rester simple : tant que votre endpoint P2P est correctement joignable, c’est très bien :slight_smile:

1 Like
3

Et sur l’aspect joignable sur les 2 types de liens en même temps, est-ce que c’est une bonne ou une mauvaise idée ?

4

Non, il vaut mieux exposer un seul endpoint P2P pour éviter toute ambiguïté

1 Like
5

Comme je remarque que mon noeud à été ajouté comme bootnode GTest avec l’url p2p

"/dns/mirror.gtest-bn.brussels.ovh/tcp/443/wss/p2p/12D3KooWD1mp5M1CsZnVuPWQBHs5PhGZfhSEtm6gh6UvypcVrpjh"

Je vais garder cette configuration via Reverse Proxy pour ce noeud là :wink:

1 Like
6

Oui j’ai pris les endpoint p2p disponibles dans gtest.json · master · nodes / networks · GitLab , merci @vit et @Nicolas80 pour vos endpoint :slight_smile:

2 Likes
7

Je suis favorable à recommander l’exposition du p2p “brut”. Ceux qui savent ce qui font et savent gérer des certificats peuvent tout à fait exposer par du wss. Cette option permet l’utilisation de ces endpoints p2p dans les navigateurs, qui ont souvent des contraintes plus fortes sur les connexions sortantes.

1 Like