Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: [Patch][RFC] Reduce superfluous tile_info packets
Home

[Freeciv-Dev] Re: [Patch][RFC] Reduce superfluous tile_info packets

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Cc: Michael Stefaniuc <mstefani@xxxxxxxxx>, freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch][RFC] Reduce superfluous tile_info packets
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 26 Oct 2001 08:24:04 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Thu, Oct 25, 2001 at 06:44:24PM -0700, Raahul Kumar wrote:
> 
> --- Michael Stefaniuc <mstefani@xxxxxxxxx> wrote:
> > On Thu, Oct 25, 2001 at 06:07:32PM -0700, Raahul Kumar wrote:
> > > 
> > > --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > > On Thu, Oct 25, 2001 at 06:15:00AM -0700, Raahul Kumar wrote:
> > > > > I quite like that. It's a good thing packets sent are being reduced
> > > > > considering that
> > > > 
> > > > > when the CMA goes into CVS, the total amount of packets sent is
> > > > > going to increase dramatically.
> > > > 
> > > > Although I have no numbers I doubt this.
> > > > 
> > > 
> > > Take the current case. Jack is playing a freeciv game. He creates an 
> > > aifill
> > > of 7 players. Two different scenarions happen in the client side ai vs
> > > server side
> > > 
> > > Server side(the current way)
> > > The ai never gets sent any packets about the location of its units. No
> > packets
> > > about anything basically. And needless to say, the slowest part of the
> > equation
> > > in playing Freeciv is the dial up connection. My Athlon 800 has no problem
> > > with rendering the graphics, or the AI warmap maths.
> > > 
> > > Client side(the new way)
> > > 
> > > 7 client side AI's need at the bare minimum the info on where their cities
> > > and units are. This has to be through packets.
> > > The AI's need to communicate to the server the unit moves, change in city
> > > production, change in worker tiles, etc etc that the server side ai does
> > not.
> > > 
> > > It is impossible for a client side AI to send as few packets as a server
> > side
> > > AI.
> > > This is always going to be true for absolutely any game. This is not an
> > > argument
> > > against client side AI. After all, I quite like the agents. They're 
> > > already
> > 
> > > an important part of my gamestyle.
> > > 
> > > > > A client side ai is always going to send far more packets than a
> > > > > server side one.
> > IMHO "client" in "client side AI" refers to the protocol used between AI
> > and server and not to the location where the AI runs. The server would
> > fork and exec the AI and communicate to it like to a normal client over
> > the loopback interface of the server mashine. The server will have to
> > handle more packets but your client will only get the packets destinated
> > to it (like befor). And the loopback device of the server should be fast 
> > enough to handle the packets for the AI.
> > 
> 
> I should have been more clear. Basically, when the CMA and other agents go 
> into
> CVS, the amount of packets sent to a server that is not HOSTED on the same 
> machine as the client is going to increase. There is no way around this.
> This will probably lead to a slower game.

If you go the agents-help-the-human-player-as-advisers road that the
increase is small. If you go the
agents-form-a-complete-AI-player-at-the-server road you use
loopback. Open is the I'm-locally-playing-and-testing-agents way.

> The server side AI does not care about the physical location of the machine.
> It will never need to send packets over a network to the server. The over a
> network part is the important bit.  

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Sit, disk, sit. Good boy. Now spin up. Very good. Here's a netscape
  cookie for you. Fetch me some data. Come on, you can do it. No, not that
  data. Bad disk. Bad." 
    -- Calle Dybedahl, alt.sysadmin.recovery


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