[CF-Devel] 1.1.0 client patches by Edgar

[Edgar Toernig]

Mark Wedel wrote:
>
     
     
     >
     
      1) His fix/check for libz is put in the configure file, and not in the
     
     >
     
      configure.in where it should be.  As it is now, the next time configure is
     
     >
     
      rebuilt via autoconf, that change will be lost.
     
     
I'm aware of that.  But as I said, I'm not used to autoconf and someone
has to figure out how to modify configure.in.

>
     
      2) The check for TCP_NODELAY should be possible in configure.
     
     
Hmm... And then?  Changing the #ifdef TCP_NODELAY to #ifdef HAVE_TCP_NODELAY?

>
     
      Also, if it really is a useful option, using something other than an
     
     >
     
      environmental variable is desired (eg, command line option, setting in
     
     >
     
      options file, etc).
     
     
Wrapping the NODELAY into an if(getenv) is mainly done for debugging.  It's
much easier to "CF_NAGLE=1 cfclient" then to change a define and recompile.

About the "usefulness" of this addition: Normally the TCP stack tries to
avoid sending small packets.  So, if you do a write(acoupleofbytes) the
system waits a little bit before sending out a small packet in the hope
that there will be some more writes that make the packet larger.  The
TCP_NODELAY disables this behavior.  Each write tries to send the data
immediately. (The actual algorithm is more complex but it comes down to
this.)

Of course, if you quickly send a lot of small packets this may hurt because
there is an overhead of ~40 bytes per packet.  You trade latency with band-
width.  What you want is normal (delaying) behavior with an additional
"flush" like call to force that data to be sent.  Unfortunately, such a
system call does not exist (at least in Linux *g*).  So, to get this, one can
turn off the delay (TCP_NODELAY) and collect the data within the application
and write it out when when you know that there will be nothing more to send.

What I did in the patch is to turn on TCP_NODELAY and at least make sure that
a single crossfire command is send with one write.  That results in one net-
work packet per command.  A future optimization would be to collect more
commands and send them together.  I'll add that later.  (In fact, the reason
I did not do it right away was that crossfire uses very little bandwidth
so there was no immediate urge to add it.)

Ciao, ET.