Differences Between Websockets and Long Polling for Turn Based Game Server

Web Socket vs Long Polling vs server-sent events for a cross-platform chat application?

WebSocket is built for applications such as this, while long polling (however well done) is a hack. Support for WebSocket is also very broad, and you can use e.g. a flash fallback in older browsers.
Server-sent-events are only part of a solution, and you have a big support gap in IE.
(Shameless promotion of an open source project I'm connected to: take a look at WAMP (http://wamp-proto.org) and Crossbar.io (http://crossbar.io), which offer communication patterns on top of WebSocket and provide a lot of infrastructure for building a chat application.)

Websockets Vs Long Polling For User Specific Details

First off, I know of no circumstance where long polling is more efficient than a webSocket connection for server push. So, if you want to push data from server to client and have the client get it pretty much real time, you will want to use a webSocket connection from client to server and then you can send data to the client at any time and the client will receive and process it immediately.

The rest of your question is a little hard to understand what your objection is to using a webSocket.

If you're concerned about data being kept private (only the specific user can see their karma value), then that's just a matter of proper implementation to enforce that. When a webSocket connection is established, the user has to be authenticated so you know exactly which user is making the webSocket connection. Assuming your web pages have some sort of user authentication already, you can piggy back on that same auth when the webSocket connection is established because cookies are passed with the http request that starts a webSocket connection. So, now let's assume you have an authenticated webSocket connection and the server knows which webSocket belongs to which user.

So, now it's a matter of only sending appropriate data on each webSocket. Your server needs to implement the correct logic for taking a given karma change for a given user, find the authenticated webSocket connections belonging to that user and then sending a message over only those webSocket connections to alert the client that there's a new karma value.

Long-polling vs websocket when expecting one-time response from server-side

The question is, can we say that for the case of one-time responses,
long-polling is better choice than websockets?

Not really. Long polling is inefficient (multiple incoming requests, multiple times your server has to check on the state of the long running job), particularly if the usual time period is long enough that you're going to have to poll many times.

---

If a given client page is only likely to do this operation once, then you can really go either way. There are some advantages and disadvantages to each mechanism.

At a response time of 5-10 minutes you cannot assume that a single http request will stay alive that long awaiting a response, even if you make sure the server side will stay open that long. Clients or intermediate network equipment (proxies, etc...) just make not keep the initial http connection open that long. That would have been the most efficient mechanism if you could have done that. But, I don't think you can count on that for a random network configuration and client configuration that you do not control.

So, that leaves you with several options which I think you already know, but I will describe here for completeness for others.

Option 1:

• Establish websocket connection to the server by which you can receive push response.
• Make http request to initiate the long running operation. Return response that the operation has been successfully initiated.
• Receive websocket push response some time later.
• Close webSocket (assuming this page won't be doing this again).

Option 2:

• Make http request to initiate the long running operation. Return response that the operation has been successfully initiated and probably some sort of taskID that can be used for future querying.
• Using http "long polling" to "wait" for the answer. Since these requests will likely "time out" before the response is received, you will have to regularly long poll until the response is received.

Option 3:

• Establish webSocket connection.
• Send message over webSocket connection to initiate the operation.
• Receive response some time later that the operation is complete.
• Close webSocket connection (assuming this page won't be using it any more).

Option 4:

• Same as option 3, but using socket.io instead of plain webSocket to give you heartbeat and auto-reconnect logic to make sure the webSocket connection stays alive.

If you're looking at things purely from the networking and server efficiency point of view, then options 3 or 4 are likely to be the most efficient. You only have the overhead of one TCP connection between client and server and that one connection is used for all traffic and the traffic on that one connection is pretty efficient and supports actual push so the client gets notified as soon as possible.

From an architecture point of view, I'm not a fan of option 1 because it just seems a bit convoluted when you initiate the request using one technology and then send the response via another and it requires you to create a correlation between the client that initiated an incoming http request and a connected webSocket. That can be done, but it's extra bookkeeping on the server. Option 2 is simple architecturally, but inefficient (regularly polling the server) so it's not my favorite either.

Pure websockets vs AJAX for browser multiplayer turn-based game

You should go for secure WebSocket. This will work in almost all network enviroments. Mobile. Enterprise. Etc. The exception potentially being so-called Man-in-the-Middle proxies which can unwrap TLS, and then WebSocket will depend on the proxy supporting and allowing it.

Note that with AJAX alone you don't have a push channel. If you want push and go with Comet, that can have it's own issues with proxies also.

WebSockets versus Long-Polling versus TCP Scalability/Ease of Use

I guess it depends on your usecase and tolerance for learning new things but, for sure, going down the path of using WebSocket APIs for communication, or even SSE, would better than a traditional long-polling/Comet solution for many reason - one that you mentioned - scalability, but also for bandwidth utilization and latency. It is important to also understand that WebSocket is to the Web what TCP is to the desktop e.g. a socket. In a desktop solution you don't necessarily code against TCP, you use a client library supporting a transport protocol like STOMP or XMPP over TCP. You do the same when using WebSocket, pick a server to communicate with e.g. XMPP server, and a XMPP client library to communicate with the server over WebSockets.

You can see our example of it here and we have docs you can read here.

The thing to watch out for is browser adoption of HTML5 WebSocket - currently in Chrome and Safari, and coming soon in FF and Opera. We have addressed this, but in case you plan to build your own server you will have to create a fall back solution for older browsers.

Connections in polling and web sockets

Long polling is where the client sends an http request to the server. If the server has data available for the request, it returns that data immediately as the http response and that connection is done.

If the server doesn't have any data immediately, then it hangs onto the connection for some period of time (designed to be less than a typical client timeout). If data arrives before the time limit, then the http response is sent with the data and the connection is done.

If new data does not become available in the server before the time limit expires, then the server returns a response that it has no data yet and that http socket is done. At that point, the client issues a new request on a new socket and starts the whole process over again.

Does long polling involve initiating a new TCP connection to the server for each request or is there a persistent TCP connection over which polling is done?

New connection each time. This is why polling is not particularly efficient.

If I understood it right, I think WebSockets allow the persistent TCP connection where data is exchanged between server and client and the duration of this connection is mentioned in the headers.

A webSocket is designed to be a persistent connection that can last a really long time and then data can be sent by either client or server at any time. A webSocket connection has additional setup compared to an http request, but can be a ton more efficient vs. long polling once it is established.

More info explained in these references:

websocket vs rest API for real time data?

Long-polling vs websocket when expecting one-time response from server-side

HTML5 WebSocket: A Quantum Leap in Scalability for the Web

What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?

In the examples below the client is the browser and the server is the webserver hosting the website.

Before you can understand these technologies, you have to understand classic HTTP web traffic first.

Regular HTTP:

1. A client requests a webpage from a server.
2. The server calculates the response
3. The server sends the response to the client.

Ajax Polling:

1. A client requests a webpage from a server using regular HTTP (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which requests a file from the server at regular intervals (e.g. 0.5 seconds).
3. The server calculates each response and sends it back, just like normal HTTP traffic.

Ajax Long-Polling:

1. A client requests a webpage from a server using regular HTTP (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which requests a file from the server.
3. The server does not immediately respond with the requested information but waits until there's new information available.
4. When there's new information available, the server responds with the new information.
5. The client receives the new information and immediately sends another request to the server, re-starting the process.

HTML5 Server Sent Events (SSE) / EventSource:

1. A client requests a webpage from a server using regular HTTP (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which opens a connection to the server.

3. The server sends an event to the client when there's new information available.

   • Real-time traffic from server to client, mostly that's what you'll need
   • You'll want to use a server that has an event loop
   • Connections with servers from other domains are only possible with correct CORS settings
   • If you want to read more, I found these very useful: (article), (article), (article), (tutorial).

HTML5 Websockets:

1. A client requests a webpage from a server using regular http (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which opens a connection with the server.

3. The server and the client can now send each other messages when new data (on either side) is available.

   • Real-time traffic from the server to the client and from the client to the server
   • You'll want to use a server that has an event loop
   • With WebSockets it is possible to connect with a server from another domain.
   • It is also possible to use a third party hosted websocket server, for example Pusher or others. This way you'll only have to implement the client side, which is very easy!
   • If you want to read more, I found these very useful: (article), (article) (tutorial).

Comet:

Comet is a collection of techniques prior to HTML5 which use streaming and long-polling to achieve real time applications. Read more on wikipedia or this article.

---

Now, which one of them should I use for a realtime app (that I need to
code). I have been hearing a lot about websockets (with socket.io [a
node.js library]) but why not PHP ?

You can use PHP with WebSockets, check out Ratchet.

---

Related Topics