The Limber Lambda

Anil Dash recently wrote an article on what he calls the Pushbutton Web, a catch-all term not dissimilar to AJAX that describes the popular concept of technology initiatives related to the real-time web.  The assertion is that open protocols like PubSubHubbub are the future means by which we’ll get real-time updates, that is, the real-time web will no longer be the exclusive domain of semi-proprietary protocols like those used with Twitter and Friendfeed.

PubSubHubbub sets out a way for subscribers to be directly notified when there’s an update to a providers RSS or Atom feed.  Here’s how it works:

• Firstly, the content provider (Any RSS source such as FeedBurner) requests a selected hub to respond to future notification pings about updated content (1);
• When a subscriber (choose your RSS reader) asks for content (2), the response (3) contains not only the newest articles but also some metadata informing the client that there is one or more hub that can be used for notifications;
• Subscribers subscribe to content updates by asking the designated hub for updates (4);
• As updates come in (5), they’re broadcast to interested subscribers (6).

Something key that I haven’t mentioned about the diagram above is that the lines represent HTTP requests and responses (blue are requests, green are responses).  The dotted lines represent the “push” part of the protocol.  Something that’s noticeable to anyone who’s ever had to do any networking or administration of a firewall is a rather naive assumption about the connectivity between the hub and the Subscriber.  Now, if by “Subscriber” we’re talking about your typical Internet-connected workstation, then there’s something missing in this picture.  That’s because the vast majority of Internet connected workstations connect via a firewall or a NAT device.

In practice, this translates to:

And trying to hunt down a response by the designers to this little snag reveals:

"I’m behind a NAT. Can I subscribe to a Hub? The hub can’t connect to me."

Anonymous

 

No, PSHB is a server-to-server protocol. If you’re behind NAT, you’re not really a server. While we’ve kicked around ideas for optional PSHB extensions to do hanging gets ("long polling") and/or messagebox polling for such clients, it’s not in the core spec. The core spec is server-to-server only.

Brad Fitzpatrick, San Francisco, CA

 

Looks like the final word on the matter. PSHB is not intended to be used by Internet connected workstation subscribers.  How then does PSHB help us get closer to an open-standard Twitter or Friendfeed?  In the short term, at least, it doesn’t.

So, to conclude, for all practical purposes, our “real-time-web” world is going to be one of piggy-backing the HTTP response, in it’s various incarnations.  To the purist, this spells “hack” and PSHB clearly hasn’t compromised on this one.  Hopefully firewall vendors out there will build in the ability to respect and forward incoming PSHB notifications at some point.  Until then though, the Internet will use what’s simple, available and works—that one I will agree with Anil on.