[CF-Devel] Performance

[Mark Wedel]

     pc-crossfire at crowcastle.net
     
      wrote:
>
     
     
     >
     
      I haven't looked at the current protocol, so I don't know how much work it
     
     >
     
      would be, but here are some thoughts for how we should do it to maximize
     
     >
     
      efficiency:
     
     >
     
     
     >
     
      Messages should be binary, not ASCII.  It makes reading the stream more
     
     >
     
      difficult, but saves lots of bandwidth.
     
     >
     
     
     >
     
      Each message should start with a 32-bit message type code.  We can then
     
     >
     
      define a range of messages that are frequent messages.  For example, there
     
     >
     
      could be message types that indicate the presence of a spell effect on the
     
     >
     
      same square as the player.  Hence, if 7 fears, 3 icestorms, and 9 slows
     
     >
     
      show up on your square, you only have to receive 19 words.  So we can
     
     >
     
      define a standard set of objects that can be sent with just a single code.
     
     >
     
      Special objects will take multi-part messages to send name and weight
     
     >
     
      information, but that's not a problem as long as we get all the spell
     
     >
     
      effects and other really common items.
     
      It really depends on the payload.

 For the most part, what data that can be sent is sent in binary form.  Now the
actual protocol commands themselves are in text, but that really isn't that big
a deal.  Yes - some bandwidth can be saved by going to binary, but most of the
protocol commands are <6 characters or so.  Presuming 1 byte is enough for
unique commands (currently is, but may not be in the future), that saves maybe
5-6 bytes.  That is useful, but not especially useful, and is really nothing at
all if it is the payload that is 500 bytes.  So what really needs to be
determined more precisely where the bandwidth is going, and try to improve that.

 For example, for objects, the biggest hog of the bandwidth is for the names. 
But there is potential for other savings - animations and animatiion speed may
not be relevant for a lot of objects, which means those fields get filled with
zeros.  Having a 1 byte mask which says what data we're sending along could save
some bandwidth there (at the expense if making the object sending code more
complicated.

 The tricky part of your example is definining the value xyz is a fear, foo is a
slow, etc.  Certainly for some objects, the amount of information sent of
objects is excessive (for fear and slow, don't really need to send a nrof,
weight, flags, or tag - that right there could save 16 bytes out of the current
data stream if only data necessary gets sent along.)

 PRobably the ideal form is some method of string reduction for commonly used
strings, and only sending object information the client actually needs. 

 But the biggest killer can be that for at least objects on the space the player
is on, if only one object gets added or removed, the entire space gets resent. 
And that is just plain not a good idea.