Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol

["Carl Edman" <>]

Kjetil Torgrim Homme <> writes:
> >--- Carl Edman:
> > Confirmations are not given or expected.  The sender just assumes
> > that the receiver will handle the packet or it will complain in
> > another packet.  At the same time the two chutes may be
> > communicating about two entirely different subjects.
> 

> Seems like a a good design goal. QUERY/REPLY doesn't fit into this,
> though, see below.

It is true.  QUERY/REPLY was a late addition which nevertheless I think  
is needed (though your version may be better).

> >---
> > Each packet consists out of one line of text terminated by a
> > newline (0x0a) character.  Line lengths of up to 4096 characters
> > (including the terminating newline) are guaranteed to work.
> 

> Of course, "packet" here is in the meaning "command" - one command
> can consume several TCP-packets (or whatever) or the other way
> around. A TCP-packet can contain one and a half command, and the
> first command must then be processed before the other half of the
> second command arrives. (Obvious, but I think it needs saying)

Absolutely.

> > All characters are case sensitive. 

> 

> Good! I'd like to add something like "whitespace is not ignored and
> not allowed in arguments except where indicated.

Well, one could add that but it wouldn't gain much.
   while(isspace(*c)) c++;
is not really more complicated or slower than 

   if (isspace(*c)) c++; else error(..); if (isspace(*c)) error();

> Control characters (0-31, 128-159) are only allowed in binary data."

Let's make it client dependent with clients encouraged to interpret  
characters with the high bit set as ISO Latin characters where that is  
easily done.  No reason to make life harder than necessary for our  
european friends. :-)

> > VALID COMMANDS FROM THE SERVER TO THE CLIENT
> > ============================================ MAP <locx1> <locy1>
> > <image1> <locx2> <locy2> <image2> ... Using one of these commands
> > the server may tell the client that it sees the map at a series of
> > location given by coordinate pairs.
> 

> You haven't defined coordinate, but I assume it is relative to the
> top left corner of the map, and that the axes runs from top to bottom
> and left to right.

Doesn't really matter.  All the client has is the current coordinate of  
the view point object and the coordinate of something in the map.  If  
everything the top left corner happens to have coordinate -10000,43434  
who is to care or to know ?  I'd like it that way to make one of my  
private preferences -- making all maps appear as just one big seamless  
map to the player easier.  But that is not really a dependent matter.   
In any case probably the most efficient way from a bandwidth standpoint  
is to chose the origin of the coordinte system to be wherever the  
player entered the map.

As far as the axis are concerned my prejudice is towards the  
mathematical convention i.e. x-axis starts at the far left at negative  
infinity and goes to the far right at plus infinity, the y-axis starts  
at the bottom of the page at negative infinity and reaches plus  
infinity at the top.  In any case a client which got this convention  
wrong might appear slightly confusing to the player who is used to see  
the map the other way around but would be perfectly functional.

> This doesn't seem cater for seeing several objects at a spot in the
> map, though. Suggested solution: Default number of objects is 1.
> The client can send a SET command.

Ah, here I disagree.  The way I see it every location has just one map  
type which describes what kind of 'terrain' it is in.  _Everything_  
else is items.  How the client choses to represent items (only display  
the top one, overlay them, whatever) is purely up to it and the server  
doesn't care.

> There will be more SET commands to control client/server
> communication, for example "SET IMAGEFORMAT XPM". Unimplemented SET
> commands should be ignored by the server. A companion command "SETF"
> should be used if failure to recognize the command is fatal to the
> client. The server will then send an ERROR packet in reply.

I'm prejudiced against SET commands in all kinds of protocols and  
languages.  In general they just add four characters which need to be  
sent with little gain.  If you really want an IMAGEFORMAT command, why  
not just call it IMAGEFORMAT ?  


Besides I think that image format is something which really should be  
up to the client.  Or are you going to add more conversion code to the  
server every single time a new client is created ?  Standard TIFFs for  
NeXTs ?  Macintosh TIFFs for Macs ?  Whatever benighted format Windows  
uses ?  GIFS for PCs ?  IFFs for Amiga clients ?  Let the clients worry  
about image conversion.  The server should just one format with the  
requirements (in order of significance) that it a) be simple and easy  
to convert into most other formats and doesn't require any big  
non-portable libraries to make use of like TIFF or XBM, b) contains a  
great deal of information so that even reasonably high end clients get  
displays worthy of them and c) is reasonably compact.  The last  
requirement is not all that important considering that with this  
protocol only a few bitmaps are transferred and even that in a nice  
interspersed manner.  Clients will cache the images in a format which  
doesn't contain more information than they need anyway.


> Should the view change immedietely, or is it reasonable for the
> client to wait until it receives a new ITEM for that tag?

Probably the server should send the item command first and the view  
command only after that.

> In general, how much caching/state _must_ the client have? MOVE seems
> to assume some state, but it is not clear to me.

Oh a lot of it and the higher quality the client the more.  MAP and  
ITEM instructions are not to be understood as command to the client to  
"draw this now there !".  Rather they are a description of the world  
which the client adds to its own internal 'world database'.  It is that  
database which it uses when it has to draw something.

> > QUERY <...> Ask the user a question with the text <...>.  Some
> > clients may want to pop up a requestor for this.  Others may not. 

> > The answer is taken from the next REPLY packet sent by the client. 

> >
> > REPLY [YES|NO] The response to the most recent QUERY command.
> 

> This won't do. My suggestion:

Yeah, probably you want to do something like you suggest.

> EXAMINE <locx> <locky> If <locx> is "IN", the server sends a
> description with REPLY <locy> <text>.  If <locx> is a real
> coordinate, a sequence of ITEM packets for all objects at that
> coordinate is returned in bottom up order, terminated by an automatic
> REPLY <tag> <description> for the topmost object.

Not at all -- this is important !  Examining items or locations is  
something which is done 100% client side without any server calls.   
That is what all those ITEM calls were good for.  At all times the  
client already know what visible items there are, where they are, what  
they are called and what they look like.  It also knows what the floor  
looks like everywhere in sight and it may have drawn a map of what the  
floor looks like everywhere else.  As a matter of fact a 'magic  
mapping' spell would be implemented by sending the client map commands  
for all squares in the map and then unmaps at end of the spell.  


> Maybe also COMMAND <command> This should be used for things like
> "who" and "pickup" unless we decide to put _everything_ into the
> protocol.

well, i see no reason not to.  BTW, i think pickup can be implemented  
purely on the client side.

	Carl Edman