Re: [Freeciv-Dev] Patch: Server end for client data saving

[Marko Lindqvist <caz@xxxxxxxxxxxxxxxx>]

On 22 Aug 1999, Falk Hueffner wrote:

> Marko Lindqvist <caz@xxxxxxxxxxxxxxxx> writes:
> 

 Umh, this mail have many sentences with words 'my implementation'. It
may(?) sound egocentric, but since there's nothing else (as far as I'm
aware) to which compare your suggestions...

> >  With this patch server stores some data for client, saves it with
> > savegames and sends back to client when loads savegame. There is no client
> > to ask this. I have just created this patch to be used with my client side
> > AI.
> 
> I like this idea. Has lot of uses.
> 
> But I think your implementation is a bit too complicated. I think 1
> byte as basic unit is even more manageable than 12 bytes.

 More manageable yes, but data/header ratio would be much worse. Someone
was already worried about used bandwith when there was some discussion
about implementing client data saving. Well, I have to admit that it was
said conserning fog of war, for which my patch does no good. (Server
memory usage is the same as if server figures maps out itself and then
there's used bandwith)

> Also, the
> server should notice itself when it has to allocate memory.
> 

 You got a point. I didn't think about that. For my present implementation
it does not matter much though. First PACKET_CLIENT_SAVE_HEADER have to be
sent anyway for header string, for memory freeing
PACKET_CLIENT_SAVE_HEADER have to be sent anyway. Also client always have
to be aware where it puts packets, and from place of the last row it's
quite straightforward to know required memory.
 There is also matter of asking too much memory. Currently server gives to
straight question straight answer. If it gives no more memory to client,
headers stay same. It would be more comlicated for client to detect failed
memory allocations, if it doesn't ask for them directly. Send data would
also be lost forever.
 Of course there's solutions to these problems, but is it worth it to
make server detect allocation need itself?


> I would do it like this:
> 
> - a packet PACKET_CLIENT_DATA, which has two strings, the key and the
> data, with the only restriction that the sum must not be larger than
> the maximal packet size. If, for example, somebody implements
> Auto-Elvis in his client, the client could send packets with key
> "AUTO-ELVIS Tenochtitlan" as key and "1" as value (or use an internal
> id and the city-id to save space). If value is empty, the server
> removes the key to save space.
> 

 Well, I think this comes to question flexible and complicated versus
simple. With my implementation this would be done just by sending one row
with using first couple of chars as id for "AUTO-ELVIS" and rest for
city-id. What I mean by flexibility is that this is not the only way to
use it.
 Your version does not require client to know in which order data is
stored, when my implementation does. On the other hand, my client does not
require server to search for id's (except if saving places are used as
id). So it's just a matter of whether actual place for data is decided at
client or at server.

> - a packet PACKET_RECALL_CLIENT_DATA, which has one string, the key,
> and would the server make send a PACKET_CLIENT_DATA packet.
> 

 This is something my implementation not yet perform, but if it's really
needed it's easy to add as some kind of command (as I suggested when
sending my patch).

> - on reconnect, the server would send out all packets it has saved. I
> can't really think of a use for querying keys, but probably there is
> one.


 Of course my views are affected by the fact that my implementation is
just created for my needs, and since it fulfills them I consider it
flexible enough. On the other hand, I know it well enough to know how it
works and how it should be used, so I don't think it too complicated.
Truth can be that it's very complicated, but can't do anything usefull.


 Caz