Performance, was RE: [CF-Devel] Future of Crossfire

Mark Wedel mwedel at scruz.net
Thu May 17 23:39:00 CDT 2001


Bob Tanner wrote:
>
     
     
     >
     
      Easily solved. Simpliest solution is have the picture servers in a round-robin
     
     >
     
      DNS setup. Just need to make sure the client, timesout quickly and tries the
     
     >
     
      next IP.
     
     >
     
     
     >
     
      A more complex setting, but vastly more reliable, would be using Linux Virtual
     
     >
     
      Server (LVS) (
      
      http://www.linuxvirtualserver.org/
      
      ) with multiple directors using
     
     >
     
      Virtual Servers via IP Tunneling (VS-TUN).
     
     
 To me, thats the biggest issue - time.

 Even with just caching, players saying that seeing the ? for a few ticks is
potentially too long - that could be a nasty monster that kills you before you
know what it is.

 I only see the addition of seperate picture servers making this longer (have to
dns lookup server, connect to it, then get the image).

>
     
     
     >
     
      > 2) Simplicity - setting up a new crossfire server now requires the potential
     
     >
     
      >    that you add new images to the picture server.  This now requires
     
     >
     
      >    authentication of some sort.
     
     >
     
     
     >
     
      Maybe use a DNS analogy here. Couldn't the client look in its local cache for
     
     >
     
      the image. If not, ask the server it's connected to, if not forward the request
     
     >
     
      the picture server?
     
     
 But given that case, the request would never get beyond the server it is
connected to - in some sense, the server connected to must have the images (if
it doesn't, whats the likelihood that a picture server would?)

 The idea of picture servers came up to reduce server load.  Sending images
doesn't really load the server, it loads the network.  The amount of processing
it takes to send an image isn't that much.

 Note that a seperate picture server does not help if the limitation is really
the bandwidth at the client end of the connection (ie, playing at the end of an
isdn or dialup modem line).  A separate picture server really only helps if the
crossfire server is otherwise using all of its bandwidth.  In this case, a
picture server only helps if it is not using the same shared connection as the
crossfire server.

 To give a real example:  If there was pictureserver.real-time.com in addition
to metalforge.real-time.com, this gains no benefit over metalforge.real-time.com
doing everything like it does right now.  while metalforge may do 1% less work
by not having to serve images, the bandwidth to/from real-time would still be
the issue

    
    


More information about the crossfire mailing list