60

I would like to know what kind of limitations there are in using websockets.

Websockets is just so.. powerful. I can't imagine that it is without disadvantages.

Say, what is the number of users that can simultaneously connect to a server (if I'm creating a game and users will connect to the game through WebSockets, what will limit the number of users able to connect at any one time?)

Also is it true that with each additional connection, the quality of the connections (speed and stuff like that) will decrease?

Pacerier
  • 86,231
  • 106
  • 366
  • 634
  • 1
    @vitaut the thread that you linked is about Gmail.. not really websockets. I've edited my question to focus more on the second part of the question in case of any confusions. – Pacerier Jun 11 '11 at 12:19

2 Answers2

56

The advantages and disadvantages will of course depend on the specific use case, but I'll try to point out some differences between WebSocket and HTTP.

WebSocket is more complex than HTTP. You can establish an HTTP connection with a telnet client, but you probably cannot do the same with WS. Even if you ignored the handshake requirements (which include the use of the SHA1 hash function), you would then be unable to properly mask and frame the data to be sent, and the server would close the connection.

As Uwe said, WebSocket connections are intended to be more persistent than HTTP connections. If you only want to receive an update every 30 minutes, you will want to go with HTTP. If you want to receive updates every second, a WebSocket might be a better option, because establishing an HTTP connection takes a lot of time.

To establish an HTTP connection, you first have to establish a TCP connection (SYN, SYN/ACK, ACK), then send a GET request with a pretty big header, then finally receive the server's response (along with another big header).

With an open WebSocket you simply receive the response (no request needed), and it comes with a much smaller header: from two bytes for small frames, up to 10 bytes for ridiculously large frames (in the gigabyte range).

You need to weigh the two costs (keeping a connection open vs establishing a new connection) to decide between the two protocols.

Note: this answer is based on the current draft of the protocol (draft-ietf-hybi-thewebsocketprotocol-09). WebSocket is evolving rapidly, many implementations are still based on older drafts, and some details may change before it is finalized.

suriv
  • 757
  • 8
  • 13
  • 4
    PS: for a real-time game you probably want WS; for something turn-based (like chess), HTTP polling might be appropriate. – suriv Jun 19 '11 at 09:18
  • heys thx for the help. what delay do you think is appropriate for chess games with http polling? – Pacerier Jun 19 '11 at 20:10
  • 3
    It may depend on how fast-paced the game is, maybe as low as 1 second for blitz chess, but 5 or even 10 seconds would be doable in a slower-paced game. The most important is to give the user a good experience. Something I forgot to mention is that you need to know how your server handles connections (thread-based or event-based). If it creates a new thread for each connection you will run out memory if many users are connected at the same time. If it is event-driven, then WS can be very efficient. – suriv Jun 19 '11 at 20:58
  • i'd understand the thread theory, but what do you mean by event-driven implementation of WS? – Pacerier Jun 20 '11 at 08:39
  • @Pacerier I mean using something like the select() system call to handle many connections in a single thread. See http://stackoverflow.com/questions/6206590/using-websockets-efficiently/6207285#6207285 – suriv Jun 20 '11 at 09:54
2

From what I read, this seems to be related to HTTP Server Push which I read that it is usually not recommended to use since it creates lots of connections on the server.

If I have to choose, I probably would always develop a client polling mechanism.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
  • 1
    yep its definitely a server push technolog. However wouldn't it be taxing for the server as well for each client to hit it once every 5 seconds.. (or sometimes even less) – Pacerier Jun 11 '11 at 12:57
  • 2
    If it hits for every 5 seconds, it only has to provide one connection to the client every 5 seconds and can later close/reuse this connection. When having a push technology, my understanding is that the connections _always_ has to be present. – Uwe Keim Jun 11 '11 at 13:40
  • Ok good point. However, instead of doing it every 5 seconds, i do it every time its completed. In other words, *connect.. done, connect.. done, connect.. done, connect..*. In this case what would be your opinion (push or pull?) – Pacerier Jun 11 '11 at 14:27
  • @Pacerier I'll still try pull first. If you are not satisfied, then try push. – Uwe Keim Jun 11 '11 at 15:07