<p>In the <a href="https://en.bitcoin.it/wiki/Protocol_specification#Message_structure" rel="nofollow">Bitcoin protocol</a> 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.</p>

<p>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.</p>

<p>According to <a href="https://github.com/bitcoin/bitcoin/blob/master/src/net.h#L29" rel="nofollow">net.h</a> 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.</p>

CC BY-SA 3.0
2013-01-06T12:46:56.247Z
2013-01-06T12:46:56.247Z
cdecker
<p>I set the following when I run <code>
bitcoind -debug -server -detachdb -printtodebugger -printtoconsole</code></p>

<p><strong>Debug.log</strong></p>

<pre><code>socket recv flood control disconnect (5018020 bytes)
disconnecting node 82.41.255.68:8333
</code></pre>

<p><strong>Question</strong></p>

<p>What client actions would cause this entry to appear?</p>

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

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

<bitcoind><bitcoin-core><server><throttling>
Digging into debug message: "socket recv flood control disconnect (x bytes) "
makerofthings7
# Digging into debug message: "socket recv flood control disconnect (x bytes) "

(Asked by: username_0 on 2012-12-09)

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)

**Tags:** bitcoind, bitcoin-core, server, throttling


---

## 1 answers

### Answer by username_1 on 2013-01-06. Score: 1 | Accepted answer

In the [Bitcoin protocol](https://en.bitcoin.it/wiki/Protocol_specification#Message_structure) 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](https://github.com/bitcoin/bitcoin/blob/master/src/net.h#L29) 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.


---

