Beim Durchgehen konnte main.cppich den Zweck einer doppelten Barriere, die als if-Anweisungen codiert ist, nicht ganz verstehen:
Ich beziehe mich auf ...
if (pto->setInventoryKnown.count(inv))
und
if (pto->setInventoryKnown.insert(inv).second)
Was ist die Idee hinter der Überprüfung, ob ein Inventar dem Ziel-Peer zweimal bekannt ist?
Mir ist bewusst, dass if (pto->setInventoryKnown.count(inv))nur überprüft wird, ob der Eintrag dem Zielpeer bekannt ist, und if (pto->setInventoryKnown.insert(inv).second)das Inventarelement eingefügt wird, nachdem seine Eindeutigkeit überprüft wurde.
Ich meine, könnte man nicht einfach nur eine if-Anweisung kombinieren?
ifAuch für die zweite Aussage sehe ich keinen Grund . Ich spreche hier nicht von irgendeiner Form von Autorität, aber es sieht für mich wie ein (winziger) Effizienzfehler aus.
Die zweite ifAnweisung gibt es seit dem ersten Commit . Die erste ifAnweisung wurde etwa ein Jahr später eingefügt, als "Trickling" von tx-Inv-Nachrichten hinzugefügt wurde, vermutlich um die Set-Mitgliedschaft früher zu überprüfen, um zu vermeiden, dass die Trickling-Logik durchlaufen wird, wenn dies nicht erforderlich ist. Ich würde vermuten, dass das Entfernen des zweiten ifeinfach übersehen wurde.
Ich bin mir nicht sicher, ob das 2. if nutzlos ist.
Das zweite if führt eine detailliertere Prüfung durch (siehe mruset.hL50 https://github.com/bitcoin/bitcoin/blob/3fce72eaa3ea75aa911e32c4d96313848338cede/src/mruset.h#L51 ), was meiner Meinung nach die Größe des Sets reduziert usw.
Christopher Gurnee
true. Muss meine Antwort aktualisiert werden?Jonas Schnelli