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). |
||
|---|---|---|
| .. | ||
| compiler | ||
| config | ||
| consensus | ||
| core | ||
| crypto | ||
| encoding | ||
| interop | ||
| io | ||
| neorpc | ||
| neotest | ||
| network | ||
| rpcclient | ||
| services | ||
| smartcontract | ||
| util | ||
| vm | ||
| wallet | ||