Ich habe einen Knoten Amit Bitcoin verbunden testnet(Port 18333). Die Knotenerkennung findet statt und ich sehe einige Verbindungen zwischen meinem Knoten Aund den Seed-Knoten. Das gesamte Senden und Empfangen erfolgt zwischen den Knoten NUR über Port 18333 (ich habe dies eingecheckt ThreadSocketHandler)
Ich füge Bdem Bitcoin einen weiteren Knoten hinzu (anderer Laptop, daher andere IP) testnet. Ich initiiere eine addnode <lappyB_IP>:18333 onetryVerbindung von Aund sie wird akzeptiert. Aber jetzt wird der Port A, der zum Senden von Daten verwendet wird, vom Betriebssystem zufällig ausgewählt und NICHT 18333. Dies kann durch überprüft werdengetpeerinfo
Wir sollten beachten, dass es sich bei beiden um ausgehende Verbindungen handelt A– nämlich bei der ersten, die wir mit Seednode verbunden haben, und bei der ersten, wenn wir mit einem anderen Knoten verbunden sind B. Wie kommt es, dass die früheren Daten über 18333 (Standardport) gesendet werden, sich aber im späteren Betriebssystem für einen anderen Port entscheiden?
Alle Knoten lauschen auf Port 18333 auf eingehende Verbindungen. Alle eingehenden Verbindungen verwenden diesen Port. Addrlocal zeigt also localIP:18333.
Jede ausgehende Verbindung verwendet einen zufälligen Port, sodass addrlocal localIP:xxxxx anzeigt
Jede Verbindung ist also entweder zufällig <----> 18333 ODER 18333 <----> zufällig. Der Knoten, der die Verbindung (out) initiiert hat, verwendet immer einen zufälligen Port.
So funktionieren alle TCP/IP-Webdienste mit bekannten Ports. Webserver lauschen auf Port 80 oder Port 443, Browser verwenden einen zufälligen lokalen Port, um sich mit ihnen zu verbinden.
Bearbeiten: Beachten Sie, dass Port 18333 für Testnet-Knoten bestimmt ist. Wäre 8333 für Hauptnetz. Auch unter Linux netstat -ntlpoder netstat -ntpwerden alle TCP-Verbindungen angezeigt
sysctl net.ipv4.ip_local_port_range="18333 18333"(Hinweis: Dadurch können Sie nur eine ausgehende Verbindung gleichzeitig haben.)
Dustin Butler
Guhan S
rpcnet.cppDie Logik unterdrückt es alsogetpeerinfo