boost :: asio :: in TCP-Client-App lesen dauert lange Zeit, wenn Konnektivität verloren geht

Question

Ich habe versucht, dies viel zu suchen. Ich bin neu in network+tcp-sockets Programmierung.

Ich verwende TCP sockets, um Daten über das Netzwerk zu kommunizieren. Ich habe ein host app & ein client app sowohl in geschrieben C++ & Verwendung boost::asio an beiden Enden Daten zu kommunizieren.

In der client app verwende ich boost::asio::read, um einige Daten aus einer socket in meiner C++ - Client-Anwendung zu lesen. Die Hostanwendung wird auf einem anderen Computer ausgeführt.

Folgendes ist der Code, wo ich einige Daten lesen & versuchen, festzustellen, ob es Fehler gibt.

boost::system::error_code error_code; 
std::size_t data_received = boost::asio::read(socket, boost::asio::buffer(&data_to_read, sizeof(data_to_read)), error_code); 
if (error_code == boost::asio::error::eof) { 
    //ends here if the host app closes the socket 
    //log error & return 
} 

if (data_received <= 0) { 
    //log error & return 
} 

Ich erhalte eine boost::asio::error::eof wenn Host App die Socket geschlossen und es funktioniert meine UI aktualisieren zu zeigen, dass ich die Verbindung verloren haben.

Aber hier ist das Problem: Wenn die network/wifi in der Host-App geht dann dauert boost::asio::read eine lange Zeit, um zurückzukehren. So etwas wie 2 Minuten. Dann bekomme ich nach langer Zeit einen boost::asio::error::eof Fehler. Seltsam ! Ich kann mir diese Latenz nicht leisten, da ich für den Benutzer schnell aktualisieren muss, dass Daten nicht aus der host app abgerufen werden konnten.

Warum kehrt asio nicht schnell zurück, wenn das Netzwerk ausgeschaltet oder die Verbindung unterbrochen ist? Gibt es eine andere Möglichkeit, dies zu erkennen oder damit umzugehen?

PS: Beachten Sie, dass boost::asio::read ein blockierenden Aufruf ist aber nicht gesperrt mein UI-Thread, wenn es Zeit braucht, zurückzukehren, weil ich dies in einem worker thread tue.

Answer 1

TCP ist so konzipiert, dass es selbst bei scheinbar katastrophalen Problemen "zuverlässig" ist. Dies geschieht mit einer Reihe von Timern und erneuten Übertragungen, wenn das andere Ende einer Verbindung nicht antwortet. Wie oft und wie lange die Neuübertragungen stattfinden, hängt vom Betriebssystem ab. Es kann Minuten oder sogar Stunden dauern, bevor eine Verbindung gemeldet wird.

Interne Sockets haben eine Gruppe von Optionen, um Keep Alive-Einstellungen zu steuern, die Sie auf den Socket setzen können (wenn boost :: asio diese verfügbar macht). Eine schnelle Google-Suche nach "tcp keepalive" brachte eine Reihe von Beispielen.

Eine andere Möglichkeit ist es, einen eigenen Zeitmechanismus zu implementieren, in dem Sie ständig Pakete & Antworten über die TCP-Verbindung senden & definieren Sie sich, was das richtige Timing sein sollte.