The HTTP protocol is very ill-suited to handle an exceedingly common scenario: what happens if a server needs to communicate with its client? If the client wants to get information from a server, that’s easy: it just issues a request which the server can answer. But for the other way around? The server can’t reach out and initiate a request to the client.
This fundamental one-sided nature of requests creates all sorts of aggravating issues. Imagine you’re Facebook, and you want to have a messaging system? How will you, as the central facebook server, reach out to tell a user that they have a new message? If they’re on mobile, you can do a push notification, but if they’re on the desktop you’re out of luck…or are you?
The easy (and really dumb) solution
You could have your client continually request new information from the server all the time. Maybe once per second or more, depending on how fast you need the response. You could probably also characterize this as ‘you could have the client continually spam the server.’ You might even characterize this as ‘you could have the client DDOS its own server.’ This is not a good idea.
Long Polling
Alternately, what if the client requested information from the server (such as ‘any new messages yet?’) and the server just…didn’t respond? If anybody actually does message the client, the server can respond with the new info, but until that point, the server will impose a significant delay before responding with ‘nope, nobody wants to talk to you.’ This way you can cut down significantly on the traffic, while still maintaining a very quick response time to the client on the event of a message. This method is especially well-suited for situations where a fast response time is necessary but an actual response is unlikely, a la Facebook Messenger. In fact, it’s the implementation Facebook uses.
Sockets
What if we have a game though, and need to have a constant state of communication between the client and server? Long polling will start to lose some of its appeal. Every single message the server wants to send to the client must be preceded by a request from the client, which not only increases the overall amount of traffic flow, but also increases the time it takes for a server to communicate with the client. Wouldn’t it be nice if the server could simply communiate with the client directly?
Enter sockets. A socket initiates a request with a server once, which establishes a session between the two. At any point in time, the server can reach out and send a message to the client, or vice versa. If the client has new information to send to the server (such as input from the user), this can be sent immediately to the server. If the server wants to send information to the client (such as a new game state to be rendered), this too can be send immediately, without waiting for a preceding request. Awesome!
Upcoming
Keep an eye out over the next few days for an example of socket usage in a multiplayer browser game! The kicker: it’s surpsingly easy.