Date: Fri, 17 Mar 95 9:09:39 MST From: terry@cs.weber.edu (Terry Lambert) To: peter@bonkers.taronga.com (Peter da Silva) Cc: hackers@FreeBSD.org Subject: Re: Batch Telnet (Re: diskless and 3Com 509) Message-ID: <9503171609.AA28800@cs.weber.edu> In-Reply-To: <199503170133.TAA08481@bonkers.taronga.com> from "Peter da Silva" at Mar 16, 95 07:33:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It is not a question of the telnet waiting for the other side to flush > > output before going away. It is a question of the telnetd (in your > > example, the nntpd) waiting for the output to be flushed to your > > machine before sending the disconnect. > > > The problem is in the server, not the client. > > *really*? That's surprising... I'm sure I did the same thing from System V > to the same client program. > > Especially when the following works: > > (echo LIST; echo QUIT; sleep 600000) | telnet localhost nntp > > I don't see how *server* side behaviour can explain this. You are implying that what Julian has suggested is the case? OK, I admit the remote possibility of this happening in a monolithic non-streams TCP implementation. I think it more likely that the close is being prematurely sent by the server, even in this case, and causing the "problem" on the client to be tickled. After all, how does one determine if the disconnect on the client side resulted from a server request or a link timeout? Now lets address the real issue, which is you shouldn't be sending the QUIT until you have the data back anyway. Use "expect" to run your telnet in a pty and don't send the QUIT until you have received your results. Quit trying to "type ahead"; you aren't guaranteed that the remote NNTP has a type ahead buffer anyway. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503171609.AA28800>