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

[Brian Olson <locke@xxxxxxx>]

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 ]

> 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 at the 
end of each turn, at least every savegame time.

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.

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?

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.

    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 )
/*etc*/


[insert clever signoff here]
Brian Olson http://bolson.org/