Server Switch Disconnect

The start into connected multi-server. The client is told by the server to disconnect, and connect to another server given by IP/name, and a given port. The client can chose to ignore this. If the client does switch, a disconnect message will notify the old server, which could optionally notify the new server in turn.

Benefits:

This is the minimal in-game support needed to allow for Mods that span mutiple servers. Server-server interaction can be implented in the Game DLL. Persistence is possible. All that is needed is minimal support in the Q3 server/client, to avoid the need of client side proxies.

Problems:

Abuse by bad map design is countered by allowing the client to simply ignore that message.

Feasibility:

The current connect/disconnect handling would have to be extended by one message. A minimal response in terms of acknowledge/disconnect/connect on the client side, based on existing code, has to be available.

Implementation:

• The first change needed is a new Server Switch (SW) command, like:

         unsigned int   SVC_SW_ID;
         char           new_server[64];
         int            port;
         int            player_id; // assigned by server
  

  This is an offer to the client. If the client ignores it, nothing happens. The server will not disconnect the client.
• If the client accepts, the client has to disconnect. It sends a disconnect/ACK to indicate that this was not a timeout/coincidental disconnect (player bored), but indeed a switch:

         unsigned int   CLC_SW_ID
         int            player_key;  // assigned by client
  

  Why? If we want to transfer client data from one server to another, we need multiserver interaction in the Game DLL. If the server thinks there is a switch, and notifies the new_server, but the client never appears, we might get confusion. However, maybe the client does try, but does not succeed. Thus we also need a switch timeout implemented in all server-server interaction. All this can be done in a modified Game DLL as long as the main engine provides id/key pairs.
• We would also need a client switch connect. I do not know how a client connects to a server in the first place (and how it responds to svc_reconnect).

         unsigned int   CLC_SWC_ID
         int            player_id;
         int            player_key; 
  

• We need some configuration: in config.cfg

    set switch "0"    // prevents switching
    set switch "250"  // maybe check ping?
  

  so the player who does not want this will not be transferred. yp>
• Next, application: we need triggers embedded in the map. Players will leave while the game continues. In loose analogy to trigger use of stufftext or centerprint functions/network commands, we would need an extension to import:

   void (*switch)(  char new_server[64],
                    int            port,
                    int            player_id );
  

  It does not seem useful to add complexity to existing mechanisms (special stufftexts, configstrings). Note that the Game DLL should verify that the new server is up and running prior to sending a switch message to the client.

• As we might want to process an acknowledge from the client, we need to change an exported function:

     void          (*ClientDisconnect) (edict_t *ent,
                                        int player_key );
  

  It gets the ACK/player_key (if we want one), or -1 of it was a regular disconnect.
• We also need to change the matching one:

     void          (*ClientConnect) (edict_t *ent, 
                                     int player_id, 
                                     int player_key );
  

  The player_id is dynamically assigned by the server, it is not "your id", but "you in this game, today, this server". It does not make sense to store it in gclient_t, as it is only temporary. The player_key would make sure that a client is authentical. If nessary, this could be an encrypted player_id response. Both are transferred from the previous server and the client to the new_server.

1. the level designer adds certain slipgates to the map
2. the mod coder implements triggers that (among other things) initiate a gi.switch() call
3. the client receives the switch message, and either ignores it, or disconnects with ACK, and tries to connect to the other server.
4. the server, when receiving a clc_sd message, might send something like a player spawn message to new_server. All this could be done in the mod, Q3 does not have to provide it.
5. the new_server will store the data (timeout).
6. if a clc_sc is received by new_server in time, it will let the client connect (and spawn the player in the right place, with persistent data, if the mod implements that).

In the minimal form (the mod does nothing), this would allow for moving from one map to another without persistence, just spanning servers. If the mod provides all the server-server interaction, you could extend at your hearts content.

In this protocol the client does not tell the new_server where it comes from, and the old server pushes the content on the new server. Alternatively, the client would name the previous server on connect, and the new server would ask for the data, and for authentification.

Related Proposals:

There is a Server State Passover proposal that could be partly implemented using this mechanism, when the modified DLL also does sufficiently detailed (savegame) state dump. The Passover proposal aims at builtin support to move an ongoing game to another server, which might be relevant for commercial purposes.

Comments:

This is a simple, completely standalone modification that allows multi-server webs now, and experimentation within the Q3 networking that would benefit the seamless multi server Trinity is aimed at. Various ways to address server-server dependencies, map changes based on available connections, protocols etc. could be experimented with within a mod, given this basic support.

Submitted 980328, revised 980406, revised 980420, comments to Bernd Kreimeier.