Dear all,
I have a funny problem with TCP.  To be honest, I am not sure if my
question is a  protocol issue or a programming issue or a convex
combination of the two, but I hope you can shed some light.

I have a program that communicates with an HTTP server (lighttpd) [it
is not an HTTP issue, stay with me...].  Both server and client run on
the same PC and talk via 127.0.0.1. On my home computer everything
goes fine, but when I run them (the server and the client) on my
office computer the  server closes the connection as soon as it sees
the double CRLF at the end of the query.  By looking at the traffic
with wireshark and/or tcpdump I can see that on my office computer my
client is sending the 1 char per packet, that is the request (say)
"GET /index.html ..." is being sent

"G"
"E"
"T"
" "
"/"

.... and so on...  I guess that the server should not care (my client
can distribute the data in the packets as it wishes), but I suspect
that this extreme fragmentation can "confuse" it.  The suspect is
confirmed by the fact that when the packets carry the whole request
(as it happen on my home computer and some Ruby scripts [both at home
& office]) everything goes fine.

In case you need to know: both PC (home & office) run Linux (2.4 at
home, maybe 2.6 at work), lighttpd is 1.4.23 at home and 1.4.19 at
work, the client is compiled with the same compiler version on both
environments.

Has someone some idea/pointers/whatever about this problem?

Thanks in advance four your help.

mockturtle <framefritti@gmail.com> wrote:

> I have a program that communicates with an HTTP server (lighttpd) [it
> is not an HTTP issue, stay with me...].  Both server and client run on
> the same PC and talk via 127.0.0.1. On my home computer everything
> goes fine, but when I run them (the server and the client) on my
> office computer the  server closes the connection as soon as it sees
> the double CRLF at the end of the query.  By looking at the traffic
> with wireshark and/or tcpdump I can see that on my office computer my
> client is sending the 1 char per packet, that is the request (say)
> "GET /index.html ..." is being sent
 
> "G"
> "E"
> "T"
> " "
> "/"
 
> ... and so on...  I guess that the server should not care (my client
> can distribute the data in the packets as it wishes), but I suspect
> that this extreme fragmentation can "confuse" it.  

TCP is a stream protocol.  

If that confuses it, then it is a bug in the receiver.  

-- glen

On Nov 11, 4:00=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> mockturtle <framefri...@gmail.com> wrote:
> > I have a program that communicates with an HTTP server (lighttpd) [it
> > is not an HTTP issue, stay with me...]. =A0Both server and client run o=
n
> > the same PC and talk via 127.0.0.1. On my home computer everything
> > goes fine, but when I run them (the server and the client) on my
> > office computer the =A0server closes the connection as soon as it sees
> > the double CRLF at the end of the query. =A0By looking at the traffic
> > with wireshark and/or tcpdump I can see that on my office computer my
> > client is sending the 1 char per packet, that is the request (say)
> > "GET /index.html ..." is being sent
> > "G"
> > "E"
> > "T"
> > " "
> > "/"
> > ... and so on... =A0I guess that the server should not care (my client
> > can distribute the data in the packets as it wishes), but I suspect
> > that this extreme fragmentation can "confuse" it. =A0
>
> TCP is a stream protocol. =A0
>
> If that confuses it, then it is a bug in the receiver. =A0


Explicit sensitivity to that sort of thing is fairly commonly
implemented in mail servers, and in at least some HTTP servers
(basically you watch for many recv()=92s retuning short bits of data).
The assumption being that a highly fragmented command is coming from a
hacker using a telnet session or something similar.  Now as to whether
or not that's a bug...

To the OP:  is your application actually doing a separate send for
each character?  You may be triggering the above problem because of
the much lower latency of the connection at work (with a high latency
connection from home, the individual sends are much more likely to get
coalesced into a single segment by Nagel).

On Nov 11, 12:58=A0pm, mockturtle <framefri...@gmail.com> wrote:

> Has someone some idea/pointers/whatever about this problem?

Do you disable Nagle? If so, why?

DS

robertwessel2@yahoo.com ha scritto:
> On Nov 11, 4:00 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > mockturtle <framefri...@gmail.com> wrote:
> > > I have a program that communicates with an HTTP server (lighttpd) [it
(snip)
>
> To the OP:  is your application actually doing a separate send for
> each character?

Tricky question... I {am using,have to use} a function of a third part
library that accepts as
parameter a string.  I give to such a function a whole line at time,
but I do not know if
internally the function sends one char at time (I would be
surprised).  I can ask to the
library vendor.

> You may be triggering the above problem because of
> the much lower latency of the connection at work (with a high latency
> connection from home, the individual sends are much more likely to get
> coalesced into a single segment by Nagel).

Hmmm.... I do not know...  Both client and server are on the same PC
and communicate
via the loopback interface (127.0.0.1).  Moreover, Ruby scripts (that
send one line per packet)
communicate with the server both at work and at home.

Actually, everything seems to point to the third part library (that,
however, I use also at home).
I'll ask to the vendor.

glen herrmannsfeldt ha scritto:
> mockturtle <framefritti@gmail.com> wrote:
>
> > I have a program that communicates with an HTTP server (lighttpd) [it
> > is not an HTTP issue, stay with me...].  Both server and client run on
> > the same PC and talk via 127.0.0.1. On my home computer everything
> > goes fine, but when I run them (the server and the client) on my
> > office computer the  server closes the connection as soon as it sees
> > the double CRLF at the end of the query.  By looking at the traffic
> > with wireshark and/or tcpdump I can see that on my office computer my
> > client is sending the 1 char per packet, that is the request (say)
> > "GET /index.html ..." is being sent
>
> > "G"
> > "E"
> > "T"
> > " "
> > "/"
>
> > ... and so on...  I guess that the server should not care (my client
> > can distribute the data in the packets as it wishes), but I suspect
> > that this extreme fragmentation can "confuse" it.
>
> TCP is a stream protocol.
>
> If that confuses it, then it is a bug in the receiver.
>

I agree, but

  1) I need to make it work (it is just for testing purposes and not
for production, so it does not
matter if the whole system is a little brittle, as long as I am able
to do my tests...)

  2) it seem quite curious a behaviour to me, and I would like to
understand it better :-)
> -- glen

On Nov 12, 2:11=A0am, mockturtle <framefri...@gmail.com> wrote:
> robertwess...@yahoo.com ha scritto:
>
> > On Nov 11, 4:00 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > > mockturtle <framefri...@gmail.com> wrote:
> > > > I have a program that communicates with an HTTP server (lighttpd) [=
it
> (snip)
>
> > To the OP: =A0is your application actually doing a separate send for
> > each character?
>
> Tricky question... I {am using,have to use} a function of a third part
> library that accepts as
> parameter a string. =A0I give to such a function a whole line at time,
> but I do not know if
> internally the function sends one char at time (I would be
> surprised). =A0I can ask to the
> library vendor.
>
> > You may be triggering the above problem because of
> > the much lower latency of the connection at work (with a high latency
> > connection from home, the individual sends are much more likely to get
> > coalesced into a single segment by Nagel).
>
> Hmmm.... I do not know... =A0Both client and server are on the same PC
> and communicate
> via the loopback interface (127.0.0.1). =A0Moreover, Ruby scripts (that
> send one line per packet)
> communicate with the server both at work and at home.
>
> Actually, everything seems to point to the third part library (that,
> however, I use also at home).
> I'll ask to the vendor.


What does the lighttpd log say about the failing session?

On Nov 12, 2:46 pm, "robertwess...@yahoo.com"
<robertwess...@yahoo.com> wrote:
> On Nov 12, 2:11 am, mockturtle <framefri...@gmail.com> wrote:
>
>
>
> > robertwess...@yahoo.com ha scritto:
>
> > > On Nov 11, 4:00 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > > > mockturtle <framefri...@gmail.com> wrote:
> > > > > I have a program that communicates with an HTTP server (lighttpd) [it
> > (snip)
>
> > > To the OP:  is your application actually doing a separate send for
> > > each character?
>
> > Tricky question... I {am using,have to use} a function of a third part
> > library that accepts as
> > parameter a string.  I give to such a function a whole line at time,
> > but I do not know if
> > internally the function sends one char at time (I would be
> > surprised).  I can ask to the
> > library vendor.
>
> > > You may be triggering the above problem because of
> > > the much lower latency of the connection at work (with a high latency
> > > connection from home, the individual sends are much more likely to get
> > > coalesced into a single segment by Nagel).
>
> > Hmmm.... I do not know...  Both client and server are on the same PC
> > and communicate
> > via the loopback interface (127.0.0.1).  Moreover, Ruby scripts (that
> > send one line per packet)
> > communicate with the server both at work and at home.
>
> > Actually, everything seems to point to the third part library (that,
> > however, I use also at home).
> > I'll ask to the vendor.
>
> What does the lighttpd log say about the failing session?

Nothing... It does not even appear.  It seems like lighttpd aborted
the reading of the request.  I tried to give a look at the sources,
but they are quite complex and I had not enough time.

Oh, by the way, some news: (1) We tried with Apache and it seems that
Apache is perfectly fine with the extreme fragmentation, (2) sometimes
(more or less at random) it happens that after few one-char-packets
the remainder of the string is sent in a single packet; in this case
everything work (even with lighttpd). :-?

mockturtle <framefritti@gmail.com> wrote:
(snip)
 
> Oh, by the way, some news: (1) We tried with Apache and it seems that
> Apache is perfectly fine with the extreme fragmentation, (2) sometimes
> (more or less at random) it happens that after few one-char-packets
> the remainder of the string is sent in a single packet; in this case
> everything work (even with lighttpd). :-?

Many systems don't like fragmentation down to length 1, but that
is IP fragmentation, not at all related to your question.

If there are programs that specifically check for 1 character
input, then I am sure someone will write a client that sends
a line at a time.  People use telnet because it is there and
easy to use, not because there is anything special about it.

(I have heard stories about systems removing telnet to prevent
such, but leaving ftp available.)

-- glen

On Thu, 2009-11-12, mockturtle wrote:
>
>
> glen herrmannsfeldt ha scritto:
>> mockturtle <framefritti@gmail.com> wrote:
>>
>> > I have a program that communicates with an HTTP server (lighttpd) [it
>> > is not an HTTP issue, stay with me...].  Both server and client run on
>> > the same PC and talk via 127.0.0.1. On my home computer everything
>> > goes fine, but when I run them (the server and the client) on my
>> > office computer the  server closes the connection as soon as it sees
>> > the double CRLF at the end of the query.  By looking at the traffic
>> > with wireshark and/or tcpdump I can see that on my office computer my
>> > client is sending the 1 char per packet, that is the request (say)
>> > "GET /index.html ..." is being sent
>>
>> > "G"
>> > "E"
>> > "T"
>> > " "
>> > "/"
>>
>> > ... and so on...  I guess that the server should not care (my client
>> > can distribute the data in the packets as it wishes), but I suspect
>> > that this extreme fragmentation can "confuse" it.
>>
>> TCP is a stream protocol.
>>
>> If that confuses it, then it is a bug in the receiver.
>>
>
> I agree, but
>
>   1) I need to make it work (it is just for testing purposes and not
> for production, so it does not
> matter if the whole system is a little brittle, as long as I am able
> to do my tests...)
>
>   2) it seem quite curious a behaviour to me, and I would like to
> understand it better :-)

You could use those Ruby scripts to test this assumption (which AFAICT
isn't disproven elsewhere in the thread):

  Assumption: there is a bug in lighttpd which makes it freak out when
  it reads a partial GET line (maybe specifically when it gets to see
  the CR but not in the same read() the LF).

It's not that unlikely; I myself maintain code with such bugs. And if
you manage to work around the one-octet segment issue, it can still
happen now and then -- maybe once a month when you least expect it ...

It's easy to write a tiny Ruby program to test that. You can sleep for
5 s or something before the LF and the rest of the request.
If that exposes a bug, file a bug report and switch to another server.

(I might be wrong, but I seem to recall that lighttpd often appears in
the Debian Linux security updates.  If it has repeated security
issues, that indicates it's shoddily written in general ...)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

On Nov 12, 1:09=A0pm, mockturtle <framefri...@gmail.com> wrote:

> Oh, by the way, some news: (1) We tried with Apache and it seems that
> Apache is perfectly fine with the extreme fragmentation, (2) sometimes
> (more or less at random) it happens that after few one-char-packets
> the remainder of the string is sent in a single packet; in this case
> everything work (even with lighttpd). :-?

Ahh, sounds like the sender is broken, passing the characters one-at-a-
time to the TCP layer. Even with Nagle enabled, this can still result
in extreme segmentation on a fast enough network. Perhaps lighttpd is
limiting the amount of senseless work it will permit a client to
impose on it.

DS

On Nov 12, 2:21=A0pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:

> You could use those Ruby scripts to test this assumption (which AFAICT
> isn't disproven elsewhere in the thread):
>
> =A0 Assumption: there is a bug in lighttpd which makes it freak out when
> =A0 it reads a partial GET line (maybe specifically when it gets to see
> =A0 the CR but not in the same read() the LF).

This seems like a good possibility, since lighttpd has had similar
bugs in the past.
http://www.lighttpd.net/assets/2007/4/13/lighttpd-1.4.x_crlf_parsing_dos.pa=
tch

DS

On Thu, 2009-11-12, David Schwartz wrote:
> On Nov 12, 2:21�pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>
>> You could use those Ruby scripts to test this assumption (which AFAICT
>> isn't disproven elsewhere in the thread):
>>
>> � Assumption: there is a bug in lighttpd which makes it freak out when
>> � it reads a partial GET line (maybe specifically when it gets to see
>> � the CR but not in the same read() the LF).
>
> This seems like a good possibility, since lighttpd has had similar
> bugs in the past.
> http://www.lighttpd.net/assets/2007/4/13/lighttpd-1.4.x_crlf_parsing_dos.patch

Oh. In that case he might want to test splitting the request at some
other point, not just in the first CRLF as I suggested above. The
patch was about that CRLF-CRLF part of (some?) request.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

On 12 Nov, 23:41, David Schwartz <dav...@webmaster.com> wrote:
> On Nov 12, 1:09=A0pm, mockturtle <framefri...@gmail.com> wrote:
>
> > Oh, by the way, some news: (1) We tried with Apache and it seems that
> > Apache is perfectly fine with the extreme fragmentation, (2) sometimes
> > (more or less at random) it happens that after few one-char-packets
> > the remainder of the string is sent in a single packet; in this case
> > everything work (even with lighttpd). :-?
>
> Ahh, sounds like the sender is broken, passing the characters one-at-a-
> time to the TCP layer. Even with Nagle enabled, this can still result
> in extreme segmentation on a fast enough network. Perhaps lighttpd is
> limiting the amount of senseless work it will permit a client to
> impose on it.
>
> DS

Well, I would not really say broken, but with a different design
choice... :-)  I was able to get some more information about the
functions we are using.  They are part of a large library to write
"generalized structures" over "generalized streams" (files, network
connections, and so on...).  An older version of the library just
iterated over the "components" of the "structure" and wrote them one
at time.  Since the components of the string are its characters, they
were written  one at time.  [Technically, this is coherent with the
documented interface of the function: they grant you that the
structure will be written, but how this is done is left to the
implementation]  The newer version has some special processing for the
string case and write  the whole string in a single step.    The
solution we were suggested (and it works) is to use directly lower-
level functions, since in this case we want just send strings over a
network connection.

On Nov 14, 2:54=A0am, mockturtle <framefri...@gmail.com> wrote:

> Well, I would not really say broken, but with a different design
> choice... :-)

The problem is, the design choice is incompatible with TCP's
documented segmentation behavior.

> =A0I was able to get some more information about the
> functions we are using. =A0They are part of a large library to write
> "generalized structures" over "generalized streams" (files, network
> connections, and so on...). =A0An older version of the library just
> iterated over the "components" of the "structure" and wrote them one
> at time. =A0Since the components of the string are its characters, they
> were written =A0one at time. =A0[Technically, this is coherent with the
> documented interface of the function: they grant you that the
> structure will be written, but how this is done is left to the
> implementation]

If this is documented behavior, then connecting this directly to a TCP
connection is broken behavior. TCP's segmentation behavior is well-
documented.

>=A0The newer version has some special processing for the
> string case and write =A0the whole string in a single step. =A0 =A0The
> solution we were suggested (and it works) is to use directly lower-
> level functions, since in this case we want just send strings over a
> network connection.

Good idea, since even that change is still not right for TCP.

For TCP, well-behaved applications accumulate data into sensible-
chunks for sending. They accumulate until they either reach a specific
amount (2KB at absolute minimum) or until they know they are not going
to be sending any more data immediately.

You can adapt poorly-behaved libraries to TCP by giving them their own
'write' function. This 'write' function checks to see if it has
accumulated at least 2KB. If not, it simply adds the data to a buffer.
If so, it passes it to the TCP connection. You then need to call a
'flush' function when you're done with the poorly-behaved library.

That way, the character-by-character writer will only write to the
buffer, passing data to TCP in 2kB chunks. The last bit will be
written by calling the flush function when you're done telling the
library to write things.

DS

On Sat, 2009-11-14, David Schwartz wrote:
> On Nov 14, 2:54�am, mockturtle <framefri...@gmail.com> wrote:
>
>> Well, I would not really say broken, but with a different design
>> choice... :-)
>
> The problem is, the design choice is incompatible with TCP's
> documented segmentation behavior.
>
>> �I was able to get some more information about the
>> functions we are using. �They are part of a large library to write
>> "generalized structures" over "generalized streams" (files, network
>> connections, and so on...). �An older version of the library just
>> iterated over the "components" of the "structure" and wrote them one
>> at time. �Since the components of the string are its characters, they
>> were written �one at time. �[Technically, this is coherent with the
>> documented interface of the function: they grant you that the
>> structure will be written, but how this is done is left to the
>> implementation]
>
> If this is documented behavior, then connecting this directly to a TCP
> connection is broken behavior.

"Stupid behavior" or "an unbelievable waste of bandwidth", yes. And in
my opinion a big blinking "We are morons! Don't use our library!" neon
sign. But it's not really broken, is it? In the sense that the TCP
stacks or the other end may not process it properly?

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

On Nov 14, 12:54=A0pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:

> > If this is documented behavior, then connecting this directly to a TCP
> > connection is broken behavior.

> "Stupid behavior" or "an unbelievable waste of bandwidth", yes. And in
> my opinion a big blinking "We are morons! Don't use our library!" neon
> sign. But it's not really broken, is it? In the sense that the TCP
> stacks or the other end may not process it properly?

It is broken to connect it to a TCP stack that is documented to not
process it properly. TCP relies on the application to hint segment
boundaries to it, as it otherwise has no way to know whether a one-
byte send is the last one for a day or the first of a million.

The issue is not that TCP may not process it properly but that TCP
cannot possibly process it properly. When it gets the first byte, it
more or less has no choice but to send it immediately. It has no idea
whether or not another byte is forthcoming any time soon and delaying
sending it would harm every application that sent single bytes and
waited for replies. When it sees the second one-byte send immediately
following, what can it do but delay? If it sends it immediately, does
it do that also on the third one and allow a link efficiency of some
tiny fraction of one percent?

Connecting a byte-at-a-time dribbler to TCP is broken. Exactly where
the brokenness lies depends on the guarantees made. (It may be in the
dribbler itself, it may be in whoever connected it it TCP.)

DS

David Schwartz <davids@webmaster.com> wrote:

> For TCP, well-behaved applications accumulate data into sensible-
> chunks for sending. They accumulate until they either reach a specific
> amount (2KB at absolute minimum) or until they know they are not going
> to be sending any more data immediately.

I am as big a fan as "send as much as you can, especially if it is
logically associated" but 2KB as the absolute minimum seems
excessively harsh.  Given the frequency of 14XX byte MSSes and that
the ratio of data to data+headers for TCP would be "decent" (decent,
not stellar) anywhere above 5XX bytes I would think something more
like 512/536 or 1024 would suffice.  At least when trying to shoe-horn
in some kludges for what was arguably an incredibly silly design
choice for the library.

rick jones
-- 
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Nov 16, 10:50=A0am, Rick Jones <rick.jon...@hp.com> wrote:

> David Schwartz <dav...@webmaster.com> wrote:

> > For TCP, well-behaved applications accumulate data into sensible-
> > chunks for sending. They accumulate until they either reach a specific
> > amount (2KB at absolute minimum) or until they know they are not going
> > to be sending any more data immediately.

> I am as big a fan as "send as much as you can, especially if it is
> logically associated" but 2KB as the absolute minimum seems
> excessively harsh. =A0Given the frequency of 14XX byte MSSes and that
> the ratio of data to data+headers for TCP would be "decent" (decent,
> not stellar) anywhere above 5XX bytes I would think something more
> like 512/536 or 1024 would suffice. =A0At least when trying to shoe-horn
> in some kludges for what was arguably an incredibly silly design
> choice for the library.

The issue is that if your accumulation level isn't larger than the
largest amount of data that fits in a single segment on the wire,
Nagle will engage. If you accumulate, say, 1024 bytes and more than
that fits in a packet, if you send 1,512 bytes, the last 512 bytes
will be Nagled.

It's almost always worth the memory to avoid spurious Nagling and get
maximum network efficiency. It's a very rare application that has so
many TCP connections or so little memory, it can't easily afford a 2KB
user-space buffer for each one.

In fact, you can use an arbitrarily large buffer if your pattern looks
like this:

1) Call a function that sends some data.

