From owner-freebsd-hackers Fri Mar 17 18:34:17 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA05864 for hackers-outgoing; Fri, 17 Mar 1995 18:34:17 -0800 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA05858 for ; Fri, 17 Mar 1995 18:34:13 -0800 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA26781 (5.67a/IDA-1.5); Fri, 17 Mar 1995 20:17:59 -0600 Received: by bonkers.taronga.com (smail2.5p) id AA02512; 17 Mar 95 19:59:18 CST (Fri) Received: from localhost (localhost [127.0.0.1]) by bonkers.taronga.com (8.6.8/8.6.6) with SMTP id TAA02509; Fri, 17 Mar 1995 19:59:17 -0600 Message-Id: <199503180159.TAA02509@bonkers.taronga.com> X-Authentication-Warning: bonkers.taronga.com: Host localhost didn't use HELO protocol To: terry@cs.weber.edu (Terry Lambert) Cc: hackers@FreeBSD.org Subject: Re: Batch Telnet (Re: diskless and 3Com 509) In-Reply-To: Your message of "Fri, 17 Mar 95 09:09:39 MST." <9503171609.AA28800@cs.weber.edu> X-Mailer: exmh version 1.4.1 7/21/94 Date: Fri, 17 Mar 1995 19:59:16 -0600 From: Peter da Silva Sender: hackers-owner@FreeBSD.org Precedence: bulk I don't believe the client is waiting for the server close. It's just closing the connection on the server and the data's getting thrown away into the ether. Charles Hannum's explanation of why it's doing this makes sense, though it does beg the question of what the System V implementation is doing. > Now lets address the real issue, which is you shouldn't be sending > the QUIT until you have the data back anyway. Technically, you're correct. In practice, when one has to satisfy customers of an internet service provider, the right thing to do is at least provide an option to wait for the server to close. > Quit trying to "type ahead"; you aren't guaranteed that the remote > NNTP has a type ahead buffer anyway. Since TCP provides buffering anyway (on the client side, if not on the server) I can't think of any reason why an implementation would not support it. It would have to deliberately read and discard data... an interactive session with a full pty would do that, but a simple TCP/IP server wouldn't.