Date: Fri, 17 Mar 1995 10:58:46 -0500 From: "Charles M. Hannum" <mycroft@ai.mit.edu> To: terry@cs.weber.edu Cc: tech-net@NetBSD.ORG Subject: Re: Batch Telnet (Re: diskless and 3Com 509) Message-ID: <199503171558.KAA27534@duality.gnu.ai.mit.edu>
next in thread | raw e-mail | index | archive | help
The problem is in the server, not the client. That's incorrect. The close should be queued by the remote server only after the remote server has recieved confirmation that the packets have arrived at the client. By default, this is not how things work with sockets. That's analogous to stating that Berkeley TCP does not implement TCP correctly. At least in this case, that's not true. The problem is that the client is closing the connection. If the telnet client's stdin gets an EOF, one might expect it should at most close the write side of the TCP connection (i.e. use the shutdown(2) system call). With a more reasonable protocol, you'd expect the half-close to be propagated to the server, and the server would notice it and shut down if appropriate. However, TCP doesn't have a half-close mechanism. The telnet client should at least have an option to not shut down if it gets EOF from stdin. It's not clear to me whether or not that should be the default.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503171558.KAA27534>