Block Broadcasting – Unaufgeforderter Block-Push

Kann mich bitte jemand zu den Quellcode-Abschnitten verweisen, die für einen unaufgeforderten Block-Push relevant sind, wie im Bitcoin-Entwicklerhandbuch beschrieben ?

Ich habe den Begriff MSG_BLOCKmain.cpp durchgesehen und gesucht , der als Beagle dient, um die richtige Stelle im Code zu finden. Aber beim Weiterlesen kommt es mir so vor, als ob ein frisch geschürfter Block nicht an eine Inventory-Nachricht angehängt wird, mit MSG_BLOCK , um ihn als „Paket“ als Antwort auf eine Anfrage (GetData Response) zu versenden, ABER als einzelne Nachricht dieser Struktur gesendet:

image ist eine beschnittene Version von en-ibd-block.svg aus dem Bitcoin Developer Guide

Für mich scheint der beste Kandidat für Unsolicited Block Push bis jetzt main.cpp#L2393 zu sein, main.cppaber ich bin verwirrt, da ich nicht weiß, ob es mehr von möglicherweise relevantem Code gibt (wie main.cpp#L3830 ) für unaufgefordertes Block-Push- in /src/.

Also: In einem ersten Schritt suche ich nach Code, der für das Broadcasten eines neu gefundenen Blocks relevant ist. Kann jemand bitte helfen?

Antworten (1)

Wir können alle Fälle im Code finden, in denen der Client eine blockNachricht sendet, indem wir nach suchen PushMessage("block". Dies ist die einzige Übereinstimmung:

void static ProcessGetData(CNode* pfrom)
{
[...]
    pfrom->PushMessage("block", block);

(Quelle.)

Das bedeutet, dass der Standard-Client immer nur dann eine Sperrnachricht sendet, wenn er ausdrücklich danach gefragt wird. Diese eingehende getdataNachricht wird wahrscheinlich ihrerseits dadurch ausgelöst, dass dem entfernten Knoten eine invNachricht gesendet wird. (Obwohl das nicht notwendig ist – Sie können nach einem Block fragen, den der andere Knoten nicht angekündigt hat.) Dies ist der Code, der Bestandsmeldungen sendet:

//
// Message: inventory
//
vector<CInv> vInv;
vector<CInv> vInvWait;
{
    LOCK(pto->cs_inventory);
    vInv.reserve(pto->vInventoryToSend.size());
    vInvWait.reserve(pto->vInventoryToSend.size());
    BOOST_FOREACH(const CInv& inv, pto->vInventoryToSend)
    {
        // If the other node already knows the message, don't send
        if (pto->setInventoryKnown.count(inv))
            continue;

        // trickle out tx inv to protect privacy
        [...]

        // returns true if remote node hasn't seen it
        if (pto->setInventoryKnown.insert(inv).second)
        {
            // Add to the list of inventory messages to send
            vInv.push_back(inv);
            // If there's 1000 inventory messages queued up, send them
            // (Protocol limit is 50000 at a time.)
            if (vInv.size() >= 1000)
            {
                pto->PushMessage("inv", vInv);
                vInv.clear();
            }
        }
    }
    pto->vInventoryToSend = vInvWait;
}
// Send any that are left over.
if (!vInv.empty())
    pto->PushMessage("inv", vInv);

(Quelle.)

(pto steht für den Remote-Knoten im obigen Code.)

Die Seite, die Sie sich ansehen, beschreibt also ein Verhalten, das Sie implementieren könnten und das andere Clients akzeptieren werden, aber es beschreibt nicht das aktuelle Kernverhalten des Clients.

"beschreibt ein Verhalten, das Sie implementieren könnten und das andere Clients akzeptieren werden, aber es beschreibt nicht das aktuelle Kernverhalten des Clients." Ich habe die oben verlinkten Dokumente geschrieben, und mir war nicht klar, dass dies nicht offensichtlich war. Verzeihung. Es sollte in Kürze aktualisiert werden: github.com/bitcoin/bitcoin.org/commit/…
@DavidA.Harding Das ging schnell. :)
@NickODell: Danke, Nick! Eines ist noch nicht ganz klar. Sie sagen: " Das bedeutet, dass der Standard-Client immer nur dann eine Block-Nachricht sendet, wenn er ausdrücklich danach gefragt wird. Diese eingehende getdata-Nachricht wird wahrscheinlich wiederum dadurch ausgelöst, dass der entfernte Knoten eine inv-Nachricht sendet. " - bedeutet dies: (1) Knoten1 & node2 befinden sich beide auf Höhe n in einer gemeinsamen aktiven Kette (2) node1 ist schneller und findet einen Block n+1 und schiebt ihn in eine inv-Nachricht und sendet diese inv-Nachricht an node2 und erhält eine getdata-Nachricht von node2, die nach Block n fragt +1 (3) Knoten1 sendet eine einzelne Blocknachricht mit Block n+1 ?
@AliakbarAhmadi Ja.
@NickODell: Ok, aber in welchem ​​Fall wird dann eine unaufgeforderte Einzelblocknachricht an Peers gesendet??? Niemals? Wird ein frisch abgebauter Block unaufgefordert nur innerhalb einer Inv-Nachricht gesendet?
@AliakbarAhmadi Niemals. Es sei denn, Sie ändern Ihren Client.
Block Broadcasting – Unaufgeforderter Block-Push
AntwortenHierDatenschutz-Bestimmungen1y, 0v