Kann ein Bitcoin-Knoten eine ausgehende Verbindung zu einem eingehenden Knoten herstellen?

Ich versuche herauszufinden, ob wir eine ausgehende Verbindung zu einem eingehenden Knoten herstellen können (ein Knoten, mit dem wir bereits verbunden sind, aber der entfernte Peer die Verbindung initiiert hat). Ich weiß, dass dies nicht viel Sinn macht, da wir Informationen zu eingehenden und ausgehenden Knoten austauschen. Ich habe mir jedoch den Quellcode angesehen und den Code nicht gefunden, der einen Knoten daran hindert, dies zu tun. Gibt es da draußen jemanden, der erfolgreicher ist?

Ich habe das falsch gelesen. Nichts hindert das, was Sie beschreiben.

Antworten (2)

Nichts verhindert dies, da es unmöglich ist zu unterscheiden, ob der Knoten, der sich mit Ihnen verbindet, derselbe ist, mit dem Sie bereits verbunden sind. Dies liegt daran, dass ein Computer mehrere Knotensoftware oder mehrere Instanzen derselben Software ausführen kann und somit mehrere Knoten im Netzwerk sein kann.

Es gibt auch keinen Grund, eine solche Verbindung zu blockieren.

Ich sehe, dass es keinen Grund gibt, eine solche Verbindung zu blockieren. Aus meiner Sicht würde ein Knoten jedoch davon profitieren, wenn er sich mit einem anderen Knoten verbindet (und nicht mit einem, mit dem er bereits verbunden ist). Können wir die IP-Adresse nicht verwenden?
Nein. IP-Adressen sind keine ausreichend eindeutigen Kennungen. Abgesehen von dem, was ich erwähnt habe, gibt es auch das Problem der NATs. Zwei Computer hinter einem NAT haben dieselbe öffentliche IP-Adresse.

Jan,

Es gibt einen Mechanismus, der Bitcoin Core daran hindert, eine neue Verbindung (ausgehend) zu einer Adresse zu öffnen, mit der es bereits verbunden ist (unabhängig davon, ob die bestehende Verbindung eingehend oder ausgehend ist).

Sehen Sie sich die Funktion an CConnman::AlreadyConnectedToAddress(), wie sie aufgerufen wird CConnman::OpenNetworkConnection()und den umgebenden Code.

Diese Prüfung könnte es jedoch in den folgenden Fällen ermöglichen, einen Ausgang zu öffnen, selbst wenn ein Eingang von derselben Adresse vorhanden ist:

  1. Beim Öffnen einer ausgehenden Verbindung zu RPC addnode onetry, RPC addconnection, ADDR_FETCHVerbindungen, Verbindungen zu Adressen an -connectund -addnode. Dann wird auch der Port verglichen. addr:8333Wir werden also mit Sicherheit keine eingehende Verbindung vom Listening-Port des Knotens (z. B. ) während der Prüfung sehen . Eingehende Verbindungen kommen von einem zufälligen Port, der vom Betriebssystem des Remote-Knotens zugewiesen wird (z. B. addr:54721). In diesen Fällen würde die Überprüfung uns nur daran hindern, mehrere ausgehende Verbindungen zu demselben Knoten zu öffnen.

addr:54721In den anderen Fällen wird nur die Adresse verglichen, ohne den Port, so dass die Prüfung beim Verbindungsversuch einen vorhandenen Inbound von erkennen addr:8333und den Verbindungsaufbau abbrechen würde. Jedoch:

  1. Zwischen den beiden gibt es ein Rennen CConnman::OpenNetworkConnection(), wenn addrsich uns verbindet:
  • prüfen, ob angeschlossenaddr
  • Wenn nicht, dann öffne eine Verbindung zuaddr

Dieses Rennen ist selten, weil das Fenster sehr klein ist, aber wahrscheinlicher, wenn das Netzwerk langsam ist und das Herstellen der Verbindung einige Zeit dauert, wie dies bei Overlay-Netzwerken, insbesondere I2P, der Fall sein könnte.