Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!nuug!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.protocols.tcp-ip Subject: Re: Batching vs lock-step Message-ID: Date: 29 Oct 90 10:00:46 GMT References: <9010221418.AA03839@ftp.com> <1990Oct24.090841@apollo.HP.COM> <1990Oct25.165545@envy.bellcore.com> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 57 Nntp-Posting-Host: hild.ifi.uio.no In-Reply-To: urlichs@smurf.sub.org's message of 28 Oct 90 19:09:17 GMT Originator: enag@hild In article urlichs@smurf.sub.org (Matthias Urlichs) writes: The problem is that on top of TCP there's the C stdio library which tends to buffer your data when a program does an fgets(). After reading the first request, said program is likely to say "wait on the _connection_ for ten minutes until data become available". No programmer bothers to examine the stdio buffer first becase - the protocol is supposed to be lock-step anyway, - examining a stdio buffer on whether it contains data is not standardized, - the alternative is to use alarm() and signal(), but longjmp()ing from a signal handler back into a program, bypassing the stdio library on the way out, may not be what the system designers had in mind. A side effect of this is that sending a single character to such an implementation, and leaving the TCP stream open, will hang it indefinitely. ;-) I didn't get this. Are you saying you switch between stdio routines and raw socket reads at some point after the first fgets? Why would anyone do this? I've used the stdio library, which presents to me a stream of characters, to read from sockets bound to a TCP port, and this maps very elegantly on top of TCP, which is also a stream. I haven't had problems of any kind. In particular, I can't think of any real situation where your "side effect" would occur. What are you doing? Phil Karn wrote: > Given that TCP is supposed to be a reliable byte stream protocol, > the designers of these systems must have gone well out of their way > to keep this from working. If the above scenario is real, I agree completely with Phil, here. I've seen NNTP get slightly confused when GNUS (a GNU Emacs news reader) stuffed a whole bunch of command lines down its throat, and the cause was that NNTP used select(2) to wait for input. Apparently, it read the data into a large buffer, strchr'ed for '\n', replaced it with a '\0', and parsed the command. Of course, this failed miserably when GNUS was waiting for more than one reply code. I don't think this implies that the programmer has gone out of his way to keep it from working, since he's only supposed to get one command line at a time. Anyway, it works with a conforming NNTP client, although a bit on the "be conservative in what you accept and liberal in what you send" side. -- [Erik Naggum] Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY I disclaim, , therefore I post. +47-295-8622, +47-256-7822, (fax) +47-260-4427 --