Блокировка широковещательной рассылки – незапрашиваемая блокировка

Может кто-нибудь, пожалуйста, направить меня к разделу(ам) исходного кода, относящемуся к незапрошенной блокировке , как описано в Руководстве разработчика биткойнов ?

Я просматривал main.cppи искал термин MSG_BLOCK , служащий биглем для поиска правильного места в коде.
Но по мере того, как я читаю дальше, мне кажется, что только что добытый блок не добавляется к сообщению инвентаризации с помощью MSG_BLOCK , чтобы отправить его как «пакет» в качестве ответа на запрос (GetData Response) , НО есть отправляется как одно сообщение такой структуры:

изображение представляет собой обрезанную версию en-ibd-block.svg из Руководства разработчика биткойнов.

Для меня до сих пор лучшим кандидатом для незапрашиваемой блокировки блоков , кажется, является часть main.cpp#L2393main.cpp , но я сбит с толку, так как не знаю, есть ли еще, возможно, релевантный код (например, main.cpp#L3830 ) для незапрашиваемой вставки блока/src/ .

Итак: на первом этапе я ищу код, который подходит для трансляции только что найденного блока. Может кто-нибудь помочь?

Ответы (1)

Мы можем найти все экземпляры в коде, где клиент будет отправлять blockсообщение, выполнив поиск PushMessage("block". Это единственное совпадение:

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

(Источник.)

Это означает, что стандартный клиент отправляет сообщение о блокировке только тогда, когда его специально запрашивают. Это входящее getdataсообщение, вероятно, инициируется, в свою очередь, отправкой invсообщения удаленному узлу. (Хотя в этом нет необходимости — вы можете запросить блок, который другой узел не анонсировал.) Это код, который отправляет сообщения инвентаризации:

//
// 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);

(Источник.)

(pto представляет удаленный узел в приведенном выше коде.)

Таким образом, страница, на которую вы смотрите, описывает поведение, которое вы могли бы реализовать и которое примут другие клиенты, но не описывает текущее основное поведение клиента.

«описывает поведение, которое вы могли бы реализовать и которое примут другие клиенты, но не описывает текущее основное поведение клиента». Я написал документы, указанные выше, и не понял, что это не очевидно. Извини. В ближайшее время он должен быть обновлен: github.com/bitcoin/bitcoin.org/commit/…
@DavidA.Harding Это было быстро. :)
@NickODell: Спасибо, Ник! Одно до сих пор не совсем ясно. Вы говорите: « Это означает, что стандартный клиент всегда отправляет сообщение о блокировке только тогда, когда его специально запрашивают. Это входящее сообщение getdata, вероятно, инициируется, в свою очередь, отправкой удаленному узлу сообщения inv ». — означает ли это: (1) node1 & node2 оба находятся на высоте n в общей активной цепочке (2) node1 быстрее и находит блок n+1 и помещает его в сообщение inv и отправляет это сообщение inv на node2 и получает сообщение getdata от node2 с запросом блока n +1 (3) node1 отправляет одноблочное сообщение с блоком n+1 ?
@AliakbarAhmadi Да.
@NickODell: Хорошо, но в каком случае незапрашиваемое одноблочное сообщение будет передано одноранговым узлам??? Никогда? Отправляется ли только что добытый блок без запроса только внутри inv-сообщения?
@AliakbarAhmadi Никогда. Если вы не измените свой клиент.
Блокировка широковещательной рассылки – незапрашиваемая блокировка
СпросиСетьПолитика конфиденциальности1y, 0v