I've got a few years of experience with the fundamentals of the BSD socket API, and LAMP servers in general. It really interests me, and I've built some little "online game" projects. With that said, if I wanted to build a matchmaking server for a game I'm working on, I'd probably build the matchmaking server as a daemon in C using BSD sockets on my configured LAMP server, then use Apache + PHP to form a login system for my game client to allow players to log into their accounts that are stored on a MySQL database. This is what I've done in the past for school projects, and one game I launched years ago.

Now, assuming that this is a practical approach, what would be a decent service for hosting my matchmaking server publicly? I'm thinking that a cloud service would be best where I have access to my own virtual machine. Once the VM's hardware specs are defined, I'd set it up as a LAMP server, upload my production build of my matchmaking server, as well as the the database and PHP scripts.

Does anyone have any recommendations for a cheap-ish cloud-based solution where I'd have access to my own VM?

I'm also currently comparing host services for a matchmaking server. So far I've looked at Amazon EC2, Google AppEngine and some local cloud provides. Pricing is highly dependent on CPU, memory, and bandwidth needs, and I'm not able to compute costs yet because I'm still deciding what needs to be done on the server and what can by done by the clients or using a peer-to-peer scheme. AppEngine seems simpler to use (no OS admin), but doesn't allow UDP servers (yet?). Amazon has a lot of nice extra services, like database and storage services, that can potentially make the solution more scalable (but the pricing gets more complicated). The local cloud providers simply give you a virtual server and a some virtual storage for a fixed monthly fee.

So no conclusions yet, I will have to continue working out the architecture before I decide.

I was also in the same situation as you are now. I also checked what Amazon and others are offering. It doesn't work for me because figuring out what my expenses will be is really messy, impossible to predict at my current development state.

Right now I'm using Gamedonia, a cloud service for game development. I contacted them via email and they granted me access to their beta matchmaking based on an ELO system. It was easy to integrate it in my game.

Their pricing is independent from API requests and other variables. It's free to use during development, so it fits perfectly my current needs.

Amazon has lots of services that can make development and management convenient. Amazon can also get very expensive in a hurry if you're not paying attention.

If you're building most things yourself (and using open source for the rest) then the simplest option is likely a simple virtual private server to host things on. $6/month from www.interserver.net is a good candidate (there are others, including linode, dreamhost, Amazon micro instances, etc -- verify how much you'll be paying for bandwidth in addition to the server!)

I've looked at Amazon and Rackspace before posting, but hplus0603 has given me some great leads I'd like to check out! Amazon looks like it's got quite a bit of tools, but I'm pretty new at this, and it'd be way too much tech to start out with. Especially since it looks like pricing can be high and complicated to figure out.

Felix brought up a really good point about CPU and memory. I could predict how much memory would be needed based on connections (typically program overhead + approximately 48 bytes per connection), but then there's the CPU... Also, how would cloud systems handle thousands of connections. Say, 10,000 users were connected to my VM on the cloud, and I'm iterating through them constantly trying to create matches, then idling when there are none, how does VM manage so many connections at once? I understand that each connection would have its own socket handle, but how would the virtual network card/OS stack up against so many connections with a VM cloud environment? I'd think it'd do better than a bare-metal server sitting in my room lol.

Would Ubuntu Server or Free BSD be the way to go for my VM's OS? Btw, I checked out www.interserver.net, and it's looking pretty good to me. Will I have full access to my VM so I could build and run software on it, configure a LAMP server, etc? I noticed that it mentioned you could install dashboards like cPanel on it, but it looks optional.

Most providers providers give you full control to configure and build the OS as you please. Amazons own Linux image seems based on Red Hat, I think I would go with that one if I would choose Amazon. So I'm currently experimenting with a CentOS setup in VMware. OTOH, choosing another distro doesn't seem like a big deal, more a matter of taste.

Say, 10,000 users were connected to my VM on the cloud, and I'm iterating through them constantly trying to create matches, then idling when there are none, how does VM manage so many connections at once?

In general, the guest OS uses a paravirtualized bridge device, which then talks to the host hardware device. In proper implementations, there is negligible overhead compared to using the raw hardware directly. I can't guarantee that all VM hosts in the world are properly implemented/configured, but I have personally not found a problem with this.

Also, 10,000 connections is not terribly much for a modern CPU / OS, assuming you use a modern networking API (boost::asio, epoll, I/O Completion Ports, or whatever.)

And, finally, if you have 10,000 users all trying to match at the same time, count yourself lucky! If 5% of those users pay you $5 per month, you have more than enough money to pay for really fancy server hardware :-)

Haha, I like your thinking. I always thought that'd be difficult. I was just watching a video on the PS4 unboxing where one of the Sony engineers was talking about the PS4 having a second low-power CPU just to handle network traffic. They'll have their own custom Linux-based firmware, so I was wondering how a typical desktop VM like Ubuntu Desktop (not server) would stack up.

The only network programming I've done are BSD sockets, which I find fun, but there is quite a bit of babysitting going on there. I've learned from some research that games typically rely exclusively exclusively on UDP "connections" instead of reliable TCP sockets (even in P2P file sharing protocols) because TCP's reliability can be emulated with UDP pretty well. I've wanted to experiment with the enet library, but I just haven't dived into that yet.

First person shooters mainly use UDP, because it's better to lose one packet and have the next one arrive timely, than to have to wait for the lost packet to get re-transmitted before getting the next packet.

Turn-based games, strategy games, MMOs, and many other kinds of games just use TCP. It works fine for most kinds of games. For example, World of Warcraft uses TCP.

Does it now? I was thinking about that last year, but over the Spring this year, I was reading up on how games typically use UDP exclusively. In fact, having a TCP connection could actually slow down UDP. This, of course, sounds interesting when considering that the computer's/device's OS usually has many ports open for various processes --both TCP and UDP. I always thought that using UDP for updating player positions/animation states would be the best way to go, but then use TCP for important events, such as getting a kill in a deathmatch, firing a weapon, change in health, etc.

TCP is often prioritized over UDP traffic. If you can build a simple reliable protocol over UDP, it'll be easier in the long run, especially with NAT negotiation, and not having to deal with multiple sockets.

Building a reliable in-order messaging system on top of UDP isn't that hard, and you can keep it simple, if you don't care about latency (your messages arriving a few fraction of a second later). And in general, you will already have some sort of protocol to establish and maintain connectivity with your clients, which would roughly mimic a TCP-IP state machine.