2

I set the following when I run bitcoind -debug -server -detachdb -printtodebugger -printtoconsole

Debug.log

socket recv flood control disconnect (5018020 bytes)
disconnecting node 82.41.255.68:8333

Question

What client actions would cause this entry to appear?

What settings (client side or server side) are available to adjust this for higher or lower capacity?

What side effects are there with adjusting this capacity (semaphore lockups, db contention, etc)

makerofthings7
  • 12,656
  • 11
  • 60
  • 129

1 Answers1

1

In the Bitcoin protocol each message is prefixed with a message header that, among other things, contains the message length (more precisely the payload length). The length field is an unsigned integer 4 byte (or 32 bit) in length. Therefore it is perfectly ok to specify payloads of length 2^32 bytes = 4 GB.

Since you wouldn't want to download 4 GB just to find out that it was an error in the other sides implementation or the peer was trying to feed you junk on purpose the mainline client added an arbitrary limit to the size of messages it accepts.

According to net.h this limit is 5'000'000 byte or a bit less than 5 megabyte. The message that caused the error and subsequent disconnect is just a little bit over that limit. Maybe you could look up which peer, or even better which client version, caused the error so we can inform the developers about it.

cdecker
  • 9,319
  • 1
  • 38
  • 61