Date: Fri, 17 Mar 1995 19:59:16 -0600 From: Peter da Silva <peter@bonkers.taronga.com> To: terry@cs.weber.edu (Terry Lambert) Cc: hackers@FreeBSD.org Subject: Re: Batch Telnet (Re: diskless and 3Com 509) Message-ID: <199503180159.TAA02509@bonkers.taronga.com> In-Reply-To: Your message of "Fri, 17 Mar 95 09:09:39 MST." <9503171609.AA28800@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503180159.TAA02509>