jmh@ns.network.com (1606) (05/24/89)
Given that most extended networks are not 100% reliable, some form of keepalive is needed to detect loss of connectivity. If I have a telnet connection to a host, and then the network fails, I would appreciate it if the remote host knew this and could undertake appropriate cleanup activities. The key question is how often KeepAlive signals should be sent, and what interval without any should result in declaring the connection dead. As a separate issue, the TCP implementation of keepalive signals is sufficiently confused and inconsistent as to make it an undeirable solution to the problem. Joel M. Halpern Network Systems Corporation jmh@nsco.network.com
phil@ux1.cso.uiuc.edu (05/25/89)
> If I have a telnet connection to a host, and then the network fails, > I would appreciate it if the remote host knew this and could > undertake appropriate cleanup activities. Perhaps what might be needed is a RAYT (Reverse Are You There) command, which is sent from server to client, and the client say YIAH (Yes I Am Here) back to the server. AYT already suffices the other way. --Phil howard-- <phil@ux1.cso.uiuc.edu>
louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") (05/25/89)
I suppose that if you were using a TELNET connection to a remote host, and you really cared to detect that the network failed, you could periodically have your TELNET client send TELNET NOP sequences on the connection. If the remote host crashed or the path disappeared, this would cause the otherwise idle TCP connection to start retransmitting the TELNET NOP. Of course, I really only care that the network is working or not if I'm trying to get work done. In that case, the connection isn't idle and all this is moot. Louis Mamakos Univ of Maryland
ulmo@ssyx.ucsc.edu (Brad Allen) (05/29/89)
> If I have a telnet connection to a host, and then the network fails, > I would appreciate it if the remote host knew this and could > undertake appropriate cleanup activities. Personally as a user, I would >not< appreciate it! I've lost work because of this, however the situation probably deserves explaining: I was using a CISCO terminal server, which routed packets through two other CISCO gw machines to the destination host and back. Because of a fault in the routings, the network disappeared for about 10 minutes. I certainly lost a lot more than I appreciated, and walked off mumbling things about how CISCO really OUGHT to have implemented user-settable preferences for this type of thing. (An interesting side note: the only successful routing I found to the host was manually: I telned'd to the first gw machine, then to the second, then to the destination host -- this was the only configuration which I could get to work, but it did! This thank god has since been fixed.)