[crossfire] Bandwith ussage too high?

[Mark Wedel]

Mitch Obrian wrote:
>
      I think it would be best to not do that. We do not
     >
      want to leak information to the client that he cannot
     >
      see, nor do we want to tell him what is connected.
     >
     
     >
      I think the best would be to specify what is cosmetic
     >
      animations (ex: monster animations, water, spell
     >
      animations (fire etc) (these eat bandwith), etc) and
     >
      keep the funcitonal ones as is (doors, gates,
     >
      triggers, spikes). Most of the bandwith hit is on the
     >
      spell, water, etc animations. 
     
  I agree.  The bandwidth of the gate moving is pretty trivial - something like 
4 bytes/tick or the like (8 ticks/second, so 32 bytes per second).

  Granted, may be several gates/doors moving, but still.

  Has anyone actually done analysis on actual bandwidth usage, or is all this 
just WAGs?

  Bandwidth for the map is 2 bytes for the space (coordinates).  1 byte for 
darkness.  2 bytes for the 3 faces.

  Worst case situation is a space is 9 bytes.  625 spaces (25x25) - 5625 
bytes/tick.  8 ticks/sec - 45000.  So worse case, which would pretty much never 
be seen, is 45 k/sec - non trivial.  But maybe it also depends on what we 
require.  But I'd also say that isn't a case your likely to see very often.  I'd 
estimate more realistic usage is closer to 10-20k/sec, even in really bad cases 
(highly unlikely you'd ever get a case where there are objects on all three 
layers, and all of those objects are also animated).

  I think that can be brought down.  But one has to be careful on how much work 
is spent to optimize this.  Conveying that a space should use an animation is 
likely to actually use more initial bandwith, with savings down the road.  But 
for something like a gate, it may actually not be much a win - and almost 
certainly not for the complexity added.

  I can certainly see that the case of oceans can be a fairly big user - maybe 
of half the map of ocean spaces - 300 * (2 + 2) * 8 = 9600 bytes/sec.

  I'd much rather go for the easy cases like letting client animate oceans and 
other things we don't care about.  IF that doesn't get enough savings, worry 
about trying to optimize the more complex cases.

  But all that said, one has to figure out what hte goal is.  Its going to take 
some bandwidth no matter what you do - you can't optimize it to zero.  Is it 
worth it to write a lot of code and add a lot of complexity to saving 500 
bytes/second?  My thought would be no - if anything, as time passes, bandwidth 
will become more available and cheaper.