[CF-Devel] 1.1.0 client patches by Edgar

Edgar Toernig froese at gmx.de
Mon Jan 14 11:44:56 CST 2002


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.



    
    


More information about the crossfire mailing list