2) If we're not done, go to step 1.

3) Flush the data to the TCP connection.

In that case, the buffer will only remain in existence (typically) for
a very small amount of time -- the time it takes you to process one
query and accumulate one reply. In that kind of case, I try to use a
16KB buffer.

DS

David Schwartz <davids@webmaster.com> wrote:
> The issue is that if your accumulation level isn't larger than the
> largest amount of data that fits in a single segment on the wire,
> Nagle will engage. If you accumulate, say, 1024 bytes and more than
> that fits in a packet, if you send 1,512 bytes, the last 512 bytes
> will be Nagled.

Be very careful with "send" (and I will be careful with reading) - I
nearly went asymptotic thinking you were trying to suggest that a
send() call of 1512 bytes would hit Nagle :)

Yes, if the accumulation point is < MSS one might run into Nagle.  If
one is interposing with the broken library anyway, and "know" the
quantity of data presented to TCP will not be epsilon each time, it
might be acceptable to actually have the interposed code disable Nagle
- it is, afterall, doing essentially the same thing Nagle would be
doing.

rick jones
-- 
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Nov 16, 11:30=A0am, Rick Jones <rick.jon...@hp.com> wrote:

> David Schwartz <dav...@webmaster.com> wrote:

> > The issue is that if your accumulation level isn't larger than the
> > largest amount of data that fits in a single segment on the wire,
> > Nagle will engage. If you accumulate, say, 1024 bytes and more than
> > that fits in a packet, if you send 1,512 bytes, the last 512 bytes
> > will be Nagled.

