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: Christian Knoke <chrisk@xxxxxxxx>
Date: Mon, 10 Jun 2002 21:16:12 +0200

On Mon, Jun 10, 2002 at 08:52:41PM +0200, Raimar Falke wrote:
> On Mon, Jun 10, 2002 at 08:38:47PM +0200, Christian Knoke wrote:
> > On Mon, Jun 10, 2002 at 08:25:01PM +0200, Raimar Falke wrote:
> > > 
> > > 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.
> 
> "cycle" is not a CPU cycle but a
> 
>  select(connections);
>  for each connection {
>    if data can be read from this connection {
>      while there are packets {
>        execute packet
>      }
>    }
>  }
> 
> So if you can depose a lot of packets at the server AND you have a low
> connection number AND this is the first cycle after a new turn you can
> get a lot of move requests executed by the server before your enemy
> can do anything.

Ah, ok, so if you have a good client goto, you can surprise your enemy,
like the AI does right now. I can't see how it can be avoided.

> It would be fair to limit the inner loop to only one execution.

That wouldn't help if the defender does not notice the attack in time.

>       Raimar

Christian

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


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