net: give up waiting for a message body that is never going to arrive

THIS IS THE WEDGE, and the note asking for this fix has been in the file
since Bitcoin 0.1: 'need a mechanism to give up waiting for overlong
message size error'.

ProcessMessages reads a header, finds the body has not all arrived, pushes
the header back onto the front of vRecv and breaks. Correct for a message
still in flight. For one that never completes it is permanent: every later
pass re-reads the same header and breaks in the same place, so that peer is
never parsed again for the life of the process -- no blocks, no inv, not
even its version message.

Nothing rescues it:
  - a header may claim up to 256 MB (0x10000000) and still pass
    CMessageHeader::IsValid(), so a garbage or truncated header is accepted
    and then waited on forever;
  - nLastRecv is refreshed by any byte that arrives (net.cpp), whether or
    not it parses, so the inactivity timeout that drops a silent peer never
    fires on a peer that is merely unreadable;
  - the socket stays ESTABLISHED and select() keeps offering it, so nothing
    at the socket layer notices either.

It also explains the signature that made no sense. A peer stuck before its
version message is parsed keeps nStartingHeight == -1, so a node with a full
vNodes still reports GetPeerMedianHeight() == -1 -- which is exactly what
was observed, and exactly what disabled the pool's behind-the-network gate
and let it fork.

Evidence, from two wedges captured on the pool by the watchdog:
MESSAGE-BREAK 2 ran 2014 times in the deaf window against 607 in the healthy
window before it, while blocks received went to zero and the node kept
processing miner traffic normally throughout.

Now: a peer that announces a body and does not deliver it within two minutes
is dropped, and says so in the log unconditionally. Two minutes is far
beyond any legitimate header-to-body gap and well inside
BTF_RECV_TIMEOUT_SECS.

(cherry picked from commit ca1e99288e03ac7beb2b97cf615a3255b4635d95)

0 files changed, 0 insertions, 0 deletions