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

[quinet@montefiore.ulg.ac.be (Raphael Quinet)]

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.  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.

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.
- 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...

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...

> > I personally don't see the need of the client to be extremly
> > efficient in how it sends to the server as really important.  I doubt
> > the client will be sending a lot of data.  However, how the server
> > sends to the client is much more important.  But it also depends on
> > what information the client knows.
> 
> I agree completely.  Remember that every TCP/IP packet (and UDP/IP is  
> not much better) has 40 bytes overhead.  Most single commands sent  
> using either ASCII or binary in either direction will be completely  
> swamped by that in any case.  The only exception will be the actual  
> contents of sounds and images and they will be transferred by an agreed  
> upon, simple binary standard in any case.  Given that we agree on that,  
> why not use ASCII to send commands and descriptions either way given  
> all the advantages I listed in my other recent post on this subject ?
> 
A few weeks ago, there has been a discussion about the server->client
protocol.  The most important thing is that several commands should be
sent in a single packet, to avoid the 40 bytes overhead.  (There were lots
of useful info in these messages.  Read them again if you forgot...)

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.

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?

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.

-Raphael