Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2002:
[Freeciv-Dev] Re: packet batches? (was: [Patch] Making city report list
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: packet batches? (was: [Patch] Making city report list faster)
From: Reinier Post <rp@xxxxxxxxxx>
Date: Mon, 10 Jun 2002 19:52:40 +0200

On Mon, Jun 10, 2002 at 06:18:54PM +0200, Reinier Post wrote:

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

I should add that Raimar already implements this with
connection_do_(un)buffer() and start/end_processing_request().

> It also introduces the problem of possible cheating: a client can
> batch up its requests indefinitely, to have all of them processed
> without intervention.  So the server would need to impose
> some requirements on what kinds of requests can be batched together.

The amount of possible "cheating" is limited by the fixed TCP packet size.
At the moment, the client only calls connection_do_buffer() in the CMA.
Perhaps the server should prohibit the client from sending multiple
move requests in the same TCP packet.

-- 
Reinier


[Prev in Thread] Current Thread [Next in Thread]