On Tue, May 28, 2002 at 01:49:45PM -0600, David Waite wrote: > Are you thinking of having an explicit heartbeat required for clients to > send over the network socket? I'm not sure if I agree with circumventing > the TCP timeout with application logic or not - it seems like just > giving a delivery error once the socket closes would be a better > long-term solution.
The problem is, that the socket is not closed on a hard physical disconnect (in some conditions). If no TCP RST Packet (because of a rebooted machione or a new client with the old ip) or ICMP Error (i.e. no route to destination from dialup server) is generated, TCP will happyly retransmit packets for minutes. It is even worse on the client side, if the client does not send anything to the server, expecting the server to send news. The client socket is alive, the server socket is reset. since the server does not tell the client so, your client wont noticve that he is dead. A TCP ping is one thing, to detect reset sockets which are idle. On IRC for example in addition to the ping, there is also a pong message required within a (configurable time frame). The server will simply disconnect the connection of no repsonse is received. this requires a echo protocol function but is IMHO quite important. Clients could even be so smart and ping the server and measure roundtrip or connect resets sthemself. Greetings Bernd _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
