Algorithms » History » Version 15
Greg Burri, 08/04/2009 10:34 AM
For a functional description see here : [[Functional definition#The-search-window]]
This schema shows how the results are sorted from one peer. Each peer result are then merged.
h2. Peer ID
Each peer owns a peer id which is unique and generated during the first start. This ID is used to identify a peer, it's better than the previous usage of peer IP, considering this situation :
* _A_ put in queue a file entry _f_ from _B_, _B_ doesn't know the hashes of this file entry.
* _B_ change his IP address.
* _A_ want to download _f_, it can ask _B_ for the hashes even _B_'s IP changed.
h2. Core threads
There are three kind of threads in the core in addition to the main thread :
* [[Protocol_core-core#Downloading-thread|Downloading thread]] : @DownloadManager::ChunkDownloader@
* Uploading thread : @UploadManager::Uploader@
* [[Algorithms#Updating-the-file-cache|Updating file cache thread]] : @FileManager::FileUpdater@
h2. Updating the file cache
Here is the algorithm for the thread (@FileManager::FileUpdater@) which will periodically update the file cache and persist it.
D : The set of shared directories
T : Time during the hashes are computed (for example 30s)
F : A set of file initialy empty
- Add a watcher to the shared directories
// First synchronize (at start)
For each d in D (recursively) :
- Synchronize physical folders and files with d content
- Add in F the files which doesn't have computed hashes
t : Time.now
For each f in F :
- Compute the unknown hash of files f
- Remove f from F
If (Time.now - t) > T : break
- Wait T - (Time.now - t)
- Wait for changes for a period of P
- When a modification occurs synchronise the file/folder
- Add each new file in F
- Persist the entire cache in a file (only every ~30min)
See here : [[Protocol_core-core#Downloading-threads]]