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

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



"Eric A. Anderson" <eanders+@CMU.EDU> writes:
> Kjetil Torgrim Homme <kjetilho@ifi.uio.no> writes:
> > +--- | 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)
>
> I think it might be better to transfer each packet as a size and the
> data.  This will work for both strings and binary data, and it
> eliminates the problem of having to figure out how much of the data
> is really yours. -- You can also eliminate arbitrary limits like 4096
> using this strategy.

Well, maybe.  That is the scheme I used in my last prototype client for  
a game like this (you know, the one which makes me dislike binary  
protocols so vigorously :-) ).  


However, that means

(a) that you can't any longer use telnet or any of the other standard  
line oriented clients to just check on a server when you have no client  
available which makes debugging harder 


(b) you need an arbitrary limit anyway.  Many clients will run on  
relatively small computers without virtual memory where you can  
guarantee correctness without a guranteed maximum packet size.  And  
while the server is probably running on better hardware than the  
client, it too has limits.  And considering that virtually every game  
like crossfire attracts immature hostile players earlier or later who  
may want to bring down the server (i.e. as revenge for having died),  
the server too needs to put some limit on packet size in any case.

(c) (for the byte counters)  That adds an extra 1 or 3 bytes to every  
single command !

	Carl Edman