Architecture guide
What happens after you choose a file?
A direct browser transfer still needs a server at the beginning. The important distinction is what that server carries. In ADrop, the server introduces devices and forwards connection descriptions; the file bytes use a separate WebRTC data channel between browsers.
The path in one minute
- Each open page registers a temporary device presence over WebSocket.
- The sender shares file names, types, and sizes; the receiver accepts or declines.
- The browsers exchange WebRTC offers, answers, and network candidates through the signaling server.
- WebRTC establishes an encrypted data channel and the sender streams bounded chunks.
- The receiver writes chunks to a selected file, browser storage, or memory, depending on browser capabilities.
1. Discovery is not file transfer
When ADrop opens, it creates or reuses a random device ID stored in that browser. A WebSocket registration sends the ID, display name, device category, visibility choice, and IDs of previously trusted devices. For automatic “nearby” discovery, the server groups connections that appear to share a public network exit. It cannot read a browser's private Wi-Fi address.
This is a useful approximation, not proof that two devices occupy the same room. A large office or carrier network can place unrelated users behind one public address, while some IPv6 or VPN setups can make nearby devices appear unrelated. That is why the receiver still sees a request and must approve it.
2. The invitation contains metadata
Selecting files does not immediately send their contents. ADrop first sends a transfer request containing each file's name, media type, size, and optional relative path. The receiving browser uses that list to show an informed accept-or-decline prompt. File names can themselves be sensitive, so the sender should choose a recognizable destination and both users should avoid descriptive private names on untrusted shared networks.
3. Signaling helps two browsers find a route
After acceptance, the sender creates a WebRTC peer connection. The two pages exchange an offer, an answer, and ICE candidates through the WebSocket server. A STUN service helps a browser learn how its connection appears from outside its local network. These small coordination messages describe the proposed connection; they do not contain the selected file.
ADrop does not configure TURN. TURN is a relay that can carry application traffic when direct connectivity fails. Omitting it means the file cannot silently fall back to an ADrop relay, but it also means a restrictive NAT, firewall, VPN, or guest Wi-Fi can make the transfer impossible.
4. The data channel encrypts transport
Once ICE connectivity succeeds, WebRTC negotiates DTLS and opens a reliable data channel. Encryption protects traffic in transit between the WebRTC endpoints. It does not scan the file, prove that the other device belongs to a particular person, or protect a downloaded file after it reaches disk. The approval prompt and correct destination selection remain important.
5. Chunking prevents an unbounded send queue
The implementation slices each file into 64 KiB chunks rather than reading the entire file into one JavaScript buffer. Before sending more, it watches the data channel's buffered amount. At an 8 MiB high-water mark, the sender pauses until the queue falls to half that size. This flow control matters: without it, selecting a large file could create a huge in-memory queue faster than the network can drain it.
Progress is computed from acknowledged application flow, elapsed time, and total bytes. The displayed rate is a useful live estimate, not a benchmark: browser scheduling, Wi-Fi contention, and brief reconnects all make it fluctuate.
6. Saving depends on the receiving browser
Where supported, ADrop asks for a destination and writes chunks through the File System Access API. Otherwise it first tries the browser's origin-private file system, which avoids keeping one large JavaScript array in memory. If neither route is available, it falls back to assembling data in memory before exposing a download. The last fallback is the least suitable for very large files.
7. Resume has a precise boundary
If the data channel drops while both pages and the original file remain available, the receiver reports its file index and byte offset. The sender builds a new peer connection and continues from that offset. Refreshing or closing the sending page breaks this promise because browsers do not let a reopened site silently regain access to the original local File object.
For a transfer that fails before the data channel opens, use the network troubleshooting guide. For storage and tab-lifecycle limits, see the large-file guide.