Bitcoin full node and query server

Feb 28, 2023

View in context in the libbitcoin Slack #general mirror.

evoskuil07:11
So once I've completed this optimization, I'll finish up the message broadcaster. This object presents an interesting question. A broadcast message should be serialized once for all peers, as there may be many and reserialization for each is costly. Previously we serialized for each peer. So imagine, with 10 peers, each rebroadcast tx was serialized to a buffer for each peer and each was serialized again to obtain its hash - for each peer - to obtain the network checksum. Where N is peer count, that's 2*N (vs. 1) serializations and N double hashes (vs. 0) for each broadcast tx. But our message serialization is purposely protocol version dependent, as there are cases where protocol may vary serialization. This means that each channel can potentially require independent serialization. Fortunately the need for this is limited, and we can rely on canonical serialization in most situations. So the broadcaster serializes and then pushes out the buffer (including header/checksum) to each peer for send. But a subscribing protocol may need to inspect the message, and not just forward it blindly. So the original un-serialized object is provided, as well as a buffer - both passed by shared pointer. This is basically the same as the message pump except that the subscribers are not receiving notifications on their own strand, they are receiving notifications on the singleton network strand - and each must therefore bounce over to its own strand for thread safety. But this doesn't affect the design of the broadcaster (vs. the pump). The main distinction is that, as a subscriber on an independent strand, the protocols/channel must handle completion for subscription in order to not miss messages. But since, unlike channel protocol, broadcast is best effort - this shouldn't be necessary.
(edited)