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.


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.


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


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.


The mechanisms would be used as such:
  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.


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.