[Freeciv-Dev] Re: Server from Client

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Fri, 28 Dec 2001, Per I. Mathisen wrote:

> On Fri, 28 Dec 2001, Daniel L Speyer wrote:
> > Unfortunately, it doesn't.  An extended version of it might.
> >
> > I recently tried it for checking when a user had connected, but it was all
> > the same '012' as tons of other messages.  I haven't looked at what would
> > be needed to expand rfcstyle to what's needed.
> 
> The server often doesn't use the correct C_* attributes to messages. I'm
> not fixing this in the console cleanup I am writing now, but I'll have a
> go at it once that is done if none else wants to.
> 
> > What's needed is really something of a mess.  As I see it, it is nessesary
> > to use C's string handling and raw unix io to both find the reply to our
> > question (with potentially anything having been printed since we
> > asked) and then to parse it in spite of numerous free-form strings.
> 
> No. With rfcstyle, you send the server a command, and then wait for a line
> that starts with "100" or one of the warning/error codes. Once I get the
> cleanup patch done, this number will be followed byseveral quoted
> arguments, like this
> 
>       100 "Per I M" "AI"
> 
> which isn't a big problem to parse.
> 
> One problem might be that string results like "AI" might be translated...
> there are a few such problem cases in the code... I am not sure what is
> the best way to deal with it, but I think I would rewrite those few cases
> to ensure rfcstyle sends untranslated information, or perhaps by exporting
> console_rfcstyle and make if ... else tests for it in those cases.
> Definitely solvable.
> 
> >  I'm
> > starting to seriously think that every query should have a unique flag
> > that the server echos back with the answer.  Does anybody have experience
> > with this?
> 
> Wouldn't that be like rfcstyle except every answer has a unique number? I
> don't see the point.

OK, here's the problem:
Client 1 sends message to server
Client 2 sends message to server
Server answers client 1's message
Client 2 picks up answer to Client 1's message
Creash, burn, error, end of game

Now, messages on the network connections are somewhat direc ted, but it is
quite possible to cause a message to be sent to another client, so parsing
becomes a real mess again.

Also, consider:
Client sends message 1
Server answers message 1
Client sends message 2
Client listens for responce to message 2
Client pick up responce to message 1
crash, burn, end of game
Server answers message 2

Now, all commands could be required to pick up any responce, but this
looks like trouble to me.  It's sort of anti-encapsulatory and seems to be
begging for future errors.  Plus, it means that adding a responce to any
server command would mean massively re-working client code.

Putting unique tags on all messages could avoid all this without
sacrificing extensibility.

--Daniel Speyer
"May the /src be with you, always"


> 
> Yours,
> Per
> 
> "Economics is extremely useful as a form of employment for economists."
>  -- John Kenneth Galbraith
> 
> 
>