Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs From: urlichs@smurf.sub.org (Matthias Urlichs) Newsgroups: comp.protocols.tcp-ip Subject: Re: Batching vs lock-step Message-ID: Date: 30 Oct 90 01:03:33 GMT References: <1990Oct25.165545@envy.bellcore.com> Organization: University of Karlsruhe, FRG Lines: 52 In comp.protocols.tcp-ip, article , enag@ifi.uio.no (Erik Naggum) writes: < 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". < [...] < 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? < No, I said (and quite a few programs actually do it) that the programs alternate between reading via stdio and using select() on the raw socket. < In particular, I can't think of any real situation where your "side < effect" would occur. < Consider a program which does: - while(TCP stream OK) - select(TCP stream, 10 minutes) - fgets(stream, data) - process (data) Now if you send a single character to this program, the select call will say OK, but the fgets() will hang, waiting for a Newline. Alterntely, if you send two short lines, the fgets will read both into its buffer (and return the first to the program), and next time 'round the select will block. < 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. [...] It's far simpler -- see above. < 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. < That seems to be the problem. ;-) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/