Adres, który jest już używany z akceptorem asio boost

Question

Napisałem serwer, który nasłuchuje nadchodzących połączeń TCP i klientów łączących się z nim. Kiedy zamykam serwer i uruchamiam go ponownie na tym samym porcie, czasami pojawia się komunikat o błędzie EADDRINUSE podczas wywoływania bind (...) (kod błędu: 98 w systemie Linux). Dzieje się tak, mimo że ustawiam opcję ponownego użycia gniazda.

Błąd nie występuje cały czas, ale wydaje się, że zdarza się częściej, gdy klienci są połączeni z serwerem i wysyłają dane podczas zamykania. Chyba problem polega na tym, że nadal są oczekujące połączenia podczas zamykania serwera (temat powiązany: https://stackoverflow.com/questions/41602/how-to-forcibly-close-a-socket-in-time-wait).

Po stronie serwera używam boost :: asio :: ip :: tcp :: acceptor. Inicjuję go opcją "reuse_address" (patrz http://beta.boost.org/doc/libs/1_38_0/doc/html/boost_asio/reference/basic_socket_acceptor.html). Oto fragment kodu:

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(); 

Akceptor jest zamknięty:

acceptor.close(); 

Próbowałem też za pomocą acceptor.cancel() wcześniej, ale miał ten sam efekt. Kiedy wystąpił ten błąd, nie mogę ponownie uruchomić serwera na tym samym porcie przez dłuższy czas. Ponowne uruchomienie sieci pomaga, ale nie jest rozwiązaniem trwałym.

Czego mi brakuje?

Każda pomoc będzie bardzo ceniona! :)

Answer 1

To były pierwotnie komentarz do pytania.

---

czy Twoje procesy rozwidlenia podrzędnego serwera? Czy na pewno gniazdo jest w stanie TIME_WAIT? Być może zechcesz pobrać dane wyjściowe netstat -ap, gdy tak się stanie

Answer 2

Kiedy rozwiązujesz te problemy "na siłę", wydaje się, że wywołujesz problemy na głowie, prawda?

Istnieje powód, dla którego domyślne zachowanie wymaga odczekać, w przeciwnym razie sieć mogłaby na przykład pomylić ACK z poprzedniego połączenia, aby było ACK dla nowego połączenia.

Nie pozwolę, aby to "rozwiązanie" znalazło się w kompilacjach wydań w moim zespole.

Pamiętaj, że gdy prawdopodobieństwo błędu jest bardzo niskie, testowanie jest niezwykle trudne!