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.


Comments

  1. UnknownMarch 23, 2013 at 12:27 PM

    Really good reading. Thx sir for writing it

    ReplyDelete
  2. The Display RoomNovember 1, 2021 at 3:39 PM

    You are providing good knowledge. It is really helpful and factual information for us and everyone to increase knowledge. Continue sharing your data. Thank you. Read more info about beyerdynamic Custom Game Stereo Gaming Headset

    ReplyDelete
  3. EntropiaNovember 16, 2021 at 1:50 PM

    Very well written article. It was an awesome article to read. Complete rich content and fully informative. I totally Loved it.Undetected Private Overwatch hacks

    ReplyDelete

Post a Comment

Popular posts from this blog

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

Image
Bandwidth estimation is probably the most critical component in the video engine of WebRTC. The bandwidth estimation (BWE) module is responsible for deciding how much video* traffic you can send without congesting the network to prevent degradation of the video quality. In the past bandwidth estimation algorithms used to be very rudimentary and based mostly on packet loss. Basically we used to start increasing slowly the video bitrate until we detected packets being lost.  To detect the packet loss you use the standard RTCP feedback mechanisms where the receiver side reports packet loss periodically using RTCP Receiver Report (RR) messages. Modern bandwidth estimation algorithms are more advanced and try to detect congestion before it is bad enough to make routers discard packets. These algorithms predicts congestion analyzing the delay between packets. The idea is that when you start having some congestion, the buffers in the routers will start filling and the delay will be
Read more

Improving Real Time Communications with Machine Learning

Image
When we talk about the applications of Artificial Intelligence / Machine Learning (AI/ML) for Real Time Communications (RTC) we can group them in two different planes: Service Level : There are many features that can be added to a videoconference service, for example identification of the participants, augmented reality, emotion detection, speech transcription or audio translation .  These features are usually based on image and speech recognition and language processing. Infrastructure Level : There are many ways to apply ML that do not provide new features but improve the quality and/or reliability of the audio/video transmission. Service level applications are fun, but they are more for Product Managers and I like technology more, so in the next sections I will try to describe possible applications of AI/ML for Real Time Communications at Infrastructure Level organizing those ideas in five different categories. Optimizing video quality Some of the ML algorithms used fo
Read more

Controlling bandwidth usage in WebRTC (and how googSuspendBelowMinBitrate works)

Image
There are cases when we would like to limit the maximum bitrate being transmitted by WebRTC to avoid wasting resources in the user endpoints or save money reducing the bandwidth usage in our servers.   This is because the maximum bitrate by default in Chrome is around 2Mbps and for many use cases a much lower bitrate provides still pretty good quality.   BTW using a lower bitrate can also help with stability of quality in multiparty scenarios by reducing the amount of competition among different streams. There is no simple API to configure the maximum bitrate in WebRTC (although there is one in ORTC) but there are 3 ways to do this by mangling the SDP. 1. U se the standard  b=AS:BITRATE (Chrome) or b=TIAS:BITRATE  (Firefox) attributes in the SDP for the audio or video channel[1] 2. Use codec specific attributes (this work at least for opus audio codec with maxaveragebitrate property) [2] 3. Use the proprietary x-max-bitrate attribute in the video channel of the SDP answer.  For e
Read more