How ShareOnline Works

High-Level System Architecture

ShareOnline coordinates direct peer-to-peer data transfers between web browsers without storing or buffering file data on intermediate application servers. The end-to-end data flow operates as follows:

1. Signaling Phase

WebRTC peers cannot discover each other automatically over the internet without a rendezvous mechanism. ShareOnline provides a lightweight signaling layer:

• Room Creation: When a user drops a file, the host browser registers an ephemeral 6-digit room code and posts its session identifier to the signaling store.
• Session Join: When the receiver scans the QR code or enters the room code, the receiver notifies the host via the signaling service.
• SDP Negotiation: Browsers exchange Session Description Protocol (SDP) offers and answers describing their supported audio/video/data codecs and transport capabilities.
• Signaling Transparency: The signaling broker handles session negotiation metadata only (room codes, connection status, SDP tokens, and candidate IP addresses). The signaling broker does not process or store the transmitted file payload.

2. NAT Traversal & ICE Candidate Gathering

Most consumer devices sit behind Network Address Translation (NAT) firewalls and home routers, meaning they do not possess publicly routable IP addresses. ShareOnline uses Interactive Connectivity Establishment (ICE) to discover valid network pathways:

• STUN Servers: Both browsers query public STUN (Session Traversal Utilities for NAT) servers (such as Google STUN servers at stun:stun.l.google.com:19302) to determine their external public IP addresses and port bindings.
• Candidate Exchange: Browsers exchange ICE candidates (host, server-reflexive) via the signaling broker.
• Direct Pathway Selection: WebRTC tests connectivity across the gathered candidate pairs and selects the fastest direct path (local LAN pathway if on the same Wi-Fi, or direct UDP hole-punched WAN link).

3. WebRTC DataChannel & SCTP Protocol

Once the peer connection reaches the connected state, ShareOnline opens an RTCDataChannel:

• SCTP Protocol: Data channels run the Stream Control Transmission Protocol (SCTP), providing reliable, ordered delivery of binary messages over UDP.
• DTLS Encryption: SCTP packets are encapsulated inside Datagram Transport Layer Security (DTLS). Encryption keys are generated and authenticated directly between both browser instances.

4. 32 KB Chunk Streaming & Flow Control

To prevent browser performance degradation and packet loss, file transfer is streamed incrementally:

• Chunk Slicing: Using the HTML5 File API (file.slice(offset, offset + 32768)), the sender reads 32 KB binary slices as ArrayBuffer payloads.
• Backpressure Management: The sender monitors dataChannel.bufferedAmount. If the outbound buffer exceeds 512 KB, transmission pauses until the bufferedamountlow event triggers, preventing browser crashes and network packet drops.
• Client Reconstruction: The receiver appends chunks into an in-memory buffer. Upon receiving the completion signal, the browser creates a unified Blob and triggers an automatic browser download prompt.

5. Connection Lifecycle & Cleanup

Sessions are completely ephemeral. Unused rooms expire after 15 minutes of inactivity. When a transfer completes or either participant closes their browser tab, the PeerConnection and DataChannel close immediately, and in-memory buffers are garbage-collected by the browser engine.