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

[Uwe H. <uh...@bi...>]

On Mon, Jan 10, 2000 at 12:38:34AM +0100, Sven M. Hallberg wrote:
> 
> >> Without the need to implement everything right away we should try to
> specify
> >> all replies we want in the concept file as soon as possible.
> >
> >Nope. The Concept file just describes how things work.
> >The specific 3-digit-numbers and the text should be in the source-code.
> 
> 
> No. Client developers should be given a clear view over which responses to
> expect.

ACK.

They must know which numbers mean what. They should not rely on the
text delivered, because this can change, and doesn't matter for the
software anyway.


> They must be specified by a set standard and not in the source.

Hmmm, well OK. But, as you said, this means the Concept will be updated
very often.


This is what we have now:

# grep send_to_client *.c
net.c:      send_to_client(new_conn, "Maximum number of connections
reached.");
net.c:      send_to_client(new_conn, "New socket descriptor greater than
FD_SETSIZE.");
net.c:     send_to_client(new_conn, "Welcome to htsserver version %s.",
VERSION);
net.c:   send_to_client(c, "Game is paused. Your input will be
ignored.");
net.c:int send_to_client(conn_t *c, const char *fmt, ...)
net.c:   lerror("send_to_client:fprintf");
net.c:   lerror("send_to_client:fflush");
net.c:  send_to_client(c, tmp);
net.c:   send_to_client(c, tmp);
net.c:   send_to_client(c, "Your login-timeout has expired. Bye.");
protocol.c:  send_to_client(c, "You must log in first.");
protocol.c:   send_to_client(c, "Player '%s' is not connected.",
destname);
protocol.c:   send_to_client(c, "Player '%s' doesn't exist.", destname);
protocol.c:  send_to_client(otherconn, "%s: %s", sendername, tmp);
protocol.c:  send_to_client(c, "Syntax error.");   /* hello commodore */


So:

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.
521 Your login-timeout has expired. Bye.
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...


Any improvements or suggestions?


> [...] but any such changes must be clearly announced in a new
> revision of the protocol standard (so client developers can state which
> standard their client complies with).

ACK.

> hm... here another thing comes to mind... A concept which is outdated by a
> new revision should not go to /dev/null right away. People should be able to
> read it as a matter of information.

ACK.

Older versions will remain on the homepage.

> My suggestion: Change D-0001 so the
> naming specification for concept files is now
> 
>     (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.

configure
mkinstalldirs
htsserver.6.in
htsserver.conf
docs/README.files
docs/ARCHITECTURES
...

Same as htsserver-0.5.5.tar.gz is not a valid DOS-name...

 
> >We still need to think of a way to transfer more than 256 bytes.
> >Maybe it's better to have protocol-commands like 'buy', 'sell',
> >'drive' etc., instead of using 'transfer 4000' and passing the 4000
> >bytes to the trade-engine? Opinions?
> 
> 
> Are we talking some kind of data transmission? What kind of data will we be
> sending that uses so much space?

prices, amounts/names of goods...


And there must be something like an 'init'-command. Everytime the client
logs in, it'll need to know the current prices, amounts of goods,
positions of his/her transporters etc. etc.


> I don't think we should be passing stuff directly to the trade engine
> because then we have some sort of sub-protocol which is kind of ugly IMHO.

Agreed.

So there will be 'buy', 'sell' etc. commands.

from docs/PROTOCOL:

buy [src] [dest] [what] [amount]  -- buy stuff
sell [src] [dest] [what] [amount]  -- sell stuff

maybe:

drive [which-transporter] [dest]  -- drive to the town [dest]
...


> Rather - if it is necessary to send large sums of data - the protocol should
> specify some sort of simple command which causes the server to await the
> data whose length will be given as an argument of the initial command.

Agreed.

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


> >Maybe the server should send
> >"000 Get list of goods from next data sent to you."
> >and then send a 4000 bytes long data-stream with all the names of the
> >goods.
> 
> 
> Server-side... hm... *headscratch*
> I don't think the server will need to send large lists of goods or whatever
> by itself.

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


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

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

> However, we should forbid nested
> replies (that's specified in FTP actually) because we won't need them and
> their an unecessary complication.

ACK.


Uwe.
-- 
Uwe Hermann <uh...@bi...>
http://www.bingo-ev.de/~uh1763/index.html
-----------------------------------------
:wq