Opened 9 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 )
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)
Change History (27)
by , 9 years ago
Attachment: | t3556_dedicated_server_WIP_v0.1.patch added |
---|
by , 9 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 , 9 years ago
Attachment: | t3556_dedicated_server_WIP_v0.3.patch added |
---|
comment:1 by , 8 years ago
Description: | modified (diff) |
---|
follow-up: 3 comment:2 by , 8 years ago
Description: | modified (diff) |
---|
comment:3 by , 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 , 8 years ago
Description: | modified (diff) |
---|
comment:7 by , 8 years ago
Cc: | added |
---|
comment:8 by , 8 years ago
Description: | modified (diff) |
---|
comment:9 by , 8 years ago
Keywords: | patch added |
---|---|
Summary: | Dedicated server → [PATCH] Dedicated server |
Update:
- Rebased the patch at https://github.com/elexis1/0ad/tree/3556-dedicated-server
- Removed all c++ gamesetup hardcoding.
- Imaroks cleanup works like a charm with this patch! The first to join (having that patch applied) can setup the game as usual.
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
NetServer
knows 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 , 8 years ago
Keywords: | beta added |
---|
comment:11 by , 8 years ago
Milestone: | Backlog → Alpha 22 |
---|
comment:12 by , 7 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:13 by , 7 years ago
Status: | assigned → new |
---|
comment:14 by , 7 years ago
Owner: | removed |
---|
comment:15 by , 7 years ago
refs #4364 a comment from scythetwirler at this ticket, that is probably better suited here: "If you could set the XMPP resource on the JID of the default dedicated server to something different (0ad is the default for the main client) for easy recognition, that'd be great. :)"
comment:20 by , 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:24 by , 3 years ago
Description: | modified (diff) |
---|
Proof of concept. Server running and chat working. Still opens an unused window and has no features besides chat yet.