Wie ich im Bitcoin-Code sehen kann, sendet derzeit ein Node einen Block parallel an alle seine Peers. Dies ist sinnvoll, da die Block-Sendezeit im Vergleich zur P2P-Latenz relativ klein ist. Meine Frage ist jedoch, wie dieser Mechanismus vor BIP152 funktionierte, als ein Peer einen 1-MB-Block senden musste. In diesem Fall ist es sinnvoller, den Block zuerst an 1 Peer zu senden, bevor Sie mit dem Senden an die anderen beginnen. Dies liegt daran, dass wir seine Upload-Bandbreite schneller nutzen, wenn wir den Block an den ersten Peer gesendet haben.
Es ist nicht so einfach wie "sequenziell senden" oder "parallel senden". Jede Verbindung ist ein eigener Socket und der Kernel führt die Paketplanung durch. Das Bitcoin-Protokoll hat keine Bestätigung. Wenn ein Knoten eine Nachricht sendet, übergibt er sie an den TCP-Stack, der oft sofort die gesamte Nachricht akzeptiert. Es ist dann Sache des Kernels, es auszusenden.
In gewisser Hinsicht ist es also nicht einmal wirklich möglich, es ohne eine Art massives Redesign "sequenziell" zu senden, aber es wäre auch nicht allgemein wünschenswert, dies zu tun: TCP sendet nicht mehr als das aktuelle Empfangsfenster, ohne ein zu erhalten Wissen. Wenn Sie also warten würden, bis TCP alle Daten an einen Peer gesendet hat, bevor Sie mit dem Senden des nächsten beginnen, würden Sie feststellen, dass Sie einen Teil der Zeit damit verbringen würden, nichts zu senden. Sie würden auch die Anfälligkeit für Tarpit-Angriffe erhöhen, bei denen ein bösartiger Peer den Empfang absichtlich verlangsamt, um die Ausbreitung an alle anderen zu verzögern.
Bitcoin ist also immer die Peer-Liste durchgegangen und hat alles, was es zu senden hatte, an jeden Peer übergeben, wobei es dem Kernel überlassen wurde, die Pakete zu planen. In der Vergangenheit wurde vorgeschlagen, es nur einigen wenigen zu geben und dann darauf zu warten, dass sie es bekommen, bevor sie den Rest treffen, aber es ist nicht offensichtlich, wie Tarpits robust verhindert werden können, und BIP152 stellt die Frage weitgehend zur Debatte.
Amaclin
Murch