Wired magazine in 1997 published an article headed “PUSH! Kiss your browser goodbye”, predicting a future where Push technology will supersede the pull mechanism. In simple terms, rather than “data surfing”, it would be “data in your face”. Even though the prediction was right on spot for push technology becoming prevalent, the browsers are still out there and pretty much active. In fact all browsers now support web notifications. Simple reason browsers can’t die, as of now, is because push is currently not a reliable and consistent mode of data transfer. With the enormous amount of data generated each second, pushing relevant content to the user is certainly the future, but the picture is far from ideal right now. There are multiple reasons for that.
First of all, there is no standard protocol for push like we have for web (HTTP, HTTPS). Push essentially uses modified pull mechanisms like long polling, periodic pulls and pushlets. Relying on lower level protocols like UDP and TCP doesn’t guarantee delivery and scale. Chat protocols like XMPP can pose separate problems like Network congestion and battery drain (in case of mobile). “Chatty” applications consume a lot of bandwidth even if they don’t transfer high amounts of data since many to and fro signals are required to reestablish a broken connection. Primary reason of call drops and unreliable net speed are network congestion and not to forget “bandwidth games” of our lovely network providers. It definitely is not easy for both the network and servers to maintain open connections for so many devices. Browsers have a limit of 6 open connections to a single host and almost all network providers have removed unlimited data plans.
Another problem is that since different platforms use inherently different push techniques, there can be a considerable difference between “apparent” delivery and “actual” delivery. Imagine a 3 Node system where node 1 receives data from node 2 via almost real time push and node 2 synchronises data from node 3, which is the actual data source via periodic pull. Even though node 1 seems to be receiving data real time but it actually can be stale.
Lets compare Android and Apple’s push notification systems. GCM’s (Google cloud messaging) new two way communication built over XMPP offers real time communication between server and device. It looks really interesting and if reliable can present whole range of possibilities. Contrary to GCM, APNS (Apple push notification service) though maintaining open TCP connections to devices, tries really hard to transfer minimum bytes over network and works only one way. In fact it had a limit of just 256 bytes of push data compared to 4096 bytes of earlier version of GCM, which it recently increased to 2048 bytes.
Simply put, it is a trade off between bandwidth used and latency. It cannot be solved just with a new protocol or building push techniques above pull. It needs to be solved at a much lower level. One solution can be placement of local server which is pushed all updated content on behalf of the whole LAN, and individual clients consuming data from that server. This solution can work for organisations but not for users who don’t have any kind of firewall. In that case, may be a data aware network can optimise bandwidth consumption by reusing duplicate data. To conclude, I would say that even though Big-Data is the hot topic right now, but it would not be able to function without a solid network layer to push data to the users.
Abhinav
[email protected]
