Real-time communications in mobile development: what it is, what protocols and how it works

Real-time communications: WebSocket, SSE and Long Polling protocols

Real-time communications are technologies that allow data exchange between client and server with minimal latency. The main protocols: WebSocket, SSE (Server-Sent Events), Long Polling and Short Polling. Each has its niche: WebSocket for bidirectional communication, SSE for notifications, Long Polling as a fallback for older browsers. Real-time in mobile development is especially important: users expect instant delivery of messages and notifications. Communications in mobile development are built on these very protocols.

WebSocket vs SSE

WebSocket is a full-duplex protocol (client ↔ server). After the handshake (HTTP Upgrade) the connection remains open. Headers are minimal (2 bytes vs HTTP headers). Used in chats (WhatsApp, Telegram), games, real-time trading. SSE is a one-way protocol (server → client). The client subscribes to events and receives them over a single HTTP connection. SSE is simpler, easier to scale (plain HTTP), ideal for Twitter feeds, currency rates, push notifications.

Long Polling is a technique where the client makes an HTTP request and keeps it open until the server sends data or a timeout occurs (30–60 sec). After receiving data, the client immediately opens a new request. Long Polling is a fallback for WebSocket. Short Polling — the client polls the server every N seconds. Simplest but inefficient (most requests return empty responses).

Signaling Server

Before establishing a P2P connection, devices need a Signaling Server — an intermediary server for exchanging SDP offers and ICE candidates between peers. Signaling can be implemented via WebSocket, SSE or any other protocol. After the connection is established, signaling no longer participates in media traffic transmission.

WebRTC: real-time communications with audio and video calls

WebRTC (Web Real-Time Communication) is an open technology for P2P audio/video/data. Works in browsers and native applications (iOS, Android). WebRTC includes: getUserMedia (camera/microphone access), RTCPeerConnection (P2P connection), RTCDataChannel (data transfer). WebRTC enables real-time in mobile applications — communications in mobile apps work without additional plugins.

WebRTC Flow

Peer A creates an RTCPeerConnection and Offer SDP. Step 2: The Offer is sent via Signaling Server to Peer B. Step 3: Peer B receives the Offer, creates an Answer SDP and sends it back. Step 4: Both peers collect ICE candidates (addresses for connection) and exchange them via Signaling. Step 5: The ICE framework selects the best path (P2P or through TURN). After connection — media traffic flows directly.

SDP (Session Description Protocol) is a text protocol describing connection parameters: codecs, IP addresses, ports. ICE Candidate is a proposal from STUN/TURN: "I can be found at this address". The more candidates, the higher the chance of P2P.

Socket.IO is the leader for startups: you control the server, no limits. Pusher and Ably are for products where you don't want to manage infrastructure. PubNub is for IoT and global audiences. IT Sectr recommends Socket.IO for projects with your own backend, Pusher for a quick prototype, Ably for enterprise with reliability requirements.

Platforms: Socket.IO, Pusher, Ably, PubNub

Real-time platforms provide ready-made server infrastructure for WebSocket and SSE. They eliminate the need to write your own real-time server, balance WebSocket connections and scale them. The choice of platform depends on budget, reliability requirements and willingness to manage a server. For real-time in mobile development, platforms offer ready-made client SDKs and infrastructure.

Socket.IO

Socket.IO is a library for Node.js and clients (iOS, Android, web). Based on WebSocket, but uses HTTP polling as a fallback. Supports rooms, namespaces, ACK confirmations. For development — socket.io-client-java (Android) and socket.io-client-swift (iOS). Communications in mobile apps on Socket.IO are handled reliably thanks to automatic reconnection.

Pusher and Ably

Pusher is a real-time SaaS platform. Simple integration: create a channel and subscribe to events. Pusher Channels for notifications, Pusher Beams for push notifications. Ably is enterprise-grade with global replication across 7 data centers. Guarantees exactly-once delivery. Supports SSE, WebSocket, MQTT for IoT. Both platforms solve communication tasks in mobile development without writing server code.

Real-time infrastructure: STUN, TURN, Signaling in WebRTC

STUN (Session Traversal Utilities for NAT) is a server that helps a device discover its external IP and port behind NAT. The device sends a STUN request, the server responds: "You are visible as 203.0.113.5:45678". STUN is used for free (Google STUN: stun.l.google.com:19302). In the context of real-time infrastructure, STUN is the first step to establishing a P2P channel.

STUN vs TURN

TURN (Traversal Using Relays around NAT) is a relay server that relays media traffic if P2P connection is impossible (e.g., both devices are behind symmetric NAT). TURN consumes server bandwidth, so it is expensive. In WebRTC, the ICE framework first tries P2P, then TURN as a last resort. Real-time in development requires TURN for communications in mobile apps when connecting through corporate networks.

ICE (Interactive Connectivity Establishment) is a framework that collects all possible connection paths (local IP, external IP via STUN, TURN relays) and selects the best one. ICE Candidate is each possible path. The more candidates, the higher the probability of successful P2P.

Peer-to-Peer

P2P is a direct connection between two devices without an intermediary server for media traffic. P2P reduces latency (< 100 ms) and server costs. Disadvantages: weak NAT traversal, need for STUN/TURN. WebRTC uses P2P by default.

P2P and ICE

Peer-to-Peer (P2P) is an architecture where data is transferred directly between devices. In the context of real-time communications, P2P is used in WebRTC to minimize latency. ICE (Interactive Connectivity Establishment) is the mechanism that finds the best path for a P2P connection. For development, P2P is the optimal way to organize communications in mobile apps in real time.

How ICE works

ICE collects ICE Candidate of three types: 1) host (local IP), 2) srflx (via STUN), 3) relay (via TURN). All candidates are sorted, and ICE tries to connect with each in priority order. The first successful connection is used. If P2P is not possible, TURN is used (but it is expensive).