[Freeciv-Dev] Re: packet batches? (was: [Patch] Making city report list faster)

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Jun 10, 2002 at 06:18:54PM +0200, Reinier Post wrote:
> >   (It looks like it does this by monitoring the request ID, which is a 
> > direct result of work for the CMA.  This is also a bit of a hack, and 
> > probably a bit unstable in the long term as well.)
> 
> Requests may fail.  Raimar sends failure notifications.
> But what happens if CMA is disabled?

The old network protocol is too relaxed to allow client side AI. It
works ok for human players but not for programs. Basic problem is:
"when is my request executed?" (so at the time you know that your
request got executed you can check if the data that you expected is
send by the server or in other words you can check if the server has
executed what you have calculated). This problem was extended to
include a solution to the question "which packets are caused by this
request".

So this is a requirement for all client side AIs especially agents
especially CMA.

> With all respect I have for Raimar and his design desision to use
> request IDs, I think Freeciv is worse off with them, because they are
> fundametally a hack.
> 
> > However, there is still lag: the change cannot be made until the last 
> > packet from the server is received.
> 
> I think that is acceptable.
> 
> > I think there is a better, and more 
> > general solution that is possible.  When a change is made by the user in 
> > the GUI, the client should change that data internally _as well as_ send 
> > the request to the server.  When the server responds, the client again 
> > updates.  If the change was approved, everything is easy and no action 
> > is needed.  If the change was not approved, it must be reverted at the 
> > client end.
> 
> That would be nice.

> Another thing that would help is batch processing for packets.
> 
> Packets would contain 1 or more requests/notifications (the existing
> packets).  The send_packet routines would not send requests/notifications
> directly, but save them up; a 'flush' operation would send them off
> in a packet.  Packet processing would just iterate over the received
> batch of requests.  You send the 'change all' in a batch, and the server
> responds by sending the city info notifications in a batch.
> 
> Then you can be smart about city info updates by looking at the batch.
> It still introduces state, but at least the state doesn't cross
> over to the server.
> 
> Of course you have to remember to flush in time.

If these packets are saved up at the client side: you can already have
this today with buffer/unbuffer.

If these packets are saved up at the server side: ???

> There was some discussions about requests when Raimar proposed them.
> Some info updates are already being sent in batches.

All server response of one request is send in a batch. With the
disable_cityrep_update_till patch also the client will batch "multiple
requests".

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Understanding is a three-edged sword; 
  your side, their side, and the truth."
    -- a well-known Vorlon