Free/cheap/easy hosting for custom server?

I'm looking for some advice regarding options for authoritative server architectures and hosting. I'd like to start with something free or cheap (<$10/mo) as a trial just to make sure everything will work right.

Custom C# App: I can write a custom TCP or UDP server. I did a multi-threaded high performance TCP server as a test and it wasn't too difficult. I should be able to host this on a VPS but at least for TCP the buffers take quite a bit of space and most of the cheap VPS servers only have 1GB of ram which could be an issue. I'm not sure how managed or unmanaged they are in terms of actual networking setup or DDOS type prevetion, if that's something I have to deal with or if it's taken care of and I just put my app on and run it.

PHP: I can write the server logic in a more segmented way and use PHP for a standard REST or similar API style of networking. All I'm doing is passing json strings (encrypted or protected, of course) so it's very capable of this and easy to do. Networking and DDOS and everything will be covered, it would scale easily, and it would be easily portable between hosts. Unfortunately I wouldn't really be able to have a solid program or game loop anymore. I'd have to do things in a more segmented way with lots of client polling for updates. It would work but it's not really correct and a lot of hosts don't even allow this sort of thing in their TOS.

Self Hosted: I can use an old computer and set it up as whatever type of host I want. Probably a C# server. Problem is that Comcast doesn't really allow this. I'm not sure if they would care or not but I certainly couldn't go past pre-Alpha with this. Even if it worked I'd have to change things for a more permanent solution anyways and if I can't find an existing host or option then I'd be stuck with my own server and co-location and managing it which I'd like to avoid.

Photon/Something: Something like Photon has some existing stuff and provides a free low-usage trial. This would be great except that I don't really need anything that Photon or the other services provide. I don't need object serialization. I don't need their lobby. I don't need their chat. I don't need their master server. None of that stuff works for this project. In fact all that I need is to send json strings (ie raw bytes) between the server and clients tens of thousands of clients. All of the features that Photon or other options provide are actually in my way and make it more confusing. Plus I'm locking myself in to a certain tool whereas with C# or PHP I'm not dependent on any outside factors.

Other: I feel like there should be another option that I'm just not seeing right now. I should know it but I just can't think of it. None of these options really seem right. Does anyone have an idea? A better way to do this or even just a free VPS trial or something I can use for testing?

 

I think my main advice is to try to be flexible during development, so you can adapt your choices later on. This is more difficult if you need to run a lot of server-side code. My server-side code is very simple, so my choices might not make sense for you. Still, you said "free", "cheap", and "easy", which are kind of the opposite of "scalable", so...

For development purposes I'm renting a really small VPS slice for $15/year. My server code is extremely lightweight, so despite the tiny VPS, it's actually capable of supporting a reasonable number of client connections - way more than I need during development. It would not work for long as a live retail server, but it is very cheap and ensures that I do keep the server code light, which should help a lot with scalability later on. I figured that even if it was too small to run my code at all, I'd only be down $15 for the sake of trying. In practice I already got more than $15 worth of value out of it, as a test-bed for server deployment, a minor stress-test for latency (it is hosted on the other side of the world), and as a convenience for development.

The server code I'm running there is currently a socket policy server, a custom UdpKit-based server, and a custom WebSocket server for WebGL connections.

The biggest constraint on this instance is memory - 128MB + 128MB swap - but the only time I've been into swap so far is while installing mono itself - apt-get was a bit greedy.

When I outgrow this tiny VPS it should be pretty easy to migrate the custom server apps to a bigger one. Using C# for server code makes me a little uneasy, due to it being sometimes hard to see what is going on deep down, especially concerning thread usage in the WebSocket libraries, but it is convenient to match the server language to the client language, and deployment has been very straightforward.

Especially for the WebSocket server, it may be smarter to user a more standard server backend. I'm not an expert on this, but I'm open to taking that step when it becomes clearly worthwhile. There are so many to choose from, and it's hard to find any concrete figures on their performance for the unusual case of game networking where many clients will hold open connections and expect reasonably low latency delivery. Most web servers will expect outbound I/O to be the bottleneck, which should never be the case for game networking, as you need to throttle your data way before it becomes an issue, to maintain a good player experience.

You could also consider Yahoo Games Network or Gamooga. Both host servers for you, and let you run your own code server-side. YGN has a very wide, well-rounded package, which I really like using. I don't like Gamooga so much - I suspect they have scalability problems, probably due to their choice of server-side technology, and I think their per-message pricing scheme also implies this inefficiency.

