Angus Robertson - Magenta Systems Ltd wrote: >> The only reliable way to detect a broken connection is to send or >> receive something. Then if the connection is gone OnSessionClosed >> will fire, and from there start your timer to reconnect. > > That is what the keep alive options do presumably, on an idle > connection, if keep alive fails the session then fails and retries > can commence.
IMO the socket keep alive feature makes more trouble than good. Both client and server must support it and keep alive packets might not be routed. Sending some custom keep alive data in intervals works more reliable IMO. However I wonder why one has to detect a brocken, idle connection at all? For example, unplugging the network cable while the connection is idle would not cause a socket close event being fired and after the cable has been plugged in again the connection continues as if nothing happend. Polling for connection alive, in almost all cases, is bad design IMO. It doesn't prevent you from handling an error due to a brocken connection at the time when something is actually sent or received. It's like polling for a file exists in intervalls doesn't guarantee that the file is accessible unless an attempt is made to open it for read or write. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
