May 30, 2018

@Mlmikael The important problem scenarios are (1) creation of a large backlog of work, essentially allowing a peer to create a memory exhaustion failure, and (2) thread starvation, where slow peers can monopolize the set of available logical threads. Message backlogging is mitigated by not subscribing to read a new message until the previous is handled. Some messages are currently “handled” by buffering them. Others (tx, block, ping...) are not. This is configured in the message subscriber. So small messages could create an overflow. We will likely move all message handling to unbuffered in v4. Peers that are slow to accept a message will delay ping processing, resulting in a dropped peer. The limit is configurable. However message send is asynchronous, so no network thread is held up by a slow peer.