[Freeciv-Dev] connection plan

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

(Ok, time to reveal the sinister plan behind my recent 
connection-related patches. :-)

I would like to see the following features:
 - multiple clients may connect to, and control, a single player;
 - or, some clients may observe a player without having control;
 - clients may connect without selecting a player, and then server
   gives them a list of players to select from, or they may observe
   the game without having a player, or maybe control the server, etc.

I started doing this once before, but it was too big a job (and lack
of time), so this time I'm trying to do it in smaller pieces.

Its a big job mainly because the code has accumulated under the 
constant assumption of each player having exactly one or zero 
connections, and each connection usually having exactly one player 
(except during initial connection join-game negotitation).  
(Note the term "player" is a misnomer which really should be eg,
"civilization", but I guess we're stuck with it... )

The plan makes significant use of "connection lists", using a somewhat
modified connection struct and implemented using speclist stuff. 
(Recall a "connection" represents a network connection to a single
client or server; this discussion will almost all be about connections 
in the server, since the client only has one connection -- thus 
connections here represent connected clients.)

Each player struct will have a connection list instead of current 
pplayer->conn.  Also there will be a connection list in the game struct 
containing all the "established" connections (maybe including some 
without associated players).  (This will somewhat duplicate the 
connections array in sernet.c, and may replace it in time?)

Thus when the server wants to send a packet to go to all connections
assocated with a player, it just iterates the player's connection list.
There are also many places where the server iterates the players, and
sends to each or to a subset.  One could still iterate the players, 
and then sub-iterate the player connections, but in some cases it may
be better to iterate the game connection list and have enough information 
in the connection struct to decide which ones to send to.  This also is
more flexible for allowing player-less observer connections.

The incremental plan is as follows:

Step 1: Code infrastructure changes, without actually changing any 
effects:
 - Adjustments to connection struct.
 - Add connection list stuff.
 - Add and maintain the server game.connections (conn_list).
 - Add and maintain a connection list for each player, but for
   now also keep pplayer->conn, and connection list will only ever
   have exactly 0 or 1 elements.
Note client can at this stage be essentially unchanged.

Step 2: Changeover code to use game and player connection lists 
instead of pplayer->conn.  By also keeping pplayer->conn at the 
same time, can do this incrementally.  Still no user-visible 
changes.

Step 3: At some point update client and protocol to understand 
about multiple connection lists to each player, though this 
shouldn't be critical, since its not that important if the client
is missing some information about multiple connections (eg, just
tell it the "first" connection).

Step 4: Once step 2 is finished, remove pplayer->conn.

Step 5: Allow multiple connections if an appropriate server option 
is set (eg, in pending allowconnect server option; eg lowercase is 
single connections, uppercase multiple?), but labelled as a very 
experimental/development feature which may not work well.  Player
connection list may now have multiple entries, in such experimental
games.  Clients may not have correct info about other multiple 
connections, etc, depending how much of step 3 is done.

Step 6: Incrementally fix up and improve handling of multiple 
connections, until it can be considered a "stable" feature, and 
then turn on the default server options if desired.

Step 7, or some time: allow non-player connections, sending new 
connections to list of players and other details, etc.  Other
related new features as desired...

The patches posted so far implement _part_ of step 1 :-)

Regards,
-- David