Adresse déjà utilisée avec boost asio acceptor

Question

J'ai écrit un serveur qui écoute les connexions TCP entrantes et les clients qui s'y connectent. Lorsque j'arrête le serveur et le redémarre sur le même port, il m'arrive d'obtenir le message d'erreur EADDRINUSE lors de l'appel de bind (...) (code d'erreur: 98 sous Linux). Cela se produit même si je définis l'option pour réutiliser le socket.

L'erreur ne se produit pas tout le temps, mais il semble que cela arrive plus souvent lorsque les clients sont connectés au serveur et qu'ils envoient des données pendant l'arrêt. Je suppose que le problème est qu'il existe toujours des connexions en attente lorsque le serveur est arrêté (sujet connexe: https://stackoverflow.com/questions/41602/how-to-forcibly-close-a-socket-in-time-wait). Côté serveur, j'utilise boost :: asio :: ip :: tcp :: acceptor. Je l'initialise avec l'option "reuse_address" (voir http://beta.boost.org/doc/libs/1_38_0/doc/html/boost_asio/reference/basic_socket_acceptor.html). Voici l'extrait de code:

using boost::asio::ip::tcp; 
acceptor acceptor::acceptor(io_service); 
endpoint ep(ip::tcp::v4(), port); 
acceptor.open(ep.protocol()); 
acceptor.set_option(acceptor::reuse_address(true)); 
acceptor.bind(ep); 
acceptor.listen(); 

L'accepteur est fermée avec:

acceptor.close(); 

J'ai essayé également d'utiliser acceptor.cancel() avant, mais il avait le même effet. Lorsque cette erreur s'est produite, je ne peux pas redémarrer le serveur sur le même port pendant un certain temps. Redémarrer le réseau aide, mais n'est pas une solution permanente.

Qu'est-ce qui me manque?

Toute aide serait grandement appréciée! :)

Answer 1

C'étaient à l'origine un commentaire à la question.

---

votre serveur fork fork traite-t-il? Aussi, êtes-vous sûr que le socket est dans l'état TIME_WAIT? Vous pouvez saisir la sortie netstat -ap lorsque cela se produit

Answer 2

Lorsque vous résolvez ces problèmes "par la force", il semble que vous appelez des problèmes sur votre tête, n'est-ce pas?

Il y a une raison pour laquelle le comportement par défaut vous oblige à attendre, sinon le réseau pourrait par exemple confondre le ACK de la connexion précédente avec ACK pour la nouvelle connexion.

Je ne permettrais pas que cette "solution" soit incluse dans les versions de version de mon équipe. Rappelez-vous, lorsque la probabilité d'erreur est très faible, le test est extrêmement difficile!