It's a Long, Long Poll

July 20th, 2010

1

HTTP, that sprawling protocol responsible for creating and sustaining
the World Wide Web, deals only in requests and responses. That is,
client-generated requests, and server-generated responses. This is strictly observed. J. Random Webserver on the Internet cannot call your web browser up and go beep in its ear.

It happens like this: A client calls out to his server and asks for a
martini. The server gives him a martini. This works fine until the
server forgets to put the olive in. Then what to do? The server can’t go give the client an olive on his own initiative. It just isn’t done. Don’t be gauche. The client must notice the missing garnish and make another request.

Or imagine a desperately sober client denied a martini because the server is fresh out of vermouth. Sure, the server can send a flunky off to buy another bottle, but how will the client get the martini when the vermouth returns? He must ask again, but how will he know when to ask? The flunky uses the back door, and the server keeps all the bottles out of sight behind the bar to avoid those Yosemite-Sam-shooting-up-the-saloon-inventory-shrink incidents. The client must keep asking the server, “Can I have a martini now? How about now?” over and over again. The conflict grows old. Client gets frustrated, server gets testy. Meanwhile, another client gets annoyed, because the server is blocked answering the requests for a martini, when all he wants is a simple mohito.

Our hero must continually poll the server for changes, but how often
to make the request is a tricky value to reckon. He wants the martini as soon as ingrediently possible, but he must not get greedy with the server’s time, or somebody may call the bouncer. If only the server could tell the client, “It may be awhile, but I’ll send you the martini when it’s ready.” So long as the server and the client have compatible conceptions of the acceptable ranges of “awhile”, this appears a viable solution.

Really, it’s not much different than a normal bar transaction. Cocktails do not appear in one’s hand the moment one asks for them. Would that it were so! Cocktails take some non-negligible time to prepare, and clients expect this. The difference between thirty seconds and thirty minutes, however, can be determinative. The client must be prepared to wait, and the server must be prepared to remember all the clients who are waiting. It helps, too, if the client can place the order for the next martini as soon as he receives the first one. Instead of interval-driven polling, the client uses event-driven polling: “Thanks for the drink; I’d like another as soon as expediently possible.”

All this may appear rigamarole. In the real world, servants ask what you want and then deliver it to you. No request/response nonsense; that would get a server fired, or dressed in embarrassing livery. But in the world beyond the world, HTTP is king of the hill. It survived; it scaled; it colonized. This strict dance of protocol passes firewalls, leapfrogs proxies, submits to Network Address Translation. Let me tell you about firewalls, and Network Address Translation:

Natalie is the waitress when there’s no room at the bar. She has flaming red hair. She’s a real firecracker. The client and his friends sit in relative comfort at your private table, and this hot chick on roller skates relays his requests to the server, and she relays his responses back. Natalie has a thankless job; every client knows what he wants, and every client expects to get the martini he asked for, and not the Peach Bellini requested by some suit in the next booth. Her little notepad, or even her correspondence-course eidetic memory, only has room for so many clients and so many drink requests. The server can keep track of them all; easy for him, as he’s got a whole bar’s worth of room for orders. Moreover, Natalie’s shift does eventually end, and she just shrugs that apron off and disappears, a drift of unfulfilled request slips swirling after. A couple hours later when the server finally gets the vermouth and stirs up a martini, you’re still waiting at the table, but nobody knows who ordered the martini. CockFAIL.

So there are limitations inherent to this long-polling plan for continuous imbibing. You have to account for intermediaries who lose track of your order, intentionally or otherwise. And you can’t just tell the bartender to keep ’em coming. You make a request, knowing that it may take some time to fulfill, and when it is fulfilled, you immediately come back with another. This is how you operate the long poll.

Long polling with HTTP works almost as well as long polling at the bar. Open up a TCP connection (you were going to do that anyway) and fire off a request for a resource. No response comes back, but you don’t panic. You want the resource when it’s ready, not before, and you know how to wait. The TCP connection is still open, and maybe the server winks a keepalive or two at you to make sure it stays that way. Before you know it the resource is available, and the server delivers its response. You keep the connection alive (because you’re no fool) and request the resource again.

For the client, long polling is easy. All you need is patience, expressed as a healthy timeout. A sympathetic firewall helps. The server has a harder job; it must maintain a large number of open connections, track an equivalent number of requests, and pay attention to the world in order to satisfy those requests. It’s a royal pain, but it makes a few things easier. Things like snazzy red number badges in your browser toolbar that tell you when you have new slides to read.

Our server said to tell you, “You’re welcome.”

(photo credit)

Tagged with: http, comet, martinis

Related Posts

• Caching: Making the Web faster
• Really using HTTP

Author