Date: Thu, 16 Mar 95 17:51:09 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: <9503170051.AA26101@cs.weber.edu> In-Reply-To: <199503161801.MAA00362@bonkers.taronga.com> from "Peter da Silva" at Mar 16, 95 12:01:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The criticism you are leveling is one of whether the telnetd waits > > for its output queue to flush before exiting when the pty master > > it is talking to has the last close on the pty slave take place. > > Slow down. Words of one syllable, please... I suspect you're talking > about a more complex situation than I'm addressing, and you're going > way over my head. > > The behaviour I'm talking about is: > > telnet localhost nntp << EOF > LIST > QUIT > EOF > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 200 bonkers.taronga.com NNTP[auth] server version 1.5.11 (10 February 1991) ready at Thu Mar 16 11:54:50 1995 (posting ok). > Connection closed by foreign host. > > On the System V based telnets I've used this waits for the remote side to > exit, so you get a list of groups on standard output. 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. > I don't see how changing the output queue flush behaviour could change this, > because there could potentially be a significant delay between the time the > remote NNTP server receives the LIST command and the time it starts sending > the list of groups. 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. The magic incantation is to force the TCP on the telnet side to ack the data packets from the server before the server closes the connection by queueing the disconnect. In other words, you are asking that the close not be seen by the client side until it has seen the data sent by the server. > The downside is, if the remote server is waiting for EOF rather than any > explicit command, you lose bigtime. So it's easily arguable that the System > V behaviour is broken, and that you shouldn't use telnet as a batch NNTP > client, which is why I wanted to get some feedback before I dove in and > broke^H^H^H^H^Hchanged things. PLEASE NOTE! The message you got on the client end was delivered before the client had processed the information returned by the server (which is why it says "Connection closed by foreign host." instead of saying "Connection closed."). It is the *SERVER* side doing the disconnect! The server is not waiting for the writes it does to complete prior to issuing the disconnect (close). The *ONLY* way you can make sure this is happening is by modifying the disconnect sequence in the way stated in the previous posting. 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?9503170051.AA26101>