From owner-freebsd-hackers Fri Mar 17 09:59:43 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA02911 for hackers-outgoing; Fri, 17 Mar 1995 09:59:43 -0800 Received: from duality.gnu.ai.mit.edu (!#$%^&*!#$%^&*!#$%^&*!#$%^&*!#$%^&*!#$%^&*!#$%^&*!#$%^&*!#$%^&*!#$%^&*!#$%^&*!#$%^&*@duality.gnu.ai.mit.edu [18.43.0.236]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA02865 for ; Fri, 17 Mar 1995 09:59:42 -0800 Received: (from mycroft@localhost) by duality.gnu.ai.mit.edu (8.6.10/8.6.10) id KAA27534; Fri, 17 Mar 1995 10:58:46 -0500 Date: Fri, 17 Mar 1995 10:58:46 -0500 Message-Id: <199503171558.KAA27534@duality.gnu.ai.mit.edu> From: "Charles M. Hannum" To: terry@cs.weber.edu Cc: peter@bonkers.taronga.com, hackers@FreeBSD.org Cc: tech-net@NetBSD.ORG Subject: Re: Batch Telnet (Re: diskless and 3Com 509) Sender: hackers-owner@FreeBSD.org Precedence: bulk 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.