Esta pregunta es el resultado de otras dos preguntas que hice en los últimos días.
Estoy creando una nueva pregunta porque creo que está relacionada con el "siguiente paso" en mi comprensión de cómo controlar el flujo de mi envío / recepción, algo de lo que aún no obtuve una respuesta completa.
Las otras preguntas relacionadas son:
Una pregunta de interpretación de documentación de IOCP: ambigüedad de la propiedad del búfer
Problemas de búfer TCP sin bloqueo

En resumen, estoy usando los puertos de finalización de E / S de Windows.
Tengo varios hilos que procesan notificaciones desde el puerto de finalización.
Creo que la pregunta es independiente de la plataforma y tendría la misma respuesta que si hiciera lo mismo en un sistema Solaris * nix, * BSD.

Entonces, necesito tener mi propio sistema de control de flujo. Multa.
Entonces envío enviar y enviar, mucho.¿Cómo sé cuándo comenzar a poner en cola los envíos, ya que el lado del receptor está limitado a la cantidad X?

Tomemos un ejemplo (lo más parecido a mi pregunta): protocolo FTP.
Tengo dos servidores; Uno está en un enlace de 100Mb y el otro está en un enlace de 10Mb.
Ordeno que el de 100Mb envíe al otro (el vinculado de 10Mb) un archivo de 1GB. Termina con una velocidad de transferencia promedio de 1.25MB / s.
¿Cómo sabía el remitente (el vinculado de 100Mb) cuándo retener el envío, para que el más lento no se inundara? (En este caso, la cola "a enviar" es el archivo real en el disco duro).

Otra forma de preguntar esto:
¿Puedo recibir una notificación de "retener sus envíos" desde el lado remoto? ¿Está incorporado en TCP o el llamado "protocolo de red confiable" necesita que lo haga?

Por supuesto, podría limitar mis envíos a un número fijo de bytes, pero eso simplemente no me parece correcto.

Nuevamente, tengo un bucle con muchos envíos a un servidor remoto, y en algún momento, dentro de ese bucle, tendré que determinar si debo poner en cola ese envío o si puedo pasarlo a la capa de transporte (TCP).
¿Cómo puedo hacer eso? ¿Qué harías? Por supuesto, cuando reciba una notificación de finalización de IOCP de que el envío se realizó, emitiré otros envíos pendientes, eso está claro.

Otra pregunta de diseño relacionada con esto:
Dado que debo usar un búfer personalizado con una cola de envío, y estos búferes se pueden liberar para volver a usarlos (por lo tanto, no usar la palabra clave "eliminar") cuando llegue una notificación de "envío hecho", tendré que usar una exclusión mutua en ese grupo de búferes.
Usar un mutex ralentiza las cosas, así que he estado pensando; ¿Por qué no hacer que cada subproceso tenga su propio grupo de búferes? Por lo tanto, acceder a él, al menos al obtener los búferes necesarios para una operación de envío, no requerirá mutex, ya que solo pertenece a ese hilo.
El grupo de búferes se encuentra en el nivel de almacenamiento local de hebras (TLS).
Ningún grupo mutuo implica que no se necesita bloqueo, implica operaciones más rápidas PERO también implica más memoria utilizada por la aplicación, porque incluso si un hilo ya asignó 1000 buffers, el otro que está enviando en este momento y necesita 1000 buffers para enviar algo tendrá que asignarse estos a lo suyo.

Otro problema:
Digamos que tengo buffers A, B, C en la cola "para ser enviado".
Luego recibo una notificación de finalización que me dice que el receptor obtuvo 10 de 15 bytes. ¿Debo volver a enviar desde el desplazamiento relativo del búfer, o TCP lo manejará por mí, es decir, completar el envío? Y si debo, ¿puedo estar seguro de que este búfer es el "próximo en ser enviado" en la cola o podría ser el búfer B, por ejemplo?

Esta es una pregunta larga y espero que nadie salga lastimado (:

Me encantaría ver que alguien se toma el tiempo de responder aquí. ¡Prometo que votaré por él dos veces! (:
¡Gracias a todos!