[Freeciv-Dev] Re: [RFC] Attaching information to objects

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Jan 13, 2001 at 06:55:53PM -0700, Brian Olson wrote:
> On Saturday, January 13, 2001, at 02:19 PM, Raimar Falke wrote:
> > AFAIK there are no variable length packets so a transfer between 
> > server and client is limited. 
> 
> Maybe it's time to make one.
> 
> > Say we have a compound key consiting of <object type, id, subkey>. And 
> > there are values of variable length up to a maximum. 
> >  
> > key1:1111111111111111111111 
> > key2:222 
> > key3:3 
> > key4:444444444444444444444444444 
> 
> all good so far. maybe pack a 64 bit compound key as [ 4 bits type;
> 28 bits subkey; 32 bit id ]

Now I understand this. Agreed.

> > The numbers denote the values. I know of two ways to map <key, value>s 
> > into a block: 
> >  - put them all together: 
> >     key1:1111111111111111111111 key2:222 key3:3 
> > key4:444444444444444444444444444 
> >     There are problems if one values grows. It preserves space and 
> > bandwidth. 
> >     At restarting time you have to find all keys. 
> >  - pad them up to the maximum 
> >     key1:1111111111111111111111ppppp 
> >     key2:222pppppppppppppppppppppppp 
> >     key3:3pppppppppppppppppppppppppp 
> >     key4:444444444444444444444444444 
> >     Values can grow. Needs extra space. 
> 
> I like the first representation. There is no problem from
> growth. This is not the active representation, merely the
> transmission and server-side storage representation. On the client
> side it's anything you can dream up with pointers. Given that the
> server does not interpret this data, only stores it until there is
> cause to send it to the client, the client is required to send all
> the data when any update is needed. Such an update is rare, at most

Ahh I understand: I only want the changed data to be
sent. (Calculation for a mid game player: 30 objects*3 keys each*30
bytes per value=2700 bytes)

Open question: How do you find the keys in the block? By a header
which consists of the offsets of all keys in the block? (90 keys*4
byte index=360 extra bytes)

I agree this would make the server truly dumb.

> at the end of each turn, at least every savegame time.

I'm not sure if the client knows about savegame time. Lets say the
block will be transmitted at least every turn.

> If you really want more frequent updates, then yes, I guess the
> server has to understand the structure of the hash and single
> key:value packets are transmitted.

> > To reduce packet count you have to fill the packets. Something like 
> > scather/gather(sp?) is needed to enable the client to 
> > request/overwrite more than one continuous region of the block. 
> 
> Yeah, or just write in a buffered way.
> 
> > To reduce code on the server side what about this: 
> >  - the client will contruct an compound keys like mention above 
> >  - the server will load/store based on such key-value pairs. So there 
> >    is only one hash per player. If you think this is to much you can 
> >    reduce this to one hash by prefixing the key with the player-id. 
> > Now the client is much more easy to code. 
> 
> I like that regardless of how much the server knows about the hash. Hash per 
> player a good granularity.
> 
> If the server understands the hash table, the client and server will
> be exactly duplicating the hash when stored in memory, otherwise the
> server will posses the same information as the client-though in
> won't interpret the data by any structure. The client should 'cache'
> the hash, but that really means keeping a local copy. The local
> 'cache' is some variant on a write-through cache, posting changes
> either as they happen or in a deferred fashion. If deferred to the
> turn end then I think it's quite likely that a majority of values
> will have been altered and so you may as well write them all at once
> as a block of data. If the average turn-end dirty percentage is low,
> then there may be savings in sending only updated records (requiring
> server understanding of the format). The longer the deferring of the
> 'cache-flush', the more records will be dirty. The inverse is also
> true.

Agreed.

> The data-block method is simple for the server and flexible for the client.
> It also goes well with the far-between updates I believe are appropriate.
> 
> Why would you want more frequent updates? Why would you expect low
> entry-dirty rates that would make partial update more efficient?

I don't have more information about this than you. We have to
implement it one way and wait to get same data.

> Regardless, these 8 hash functions should be easily implementable as
> a client-only feature for the immediate future. Maybe figure out a
> server update policy after there are some concrete uses of this
> service.

I see you came to the same conclusion.

>     int {tile,player,city,unit}_get_attrib(int id, int key, int max_length, 
> char *data);
>     void {tile,player,city,unit}_set_attrib(int id, int key, int max_length, 
> char *data);
> or 2 functions
> enum attr_type {
>       attr_tile,
>       attr_player,
>       attr_city,
>       attr_unit /*other? 4 now, could be more? */
> };
> int get_attrib( enum attr_type, int id, int key, int max_length, char *data);
> void set_attrib( enum attr_type, int id, int key, int max_length, char *data);
> #define tile_get_attrib( i, k, l, d ) get_attrib( attr_tile, i, k, l, d )

Something like above or:
enum {
  attr_tile_start=0,
  attr_player_start=100000,
  attr_city_start=200000,
  attr_unit_start=300000
};

enum {
  attr_unit_auto_settler=attr_unit_start,
  attr_unit_auto_explore,
  ...
};

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "This is Linux Country. On a quiet night, you can hear Windows reboot."