[Freeciv-Dev] Re: CMA passes back control without reason (PR#1505)

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Jun 03, 2002 at 04:45:22AM -0700, Christian Knoke wrote:
> On Mon, Jun 03, 2002 at 01:27:36PM +0200, Raimar Falke wrote:
> > On Mon, Jun 03, 2002 at 04:08:19AM -0700, Christian Knoke wrote:
> > > On Mon, Jun 03, 2002 at 12:56:30PM +0200, Raimar Falke wrote:
> > > > On Mon, Jun 03, 2002 at 03:03:57AM -0700, Christian Knoke wrote:
> > > > > On Mon, Jun 03, 2002 at 02:38:08AM -0700, Per I Mathisen wrote:
> > > > > > On Mon, 3 Jun 2002, Raimar Falke wrote:
> > > > > > > > I think attributes shouldn't be sent to the server at all.
> > > > > > >
> > > > > > > See the threads from 2001 why this isn't a good idea. Basically 
> > > > > > > you
> > > > > > > can't know what are the proper attributes for a savegame if you 
> > > > > > > don't
> > > > > > > save the attributes in the savegame.
> > > > > > 
> > > > > > Maybe the server can request the attributes from the clients when 
> > > > > > it wants
> > > > > > to save them? That way we minimize the number of times you need to 
> > > > > > send
> > > > > > them to the server.
> > > > > 
> > > > > Maybe both? Transmitting each turn + transmitting on server request 
> > > > > (on
> > > > > save). This gives great chance that attributes are stored properly. 
> > > > > If the
> > > > > client/connection crashes not much is lost. Low Bandwidth. Easy to 
> > > > > implement
> > > > > I hope/guess.
> > > > 
> > > > Saves usually happens each turn. So I don't see the difference.
> > > 
> > > The difference is, 
> > >    1. it avoids the bug this thread is about, 
> > 
> > Why? How?
> 
> Ok, sorry, I'll be more verbose. The bug "CMA passes back control ..."
> occured, because the player changes the CMA setting after "turn done",
> before saving the game. Thus the CMA changes got lost. But other game
> settings, i.e. tax rates *are* saved. So the old CMA setting can't
> fullfil the new requirements (after reload) and passes back control.

Ok. But you get other problems: what if the client don't answer? How
long do you wait? Also while you wait for the response you can't
accept packets from other connections.

> > >    2. it (really) saves attributes when the game itself is saved.
> > 
> > I also don't understand this. The client sends the attributes before
> > the PACKET_TURN_DONE is sent. So the server will have up to date info.
> 
> This is only true if the player saves immediately after pressing turn done
> (and even this is not guaranteed), what can by no means supposed.

Ok. I think the best for the release would be to leave it as it is
now. After the release we should change to code to retransmit the
attributes after every change AND implement some bandwidth savings
(i.e. only transport the changes). 

Or we can think about client side saving of attributes. But this would
be hard since the server and all clients have to have consistent
state. Something like this:

 user request save at the server
 server requests save from all clients
 all clients reply
 server freeze (no network communication)
 server saves
 server calcs hash over savegame
 server thaw
 server sends save-finished with the hash
 clients save their current attribute under the given hash

The server has to obviously send the hash of the savegame at the
start.

This would work but is a lot more complicated.

        Raimar
-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 checking for the vaidity of the Maxwell laws on this machine... ok
 checking if e=mc^2... ok
 checking if we can safely swap on /dev/fd0... yes
    -- kvirc 2.0.0's configure