forked from TrueCloudLab/neoneo-go
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 | ||