Path: utzoo!attcan!uunet!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: Batching vs lock-step Message-ID: Date: 28 Oct 90 19:09:17 GMT References: <9010221418.AA03839@ftp.com> <1990Oct24.090841@apollo.HP.COM> <1990Oct25.165545@envy.bellcore.com> Organization: University of Karlsruhe, FRG Lines: 33 In comp.protocols.tcp-ip, article <1990Oct25.165545@envy.bellcore.com>, karn@thumper.bellcore.com writes: < < While we're on the subject of piggybacking, another thing I would < really like to see is widespread use of batched SMTP on the Internet. < I think the number of packets it takes for most SMTP implementations < to transfer a short mail message is criminal, especially when the < message has several recipients on the same system. There's no reason < that you shouldn't be able to send a series of SMTP commands in a < single TCP segment and receive a series of responses, except that many < SMTP servers inexplicably blow up when you try this. 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. < 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. ;-) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/