There is also Photon, which has a good reputation in Unity circles. It doesn't matter if you don't want all their services, so long as they do a good job of providing the services you do need. They have several flavours to choose from, in particular you can self-host a server instance, or use their cloud. If you need server-side code, though, you must self-host. Their server software is well-designed and has a good reputation for scalability. However your interaction with it is closer to the metal than with some other products, which is bad in the short term (not obvious where to insert your code) but good in the long term (you get more control over all aspects).

In the end there are a lot to choose from. Generally the route of hosting servers via VPS is very flexible - there are many server technology options, and many VPS providers to choose from, as well as cloud services if they fit your needs, and generally it should be easy to migrate your server code if your requirements change. And Yahoo seems a great choice if you don't really want to manage your own servers, so long as you accept their pricing scheme and trust them to provide a good service.

 

Thanks for the feedback.

Something like Photon or Yahoo might work but it seems like a waste to lock myself into their architecture when I'm not actually using any of it. The big issue is that most/all of these services are designed around an FPS-style hosting setup where there is a master server or lobby system where players can join or even host individual game servers. This is completely contrary to what I need. I would have my own custom matchmaking queue and all the games would be hosted on the server using a fully authoritative networking mode. The players can't host a match or choose which match or game server to connect to.

I think a cheap VPS like you have is ideal for me right now but I'm not really familiar with this type of hosting and I'm not sure what kind of mistakes I could make. For example I know how to secure the data streams for my game but I'm not really sure how to secure or operate the actual server itself. I'm worried that I'll spend more time and effort working on the server then the game. Or maybe not and it's just my unreasonable concern due to unfamiliarity and it's actually not that difficult?

 

Security is certainly a concern, and one reason why having somebody else manage your servers can be appealing.

On the architecture point though, YGN, Gamooga and Photon Server are not peer-to-peer, they are all principally client-server. In each case the idea is that clients only talk directly to the server, which relays messages to other clients when required. I think this is what you want.

For YGN and Gamooga, the servers are managed for you, and there is a degree of built-in matchmaking which you can use or not depending upon your requirements; in any case, you need to implement your matchmaking for these systems as part of your server plugin, running on their servers, and can't really integrate with an external system. I'm not sure whether that's what you meant. You also need to bear in mind, at least with YGN, that they run instances of your server in multiple geographic locations, so there's no one central server, nor room list, nor global online user list. Two online players may not be connected to the same server, so may not be able to play together. This is a feature of the system, leading to greater scalability, but might not suit your needs.

For Photon Server it is different - you host your own servers, running the Photon Server software, and you have a much higher degree of control over what happens on the server. They supply some example projects that perform basic room-based matchmaking, and you can extend those, or replace them with whatever you like. It is entirely up to you. What you get is a proven efficient server design and networking framework, and not really much more than that.

I think you're right to be worried about locking yourself into a third party architecture, but with good code factoring you should be able to avoid having much of your code depend on the middleware. Write a C# interface to encaplusate your client's interaction with the server, which will probably only have about four methods in it (connect, disconnect, send, receive), and then if you change backends you only need to change the code on one side of the interface (and the server code of course).

 

All of that makes sense. I saw that Unity 5 was just released so I'll see what that brings to the table later tonight. I also thought of my other option which for some reason didn't occur to me earlier.

I looked more into YGN during my breaks and for reasons you also mentioned it wouldn't work. The scaling is great but I would indeed want one global player list where anyone could be matched together so it wouldn't work. They also mentioned something about 100ms maximum cpu time which could be an issue.

Photon server might work and I would be able to use a home computer as a temporary solution. I really only need to send basic messages back and forth, something I can do with a custom written TCP server quite easily, so I'm still concerned about the 3rd party lock-in and unnecessary features. I will look more into this tonight though.

What I was missing before is the simple fact that Unity uses C# and Mono. I don't necessarily have to use Unity itself but C# and Mono should allow me to write my C# server and host it on a Linux box which would happily avoid some of the issues with a Windows box (ie hosting price, PHP version compatibility, etc). At least in theory, anyways.

Do you have any recommendations or comments between the Photon and C# Mono options? I will look more into both options tonight but if one is a known dead-end then there isn't any point in wasting time on it. Just to note: I'm not doing any physics or using anything from Unity in the server. It's really just basic logic and tons of database requests, and several tens of thousands of TCP/SSL clients that need to transfer raw bytes back and forth.

 

Babysitting tens of thousands of TCP connections is awkward. I'm no expert in that, except insofar as I'm aware that it's hard, but the first place I'd look would be off-the-shelf web servers, and websockets.

