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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Jan 16, 2001 at 05:15:40PM +0100, Reinier Post wrote:
> 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!

As I said it can be done with the current cvs version. There is no
impact on the generic code. Just some send_*_and_wait() methods which
are additional. If there would be a packet coming back guaranteed in
every case (result_packet or the new_event packet) it would ease up
things.

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

If it is guaranteed that for every command there is response they
packet _are_ a function call. The difference between this and the
current code are: on some error conditions is nothing sent back; the
format of the response isn't nice (text) and not uniform.

I don't see why this isn't native to the freeciv code.

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

I don't see an advantage by sending code to the server. You have to
protect against cheating and DoS attacks,....

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Many of my assistants were fans of Tolkien, who wrote 'Lord of the Rings'
  and a number of other children's stories for adults.  The first character
  alphabet that was programmed for my plotter was Elvish rather than Latin."
    -- from SAIs "life as a computer for a quarter of a century"