>> A TCP SHOULD implement [Nagle].  However, there MUST be a way for an
>> application to disable the Nagle algorithm on an individual
>> connection.
> The MUST is to "disable".  Therefore, the default has to be "enable".
> (There's no other way to enable.)

I don't follow that.  By that logic, it has to be implemented, and the
immediately preceding SHOULD is irrelevant.

I see nothing wrong with "the way to disable Nagle is to fail to
explicitly enable it, that is, you do nothing".  Of course, to be
useful, a way to explicitly enable it has to be provided, but any
discussion of disabling it by default that even has pretensions to
seriousness has to include that.

Jonathan Stone's comments I'll address in a separate message.

>> [...game...]
> This sounds more like a buffering and execution design problem.
> Turning off Nagle only helps here as something in your message design
> is prompting the execution at the other end, which in turn sends a
> message prompting execution at the original end, causing oscillation.

That doesn't sound plausible in view of the way the network link in
question works.  I can go into more detail, but perhaps we should take
this part of it off-list?

> Nagle and delayed ack are about being kind to your neighbors.  They
> souldn't be turned off except in the most unusual circumstances.

In the case of my game, being kind to any other putative users of the
network is less important than good performance; I don't run that game
if I'm not willing to ruin performance for anyone else trying to use
the house LAN.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B