{"id":11960,"date":"2021-10-07T08:00:39","date_gmt":"2021-10-07T15:00:39","guid":{"rendered":"https:\/\/softwareengineeringdaily.com\/?p=11960"},"modified":"2021-10-08T09:27:09","modified_gmt":"2021-10-08T16:27:09","slug":"how-your-network-affects-user-interactivity","status":"publish","type":"post","link":"https:\/\/softwareengineeringdaily.com\/2021\/10\/07\/how-your-network-affects-user-interactivity\/","title":{"rendered":"How Your Network Affects User Interactivity"},"content":{"rendered":"

The internet was designed to move data worldwide, despite technological advancements, global catastrophes, or your geography.<\/p>\n

It\u2019s meant to be reliable, no matter any of those conditions.<\/p>\n

But the evolution of the internet has seen an increased pressure to deliver a larger volume of data while maintaining the same level of reliability.<\/p>\n

For example, real-time applications have begun to take over the internet. While they don\u2019t necessarily rely on transferring large amounts of data, they do require stable connections and the lowest possible latency to avoid minimal delays or interruptions.\u00a0<\/p>\n

Enter WebRTC.<\/b><\/i><\/p>\n

Google first announced WebRTC as an open-source package to facilitate real-time audio and video streaming in a browser-agnostic fashion. Fast forward roughly ten years since the release in 2011, and we have reached a point where we can\u2019t imagine life without using these real-time communication applications.\u00a0<\/span><\/p>\n

While the support of WebRTC is still a work in progress, to say the least (Safari being the most notorious offender of all major browsers), both WebRTC and the applications employing WebRTC have come a long way, to the point where for the most part our online communication feels as good as real-time with a decent frame rate and overall video\/audio quality.<\/span><\/p>\n

A vast majority of the applications employing WebRTC rely heavily upon an underlying API present in most modern-day browsers called \u201cgetUserMedia.\u201d Here\u2019s where we can draw a correlation-causation analogy. getUserMedia is used to fetch either the audio or video streams from the user\u2019s microphone and camera. Since most WebRTC based applications rely on either voice or video or both, we can make an informed guess that an upward trend in microphone and camera use would imply an increased usage of WebRTC based products, too.\u00a0<\/span><\/p>\n

We can glance over the <\/span>Chrome platform status<\/span><\/a>; for this API (getUserMedia), you can see that the trend keeps going upwards! The slight downward trend can be attributed to the fact that offices started opening up – this isn\u2019t necessarily indicative of the fact that WebRTC\u2019s usage has gone down –\u00a0 remember, we are making a correlation-causation analogy here!<\/span><\/p>\n

\"\"<\/a><\/p>\n

One can quickly realize that this leads to a central point of failure – if a malicious actor understands how to game the WebRTC protocol, they can essentially apply the same formula to most communication tools to overtake them. Since the pandemic caused in-person meetings to be a thing of the past, all talks, be it random jibber-jabber or highly secretive\/sensitive business topics, happen over these applications.\u00a0 Security needs to be one of the top concerns of a software group deploying WebRTC.<\/span><\/p>\n

What exactly would a company that relies heavily on WebRTC in their application want to achieve? Given the current state of WebRTC, there are three things to consider:\u00a0<\/span><\/p>\n

    \n
  1. Latency<\/span><\/li>\n
  2. Security of communications<\/span><\/li>\n
  3. Maintenance cost of infrastructure<\/span><\/li>\n<\/ol>\n

    Latency<\/b><\/h3>\n

    To understand what affects latency, we need to know how WebRTC functions. The diagram below describes the handshaking and eventual secure communication between Peer A and Peer B.<\/span><\/p>\n

    \"\"<\/p>\n

    A quick takeaway from looking at this picture is that Peer A and Peer B cannot somehow magically communicate with each other. WebRTC needs an intermediary infrastructure in place to somehow connect these two peers.<\/span><\/p>\n

    Suppose Peer A wishes to speak with B, then A generates something called an offer, and the task of the WebRTC protocol is to relay the offer to B. Hiding the underlying intricacies, Peer A\u2019s \u201coffer\u201d includes information that can help Peer B link back to Peer A, the protocol facilitating this transfer is called Session Description Protocol & the act of exchanging the offer is managed by signaling methods which can either be SIP (Session Initiation Protocol) over a WebSocket or a JSON over WebSocket. Once this initial offer\/answer combination is exchanged, ICE (Interactive Connectivity Establishment) swoops in and processes the inbound SDP (Session Description Protocol) to then determine the optimal path to connect through – here\u2019s where STUN, TURN & Signalling servers come into the picture.<\/span><\/p>\n

    A STUN server is required by the party initiating the offer (in our case Peer A) to generate a list of ICE candidates. Once that\u2019s done, using the signaling servers, we transmit the offer to the intended Peer (Peer B in our example).<\/span><\/p>\n

    Skipping a few steps ahead, Peer B would now employ the signaling servers again to send an answer to the offer generated by Peer A.\u00a0 Then, based on the answer, the two peers may begin communicating.<\/span><\/p>\n

    You might wonder how and why TURN servers never came into the picture in this entire description. And you\u2019re right – TURN servers are a sort of fallback. In cases where your clients cannot generate a direct Peer-to-Peer connection, TURN (Traversal Using Relay NAT) servers come into the picture and facilitate your peers to connect to each other.<\/span><\/p>\n

    TURN is a must-have for any application that is heavily reliant on WebRTC since not all clients can have a P2P connection. However, these are notorious for introducing latency into your network.<\/span><\/p>\n

    An application like Subspace provides a managed solution to this problem. <\/span>GlobalTURN<\/span><\/a> is a way to achieve managed TURN servers providing the least latency! The graph below indicates the latency savings achieved when using Subspace instead of normal internet routing.<\/span><\/p>\n

    \"\"<\/a><\/p>\n

    Think about it – you\u2019d ideally have to figure out the best server pairing by investing development time behind this. Even after investing all this time, as your application expands and your user base grows, this data becomes irrelevant since users from different parts of the world start connecting. By eliminating the act of self-managing, you free up time that can be invested behind actual business logic and let a network experienced in managing these to the most optimal degree do it for you – ensuring your users get the best experience possible. Traffic bottlenecks are one of the significant sources of delay in RTC. GlobalTURN avoids this altogether, making even the TURN-based connections feel as if they were genuinely peer-to-peer.<\/span><\/p>\n

    Security<\/b><\/h3>\n

    Building on top of what we\u2019ve established so far – we can realize there are many points of failure in this entire communication channel, leaving the peers and subsequently the whole network-wide open to attacks.<\/span><\/p>\n

    A bunch of possibilities includes:\u00a0<\/span><\/p>\n