[CF-Devel] Compression

Sat Oct 16 08:48:05 CDT 2004

Please keep a TCP only as an Option. I need it so I
can tunnel over SSH.

--- Mark Wedel <

     mwedel at sonic.net

     > wrote:

>

     >

        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

>

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!

     http://vote.yahoo.com

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel