How LAN Sync Moves Data Between Nearby Machines
Dropbox’s LAN Sync feature lets a desktop client pull file data directly from another computer on the same local network, rather than always fetching it from Dropbox’s servers. For a user on the same LAN as someone who has added a file to a shared folder, this means faster transfers and less bandwidth consumed on the upstream connection.
The feature was recently rewritten and improved. Here is a technical look at the pieces that make it work.
Data Is Addressed by Blocks, Not File Names
Internally, Dropbox splits files into 4 MB blocks (the last block is smaller if the file size is not evenly divisible by 4 MB). Each block is identified by the SHA-256 hash of its contents. A file is described simply by the ordered list of hashes of its constituent blocks.
Namespaces are the abstraction behind Dropbox’s permissions model. Each account has its own personal namespace, and every shared folder is itself a namespace that multiple accounts can access. Download requests can therefore be reduced to a series of (hash, namespace) pairs: “download this block, authenticated as that namespace.” This keeps the download pipeline agnostic of file names and how blocks assemble into files.
Because LAN Sync handles only actual file data, all metadata — including file names — is always fetched from Dropbox’s servers. That ensures all clients converge on a consistent state.
Three Components Run on the Desktop Client
Discovery
Finding peers on the LAN is the first task. Each machine periodically sends and listens for UDP broadcast packets on port 17500, a port reserved for LAN Sync by IANA. The packets advertise the protocol version in use, the set of namespaces the machine supports, the TCP port where it runs its server (17500 may be unavailable, so the server may bind elsewhere), and a random identifier. The random ID is necessary because IP addresses alone make it hard to avoid seeing the same peer twice across multiple interfaces — or to avoid connecting to yourself.
When such a packet is received, the sender’s IP address is added to a potential-peer list for each namespace it advertised.
Protocol and Transport
Block transfer happens over HTTPS. Each machine runs an HTTPS server with endpoints shaped like /blocks/[namespace_id]/[block_hash], supporting both GET and HEAD. A HEAD request returns 200 if the block exists and 404 if not; the GET request returns the block payload. That split allows a client to poll several peers to see who holds a block, then download from only one of them.
Security here is subtle. The concern is not that a malicious peer might serve bad data — the client can verify the content by hashing it. It is that an unauthenticated observer can learn which block hashes are being requested. To prevent that, Dropbox uses SSL in a custom way: each namespace gets its own SSL key/certificate pair, distributed from Dropbox servers only to clients authenticated for that namespace. The certificates are rotated whenever namespace membership changes, such as when someone is removed from a shared folder.
Both ends of the HTTPS connection authenticate with the same namespace certificate, proving that both are authorized. Server Name Indication (SNI) tells the server which namespace certificate the connection is intended for before the handshake completes.
Server and Client
The server side is straightforward: it knows which blocks it has stored and where to find them. The client maintains per-namespace peer lists from the discovery engine. When asked to retrieve a block, it sends HEAD requests to a random sample of those peers, then pulls the block from the first peer that confirms it has the data.
To avoid paying an SSL handshake cost for every single block, the client uses connection pools. Connections are opened lazily, kept alive after use, and carefully managed across multiple threads so they can be checked out, returned, or closed when a connection is dropped.
The client is designed to fail over fast. Aggressive timeouts ensure that a slow peer does not delay syncing: if a LAN peer does not respond quickly, the client falls back to the regular Dropbox block server. The implementation also caps the number of connections made to a single peer and the number of peers asked for a given block. These parameters were tuned with real-world use in mind and can be adjusted remotely via Dropbox’s servers when needed.
Enabling LAN Sync
LAN Sync is built into the Dropbox desktop app. Users can toggle it from the Network tab of the preferences. To observe it working, set up two computers on the same network that share either an account or a folder, drop a file on one machine, and watch the other pick it up.
