Profundizando en el mensaje de depuración: "desconexión del control de inundaciones del receptáculo del zócalo (x bytes)"

Configuro lo siguiente cuando ejecuto bitcoind -debug -server -detachdb -printtodebugger -printtoconsole

Registro de depuración

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

Pregunta

¿Qué acciones del cliente harían que apareciera esta entrada?

¿Qué configuraciones (del lado del cliente o del lado del servidor) están disponibles para ajustar esto para una mayor o menor capacidad?

¿Qué efectos secundarios hay al ajustar esta capacidad (bloqueos de semáforos, contención de db, etc.)

Respuestas (1)

En el protocolo Bitcoin, cada mensaje tiene como prefijo un encabezado de mensaje que, entre otras cosas, contiene la longitud del mensaje (más precisamente, la longitud de la carga útil). El campo de longitud es un entero sin signo de 4 bytes (o 32 bits) de longitud. Por lo tanto, está perfectamente bien especificar cargas útiles de longitud 2^32 bytes = 4 GB.

Dado que no querría descargar 4 GB solo para descubrir que se trataba de un error en la implementación de los otros lados o que el par intentaba enviarle basura a propósito, el cliente principal agregó un límite arbitrario al tamaño de los mensajes que acepta.

Según net.h este límite es de 5'000'000 bytes o un poco menos de 5 megabytes. El mensaje que causó el error y la posterior desconexión está un poco por encima de ese límite. Tal vez podría buscar qué pares, o incluso mejor, qué versión de cliente causó el error para que podamos informar a los desarrolladores al respecto.