From owner-freebsd-hackers Fri Mar 17 10:35:16 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA05563 for hackers-outgoing; Fri, 17 Mar 1995 10:35:16 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA05557 for ; Fri, 17 Mar 1995 10:35:14 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA28800; Fri, 17 Mar 95 09:09:39 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503171609.AA28800@cs.weber.edu> Subject: Re: Batch Telnet (Re: diskless and 3Com 509) To: peter@bonkers.taronga.com (Peter da Silva) Date: Fri, 17 Mar 95 9:09:39 MST Cc: hackers@FreeBSD.org In-Reply-To: <199503170133.TAA08481@bonkers.taronga.com> from "Peter da Silva" at Mar 16, 95 07:33:04 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > > 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.