Inside LAN Sync | Hacker News Reader

Inside LAN Sync

blogs.dropbox.com

68 pointstweakz31 comments

I’m disappointed that they used the stone-age method of UDP-broadcasts-on-a-reserved-port to find other servers when there are modern standards like ZeroConf which work quite well.

UDP broadcast is probably much simpler to implement and the code to implement it is likely to be cross platform, whereas using ZeroConf would require interfacing either with the native platform's specific implementation, or including it's own implementation when the platform lacked one, and then dealing with interoperability issues between all the platforms.

Interoperability shouldn’t be an issue – that’s what a standardized protocol is for. MacOS X has Bonjour already built-in. On Linux you can simply require Avahi. For Windows there seems to be a large selection of available ZeroConf libraries, depending on your implementation language (unless you want to simply require Apple’s “Bonjour Print Services for Windows” bundle).

>For Windows there seems to be a large selection of available ZeroConf libraries

Not the last time I looked. Apple's SDK seems to be the defacto implementation on Windows.

https://learn.adafruit.com/bonjour-zeroconf-networking-for-w... - hah, looks like you need to get iTunes if you want the newest Bonjour. I might write something to extract it from the installer. I wonder how many EULAs I'd break in the process.

You wouldn't be the first to think of that: http://lists.apple.com/archives/bonjour-dev/2015/May/msg0000...

Crap. Time to work out how to fund an implementation of Avahi for Windows.

Also: https://developer.apple.com/softwarelicensing/agreements/pdf...

Wasn't Windows 10 supposed to come with an mDNS/DNS-SD stack?

It does, and there's apparently something in it that's not what Avahi expects, which causes Avahi to spam your syslog with "invalid packet received" maany times. And there's no option to tell avahi to shut up about it :/

Oh yeah I saw something on the Avahi mailing list the other day about that:

http://lists.freedesktop.org/archives/avahi/2015-October/002...

You just mentioned three different things necessary for three different platforms. I could imagine it being easier to write a simple platform-independent piece to handle the subset of functionality Dropbox needs.

I'm sure Dropbox has the engineering resources to support Zeroconf is they want to :)

Apple's C DNS-SD API[1] is available on OS X and Windows and Avahi offers a shim that implements a decent subset of it.

1: https://developer.apple.com/library/mac/documentation/Networ...

Down votes for pointing out the same API is available on three platforms? (And iOS and recent Androids for that matter.)

> Interoperability shouldn’t be an issue – that’s what a standardized protocol is for.

It's definitely an issue with many cases. Unfortunately people make mistakes in implementation and standards have ambiguities, so a common case is doing a lot of interop experiments and code tweaks, and your position is going to be weak if you're not a big player: Others won't test their changes against you and their changes may break your interop.

Depends a lot on the complexity and maturity of the protocol of course, cost/convenience of interop testing, whether there's a de-facto standard/dominant implementation to be bug compatible with, and whether you need (m)any-to-(m)any interop or not.

Something like Bluetooth is going to be the worst case because it's physical devices, can't test it remotely and you need many-to-many interop testing and there are a zillion implementors with varying levels of competency... and something like SMB is going to be easy because everyone talks to 1-2 server implementations and they're just software.

Zeroconf might be somewhere in between.

ZeroConf is a relatively simple protocol, and there are only a few implementations on the OS level. Since Dropbox control both sides of the protocol, and only run on operating systems (and not on embedded devices), they could easily ensure that all their implementations interoperate by testing all combinations.

This subthread was about zdw's option b) of Dropbox having to support both the OS protocol implementation and its own. In which case Dropbox would not control both sides of the protocol.

I think the protocol fairly complex and simultaneously underspecified (if by ZeroConf you mean mDNS and DNS-SD). Mash up multicast, DNS, dynamic DNS updates, and DNS-SD so that every node is running in effect both a DNS server and client... what could possibly go wrong ;)

> relatively simple protocol

We must have a completely different definition of 'relatively simple' then.

