[Freeciv-Dev] patches: multi_conn2 (multiple connections per player)

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

I have uploaded to ftp a second set of patches to have Freeciv allow 
multiple connections per player.

  ftp://ftp.freeciv.org/freeciv/incoming/multi_conn2.tar

This contains 11 gzipped patches (to be applied in specified order), 
with explanations included, and reproduced here:

----
conn_more_misc1:
More miscellaneous connection list conversions.

cmd_list_more1a:
For 'list connections' show command levels.  For 'list players' add
ability to show multiple connections per player, and other revisions, 
including showing nation name.  Set pplayer->username to something
sensible for barbarians and civil war rebel players when created.

current_conn1b:
Add a pplayer->current_conn field, which is set when the server is
dealing with a packet from a specific connection.  Intended for code 
which sends to all player connections if at end turn, but only to 
originator if during request.

conn_diplhand:
Convert diplhand.c to send to player->connections.

conn_spy:
Some connection list conversions for diplomat/spy actions.

conn_handchat:
Update handchat.c for connection lists, though could do with 
additional functionality (no chat to single connection), and 
chatline server commands don't work properly yet for multi-connects.

conn_stdinhand1a:
Convert stdinhand (and related) so that 'caller' is connection, 
not player.  Changes 'cut' and 'cmdlevel' commands to take 
connection names instead of player names.

joingame_messages1:
Adjust messages sent when a client joins game (or tries to join), to 
be appropriate for multiple connections per player (when implemented).
Also adjust rejection messages to have more consistent form, and/or
improved clarity.  Also removed an obsolete clause in rejection code.

remove_conn_addr1:
Remove player.conn and player.addr fields, since should now use 
player.connections (or player.is_connected) and connection.addr.
Added player_addr_hack() to support code which still expects single
addr per player.  Also hacks to handle that client doesn't have full 
information about connection lists yet.

packet_conn_info:
Send clients full info about connections to server, in new packet_conn_info.
New non-mandatory capability tag "conn_info".
Add connection.id field for communication purposes, and find_conn_by_id().
Client now maintains player and game connection lists.
Also adjust conn_description() to return "server" for client aconnection,
which is clearer and simplifies some cases.
Add conn_id field to packet_join_game_reply, and game.conn_id, so client 
knows which connection id is itself.

allow_conn_multi:
Change allowconnect server option so that it can be set to allow 
permit multiple connections per player, and player observers.
(Still experimental.)  Changed set_command() in stdinhand.c to 
allow '*' and ''+' in parsing server option value.
----

After the above patches are applied, multiple connections (either
multiple controllers, or 1 controller + observers) may be permitted
based on player type by adjusting the allowconnect server option.  
But this is still marked as EXPERIMENTAL, as there will still be 
bugs/deficiencies etc.

Things still to do:

- Improved join_game interface.  Players should not have to specify 
player name when they join, instead they specify their "username",
and then get a list of players, and which ones they can connect to,
and whether as controller/observer, or create new player (pregame) 
etc.  During this time should also allow chat etc.  There is some 
support for this approach in the sense that have some infrastructure 
for having established but "non-player" connections (but 
implementation still incomplete).  This needs further client and 
server work.

- Client improvements: with above patches Player Dialog says 
"<multiple>" in address field if there are multiple connections - 
should list the connections (the client does now have the information, 
just requires gui changes, maybe integrated with above).
   
- Improved/additional interface for controlling when multiple connections
are allowed.  Eg, you don't want your opponent to open a controlling
or even observing connection to your player!  Possibly: first connection
to each player has privilege to set "permissions" (eg, in addition to 
server allowconnect option).  Eg, have "Permissions Dialog" with 
"allow observers", "allow other controllers", each with possible values 
"Yes" or "No", or even nicer "Yes/No/Ask", where "Ask" means another
connection can try to connect, and the privileged user gets a dialog 
to accept/deny just that connection (eg, after interrogating on the
chatline :-)

- Bug fixes etc! :-)

Regards,
-- David