Push or Pull? Stateless or Stateful?
So Bill says XMPP matters and is “pushing” a push model for message delivery.
Am curious, though, if this debate can be re-framed as Stateless or Stateful? A stateless messaging system would map to a Pull strategy, placing the burden on the client to actively poll or pull its messages. A stateful system would map to Push, where the server maintains a connection for every subscribed client.
Stateful systems are hard to scale over the internet. One reason is because there’s a limit to the number of TCP connections I can maintain open at any one time. What’s the limit? Not sure, probably OS and configuration specific, but is that a limit that I’ll easily hit? If I’m not actively maintaining an open connection, can the system still be called Push?
An aside on Push vs Pull. Push might make for faster reacting systems, but I know that Pull is usually the way I want to process information. The more Push events I have, the less I get done, the less I can focus, and the more transient everything becomes. To get things done, I need to Pull information when I’m good and ready. So even if we’ve figured out how to scale Push and deploy it everywhere, the edge agents of mine will still buffer everything until I’m ready to Pull it.
So take that, Outlook email notification popups!
“If I’m not actively maintaining an open connection, can the system still be called Push?” - IMO yes, as long as I can open a connection to you and push information at you.
David Illsley
29 Aug 07 at 1:13 am
“The more Push events I have, the less I get done, the less I can focus, and the more transient everything becomes. To get things done, I need to Pull information when I’m good and ready.”
What makes you believe that Pull is more appropriate for doing more and more efficiently? Taking syndication as an example of a traditional Pull application, imagine that you go offline for vacations and after 2 weeks you get back: Are you sure that you are “good and ready” to manage the Pulled information from a large number of feeds (or email)?
Also Pull/Push can be combined in some interesting scenarios: email is Push as far as the sender in concerned but Pull for the receiver. You can also have email-to-im bridges or instant messages stored in a database and retrieved by Pull for some “enterprise” scenarios…
Stelios Sfakianakis
3 Sep 07 at 3:29 am
When I’m on vacation, I certainly don’t want any feeds pushed to me.
So in either case, I’m going offline. In a Push world, the server (or content provider) is responsible for maintaining the state of which events I’ve received and buffering the rest. That doesn’t seem too scalable.
Also, in the Pull model, when I get back from vacation, I can easily control the flow of old events as I pull at the rate I’m comfortable. In the Push model, there would have to be some protocol elements that helped control flow (rate).
sethladd
3 Sep 07 at 8:19 am