Lors de l’exécution d’une async_write avec un socket TCP, quand le gestionnaire est-il appelé?

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:

  • Toute la séquence de mémoire tampon a été écrite dans le stream.
  • L’opération a été annulée. Par exemple. socket_.cancel() .
  • Une erreur se produit. Par exemple, le sharepoint terminaison distant ferme son socket.

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:

  1. async_write opération 1 est terminée.
  2. le gestionnaire de l’opération 1 invoqué.
  3. async_write opération 2 est terminée.
  4. le gestionnaire de l’opération 2 invoqué.
  1. async_write opération 1 est terminée.
  2. async_write opération 2 est terminée.
  3. le gestionnaire de l’opération 1 invoqué.
  4. le gestionnaire de l’opération 2 invoqué.
  1. async_write opération 1 est terminée.
  2. async_write opération 2 est terminée.
  3. le gestionnaire de l’opération 2 invoqué.
  4. le gestionnaire de l’opération 1 invoqué.

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.