Re: [Freeciv-Dev] Forking of the client

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

James Blackwell wrote:

> ClientA: Hey Server! I need a map update!
> Server: Ok ClientA. Here it comes 
> [Server forks off connection and starts sending to client]
> ClientB: Hey Server! I'm moving my unit to x,y
> Server: Ok ClientB. Doing it.
> [Server sends unit move update to all clients that can see it]
> ClientC: Thanks Server Dude!
> ClientB: Thanks Server Dude!
> ClientA: HEY! This doesn't look like the map to me! I'm confused! Live is 
>          no longer worth living, and I should core!

This is why the client _doesn't_ actually wait for any specific
response from the server, right?  I'm not sure if the client 
really does ask for map updates, but an example fresh in my
mind is when a diplomat bribes :-)  The client sends a
PACKET_INCITE_INQ (inquire for the bribe cost), expecting
back a PACKET_INCITE_COST.  But the client doesn't actually
remember that its waiting for a PACKET_INCITE_COST -- it just
processes packets normally.  If the server is kind enough to
eventually send a PACKET_INCITE_COST, the client triggers on
that and pops up the appropriate dialog.

While this approach may make some things more difficult, it
does seem to me quite robust, in terms of avoiding problems
with ordering of packets, and lag, etc.

Though I don't really see this impacting either way on
the idea of having the server fork a process to communicate
with each client.  But I don't know enough about 
sockets/processes etc to comment on the pros/cons of that idea.

Regards,
-- David