Re: A few thoughts on client/server in multi-player games

["Carl Edman" <cedman@cedman.remote.Princeton.EDU>]

quinet@montefiore.ulg.ac.be (Raphael Quinet) writes:
> Carl Edman (cedman@cedman.remote.Princeton.EDU) wrote:
> > Mark Wedel <master@rahul.net> writes:
> > > I don't think all images and sounds should be referred to by name
> > > when the client is actually playing.
> > > 

> [stuff deleted]
> > But haven't we learned from the old map numbering scheme what
> > happens   with fixed numbering schemes when several independent
> > groups work on   the code ?  *Please* let us avoid that pitfall in
> > the client/server   design.
>
> First note: remember that you never need to send the binary data for
> the sounds.  The rplay daemon will fetch the sound files from the
> nearest RPTP server if they aren't available locally.  So you only
> need to send the filenames.

If you chose that route you virtually guarantee that the crossfire  
client will never run on anything but X machines.  That throws out of  
the window one of the beauties of the client/server design -- that you  
can write a client to work well on virtually any hardware platform.   
How far do you think the World Wide Web would have gone if you needed  
to have an X terminal to use it ?  With just a little bit of care in  
the protocol design stage the possibilities for expansion are without  
bounds.  For example, I imagine that at some point a programmer should  
be able to easily write a "dumb" client which only connects to the  
server, puts the terminal in a raw mode and then just streams data  
between the socket and the users tty.  Then the vast majority of home  
users with non-networked Macs and PCs and will be able to run serial  
clients at home (which for most people is the best place to play  
games).

> But the pictures are another problem: if a client doesn't have the
> pixmap for one object, it will have to get it from the CrossFire
> server.

Exactly.  If you go to the lengths of having a naming scheme, caching,  
conversion a.s.o. for the images, why not just use the same scheme for  
the sounds (but probably with a separate name space) ?

> There are two solutions if we want to save bandwidth:

> - when the client connects to a server, the server sends all
> filenames (images and sounds) to the client, along with their id
> numbers.  Then, each time a sound or image has to be used, its id
> number (2 or 4 bytes) is sent instead of its name.

That is a false economy.  On the systems on which bandwidth _really_  
matters i.e. SLIP or 57.6 kBps fixed line systems you are trading  
adding several minutes to the startup time for being able to shave off  
some unnoticeable 2 or 3 bytes off a reference to a new image or sound.   
The user visible performance gain for that is completely below the  
threshold of noticability (and may even be a loss as I explained in the  
article about the efficiency of ASCII vs. binary I posted yesterday).

Of course this proposal also gives away a list of all images and sounds  
to the user -- arguably not as bad a problem of cheating as sending the  
entire map to the client, but nevertheless.

> - same as above, except that nothing is sent when the client
>   connects.  The names and id numbers are sent when they are needed
>   for the first time. The server will have to keep a table with what
>   has been sent to every client.  Hmmm... Not a good idea...

Exactly.  The solution is always to refer to all images and sounds by  
name.  (Not necessarily filename -- the name is just a handle used by  
the client and the server.  Either one may use it (or some mangling of  
it) as a filename, but that really shouldn't be a requirement).

> The list of id's will be created when the server starts, so there is
> no need to worry about compatibility, etc.  Static lists of numbers
> are a bad thing (look at the old maps), but dynamically-created lists
> save a lot of time...

They may (almost certainly do) save time internally for the client and  
the server.  They do not save bandwidth and do not enhance performance  
over slow links.  When Fred Brooks called premature optimization the  
root of all programming evil, he knew what he was talking about.

> I'm not sure that ASCII would help, at least on the server side. 

> Unix comes with various functions to convert short and long integers
> in network or host format (htons, htonl, etc.), so this shouldn't be
> a problem.  But we need to keep the packets as short as possible, in
> order to save bandwidth and processing time.

Ah, yes, there's the rub.  As I've been trying to explain in a recent  
post on this subject, ASCII packets are not necessarily larger or  
slower.  And contrary to popular perception parsing ASCII packets does  
not have a signficant impact on CPU performance.  Remember that we are  
not trying to parse arbitray ambiguous natural language sentences here  
like an adventure game would.  Those packets will almost always be  
machine generated and clear.  Generating and parsing such ASCII can be  
done extremely quickly.

> Obviously (?), the server will have to send its data in binary form. 

> You don't want to waste your time translating a map from binary to
> ASCII in the server, then back from ASCII to binary again, do you? 

> BTW, how do you want to translate a map to ASCII?

What the server sends the client is not the map.  What it sends is a  
description of what the player would see (for which the client then  
chooses an appropriate graphical representation).  There is nothing  
equivalent in the server.  I hope you are not suggesting that the  
server should just take some arbitrary internal structure which it  
happens to have now and just write(fd,&my_struct,sizeof(my_struct)) it  
out.  Doing so would both impose great constraints on the internal  
structure of the client and make any deep changes in the server almost  
impossible once there is an installed basis of clients.

> But, as was mentionned in a previous message, ASCII might help when
> an "old" client wants to send a new command to a server.  IMHO, only
> unrecognized commands should be sent in ASCII format.  All other
> commands should be sent in binary, with all pre-processing done by
> the client.

But why have two distinct instruction formats ?  It doesn't gain you  
much if anything in bandwidth, or CPU time and it does cost you human  
readability, ease of extension, and a huge number of bugs which are  
invariably created when sharing binary data on the net between  
computers of different archictectures (and that is not just my  
assumption -- it is an empirical fact).

	Carl Edman