The server can issue another notice that Client D indeed has the latest copy of the file A. upon learning that Client D indeed seems to have the latest copy of the file (it can lie but it will be exposed at the end of the copying process with another client since the checksum does not match if client D does not have the authentic copy or corrupt copy.).That it has the latest copy of the file A by sending its check sum etc. Upon the successful completion of the file copy, client D can notify the server (Possible additional step to let Client D also act as the source of the latest copy of File A.) copying of the file is done from Client C to Client D.client D verifies its authenticity by checking the server PKI sign of the notice,.Let's pick up another client D on the LAN.Ĭlient D always listens for such an announcement on the LAN. This client C advertises that it has the latest copy of File A by broadcasting the notice on the LAN (this is similar to UPnP). Now upon receiving the notice from the server, If each client has its own PKI key pair, obviously, that client can be identified by its public key.) has the copy of a file, let's call it file A, and others can copy it instead of copying it from the server. Maybe a MAC and other PC identification combined. When a client creates/modifies (or removes) a file, and this is propagated to the owncloud/nextcloud server after the ordinary processing (transaction-wise), the server issues a notice (signed by server PKI key to avoid forgery) that this client, let's call this Client C (I am not entirely sure how the client is identified uniquely. I am not claiming Dropbox's method is the best, but it uses an established protocol (RFC) to broadcast the new file/modification and to exchange application-level command/data/response and so owncloud/nextcloud should do something similar. So if you have Dropbox installed on your PCs in your LAN, monitor the LAN traffic with a packet capture tool.Ĭreate/modify/delete files on one PC or the other, and you will see what I described above. The server can keep track of what version files were placed into each client with the LAN sync featureĪnd that the proper syncing will continue. Of course, there may be a few more version-related information, etc. When the other client checks with the server and finds that it needs to download a set of files, it canĪsk the local LAN first to see if other PCs have such files, and when one PC answers yes with the above list (and it is signed with server's key), it can begin copying the file using SSL using a key based on RSA/DH or whatever. Obviously, this client has the most up-to-date copy of the files.) ![]() Maybe for the files the particular client has created/updated recently (i.e., has just uploaded to the server. ![]() With server's PKI signature (to avoid forgery), that the client has theįiles (timestamp, checksum) and the authority to hand out the files. ![]() Its payload seems to contain the file list and other information that tells, based on my educated guess, That is, Dropbox uses the same underlying protocol used by UPnP to broadcast a request or announce the availability of files and then let the peers to exchange files after a certain negotiations. I found out about it when I checked the LAN activity for UPnP and other low-level lan activity. ![]() I am not entirely sure what Dropbox does (especially the communication with its server: it is encrypted using SSL, I think.), but as someone mentioned that there are peer-discovery and communication. Hi, I wrote in 2015 at owncloud/client#230
0 Comments
Leave a Reply. |