Everything Old Is New Again: The Return Of Push
from the this-ain't-your-father's-pointcast dept
Recently I mentioned that I think services like Twitter are likely to help stitch together the variety of short-messaging options that are becoming available to mobile users. There’s another story here, though: the shift in net architecture that’s taking place in order to support these new services.
Jive Software has an interesting blog post about one of these technologies: XMPP, aka Jabber (ReadWriteWeb also has a thoughtful post on the matter here). Jabber is an increasingly popular XML protocol that powers instant messaging services like Google Talk — and many other things. As the Jive post points out, Tivo is beginning to use XMPP to notify its customers’ set-top boxes of schedule updates. The old alternative involved each Tivo polling a central server every so often to check for updates, the same way that email and RSS clients do. But that’s inefficient, particularly if the polling needs to be done frequently. An IM protocol is ideally suited to delivering messages with little latency and in a lightweight manner (and will know how to traverse users’ NAT routers, too). XMPP is particularly extensible and comprehensive, making it useful for many different applications.
And XMPP isn’t the only technique being used to solve these problems. Comet is another emerging technology with a similar purpose, but focused specifically on the web. Instead of repeated polling, a Comet app keeps one very long-running HTTP connection open, along which messages can be sent without waiting for the browser to ask for them. This lets applications like Gmail and Meebo deliver performance that’s virtually latency-free.
Although I’m tempted to avoid the baggage that comes with it, this trend does fit pretty comfortably into the push/pull paradigm of the late 90s. I have good reason for that reticence: as anyone who’s lived through periods of both thin and fat client triumphalism knows, enthusiasm for different technological approaches is cyclical, driven by whatever applications people consider most exciting at the time, and along the way shoehorning a lot of ill-suited apps into the hot paradigm du jour.
But this time the demand for push protocols is more than just a fad. It’s also a sign of our increasing technological sophistication. Polling is no longer an option for a lot of reasons, but all of them have to do with computing’s ubiquity: there are too many users, too many devices, and no patience for less than immediate performance. Broadcast was fine when technology was just entertainment; pull was fine when technology was just a supplement to our lives. But now it seems that the network is driving our daily activities, and we can’t wait around for it to do so.
Comments on “Everything Old Is New Again: The Return Of Push”
So, I’d like to comment not on the topic but on the writting. The article’s fine, Mr. Lee, but particularly towards the last two paragraphs you get very heavy into the jargon, with something of a corp-speak marketing bent, even.
I’m a tech salesman, so I swim in these kinds of terms daily, and STILL I had to spend a bit of time picking it apart to understand.
I’d just speak a bit more plainly, is what I’m sayin’.
I’ll admit I’m more tech savvy than a lot of people, but I can’t even find what you might consider jargon. Thin clients? Broadcast? Push and pull? Paradigm?
That’s great! Nice article. I’m not a tech salesman or even a man so I had to read the blog, but that’s good to know. A+ on that one Tim.
IPv4 vs IPv6
This is another illustration of the problems with IPv4 and the need to move to IPv6. Lots of those push devices will currently be behind NAT routers. Depending on how dumb those routers are, they are liable to drop entries from their tables for connections that have been inactive for some time.
The only way to prevent this happening is for at least one end to periodically send “Are you there?” messages to the other. The sole purpose of this is so the NAT router notices the connection is still active.
What does this sound like? Right–it puts you back into exactly the polling situation which you were supposed to be avoiding.
Re: IPv4 vs IPv6
So… redesign the internet with IPv6, or get smarter NAT routers?