Como puedo ver en el código de Bitcoin, actualmente un nodo envía un bloque en paralelo a todos sus pares. Esto tiene sentido ya que el tiempo de envío de bloques es relativamente pequeño en comparación con la latencia P2P. Sin embargo, mi pregunta es cómo funcionaba este mecanismo antes de BIP152 cuando un compañero tenía que enviar un bloque de 1 MB. En ese caso, tiene más sentido enviar el bloque primero a 1 compañero antes de comenzar a enviarlo a los demás. Esto se debe a que si terminamos de enviar el bloque al primer par, utilizaremos su ancho de banda de carga más rápido.
No es tan simple como "enviar secuencialmente" o "enviar en paralelo". Cada conexión es su propio socket y el núcleo realiza la programación de paquetes. El protocolo Bitcoin no tiene ningún reconocimiento. Cuando un nodo envía un mensaje, lo entrega a la pila TCP, que a menudo acepta inmediatamente el mensaje completo. Entonces depende del kernel enviarlo.
Entonces, en cierto sentido, ni siquiera es realmente posible enviarlo 'secuencialmente' sin algún tipo de rediseño masivo, pero tampoco sería deseable hacerlo: TCP no enviará más que la ventana de recepción actual sin obtener un Reconocimiento. Entonces, si tuviera que esperar hasta que TCP haya enviado todos los datos a un par antes de comenzar a enviar el siguiente, se encontraría esperando sin enviar nada parte del tiempo. También aumentaría la exposición a los ataques tarpit, donde un compañero malicioso ralentiza intencionalmente la recepción para retrasar la propagación a todos los demás.
Entonces, Bitcoin siempre revisó la lista de pares y entregó todo lo que tenía que enviar a cada par, dejando que el núcleo programe los paquetes. Se ha propuesto en el pasado entregarlo solo a unos pocos y luego esperar a que lo obtengan antes de atacar al resto, pero no es obvio cómo prevenir los tarpits de manera sólida, y BIP152 en gran medida discutible la pregunta.
amaclin
muro