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

[Reinier Post <rp@xxxxxxxxxx>]

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?

Yes; sometimes you're willing to pay the price of delay if it means that
your moves are going to be executed without intervention.

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

Being on a faster connection is not really "cheating".  But of course
the server can always pretend that packets actually arrived separated
by some delay, or something.

As I said, I don't understand TCP/IP very well.  Perhaps even on
slow connections, a batch of packets sent at the same time
will usually arrive at the same time.  In case of transmission
errors, packets will be clustered *more*, not less.

If I understand correctly, the output is a bigger issue.
I don't think the send_packet_() calls can block, but the server
sometimes sends flush_packets(), and that may cause incoming packets
to queue up.

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

This can be fixed by using shuffled_player().

>       Raimar

-- 
Reinier