Ceci est juste une simple question de la façon dont async_write se comporte avec les sockets TCP. Fondamentalement, lorsque vous travaillez avec un socket TCP, le gestionnaire d’écriture est-il appelé lorsque les données sont écrites sur le socket ou lorsqu’un accusé de réception est reçu de la destination?
Autant que je sache, le gestionnaire est appelé dès que des données sont écrites dans la mémoire tampon du kernel de la socket.
Même comportement que send()
du socket BSD – il se termine lorsque le système d’exploitation dispose d’une copie des données. Ce sera avant un ACK.
La seule garantie fournie par Boost.Asio est que le gestionnaire sera appelé à la fin de l’opération. Dans le cas d’ async_write
, l’opération est considérée comme terminée lorsque l’une des conditions suivantes est remplie:
socket_.cancel()
. Une fois l’opération terminée, le gestionnaire est enregistré pour une invocation différée. Cependant, il n’est pas précisé exactement quand et l’ordre dans lequel les gestionnaires seront invoqués. Prenons le scénario dans lequel une opération async_write
a été lancée pour 2 sockets différents. Toutes les séquences suivantes sont possibles:
async_write
opération 1 est terminée. async_write
opération 2 est terminée. async_write
opération 1 est terminée. async_write
opération 2 est terminée. async_write
opération 1 est terminée. async_write
opération 2 est terminée. Je pense que vous avez besoin de protocoles de couche supérieure. Si un programme homologue distant bloque votre demande, ACK ne répond pas non plus à vos besoins.