TCP vs Push Notifications

Analyzing existing RTC mobile apps from a technical perspective we can appreciate a clear dichotomy in the solutions being used today to maintain the communication channel between the apps and their respective servers to signal messages, calls and any other communication event.

In one side we have those apps maintaining a permanent TCP connection established between the client and the server, this is the case of Skype, TU Me or Google Talk.

In the other side we have those apps not maintaining a permanent TCP connection but using push notifications provided by the operating system (APNS in iOS and GCM in case of Android) to alert the applications of incoming events like messages or calls.   This is the case of WhatsApp or Viber.

Just looking at the user experience second group of applications tend to consume less battery (because maintaining a TCP connection usually requires periodic keepalives) and tend to be more reliable (because solutions more tightly integrated with operating system have less restrictions and fine grane control on network status specially in iOS).

With those arguments in place it would be obvious that it is better to use Push Notifications, but there are some limitations that typically are used to argue in favor of TCP permanent connection solution:

  • Providing contacts presence requires maintaining a TCP connection to detect which users are online/offline.    Yes, but...
    • Presence on mobile devices tend to be unreliable because of frequent changes on connectivity and it makes decrease the value of presence information.
    • The assumption of being always online is more realistic every day and having an extra presence information is of limited value.   Presence is a must in desktop applications but probably less than a nice-to-have in mobile apps.
    • Communications are moving to more asynchronous ways were being online or not is not so important.
  • Delays are higher because push notifications tend to be slow (quantitative measurements make me disagree with that argument at least in android with subsecond delays on Wifi and around 2-3 seconds on 3G) and because due to the size limitations of push notifications some times it requires an additional roundtrip to the server to retrieve the complete message.   This second problem should be marginal if implemented properly and most of the time the information can be presented instantaneously at least for text messages and telephone calls.
  • Lack of feedback after sending a push notification.   Google and Apple don't offer an explicit notification of destination having received the notification making the services requiring timeouts to detect those situations.    This can be a problem for applications having to take a decision based on reachability of destination (for example routing the call through PSTN if VoIP is not available) but I have doubts that is a common requirement for most of the apps.
  • Lack of control of user experience in iOS because the UI presented for an incoming push notification is decided by the OS.   But on the contrary that is the UI expected by iOS customers.
Having implemented both types of solutions in the last years I would recommend everybody using native push notifications unless there is a really really strong argument to not do that.  Less headaches and by the way probably some thousand of dollars saved on server infrastructure.


Post a Comment

Popular posts from this blog

Bandwidth Estimation in WebRTC (and the new Sender Side BWE)

Controlling bandwidth usage in WebRTC (and how googSuspendBelowMinBitrate works)

Using Native WebRTC simulcast support in Chrome (or how to be as good as Hangouts) [WiP]