Re: client server part 1

["Eric A. Anderson" <eanders+@CMU.EDU>]

Philip Brown <philb@CSUA.Berkeley.EDU> writes:
> You seem to be replacing an incredibly cumbersome, overkill, net-hogging
> protocol with a medium cumbersome, somewhat overkill, net-intense
> protocol :-)
Which can then be migrated to a less cumbersome protocol while at the
same time the X stuff can be removed from the server.  Morover, since
the client is working, people can actually examine it to determine
what will take up a lot of time and optimize for that.  Furthermore, 
because the client is complete, we know that the procol handles all 
of the things.  Can anyone tell me how magic spells are going to be
handled according to the protocol?  Are the effects of say a burning
hands an item or a map?  It doesn't seem to be either since map stuff
is for non alive objects like walls, floor, and items are things that
can be put into the clients possession.  Regardless of the choice, the
protocol will be strictly more inefficient than the protocol I'm
using; because I represent a single image+location in ~4 bytes instead
of 10 or eleven for the map protocol or 29 for the item message.
--
So if map updates consume most of the bandwidth, then my protocol is
more efficient. :)   On the basis of this explanation, we probably
need to measure what will take up the bandwidth so we will know if the
protocol will be sufficiently compact.

> It's better to wait 2 months, and have something more useful in the
> long-term, than have something in two weeks that isn't quite what was
> hoped for, methinks.
I guess my standard argument is that anything that could be put in the
other client can also be put into this one, and hence the only
substantive difference is what the clients can do right now.

"Rupert G. Goldie" <rgg@aaii.oz.au> writes:
> Eric writes: 
> [ slow down the game to reduce bandwidth consumption ]
> 
> Why ? People keep saying that we need to go to client-server to reduce 
> network bandwidth, so if I can play crossfire quite happily at the moment
> over 9600 bps why should the c-s implementation need more bandwidth ?
Can you?  Which maps are you playing on?  Is anyone else playing at
the same time?  Are you playing with synchronization or flushing?  Are
you using pixmaps, bitmaps or fonts?
I haven't tried playing over 9600 bps, but had just assumed it would
be intolerably slow given that people playing remotely on the berkeley
server drastically slow down the server.  The client already requires
less bandwith in xpm mode than the old server, I've just observed that
to maintain 10 fps won't be possible even with this bandwidth
reduction.  I just checked it sending only one pixmap per square, and
with that, which is somewhat more inefficient than fonts, you could
play at about 5fps, the immediate calculation with fonts (11*11*2=242)
Implies around 5fps also.
          -Eric 
*********************************************************
"It seemed like a good idea at the time"
           -The Mad Hatter
"Yes, you're very smart.  Shut up."
           -In "The Princess Bride"
*********************************************************