Feature Request: Dedicated Game Server Apps

[Toasterson]

Hi there.

Have you given any Thought about Dedicated Game Servers. It may not be Possible to Provide the Closed Source ones, but there are a few very popular OpenSource ones like Bukkit for Minecraft.

[kpreid]

I thought I'd comment on the feasibility of this. I'm not a Sandstorm dev, but I'm somewhat familiar with how the Minecraft server works.

• It is closed-source Java code; the owners are OK with third-party patches but not with decompiled source being available. This means that any compatibility patches require extra development work. (Contrary to the above comment, Bukkit is, as far as I know, a patch to the official server, not a from-scratch server.)
• It accepts incoming TCP connections that are not HTTP. This would require special install-time permissions in the Sandstorm security model.
• It authenticates users by making HTTP connections to official account servers. Replacing this with Sandstorm's accounts would be impractical because
  • the Minecraft client expects to log in with an official account (and if it isn't doing so, it's likely “pirated”),
  • permissions to manage the game world are based on said accounts, and
  • game world content can include references to said accounts (even including “well-known” ones that won't ever connect to this server).

All that said, I think running Minecraft servers would be a very attractive application if it's technically feasible.

[kentonv]

The big challenge with game servers is that they usually want to be able to open TCP or UDP ports directly, which Sandstorm can't support.

If the game is open source or the developer is willing to do some work to get it to run on Sandstorm, then there's no problem -- the game just has to be adjusted to expose a Cap'n Proto API instead, and then you invite people to your server by "sharing" it with them. (This doesn't work yet, but it will.)

But taking an arbitrary proprietary game server and trying to get it running in Sandstorm would be challenging. You might be able to do it by devising some sort of IP-over-Cap'n-Proto proxy layer and convincing all your friends to install the client side of that proxy on their machines, but without that there'd be no way for people to connect, unfortunately.

Another issues with game servers is that they use a lot of resources, particularly if they are running all the time. You may need to pay your host more for higher resource quotas.

[Toasterson]

I read some more of the Samndstorm and Cap'n Proto Docs. Now i'm Confused. If the Apps are unable to open TCP Ports. How can they Communicate with the outside World?

Looking at your Porting Guide, i would use a standard Node.js Server as Packaged with my Linux Distribution of choice. I then tell Sandstorm that my App Listens on Port 10000 TCP.

If Sandstorm does not support opening of TCP Ports directly, what does this mean for Node.js. Do i have to Port Node to use the Cap'n Proto API? Or do you have some modified Version of a Library that when a HTTP Server Requests to Open a Port it opens a Cap'n Proto API Equivalent instead?

[kentonv]

There is a loopback network device, so an app can open a connection to itself, just not the rest of the world. Most apps include sandstorm-http-bridge which converts Cap'n Proto request into loopback HTTP requests.

The app's only connection to the outside world is through a socket over which it can speak Cap'n Proto RPC to the Sandstorm supervisor. Through this, the app can communicate transitively to the rest of the world, but only in ways that Sandstorm allows. Eventually it will be possible for the app to export Cap'n Proto APIs all the way to clients, and this could be used by a game server. We need this to be done using Cap'n Proto rather than TCP ports because Cap'n Proto has a strong notion of objects which we can plug into our permissions system, the Powerbox UI, etc.

[lazzarello]

@kentonv This might be out of the scope of this thread but how does Cap'n Proto handle synchronous network sockets like UDP? Skimming the spec looks like it's a highly structured data format which isn't necessary for example, full-duplex RTP traffic coming from a VoIP server running in a container.

[kentonv]

@lazzarello See: https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/ip.capnp

Basically, if an app needs raw TCP or UDP traffic, it will need to layer on top of a Cap'n Proto interface. We have some plans to improve Cap'n Proto so that the overhead of this is relatively low.

That said, most apps will hopefully use higher-level protocols. HTTP-over-Cap'n-Proto is a separate thing, and of course anything that natively uses Cap'n Proto in the first place will have an easy time integrating.