It shouldn't be an issue, but it actually is. There is the exact same problem in bittorrent space: there's a BEP (extension) for discovering peers using Zeroconf (BEP 0026, as can be read in [1]) and "Local Peer Discovery" that doesn't even have a BEP.

The Zeroconf way is kind of cumbersome, especially if you don't have an easy way to do the whole mDNS and DNS-SD. And since Windows doesn't have a native way to do this (you need to use the Apple SDK) and it seems most bittorrent users are Windows users, nobody seriously bothered with that.

LPD on the other hand is the simplest thing you can ever think about (https://forum.utorrent.com/topic/54306-local-peer-discovery-...):

> in short: join the multicast group 239.192.152.143:6771 and listen for SSDP messages. Every 5 minutes, announce yourself to the multicast group by sending this message:

> snprintf(msg, 200, "BT-SEARCH * HTTP/1.1\r\n" "Host: 239.192.152.143:6771\r\n" "Port: %d\r\n" "Infohash: %s\r\n" "\r\n\r\n", listen_port, ih_hex);

I'll agree with you that if everyone talked Zeroconf it would be great, but the truth is, it's far too heavy and difficult compared to the alternative of polling a simple UDP socket, which pretty much any language can do easily.

[1] http://bittorrent.org/beps/bep_0026.html

"Standards?" Only within the same operating system, and forget Windows. Actually most good things with networks evaporate when you consider the need to support Windows.

Does anyone know why LAN Sync is normally turned off by default?

Security reasons. It can be used to confirm whether or not a certain file exists on another PC on the network by observing where it's synced to/from.

That said, there's nothing novel here. People have been doing this for decades, and extensions to the bittorrent protocol use it all the time to prioritize LAN seeds over internet seeds. In fact, I believe there was talk a while back about optimizing BT to prioritize peers and seeds on the same subnet/ISP as a way of mitigating ISP bandwidth concerns and whatnot.

Facebook use bittorrent as part of their deployment process, they exploit rack and cluster affinity to improve performance [1].

[1] https://facebook.com//download/1411324735760067/devops.pdf

ROCKS clustering software was doing this before Facebook. We'd use it to reinstall Redhat on ~6000 Linux nodes. Could reinstall the entire cluster in 15 minutes while still running jobs for end users.

Twitter has been doing this for a while: https://blog.twitter.com/2010/murder-fast-datacenter-code-de...

Perhaps your concern is slightly distinct, but the article addresses the discovery concerns you have given.

Specifically, a LANSync peer can only request blocks for which it shares namespace authorization. Each distinct shared folder context (e.g. a folder shared between users, a whole Dropbox folder authorized for a single user on multiple computers) has a different namespace, and that namespace is associated with a keypair, issued by Dropbox. Block discovery and exchange is conducted over HTTPS, with each client and server having to use the key associated with the namespace of the block they wish to exchange.

Since Dropbox clients/peers use SNI to identify the namespace, an eavesdropper on the network could know that two computers have access to the same namespace/folder (it is not clear from the post if the namespace contains any specific identifying information beyond its uniqueness), but not which files (or, more accurately, blocks) that namespace contained. A user who knew the key for a namespace could identify blocks being exchanged, but such a user would already have owned the Dropbox installation enough to have access not just to the list of files but to the files themselves.

I can say why it should be turned off by default -- because as a user, I don't want Dropbox knowing anything about computers on my network and relating IP addresses on the LAN to specific users. I'll take the long download times.

But you are still running dropbox on those computers on your LAN. What makes you think dropbox doesn't already know all about those computers?

This explains the high cpu usage on lan sync. Using http to send large files. So, it has to constantly encode/decode to send over http. For reasons like this I'm saddened that we never standardized on a secure file transfer protocol.

What do you mean by encode/decode? I would expect TLS is the bottleneck here.

Druva already something similar called Cloud Cache. Excerpt: Metadata is managed directly on the cloud for snapshot consistency and global deduplication across all enterprise endpoints.

http://www.druva.com/documents/Druva-CloudCache-Datasheet.pd...

Reply on news.ycombinator.com