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\$

3 Answers 3

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\$
5
  • \$\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.
    Commented Jan 19, 2014 at 20:03
  • \$\begingroup\$ @StevenB.: github.com/TooTallNate/Java-WebSocket ? \$\endgroup\$ Commented Jan 19, 2014 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.
    Commented Jan 20, 2014 at 5:48
  • \$\begingroup\$ @StevenB.: ah, that's disappointing. \$\endgroup\$ Commented Jan 20, 2014 at 6:09
  • \$\begingroup\$ > not designed for games - wrong \$\endgroup\$ Commented Aug 30, 2019 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\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .