Peer खोज

एक नोड एक एंट्रीपॉइंट डायल करके जुड़ता है और नेटवर्क के बाकी हिस्से को स्वयं ढूँढ़ता है। Peer खोज (OFS-1100) उसी कनेक्शन पर ज्ञात peers का आदान-प्रदान करती है जिसे gossip पहले से उपयोग करता है, इसलिए एक नोड ऐसे peers सीखता है जो उसे कभी नहीं दिए गए और उन पतों को घोषित करता है जिन पर वह पहुँच-योग्य है।

इसे स्पष्ट रूप से कहना सार्थक है क्योंकि यह हमेशा सच नहीं था, और विफलता अदृश्य थी: खोज सेवा पूर्णतः लागू थी और अपने ही टेस्ट में पाँच नोड को अभिसरित करती थी, और कोई चल रहा नोड कभी एक नहीं बनाता था। नोड न कोई पता घोषित करते थे और न कोई ऐसा peer सीखते थे जो उन्हें स्थैतिक रूप से न दिया गया हो, जबकि हर स्थानीय जाँच से पूर्णतः स्वस्थ दिखते थे। एक नोड का एक libp2p swarm होता है, केवल एक चीज़ उस swarm के इवेंट लूप को चला सकती है, और gossip के पास वह था — इसलिए वह सेवा जो swarm की मालिक नहीं थी, कुछ भी प्राप्त नहीं करती थी, सदा के लिए। दोनों अब एक कनेक्शन साझा करते हैं, और संदेश आवरण के अपने ही OFS spec नंबर से एक या दूसरे को रूट होते हैं।

खोज एक फ़्लैग नहीं है और इसे बंद नहीं किया जा सकता।

पहला कनेक्शन

कुछ भी शून्य से एक नेटवर्क नहीं ढूँढ़ सकता, इसलिए --entrypoint अब भी वह तरीका है जिससे एक नोड आरंभ होता है:

openfiat-node --entrypoint /dns4/openfiat.allenhark.com/udp/4001/quic-v1/p2p/12D3KooW...

कई के लिए इसे दोहराएँ। एक होस्टनाम काम करता है और पसंदीदा है — नोड इसे आरंभ पर ऑपरेटिंग सिस्टम के अपने रिज़ॉल्वर के माध्यम से हल करता है, इसलिए क्लस्टर एंट्रीपॉइंट का IP बदलने पर भी टिका रहता है। /p2p/<peer id> उपसर्ग रखें: DNS प्रमाणित नहीं है, और peer id वही है जो एक हाईजैक किए रिकॉर्ड को हैंडशेक में विफल कराता है, बजाय चुपचाप आपका एकमात्र peer बनने के।

एक एंट्रीपॉइंट जो हल नहीं होगा, नोड को छोड़े जाने के बजाय आरंभ पर रोक देता है। एक नोड जो चुपचाप एक छोड़ देता, वह बिलकुल भी peers के बिना ऊपर आता और किसी से बात न करते हुए पूर्णतः स्वस्थ दिखता — जो ठीक वही विफलता है जिससे यह अनुभाग खुला।

बिलकुल किसी एंट्रीपॉइंट के बिना आरंभ करें और नोड यही कहता है, WARN पर। वह एक नए क्लस्टर के पहले नोड के लिए सही है और बाकी सबके लिए गलत।

आपका नोड अपने बारे में क्या घोषित करता है

हर वह पता जिस पर नोड जानता है कि वह सुन रहा है, माइनस bind वाइल्डकार्ड। 0.0.0.0 और :: सुनने के निर्देश हैं जिनका अर्थ «हर स्थानीय इंटरफ़ेस» है, गंतव्य नहीं — और चूँकि --gossip-bind-address का डिफ़ॉल्ट ठीक वही है, इसे बिना फ़िल्टर घोषित करना ठीक वह बग है जो peers को डायल करने के लिए कुछ नहीं छोड़ता।

