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

[Daniel R. <br...@bi...>]

On Mon, Jan 10, 2000 at 03:07:37PM +0100, Uwe Hermann wrote:
> 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...

Well, with multi-line responses, it would be possible this way:

xxx Data approaching
000 Data-blabla
xxx end-of-data

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

I think it would be appreciate to use the upper method.

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

Perhaps we use another protocol for data transmission... maybe even
another port?

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

In this case, another port could be a solution also...

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

In this case, we *will* need a second protocol, therefor it could
approach data before the 34 bytes are recieved.

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

ACK

> Uaa... I don't like this. Either we make the maximum line length bigger,
> and/or use 'transmit'. 

I think, Sven's idea is good. It would save us from much trouble, I
think.

HTH Daniel