1
\$\begingroup\$

I'm creating an html5 multiplayer game and am looking at how to create a websocket server.

I've been looking at various libraries and one thing I noticed is that each one will create a new thread for every client that connects. Now I'm fairly new to websockets, but I know that in the past when it came to game server design that a thread per connection was bad practice.

Is that true for websockets? Why is there a need to a new thread for every connection?

\$\endgroup\$
1
\$\begingroup\$

For game servers, yes this is a little less than ideal. There's nothing magical about WebSockets that make using them different than other similar protocols.

Most libraries implementing WebSockets are not designed for games. Threads are deemed the easiest way to implement these things by some Web programmers, driving mostly off of the unfortunate design of Java (which uses a separate thread for practically everything up until NIO was released, and that didn't take off the way one would have hoped). C# also sadly stuck by this design. Some Web programming environments also don't support multiplexing connections in a single thread due to their integration with external Web servers (the popular Apache having also been a one-thread-per-active-connection model in the past).

For a small side project I've been toying with I found the Tornado server (Python) to be the easiest to get high performance WebSockets (no threads). There are absolutely WebSocket implementations in most other languages that don't require threads, but most of them are either difficult to use, mostly unknown third-party libraries, or out-dated/buggy. If you're looking for such a library for your language of choice, you should ask on the main forums or mailing lists for that language; surely someone there would be able to give you links to usable libraries.

\$\endgroup\$
  • \$\begingroup\$ Thank you for the response. Unfortunately I feel like I may have to implement the websocket protocol myself. I'm creating the server in Java and I've searched high and low for a library that fits my needs to no avail, hence why I asked this question. \$\endgroup\$ – Steven B. Jan 19 '14 at 20:03
  • \$\begingroup\$ @StevenB.: github.com/TooTallNate/Java-WebSocket ? \$\endgroup\$ – Sean Middleditch Jan 19 '14 at 22:53
  • \$\begingroup\$ I've tried that library out and the WebSocketServer class creates a new thread for every client. I have thought of changing that class to suit my needs but I haven't looked at it in depth. \$\endgroup\$ – Steven B. Jan 20 '14 at 5:48
  • \$\begingroup\$ @StevenB.: ah, that's disappointing. \$\endgroup\$ – Sean Middleditch Jan 20 '14 at 6:09
  • \$\begingroup\$ > not designed for games - wrong \$\endgroup\$ – Vladimir Ishenko Aug 30 at 13:08
0
\$\begingroup\$

You could use Akka to manage all the concurrency and thread management for you. Or you could use the Play Framework that already builds on Akka and that supports WebSocket quite nicely. With Play you can choose between Java and Scala on the server side.

\$\endgroup\$
0
\$\begingroup\$

JS is a single-thread by design. You can't implement multithreading at all.

The only thing I can recommend is to use

Basically it's just a wrapper for classic ws package, but also allow to specify a messaging protocol to get rid of parsing JSON.

\$\endgroup\$

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.