Next generation metaserver
The WorldForge metaserver is simple and very scalable, but a number of limitations have been identified which need to be resolved to support future WorldForge development.
The new metaserver must seamlessly support all kinds of clients of the old metaserver without upgrade.
The new metaserver must support IPv6 both in terms of communication, and supporting IPv6 addresses for servers.
The new metaserver should support additional data fields to allow clients to search for types of server without resorting to contacting those servers speculatively
The new metaserver should support extensions to the protocol to support future requirements.
The new metaserver might support authentication of server identities to assure users of continuity of security of their game.
Blueprint information
- Status:
- Started
- Approver:
- Erik Ogenvik
- Priority:
- Medium
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Sean Ryan
- Definition:
- Approved
- Series goal:
- None
- Implementation:
-
Deployment
- Milestone target:
- None
- Started by
- Erik Ogenvik
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
How much of what's enumerated here has been implemented in the metaserver-ng?
>The new metaserver must seamlessly support all kinds of clients of the old metaserver without >upgrade
This is done. We had discussed this as not necessarily being important as it was, but I do not recall changing anything that would break things.
>The new metaserver must support IPv6 both in terms of communication, and supporting IPv6 >addresses for servers.
This is a tough call. The answer is "sort of" Boost::ASIO allows for this, and I've used it. I also have not really had a location that is ipv4 + ipv6 enabled in order to ensure that it's robust. By and large, it should work, but it needs real-world testing that I don't have the ability to do for me to put a done on it.
>The new metaserver should support additional data fields to allow clients to search for types of >server without resorting to contacting those servers speculatively
Yes this is supported at the model level (I changed it so that everything became an "attribute", and thus we can store any information we want). My goal for this was to add to cyphesis a range of data that it sends to the metaserver (connections, uptime, traffics stats [in/out], system load, world objects, players connected, and a few others). I added one such when i merged in the API ... the call I think is serverATTR (or some variation of "server attribute" ... I'd have to check). It is setup already as-is that servers can send additional attributes. IMO, any attributes that a client would query the server for, should be sent to the metaserver periodically. The second half of this whereby the query based on such information, is not fully completed. It is the next on the TODO for the ms. I can make this a priority for you if it would help you out.
>The new metaserver should support extensions to the protocol to support future requirements.
This is in place. Protocol additions are trivial.
>The new metaserver might support authentication of server identities to assure users of continuity >of security of their game.
This is not done. There was never any real requirements other than the most highest level (I can recall multiple emails about my ideas that were not really looked at). I have no problem implementing something like this, but it would need to be well defined. Personally I was thinking about something like:
- game server 'registers'. As in now, but to include something like a key/token of some sort.
- user information could be stored (or queried and fed ... depends), and then MS could perform authentication ala user@server_token sort of thing.
As i said, it needs to be well thought out, and IMO it either needs to be simple, or leverages an existing technology.