This page might also be interesting - it is old but I feel still an interesting round up of techniques for serving large numbers of clients: http://www.kegel.com/c10k.html

I am supporting websockets in my own library at the moment, using the Alchemy websocket library on the server side.

You should probably work through some numbers though if you're hoping to support 10k clients on one machine. How frequently will each client send data to the server, how frequently will the server send data to each client, how much data, what is the total bandwidth, what is the server's net input/output packet frequency, how frequent are the database requests, how expensive are they, etc. The higher the numbers are, the more engineering work you need to do to keep it running smoothly. It is not going to be a walk in the park.

 

Totally agreed. I will check out that link when I get home.

The nice thing about this project is that it's relatively basic. Even though the gameplay is totally unrelated, the networking and server needs are probably very similar to a poker site.

A web-based API is almost perfect for it except that I'd have no way to push updates from the server to the clients. The clients would have to poll for updates and suddenly instead of a message every 3 to 30 seconds I have each client polling every second and I lose the advantage of good scaling.

 

Here is game server backend that you can run on your own hardware. They have great service and Unity SDK:
http://appwarps2.shephertz.com

 

You can use something like Amazon or Google Compute Engine for free for a small instance. However I think even that is a "further down the road" goal if you haven't written the server yet, testing on localhost works pretty good until you get to the point you need to optimize bandwidth and test latency.

 

Also one thing you might want to keep in mind for your server is making it HTML5 "compatible" by using WebSockets. WebSockets are very efficient and give you that ability to have the server push to the client(just like a standard socket). If you think you might at some point want to publish your game to web it is a nobrainer to just write the server as a WebSocket server to begin with, and it gives you some nice things like the ability to easily use TLS for encryption etc.

 

I hate to admit it but I don't really know how WebSockets work. I mean I get the idea but what I don't understand is what exactly is the server "program"? For example PHP supports WebSockets I know but I don't exactly expect 10,000 people to connect to a single PHP script that runs for weeks on end. I'm sure I'm missing something obvious, but doing things on a web platform would actually make a lot of sense in some ways so I'd be interested to understand this better.

 

Think of WebSockets just like a tcp socket but with a http handshake at the beginning.

Starts out as a http request and then with a simple header it gets "upgraded" to a web socket, after that point it is(roughly) the same as a normal socket(message based) and you can pass whatever you want on it. You can easily write a C# server that accepts websocket connections if that is the language you prefer, or a multitude of other languages(I ported mine over from Python to Go).

The big advantage is that browsers can open websockets to servers, they can't open a regular bsd style socket. Otherwise you are stuck with AJAX style polling like you mentioned, which is not very efficient and I expect to see fade away as more people start using websockets.

 

Sorry I should have been more clear, websockets don't connect and retrieve a page, they connect to a running program which is executing it's server loop just like a socket server. Some web servers will pass a websocket connection to the appropriate server, which is where the confusion comes in. Ie. if I request /index.html from Apache I get a static page back but if I go to /game I might get connected to a websocket server that is running on the host(with Apache acting as a proxy so to speak).

 

If I'm using Unity as the client though, what advantage does a web socket provide over a normal socket if both connect to a server program anyways?

 

The main advantage is you can use web sockets with browsers(WebGL target), if that's not a concern then not too much.

 

You can also lean on existing large scale servers, like Apache Tomcat, node.js, or PHP if you must! nginx is another great server-side component, especially for load-balancing. You still need to choose carefully though, if you need a lot of scalability.

The third advantage is that HTTP(S) traffic over standard ports can sometimes burrow its way through corporate firewalls in ways that other protocols can't. WebSockets support proxying for example, through regular HTTP proxies.

So there are a few wins, which each may or may not be relevant for you.

 

Just a quick update for anyone who is following this thread or has a similar concern in the future.

Since I am planning on using Unity for the client, my primary plan is that I can use Mono to develop a C# TCP socket server. Being able to run the server components on both Windows and Linux and also to share code between the client and server will give me a lot of flexibility and efficiency with the project. This is of course assuming that I don't need to use any features in C# that are not yet supported by Mono.

Having said that, and although I already have a functional multi-threaded TCP socket server as a personal test, I will be spending a day or two and looking into web sockets. There appear to be advantages and disadvantages to both methods so I need to better understand web sockets to either select or eliminate that option.

I will post again with another update once I've had a chance to go through this and try a few things out.

 

For C# websockets I mentioned Alchemy before - looking at the code though I have changed my mind and personally switched to using websocket-sharp, which (I think) has a more scalable threading model (better use of async I/O operations).