Opened 8 years ago

Last modified 3 years ago

#3556 new enhancement

[PATCH] Dedicated server

Reported by: elexis Owned by:
Priority: Nice to Have Milestone: Backlog
Component: Network Keywords: patch, beta
Cc: andy011973@…, Victor ADASCALITEI Patch:

Description (last modified by wraitii)

Requirements

  • A dedicated host is a gameserver running from command-line
  • It has almost no performance requirements
    • no graphics are displayed
    • no local player/observer joins the game
  • could allow Wildfire Games to host multiple games on a single machine
    • can be patched independently from the release cycle (f.e. in case of bugs or abuse)
    • might satisfy the demand for servers (as only a minority of users can host/configure their router currently)
    • useful for rated games as we could make sure to not quit the server prematurely
    • ideally ensure not to kill all games when restarting the lobbybot

Notice that the source code is freely available, which means everyone will be able to use dedicated hosts. It will be the job of the programmers and lobby moderators to prevent and stop abuse.

Roadmap:

Done:

  • the 'Controller' of a game is determined by a secret, so it could be assigned dynamically (r24952)
  • hosting can be done on different ports (#3575)
  • can host with one account under multiple JIDs (r25407), so a single 'wfg' account can provide the games.

TODO:

  • The whole "spin a 0 A.D. instance, get the access, send the game report, close the 0 A.D. instance" needs to be implemented.
    • Starting a new dedicated game could probably be done via an external bot that starts a pyrogenesis executable with appropriate CLI arguments, auto connecting to lobby with a given secret (that the requester knows) so the requester can join-as-host. This would advertise the lobby game.
    • How to send the game report & finish the game needs to be determined.
    • that bot needs coding.

Attachments (3)

t3556_dedicated_server_WIP_v0.1.patch​ (20.1 KB ) - added by elexis 8 years ago.
Proof of concept. Server running and chat working. Still opens an unused window and has no features besides chat yet.
t3556_dedicated_server_WIP_v0.2.patch​ (23.1 KB ) - added by elexis 8 years ago.
No more useless windows, only command line. Takes a fraction of a second to start. Changed to class structure.
t3556_dedicated_server_WIP_v0.3.patch​ (54.1 KB ) - added by elexis 8 years ago.

Download all attachments as: .zip

Change History (27)

by elexis, 8 years ago

Attachment: t3556_dedicated_server_WIP_v0.1.patch​ added

Proof of concept. Server running and chat working. Still opens an unused window and has no features besides chat yet.

by elexis, 8 years ago

Attachment: t3556_dedicated_server_WIP_v0.2.patch​ added

No more useless windows, only command line. Takes a fraction of a second to start. Changed to class structure.

by elexis, 8 years ago

Attachment: t3556_dedicated_server_WIP_v0.3.patch​ added

comment:1 by elexis, 8 years ago

Description: modified (diff)

comment:2 by elexis, 8 years ago

Description: modified (diff)

in reply to:  2 comment:3 by Vladislav Belov, 8 years ago

Current patch still creates the graphic context, so app could be crashed when runs on the server w/o a graphic card. The rest of the patch looks good.

comment:4 by elexis, 8 years ago

Description: modified (diff)

comment:5 by elexis, 8 years ago

Component: Multiplayer lobby → Network

(set component to network)

comment:6 by elexis, 8 years ago

In 18322:

Major network cleanup. Patch by Imarok.

Access the server from the client only, not from the GUI (except for autostarted games).
Thereby lay the foundation for clients to setup the game (refs #3806) and dedicated hosting (refs #3556).
Doesn't transfer nor remove the SetTurnLength showcase from r7936.

comment:7 by Andy Alt, 8 years ago

Cc: andy011973@… added

comment:8 by Imarok, 8 years ago

Description: modified (diff)

comment:9 by elexis, 8 years ago

Keywords: patch added
Summary: Dedicated server → [PATCH] Dedicated server

Update:

Besides the new controller authorization mechanism #3806, removing DedicatedServer_Gamesetup.cpp implies:

Problem: lobby stanzas

  • The server should send the stanza (so that it doesn't depend on some client registering the game which might disconnect and thus unregister the game)
  • but only the client has access to the simulation data (defeated state #3476) and the server should avoid any gameattribute-parsing logic ideally
  • Edge cases empty host: If the server doesn't construct the packets on its own, but relays a copy sent by a client: which packets should be sent if no client connected yet? what stanza to send if the game is running and all clients disconnected (the "player X is offline" state would be outdated with the last disconnect)

Proposed solution:

  • So the server has to construct an empty packet from scratch when starting a lobbied game. If the last client disconnected from a lobbied game, the server has to correct the playerlist entry. Therefore it would make sense if the server can produce the entire logic on its own.
  • Instead of requesting a lobby stanza from a client, the server could just request the player-defeated-state. But introducing a packet for either of these things seems very undesirable. It is probably better to just not send the defeated state if the game is hosted by a dedicated server. (There might be a dedicated server that also simulates the game optionally, for example to determine the winner of rated games. If that were enabled, it could also report the defeated state without asking a client).
  • The NetServerknows the current player assignments, game attributes and has a list of connected GUIDs / clients, thus could send these 3 arguments to a JS function that does the complex stanza construction in r18534. The affected functions would have to be moved to source/lobby/ if we want to distribute the dedicated server without requiring public/.

comment:10 by scythetwirler, 7 years ago

Keywords: beta added

comment:11 by scythetwirler, 7 years ago

Milestone: Backlog → Alpha 22

comment:12 by Andy Alt, 7 years ago

Owner: set to Andy Alt
Status: new → assigned

comment:13 by Andy Alt, 7 years ago

Status: assigned → new

comment:14 by Andy Alt, 7 years ago

Owner: Andy Alt removed

comment:15 by Imarok, 7 years ago

refs #4364

Version 0, edited 7 years ago by Imarok (next)

comment:16 by elexis, 7 years ago

Milestone: Alpha 22 → Backlog

Backlogging due to lack of progress

comment:17 by Victor ADASCALITEI, 6 years ago

Cc: Victor ADASCALITEI added
Description: modified (diff)

I'm interested in this.

comment:18 by elexis, 4 years ago

In 23374:

Gamesetup class rewrite, fixes #5322, refs #5387.

  • Decouples settings logically which in turn allows fixing many problems arising from previous coupling.
  • Fixes the persist-match-settings feature, refs #2963, refs #3049.
  • Improves performance of the matchsetup by rebuilding GUI objects only when necessary.

Provides groundwork for:

  • UI to control per-player handicap, such as StartingResources, PopulationCap, StartingTechnologies, DisabledTechnologies, DisabledTemplates, ..., refs #812.
  • Map specific settings (onMapChange event), refs #4838.
  • Chat notifications announcing which settings changed, refs D1195,
  • Multiple controllers setting up the game (since setting types can check for permissions in onUpdateGameAttributes without the need for a new data model or a second gamesetup data network message type), refs #3806, subsequently dedicated server, refs #3556.
  • MapBrowser (MapCache, MapTypes, onUpdateGameAttributes interface), refs D1703 and D1777,
  • Multiplayer saved games (decoupling and setting dependent unique logic), refs #1088.

Refs ​https://wildfiregames.com/forum/index.php?/topic/20787-paid-development-2016/ ​https://wildfiregames.com/forum/index.php?/topic/20789-paid-development-2016/

Enable maps to restrict setting values:

  • If a map specifies an AI or Civs for a playerslot, the controller can't assign a player/other AI or Civ to that slot, refs #3049, #3013.

Fix per player StartingResources, PopulationCap, StartingTechnologies, DisabledTechnologies, DisabledTemplates following rP12756, refs #812, fixes #4504. Use this for DisabledTechnologies on Polar Sea.

Persist user settings for Skirmish maps:

  • All user chosen settings are persisted when changing the selected map or maptype, except where the selected map overwrites the setting value and except for Scenario maps which still use the default value where the map doesn't specify the setting value.
  • Tickets relating to that Skirmish mapchange user setting persistance:
    • Selecting a map doesn't change the selected civilizations, fixes #3120 (together with r23279 removing map specified Civs).
    • Selecting a map type doesn't reset the selected settings, fixes #5372.
    • Selecting a map doesn't change the selected victory conditions, unless the map specifies those, refs #4661, #3209. (Atlas still writes VictoryConditions to every map.)
    • Consume the player color palette from Skirmish maps, refs rP17040 / #1580. Preserve the selected playercolors when switching the Skirmish/Random map by chosing the most similar colors if the map comes with a different palette.

Rated games:

  • Hide and disable Rated game setting unless there are exactly two players, fixes #3950, supersedes D2117.
  • Display conspicuous warning if the game is rated, so players are perfectly aware.

Autostarted games:

  • Allow using the gamesetup page to autostart matches with arbitrary maps, not only this one tutorial, as reported in D194 and rP19599, refs D11.

Networking:

  • Keep gamesetup page open after disconnect, allowing players to read chat messages indicating why the host stopped the server, fixes #4114.
  • The message subscription system allows new and mod settings to run custom logic on arbitrary setting changes (most importantly on map change). This removes hardcoded logic restrictions from the gamesetup option unification rewrite in rP19504/D322, refs #3994, such as the hardcoding of setting references in selectMap to biomes from rP20115/D852 and the difficulty from rP20760/D1189, RelicDuration, WonderDuration, LastManStanding, RegicideGarrison, TriggerScripts, CircularMap, Garrison, DisabledTemplates.

Checkboxes:

  • Display values of disabled checkboxes with Yes/No labels, fixes D2349, reviewed by nani.

Clean g_GameAttributes of invalid values and gamesetup GUI temporaries, refs #3049, #3883:

MapCache:

  • Refactor to MapCache class, store maps of all types and use it in the replaymenu, lobby and session as well.

SettingTabsPanel:

  • Remove hardcodings and coupling of the SettingTabsPanel with biomes/difficulties/chat UI from D1027/rP20945.

GamesetupPage.xml:

  • Restructure the page to use hierarchical object organization (topPanel, centerPanel, centerLeftPanel, bottomPanel, centerCenterPanel, centerRightPanel, bottomLeftPanel, bottomRightPanel), allowing to deduplicate object position margins and size math and ease navigation.

New defaults:

  • Check LockedTeams default in multiplayer (not only rated games).
  • Persist the rated game setting instead of defaulting to true when restarting a match, which often lead to unintentional rated games when rehosting.
  • 60 FPS in menus since they are animated

Autocomplete sorting fixed (playernames should be completed first).
Refactoring encompasses the one proposed in Polakrity and bb D1651.

Differential Revision: ​https://code.wildfiregames.com/D2483
Tested by: nani
Discussed with:

Emojis by: asterix, Imarok, fpre, nani, Krinkle, Stan, Angen, Freagarach

comment:19 by wraitii, 3 years ago

In 24775:

Net Server: Verify password in Authenticate

Follows rP24728.
Validate the password when a client joins a game, so even a player that knows the connection data cannot join.

Refs #3556, Refs #5913

Differential Revision: ​https://code.wildfiregames.com/D3438

comment:20 by wraitii, 3 years ago

I've been POC-ing this. After ​Phab:D3075, one of the significant questions is resolved (who is 'host'?).

However, while I could get something hacky to work, there are still a number of hurdles:

  • The first hurdle is that 0 A.D. enforces a "/0ad" XMPP resource. We probably want dedicated server to use a single user-account, so we'd need to acknowledge multiple resources (one per hosted server). This requires updating the lobby/xmpp logic to store the resources of clients, so that we can differentiate (right now the game code doesn't).
  • The second hurdle is when to close the NetServer - presumably somewhat consistent with "sendGameReport". It ties into the next hurdle:
  • How to communicate between controller and server.
    • We could use in-game chat, per above patches, or XMPP messaging - depending.
    • I am actually unsure which is most relevant. Some things we want in-game (like closing the server), but stuff like a voting system to change settings & so on could probably be done via XMPP. Not sure.
  • The final hurdle is actually how to start/stop a dedicated server.
    • It is pretty easy to make 0 A.D. start to host and advertise to the lobby. The hard part is knowing when and how exactly.
    • My preferred approach, I think, would be to have a 3rd party bot to communicate with on the lobby - we could use private XMPP messaging for that purpose - and that bot spins up 0 A.D. instances as needed. Those connect to the lobby, host a game, but don't advertise it - they'd relay that to the bot, who relays it to the controller player (alongside secret etc.), who then does the advertising (or maybe the relay bot does). Since we don't need the bots to get the IPs now, that's doable with STUN hosting. The bot would handle the management of instances, report the logs etc.
      • The summary says this should be WFGBot, but I think a new bot is better since it's a rather orthogonal concern, and we probably want to allow dedicated hosting without running the full WFGbot, so that there can be different dedicated hosts in the lobby.
  • As a sidenote, users might want to join a dedicated server they host locally, and most routers don't actually support that (NAT loopback). One solution would be to detect the client external IP using stun, and check if it matches the server.

comment:21 by wraitii, 3 years ago

First hurdle tackled at ​Phab:D3500

comment:22 by wraitii, 3 years ago

In 24952:

Netcode: Identify controller client via a secret key

The 'controller' of an MP game (the host in general, though dedicated servers would change that) is currently whoever first tells the server that it is. This can be abused since it relies on trusting the clients.

This changes that logic: the server defines a 'controller secret', and the first client to sent the correct controller secret is the controller. This is safe assuming the secret is unknowable enough (the current solution wouldn't pass strict cryptography tests, but it's likely good enough).

Reverts rP18140, which introduced the 'trust the clients' mechanic, as a change over 'the first local IP is controller'.

Necessary step towards dedicated server, if we want to use the regular gamesetup (Refs #3556)

Differential Revision: ​https://code.wildfiregames.com/D3075

comment:23 by wraitii, 3 years ago

In 25407:

Don't hardcode the "0ad" resource into lobby XMPP & hosting

XMPP JID has a concept of 'resources', which can be used to differentiate multiple clients of the same account.

We currently hardcode this 'resource' to '0ad' in two places:

  • The 0 A.D. client always uses '0ad'
  • The network code expects a host resource to be '0ad' when connecting.

As noted in ​https://code.wildfiregames.com/rP21520#31215, it is less effort to store the JI
D directly. This patch does that. It also makes 0 A.D. use a different resource each time.
Note that resources ought not contain particular information, as the XMPP server is free to

clobber it. I keep '0ad-' here for debug purposes.

This allows:

  • multiple 0 A.D. instances to log on the lobby at the same time (not massively useful, but good for debugging sometimes)
  • hosting a game with a custom resource, which will potentially make it easier to have dedi

cated servers on one account.

Note that hosting multiple games on one account is currently not supported and will have weird behaviour on the lobbybots side. They should be upgraded independently of this.

Refs #3556

Differential Revision: ​https://code.wildfiregames.com/D3500

comment:24 by wraitii, 3 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.