Vous ne devriez pas envoyer directement des messages TCP ACK - ceux-ci sont gérés à un niveau bas par le système d'exploitation. Je regarderais ce qui suit dans l'ordre de vraisemblance:
- Y a-t-il une optimisation facile sur le récepteur? Il est assez rare que vous puissiez vraiment remplir un tuyau réseau plus rapidement que le destinataire peut gérer les données. Assurez-vous que le récepteur a au moins deux threads: un thread d'E/S réseau et un thread de travail.
- Si le récepteur commence à paniquer, il peut envoyer un message d'accélération au serveur, ce qui fait refroidir le serveur jusqu'à ce que le récepteur le rattrape. C'est plus efficace que d'attendre un message d'accusé de réception après chaque message, mais cela nécessite que le récepteur sache quand il est environ pour tomber, ce qui peut être difficile.
- Alternativement, la chose la plus lente mais la plus fiable est d'avoir le récepteur acquitter tous les messages du serveur, un peu comme vous l'avez mentionné. Ce ne serait pas un ACK TCP, mais un message spécial dans le format de données que votre expéditeur/récepteur utilise pour comm.
Si le récepteur ne peut pas suivre, l'expéditeur bloque en écriture. Ce comportement n'est-il pas ce que vous voulez? – jdizzle
@jdizzle, c'est bon pour moi. – Benny