[Freeciv-Dev] Re: Server from Client

[Reinier Post <rp@xxxxxxxxxx>]

On Fri, Dec 28, 2001 at 11:35:13PM -0500, Daniel L Speyer wrote:
> On Fri, 28 Dec 2001, Reinier Post wrote:
> 
> > On Fri, Dec 28, 2001 at 12:29:22PM -0500, Daniel L Speyer wrote:
> > 
> > > 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
> > 
> > In rfcstyle, it shouldn't (except as a comment).
> > 
> > End of problem.
> 
> Maybe, if the responce tracks are really clearly distinguished.

They are: the clients are on different channels, and the server sends
different messages to each.

>This can
> still happen if multiple clients have the pipe (which the current version
> doesn't use) or if something is communicationg through /proc, which should
> probably be forbidden.

This is creating problems where there are none.
I'm against a pipe, it's the wrong design.  We already communicate
with clients via the Freeciv protocol, there's no need to add another
communication channel.

> > > 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
> > 
> > Impossible, as long as the server is single-threaded, which it will remain
> > for some time to come.
> > 
> 
> Perfectly possible.  This comes from the server replying to message 1 and
> the client not picking it up.

Oh, you're right!  My brain must have been in a knot there.

In that case the best solution is to encode the full meaning
of replies into the reply status codes, i.e. have a status code
'here comes an attribute/value pair' in /show responses, etc.
This way you don't even depend on a /show command having been issued,
such pairs can be sent whenever the values change.

Perhaps I've been brainwashed by my CS classes, but depending on state
when you don't have to is bad design.

> Admittedly, this risk could be reduced if all this were put under some
> sort of abstraction layer, which might be a good idea anyway, but it would
> eliminate the /command capability of the chatline.

The chatline command feature is a hack; it was added because it was
so easy, but it is really a kludge to work around the problems of the
Freeciv protocol.

The /show command is a hack; the information should be sent to the client
automatically, without any command, and in terms of the C data structures,
just like any information update from server to client, so the
client can read it off locally whenever it wants to.

Likewise, the /set command (and any other command) should be a regular
Freeciv update request packet.

The server command line lives in the server process so it doesn't actually
have to talk over the network; it can update the relevant structures
directly.  But conceptually this is just an optimization.

All /commands can be interpreted as requests to read the contents of certain
C structs or requests to have them updated.  The abstraction layer would
describe a fairly generic C struct updating language.  We have discussed
this in detail.

Meanwhile I saw the KGames specs; all of what we're discussing here seems
a pathetic attempt to take one step in that direction.  But KGames is
already there, so isn't this a waste of time in the long run?

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

To be honest, I prefer ~/src :)

-- 
Reinier