e1b5ac9b81
This allows to naturally scale transaction processing if we have some peer that is sending a lot of them while others are mostly silent. It also can help somewhat in the event we have 50 peers that all send transactions. 4+1 scenario benefits a lot from it, while 7+2 slows down a little. Delayed scenarios don't care. Surprisingly, this also makes disconnects (#2744) much more rare, 4-node scenario almost never sees it now. Most probably this is the case where peers affect each other a lot, single-threaded transaction receiver can be slow enough to trigger some timeout in getdata handler of its peer (because it tries to push a number of replies). |
||
---|---|---|
.. | ||
capability | ||
extpool | ||
payload | ||
blockqueue.go | ||
blockqueue_test.go | ||
compress.go | ||
discovery.go | ||
discovery_test.go | ||
fuzz_test.go | ||
helper_test.go | ||
message.go | ||
message_string.go | ||
message_test.go | ||
notary_feer.go | ||
peer.go | ||
prometheus.go | ||
server.go | ||
server_config.go | ||
server_test.go | ||
state_sync.go | ||
tcp_peer.go | ||
tcp_peer_test.go | ||
tcp_transport.go | ||
transport.go |