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

[Christian Knoke <chrisk@xxxxxxxx>]

On Mon, Jun 10, 2002 at 08:25:01PM +0200, Raimar Falke wrote:
> On Mon, Jun 10, 2002 at 08:07:10PM +0200, Christian Knoke wrote:
> > On Mon, Jun 10, 2002 at 07:52:40PM +0200, Reinier Post wrote:
> > > 
> > > > 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.
> > 
> > How do you think it's cheating? If the user buffers everything up to
> > the end. If the data receive the server too late, he is bad off.
> > Also, his commands can fail. Movements can fail due to ZOC. And this
> > happens in battle where you may think it is an advantage to batch the 
> > move requests. In any case, he must process his batch before turn done.
> 
> > Do I miss something?
> 
> It is indeed possible for a faster client (faster means here faster to
> push requests into the incoming socket buffer of the server) to get
> more requests executed per "cycle".

But where is the advantage? Neither server cycles nor network volume
is a limited ressource. I still don't get it.

> Another thing which is unfair (at least theoretical) is that the
> connections are scanned in a fixed way. So if you got a low index in
> the connections array your requests are always execute before the
> requests of another player. But this only matters if the server gets
> more than one request from all player in one cycle.

-- 
Christian Knoke     * * *      http://www.enter.de/~c.knoke/
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.