Re: [htsserver-devel] D-0002.txt: Holsham Traders Server-Replies]

[Sven M. H. <pe...@so...>]

----- Forwarded message from "Sven M. Hallberg" <pe...@dr...> -----

sorry, pressed the wrong button again...

Date: Tue, 11 Jan 2000 14:19:41 +0100
From: "Sven M. Hallberg" <pe...@dr...>
To: Uwe Hermann <uh...@bi...>
Subject: Re: [htsserver-devel] D-0002.txt: Holsham Traders Server-Replies
Reply-To: pe...@gm...
X-Mailer: Mutt 0.95.5i
In-Reply-To: <200...@bi...>; from Uwe Hermann on Mon, Jan 10, 2000 at 03:07:37PM +0100

On Mon, Jan 10, 2000 at 03:07:37PM +0100, Uwe Hermann wrote:
> 441 Maximum number of connections reached.
> 442 New socket descriptor greater than FD_SETSIZE.
> 200 Welcome to htsserver version 0.5.5
> 451 Game is paused. Your input will be ignored.

What's the purpose of a pause command? The game can't be paused, if someone
wants to leave the game, let him leave... It has no effect on his situation
when he returns.

> 521 Your login-timeout has expired. Bye.

What's a login-timeout (in this case, of course). Sorry, I'm not up-to-date on
the source...

> 421 You must log in first.
> 422 Player is not connected.
> 423 Player doesn't exist.
> 000 Chat message from XXXX: "foo bar ..."
> 511 Syntax error.
> 
> 
> The chat-message is an exception, here, because important information is
> stored in the text-part, which is not a very good solution. I'm not
> quite sure about how to make this better, at the moment...

Multi-line?

> > 
> >     (D|C)-xxx-yy.txt
> 
> (D|C)-xxxx-yy.txt
> 
> > where 'xxx' is the concept ID and 'yy' is the revision number. Note:
> > changing the concept ID to a 3-digit number keeps the name fitting in MS-DOS
> > style 8.3 notation.
> 
> That's not *that* important. First, I don't think this will ever be
> ported to DOS. Second, there are already lots of files in the distribution,
> which don't fit in the 8.3 notation, e.g.

Good point, thank you :)

> transmit [count]    -- client must wait for server to transmit [count] bytes.
> 
> But we possibly won't even need this. Most of the time this could be
> built in the corresponding command, e.g.
> 
>  update-prices 34
> 
> And then send 34 bytes containing new prices for some goods, e.g.
> 
>  Wheat 56, Wood 11, Oil 87, Gold 119

ACK.

> It will. The server must inform all affected clients of changing prices,
> changing amount of goods etc.

The key word is _affected_. A client will only need updates on stuff that it's
currently displaying on-screen. That will not be everything, so we'll actually
only have stuff like

000 Price update...
 Wheat:25
 Fluffy Rodents:104
000 End update.

> > that will probably only be caused by some sort of client request
> > for a complete list or something.
> 
> Definately. But not only. The server will send data, without being
> asked to, too.

see above.

> > But in any case I suggest using a
> > multi-line reply. That reminds me, I'd make multi-line repies have the form:
> > 
> > xxx-blahblah
> > otherblahblah
> >   moreblahblah
> >  xxx blahblah that looks (almost) like the end line
> > xxx end of blahblah
> > 
> 
> Uaa... I don't like this. Either we make the maximum line length bigger,
> and/or use 'transmit'. 

I don't like 'transmit' :) It kind of "bends" if not "breaks" the protocol.
Let's increase maxlinelen to 512. That should be sufficient provided we don't
allow good names that are too long. That however is not good anyways because
then they won't find nicely into any display window.

I think a rather short limit on good names should be set. That forces readable
names. What about 32 characters (including trailing newline of course, because
33 is not a buflen you want (real programmers appreciate their powers of
two!)) ;^)


TTL expired,
Sven

-- 
Sven M. Hallberg <pe...@gm...>
PGP key available at http://www.sh-home.de/~sol
 [ KeyID........: 0x0F520CF9 ]
 [ Fingerprint..: 56 61 00 18 14 B4 01 01  06 90 D0 29 96 BD 58 6F ]
return 0;

----- End forwarded message -----

-- 
Sven M. Hallberg <pe...@gm...>
PGP key available at http://www.sh-home.de/~sol
 [ KeyID........: 0x0F520CF9 ]
 [ Fingerprint..: 56 61 00 18 14 B4 01 01  06 90 D0 29 96 BD 58 6F ]
return 0;