[Freeciv-Dev] Re: [PATCH] Unit movement

[Reinier Post <rp@xxxxxxxxxx>]

On Tue, Jan 16, 2001 at 12:30:22AM +0100, Raimar Falke wrote:

> Let me rephrase what I think: the communication between server and
> client is asynchronous. It was design this way because humans didn't
> notice the delay or can handle it. In general (not limited to freeciv)
> it possible to use a asynchronous protocol in a synchronous way. To do
> this with the current freeciv protocol it would be nice if there is a
> result packet but it is also possible to do without the extra packet.
> If the request will be serialized there is a performance impact in
> terms of extra delay. I'm willing to pay this price to get an easier
> programming model. I'm not sure if synchronous use of the protocol
> would really simplify the code. But my feeling says yes.

Well, my feeling says no, and it is a big price to pay in terms of
complication of the Freeciv code; this is why I brought it up.
But it's you doing the coding, and I hope you are right!

> > > Suppose <http://arch.freeciv.org/freeciv-dev-200008/msg00248.html> is
> > > implemented with an extra result field and a serial number of command
> > > field. And if there would be a serial number in every command would
> > > this solve your problem? (I will propose something like that if the
> > > attributes are implemented)
> > 
> > I think it's a good idea to extend the idea presented there and I also
> > think extended to a general way for the client to obtain information
> > about the game state from the server.  But if you are going to use
> 
> It is about returning information to the clients.

Yes, but it is about single request/response pairs.  They look like calls
to the user, but they do not look like that in the Freeciv code.

> > it as a vehicle to specify actions, changes to the game state, I think
> > it will be a better approach to specify actions to run at the server
> > side.  See
> > 
> >    http://arch.freeciv.org/freeciv-data-200101/msg00001.html
> > 
> > for what that could look like.
> 
> Nice vision. It would be nice if the server accepts string
> commands. No need to for {send,receive}_packet_*. However if I look at
> the current protocol and how sometimes data is compress into bits to
> preserve bandwidth I think it would be hard to have a "big" protocol
> of ascii strings accepted. The coding/decoding has do be done
> nethertheless. Maybe also other methods (CORBA for example) can be
> used.

I agree, but the ASCII-to-binary encoding can be done on the client end,
if the binary reporting facility (used for server options now) is
extended.
 
> > Of course, if you can produce a client AI based on your ideas
> > I will only be happy to use it, but at the moment I don't see
> > how the approach of feedback packets is going to pay off.
> 
> I all depends how the ai code on the client will be/can be/is
> programmed.

My problem is, I can't see how to program the algorithms
as C algorithms, because of the synchronization issues.
Another problem with C is how to make them scriptable, but
maybe that is not your goal.  With a scripting language it
would be possible to send programs to the server as easily
as executing them in the client.

-- 
Reinier