> Be very careful with "send" (and I will be careful with reading) - I
> nearly went asymptotic thinking you were trying to suggest that a
> send() call of 1512 bytes would hit Nagle :)

Sorry, I didn't word that quite as clearly as I could have.

> Yes, if the accumulation point is < MSS one might run into Nagle. =A0If
> one is interposing with the broken library anyway, and "know" the
> quantity of data presented to TCP will not be epsilon each time, it
> might be acceptable to actually have the interposed code disable Nagle
> - it is, afterall, doing essentially the same thing Nagle would be
> doing.

If the interposing code does its job correctly, Nagle should only kick
in where it is helpful. The cases where Nagle hurts you are all the
cases where you do something awful, which the interposing code should
eliminate anyway.

I've seen a lot of code that disables Nagle with the logic that Nagle
shouldn't be doing anything anyway, and that disabling Nagle will
solve performance problems if someone breaks the send logic. Frankly,
I think this is backwards reasoning. If you screw up your send logic
somehow, Nagle *saves* you from disaster. It's there precisely in case
your send logic is busted.

DS

David Schwartz <davids@webmaster.com> wrote:
> I've seen a lot of code that disables Nagle with the logic that
> Nagle shouldn't be doing anything anyway, and that disabling Nagle
> will solve performance problems if someone breaks the send
> logic. Frankly, I think this is backwards reasoning. If you screw up
> your send logic somehow, Nagle *saves* you from disaster. It's there
> precisely in case your send logic is busted.

Violent agreement - at least 99 times out of 10 :)

rick jones
-- 
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...