Loopback और निजी रेंज जानबूझकर नहीं फ़िल्टर किए जाते। एक होस्ट पर प्रक्रियाएँ एक दूसरे तक loopback पर पहुँचती हैं, एक docker-compose क्लस्टर या एक LAN अपने peers तक केवल निजी पते से पहुँचता है, और एक एकल-होस्ट क्लस्टर एक टेस्ट कलाकृति के बजाय एक असली परिनियोजन है।

NAT के पीछे, एक कंटेनर में, या एक मैप किए IP वाले क्लाउड होस्ट पर

जिस पते को आपका नोड bind करता है वह वह पता नहीं जिस पर peers इसे पहुँच सकते हैं, और नोड सार्वजनिक वाला निकाल नहीं सकता। वह एक चूक नहीं — निर्माण से, केवल NAT के दूसरी ओर की कोई चीज़ ही सार्वजनिक पते को देख सकती है। इसलिए ऑपरेटर इसे घोषित करता है:

--external-addr /ip4/203.0.113.7/udp/4001/quic-v1

दोहराने-योग्य। घोषित पते bind किए पतों से पहले घोषित किए जाते हैं, इसलिए एक peer जो उन्हें क्रम में आज़माता है, 172.17.0.2 पर टाइम-आउट होने के बजाय पहले प्रयास पर जुड़ जाता है। bind किए पते फिर भी घोषित होते हैं — उन्हें गिराना दूरस्थ मामले को स्थानीय को तोड़कर ठीक करेगा।

फ़्लैग छोड़ें यदि आपका नोड सचमुच एक सार्वजनिक इंटरफ़ेस पर है। इसका bind किया पता पहले से इसका सार्वजनिक है।

एक नोड से पूछना कि वह क्या जानता है

curl -s -X POST http://localhost:7080/rpc -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getPeers","params":{}}' | jq

{
  "self_peer_id": "12D3KooWK9hQ7TwbfvFiaAxUbRFCkdhS7iEpAJDnewNL1anyREQ1",
  "announced_addresses": ["/ip4/203.0.113.7/udp/4001/quic-v1"],
  "peers": [
    {
      "peer_id": "12D3KooW...",
      "addresses": ["/ip4/198.51.100.4/udp/4001/quic-v1"],
      "node_version": "openfiat/0.1.0",
      "supported_ofs": [1000, 1100, 1200, 1300, 1400, 1500, 2000, 2100, 2200, 2300, 2400, 3000, 4000, 4300, 6000, 7000, 8200],
      "roles": ["MerchantGateway", "OracleProvider", "NotificationGateway", "RiskIntelligenceProvider"],
      "last_seen": 1753800000000,
      "latency_ms": 42,
      "successes": 17,
      "failures": 0
    }
  ]
}

उस प्रतिक्रिया के बारे में तीन चीज़ें जानने योग्य हैं।

self_peer_id वह 12D3Koo… रूप है जो उस एंट्रीपॉइंट में जाता है जिसे आप अन्य ऑपरेटरों को प्रकाशित करते हैं। एक नोड जो अपना peer id नहीं बता सकता, जोड़ा नहीं जा सकता, और उसे एक लॉग पंक्ति से जोड़ना ही वह तरीका है जिससे वह गलत टाइप होता है।

announced_addresses वह है जो आप peers को डायल करने के लिए कह रहे हैं, उस क्रम में जिसमें वे उन्हें आज़माएँगे। «मेरा नोड कुछ घोषित नहीं करता» जब तक सच था तब तक बाहर से अदृश्य था, और एक ऑपरेटर जो जाँच रहा है कि उसका --external-addr प्रभावी हुआ, कहीं और देखने को नहीं है।

successes और failures उस peer के साथ आदान-प्रदानों की इस नोड की अपनी गिनती हैं। जानबूझकर कोई अपटाइम प्रतिशत नहीं और कोई स्वास्थ्य स्कोर नहीं: दो गिनतियों को एक संख्या में मोड़ना एक एकल नोड के स्थानीय अनुभव को एक नेटवर्क-व्यापी फ़ैसले के रूप में प्रस्तुत करेगा, और दो ईमानदार नोड दोनों पर असहमत हो सकते हैं।