I'm designing a distributed game server which will support both browser and UE4 clients (hopefully both over HTTP for simplicity) and I keep butting my head against REST and doing semantic backflips to get the logic I want put in place.

For some things, REST makes perfect sense - get a list of games, create a new game, get metadata about a specific game, etc.

But for other things, the client really only wants to generate an "event" - "I joined game X", "I performed action B in game X", or receive notification that an "event" occurred - "player A joined the game you are in", "player A performed action X in the game you are in", etc. Inside the REST world, you can make this work (believe me, I've tried) but it always involves some peculiarity that either distorts the domain model to make it fit the semantics of REST or distorting REST to make it fit the semantics of the domain model.

Is there any framework or paradigm for creating such a pub/sub model that supports interaction from the browser? My current idea is to hook up a websocket -> MQ proxy and use an MQ server as an event bus, but the problem is I'm finding it hard to find any such proxies and I'm not sure what the security implications of this architecture actually are (in particular I'm worried about protection against DDoS attacks, where multiple distributed users could spam the MQ and saturate it, causing the whole system to fail).

Websockets are also not preferable as, while UE4 supports HTTP out of the box, I'm not aware of it having any websocket support so I would need to find and link a C++ websocket library to the game client and that already sounds painful.

  • can you elaborate more on the "distorts the domain model to make it fit"? because REST, is a architectural style of communication, your domain should not know AT ALL about how the "outer layers" are receiving/sending messages... your domain should not care if its REST, SOAP or smoke-signal or whatever... – Leonardo Mar 30 '17 at 14:12
  • Right, that's exactly my point - in order to make the semantics of "performing an action in a game" work in REST, you have to pretend that "actions" are actually resources, at which point your domain model has been disturbed by the presence of REST, which is - as you rightly point out - an anti-pattern. The point here is to avoid treating what is semantically a verb as if it were a noun. – Chris Browne Mar 30 '17 at 18:50
  • @ChrisBrowne Treating "actions" as resources isn't a distortion of REST, it's necessary for distributed communication. "Actions", as typical languages tend to think of them, are functions, methods, procedures, subroutines, etc. Actions are code. Code doesn't serialize well in the general sense, so if you want to pass actions between two distributed actors you need an "action resource", a serialize-able representation of an action, to do that. This problem isn't unique to REST, REST just gives you a manageable way to model lots of distributed heterogeneous resources. – Jack May 2 '17 at 20:29
  • You say websockets are out, but they're exactly what you want... – RubberDuck May 4 '17 at 1:37

If you are looking for simplicity, you'll probably end up using WebSockets. In terms of simplicity, it has two major benefits:

  • Lots of libraries for many programming languages make it easy to set up.

  • Since it uses port 443 (or 80) and is mature enough to be supported by a broad range of software products, you'll have less problems with firewalls, proxies, reverse proxies, etc.

With a help of a message queue service, you can achieve a highly scalable platform where, in order to support a growing number of requests and users, you'll simply add nodes to MQS, or servers which will upstream MQS events up to the client through WebSockets. Popular MQS systems include a support for WebSockets, but scalability concerns may require a hand-made solution.

DDoS attacks can be avoided in a similar way you would do it for a simple REST service. WebSockets being a bidirectional communication protocol, it's technically possible to use it to send messages from client to server, not barely receiving messages from the server. However, you may also want to use WebSockets exclusively to push events from the server to the client, and keep REST requests for anything else. In both cases, your application should position itself as an intermediary between the client and the MQS, not only to protect you against DDoS, but simply to sanitize the inputs and provide an abstraction level. By comparison, the fact that a website uses an SQL database doesn't mean that the clients are able to run SQL queries directly; with MQS, it's exactly the same thing.

If you're at a level where WebSockets becomes a bottleneck (although I never developed any game, I could imagine that some games can hit the bottleneck), then and only then do you need to search for an UDP-based replacement.

| improve this answer | |

You could try SignalR 2.

It can be used to tie many clients together and all (or filtered) can receive messages from any that post to the server (or the server initiating the message directly).

There are many examples online demonstrating chat applications. But using these, instead of updating a textarea with someone's message, you can send whatever you need to update any client.

Basically, you can have a client send a post, the server can do what it needs to, and can then send out a message to the required/listening clients.

The clients can receive the message, then carry out any action they wish from that.

By default SignalR 2 will use the following connection methods (depending on support):

  • Websocket (full duplex over TCP)
  • Server Sent Events (based on HTML5 EventSource)
  • Forever Frame (hidden iframe)
  • Ajax long polling (artificial live connection)
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.