Apr 28

Apr 28 Designing WiFi for Dropbox

We use Dropbox… a lot!

Which got me to thinking… I should probably share what I do for WiFi and why I do it. Quite often I explain to a customer the reason for the configuration we’ve chosen other times I can tell they don’t care as long as ‘it works’.

So why am I specifically bringing up Dropbox? Well, it’s an interesting one because depending on the needs of the customer I’ll set up the WiFi differently.

Let me explain….

Dropbox is a cloud service, right? Well… kinda…

Its also a LAN service and it can have a massive impact on the network depending on how they have their network setup. Dropbox has a function called ‘LAN Sync’ where it will ask the Dropbox server for a file and it’ll let the client machine know ‘someone at your Public IP already has this file (if they’re on the same subnet)’ the client device will use some network discovery to find it and download it from there first. I won’t go into the full details but you can find them here.

Here are the best bits…

Each machine periodically sends and listens for UDP broadcast packets over port 17500. These packets contain:

The version of the protocol used by that computer
The namespaces supported
The TCP port that they are running the server on (17500 is reserved, but that is no guarantee that it will be available, so we may bind to a different port)
A random identifier. We could identify requests by IP address, but it is hard to avoid connecting to ourselves or to avoid seeing the same peer twice just using that (we may get their packets over multiple interfaces, for example).

When a packet is seen, we add the IP address to a list for each namespace, indicating a potential target.

The actual block transfer is done over HTTPS. Each computer runs an HTTPS server with endpoints of the form '/blocks/[namespace_id]/[block_hash]'. It supports the methods GET and HEAD. HEAD is used for checking if the block exists (200 means yes, 404 means no), and GET will actually retrieve the block. HEAD is useful in that it allows us to poll multiple peers to see if they have the block, but only download it from one of them.

So now we need to balance out internal and external traffic… or do we? So the same thing can be said here again for just use 80MHz until you can’t, use 40MHz until you can’t then use 20MHz. If you’re an engineer on site all the time I agree this is a good way to go. When you have to get something up and running first-time, no mistakes. I tend to err on the side of caution and go the other way. Start at 20MHz width channels and if you need it to go up to 40MHz. That’s what I want to suggest here.

For my clients that use Dropbox ‘normally’ (i.e. they work on their files but might need to share them internally and they’re mainly smaller files) I normally just stick to 20MHz wide channels and they don’t notice a difference because often the internet bandwidth is a bigger bottleneck than the channel width (especially because my WiFi designs are so on point 😉).

However, working mainly with ‘creative’ companies (who all use Apple) they quite often have large files that teams of people work on. This is where we tend to have a Dropbox caching server (there’s no such thing it’s just what we call it). We’ll get a decent computer (not always a Mac but most of the time, yes a Mac) and add some serious storage on to it (normally a thunderbolt RAID device). This has nothing special attached to it other than maybe a faster NIC (we used to use thunderbolt to fibre SPF+ adapters but some Macs come with 10Gb Ethernet now… the Mac mini is a fav). We then use the admin login for Dropbox and set everything as downloaded or ‘local’ to that RAID device.

Now whenever a client on the network needs a file it’ll download it from the RAID rather than from the internet. Unfortunately, this doesn’t solve the upload issue although Dropbox only updates any changes to a file and not the whole file (save your work regularly people). It actually does this in a cool way by splitting up all the files into smaller 4MB files that are hashed. Like this…