Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: client server part 1



 There are serveral goals of client/sever:

1) To make it a low bandwidth protocol (sufficiently low so that it
can be played over modem 14.4 is an optimistic goal, but it should be able 
be played at 28.8 no problem.)

2) To keep a smart client, but assumed unsecure client.

3) To keep things relatively simple in coding standards.

 (these are not in any order.)

 So some comments:

 I don't see how using absolute map coordinates enable the client to cheat.  Information
will only be sent to the client if the client should know
about it.  Thus, if the player is at 20,20, then only information
from 15,15 to 25,25 will be sent the client (this is the 11x11 map area.)

 The only hint that absolute coordinate gives are the size of the
map.  The player might then also be able to mark locations of
certain things, but even if using relative coordinates, the
client could still keep track locations (ok, so stairs we just
came down aren't at 20,25 (absolute), but are at +5,-5 to where we
are.)

 PROTOCOL just describes what commands the client and server understand.
The server can care less if the client is a mac or ibm, is in 3d
graphics mode, using pixmaps, or anything else.  The client is
just something to send the data to - it is up to the client to handle
that data appropriately.

 Also, any strings that have spaces should be double quoted.  So
order is not really important, but it is true that keeping such
strings as the last data element is a command does make some
things easier.

 SEND_IMAGE_NAMES & SEND_ARCH_NAMES:  In general, the client should only
be missing a few of these images.  If you are missing a lot, you probalby
don't want to wait for all of them to be transmitted when you enter
a map (there may be monsters around.)  Also, to find all the images/archs
used on a map would be quite slow (it would require the server to
go through the map and see what is used.)

 STACKING:  This is one of the few commands which does make the
server treat the client differently.  It is in place because if you
are using fonts or normal pixmaps, you can only see 1 object per
square.  So why send all the objects on a square, killing bandwidth.  And
in some cases, even with XPM which can display numerous objects), you
might not care about see all 10 objects that the dragon drops when it
dies - in general, onany more then a few just get
blurred into a jumble.  But maybe you do want to see all.  Then you
set STACKING to some very high value (or maybe -1, to mean all.)

VIEWRANGE & HEARRANGE: There server (at least now) will never le the
client know about something than an 11x11 map (to do so would greatly
change teh game, and give some clients huge advantages).  I can't think
of why you would wan it smaller than that either (and if so,y you could
just ignore the data that is in that out of bounds area.)

MAP: ranges will be  pain to do on the server side (the server then
needs to start examining the rea to see if that object is on the
next square, etc (so much for rule #3 above).  IT will save bandwidth,
but depending on the stacking, it may not make much difference (if
you have some floor, but mostly hve chairs & monsters on it, then
to send that range of floor if the person just has a font display
doesn't do anything.)

 When sending data the the client, the server doesn't cht check to see
if the write wil lblock (and as far as I know, you would need to send that
character, check with another select, etc.)
In fact, if the server sends to much data so
the buffer overflows, that data is lost (the server does check for
this.)  If the client is that far behind, it won't be able to play
at all -it will probably be several ticks behind on its data.
And if data would block, what do we do?  Buffer the data for a future
write?  This would be a pain.  32K is a pretty big buffer - it
should only be a problem if we have really poor net
connectivity.  No matter what, in some case, there is some point where
the server just can not send data to a client that is so slow.

 ATTACK:  Attacking is not a true command.  Right now, an attack hapens
when you try to move into an unfriendly creature.  That is how it
should remain.

 SAY will act just as the say command does.   QUERY & REPLY commands
have no use - at least not until how things are asked.  Right now,
a monster just says something, and listends for a response.  There is
no matching with what the monster says and its expected response.

 GENERAL NOTE: I've look over the Protocol file, and for the most
part, it seems just fine.  I am not going to make any significant
changes - that would then delay any developement on client/server until
an agreed upon protocol is once again formed.  This one was
discussed (but I have made some changes to make coding easier), and unless
I see a very good reason it should be scrapped or have significant
changes made, it will for the most part remain as it is.

 --Mark