[CF-Devel] Compression

[crossfire-devel at archives.real-time.com]

  Try to cover some points quickly:

Text messages - the hit messages could certainly be reduced in size - even just 
sending it like 'hit:orc:20' or something is a lot more terse than 'you hit the 
orc very hard'.  However, even if you presume 20 messages per second, at 30 
characters per message (both which seem would be pretty high), that is really 
only 600 bytes/second.

  I'm ignoring tcp overhead here, because in practice, the OS can certainly 
combine several messages into a single packet, so you're not necessarily going 
to incure the tcp overhead for each message.

UDP could certainly be used, and could make sense for some data.  Realistically, 
you'd probably have both a tcp and udp connection - there really isn't any 
reason for the client or server to re-implement the tcp protocol.  So for data 
that must get to the other end, you use the tcp connection, or data which can be 
lost, you use the udp.

  The problem here is figuring out what data can go over udp, and potentially be 
lost or end up out of order.  Certainly, things like the 'hit' messages 
mentioned above could be udp - if you miss a few messages about hitting hte 
monster, or a few come out of order, not a big deal.

  However, map data is much more problematic - the current map logic only sends 
differences, and order is pretty important.  Thus, for example, if a map update 
was lost, some squares will remain incorrect until either the player leaves and 
re-enters the map, or they disappear from view.  So to in a sense fix this, 
you'd need to periodic send the entire map to the client just to cover such lost 
spaces (and this entire map has to be send reliably) - its unclear, depending on 
how often you need to send these total maps, of whether much bandwidth would 
actually get saved.

The potentially easier way to save bandwidth is to send map updates less often. 
  For example, if isntead of sending it every frame, it was sent every other 
frame, there'd probably be quite a bit of bandwidth saved, and such a change 
would easily be done.

  To me, trying to send the static map to the client is a no go - it adds a lot 
of complication, a lot of potential cheat ability, and potentially changes when 
you get lag - eg, in such a method, you're fairly likely to get noticable lag 
when changing maps.

  Making the map protocol more efficient is one of those things I plan to do - 
including having the client deal with animations.  However, like most things, 
there is so much that could be done, and so little time.

  However, the issue always comes to minimum requirements.  For example, there 
was discussion a while back about minimum system to play the client on (given 
the x11 client used less resources than the gtk, but not as well supported.

  The same can be said for bandwidth.  At some point, you just have to say you 
need XYZ bandwidth and if you don't have it, tough luck.  Perhaps a bit cruel, 
but no matter what you do, there will be some minimum (a 9600 baud modem will 
never be acceptable for example)


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel