Multi-server hubs?

[Spottswoode]

This thought has crossed my mind for some time. Originally, I was conceiving a way to deal with the "hub problem" (which is to say, to make hubs transfer items between hub centers) and while it technically does not do that, it does address several other problems.

In a nutshell, the idea is to make the central hub on one server and all of the maps connected to the hub on several or one other server. When players travel to another map, the central server sends the destination server a packet with the map to be loaded, player inventory, and the player info and current state. If there are multiple servers (3 or more) the main server sends the player to the corresponding server with the correct map (or sending the map to be loaded if there is no server with the map currently loaded) along with the player's inventory and current state. In the event that the server must change map with players still in it, the server either 1) changes the map with the players still in it (hexen style map change) or 2) refuses to load the map pending conditions. (probably 50% or more of the players trying to change to that map) Once the player connects to the other server it's business as usual until they return to the central hub. The "outside" server would then send the player back to the central hub. Now when the hub changes, the central server can either 1) preconfigure all of the maps to be used with the hub on the other server(s) or 2) load them individually as needed.

Loading them individually allows the players to play on several different maps at the same time without the need for the retarded Hexen style forced map change every time somebody wants to go back or starts trolling. These types of multi-server configurations would also lot modders and mappers make huge conglomerate maps without fear of using up too much map space and causing most server related issues with huge map sizes.

Now, other than the work involved, does anyone perceive any potential problems with this particular idea?

[Discount Ninja]

Though I like the idea, connecting to different servers across the Internet would be very problematic. I think having a local cluster of servers working in conjunction would be a lot better. A login server would handle incoming clients and would handle traffic between map servers. And if you wanted to store data permanently you could have a character server store and handle that information. There are some programs that do something similar to this, but not for FPS's that I know of.

[mifu]

What if a server were to spawn an instance (or a mini server) that can not be seen on the master server but allows people who are playing in the hub server to connect to them when the client needs too.

This is a good idea, but I see problems on how this would be implemented

[Slim]

I really, really love this idea. But it just sounds so vulnerable to issues. Like how would servers be handled? How would there be flawless transition? All that jazz. If this ever comes to be, I'll definitely be surprised.

[Spottswoode]

For the most part, both the hub and the other servers should be on the same machine. The hub would have a list of the number of servers and their names, ip, port, etc. The hub would just fill them in as necessary. Ideally with most connections, in non hexen style games, the hub could just handle the initial connection. (You could design "logon" maps that basically function like match making if you wanted.) Transition would occur when you leave the map and only reoccur when you change back to the hub. (So it is possible that you stay connected to the server you are playing on.) The transition wouldn't be flawless per se, depending on what machine you connected to, but it could be worked out to be pretty smooth over the same machine or same network.

mifu, that would basically be how it works. Depending on the needs of the server, the non hub servers could either be listed or unlisted. (the latter would be recommended in all non match making cases)

[Cruduxy]

Turning the game from a client-server model to a distributed one will b a nightmare though :P

[Spottswoode]

Honestly, the focus is more or less on distributing specific games. The overall structure of zandronum wouldn't be changed because this type of model is specifically made for hub designs. Even if you made a dm hub, the overall effect on the port as a whole would be minuscule unless the performance was rock solid. If you are talking about the work involved, it's really just about getting the server to send you to another server. The configuration would be the easy part.

[Watermelon]

Each server would require
- It's own 'master' server
- All the sub servers

The sub servers would communicate to the master server chat messages, number of players, etc.


There was another idea I had (but it's RAM heavy), and that is to run multiple worlds on a single server. This restructuring probably would not happen to zandronum though because it'd require a huge overhaul and would make zdoom codebase upgrades probably ultra messy.

If it ever happens, I see the former being done (despite being much much more complex/time consuming)

[Blzut3]

This actually is an interesting idea. I don't think having multiple servers is necessary. It might be possible to fork the process at the level load and then use pipes to forward network communications to each child. The advantage to doing that is the connection can be passed around server side without having to inform the client of anything. (And since you don't need to allocate ports to the children, you don't need to know up front how many simultaneous maps are loaded.) It would still be fairly heavy in terms of RAM to run such a server though.

If such an architecture were implemented it may be possible to narrow the number of children spawned to just levels with at least one player occupying.

[Dusk]

.. that sounds mega interesting actually. Would be a ton of work to make it actually happen though.

[Spottswoode]

Honestly, I don't actually see this happening unless there is a very specific model developed and there is significant interest amongst our community. If interest picks up on it, I would suggest dedicating a developer to the hub code. Honestly, it would almost be a separate port unto itself.

Watermelon, it would not be necessary to send/return player communications back to the hub or other servers. As a matter of fact, I would be against it. Most MMOS don't use global chat for players because of the trouble involved and it isn't necessary. It's a rather simple matter to develop around limited range communications. As the players would only receive about the same load for any other game, it is much more beneficial to require players to use an external program.