In addition, we limit the number of connections we are willing to make to any single peer, and how many peers we are willing to ask for a block. To this end, we have a fairly aggressive timeout on how long we are willing to wait before falling back to the block server. Of course, the most important thing is getting your files to you quickly, and we wouldn’t want a slow computer or connection on your network to slow things down. Designing these pools was a good exercise in concurrency, since they needed to be able to give out connections or have them released back into the pool or be shut down when the connection died, all while being accessed from multiple threads. We don’t open a connection until it is needed, and once it is open we keep it alive in case we need it again. One important optimization to avoid the latency of an SSL handshake each time we need a block is to use connection pools to allow us to reuse already-started connections. When the LAN Sync system gets a request to download a block, it sends a HEAD request to a random sample of the peers that it has discovered for the namespace, and then requests the block from the first one that responds saying it has the block. The client maintains a list of peers for each namespace (this list comes from the discovery engine). It just needs to know which blocks are present and where to find them. Given this protocol, the server is not complicated. One interesting problem: when making a connection, how do we tell the server which namespace we are trying to connect for? For this, we use, so that the server knows which certificate to use. This proves that both ends of the connection are authenticated. We can require both ends of the HTTPS connection to authenticate with the same certificate (the certificate for the namespace). These are rotated any time membership changes e.g., when someone is removed from a shared folder. These are distributed from Dropbox servers to user’s computers which are authenticated for the namespace. We generate SSL an key/certificate pairs for every namespace. The solution to this is to use SSL in a creative way. The concern here is not that they might try to give you bad data (we can check for that by ensuring that it hashes to the right thing) but rather that they might be able to learn something by watching which block hashes you request. We also want to make sure that computers cannot pretend to be servers for namespaces that they do not control. 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.īecause Dropbox aims to keep all of your data safe, we want to make sure that only clients authenticated for a given namespace can request blocks. HEAD is used for checking if the block exists (200 means yes, 404 means no), and GET will actually retrieve the block. Each computer runs an HTTPS server with endpoints of the form '/blocks//'. The actual block transfer is done over HTTPS. When a packet is seen, we add the IP address to a list for each namespace, indicating a potential target. 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). 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).The version of the protocol used by that computer.To do this, each machine periodically sends and listens for UDP broadcast packets over port 17500 (which is reserved by IANA for LAN Sync). The first challenge about LAN Sync is finding other machines on the LAN to sync with. The client is responsible for trying to request blocks from the network. The server handles requests from other machines on the network, serving requested block data. The discovery engine is responsible for finding machines on the network that we can sync with (i.e., machines which have access to namespaces in common with ours). There are three main components of the LAN Sync system that run on the desktop app: the discovery engine, the server, and the client.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |