Home » History » Version 39
Greg Burri, 11/27/2008 04:23 PM
| 1 | 1 | Greg Burri | h1. Home |
|---|---|---|---|
| 2 | |||
| 3 | 3 | Greg Burri | * [[Study of bittorent protocol]] |
| 4 | 8 | Greg Burri | * [[Study of UPNP]] |
| 5 | 39 | Greg Burri | * [[Study of UDP multicast]] |
| 6 | 38 | Greg Burri | * [[Study of Thrift]] |
| 7 | 37 | Greg Burri | * [[Study of Protocol Buffer]] |
| 8 | 30 | Greg Burri | * [[Protocols]] |
| 9 | 3 | Greg Burri | |
| 10 | 31 | Greg Burri | h2. Brainstorming |
| 11 | 4 | Greg Burri | |
| 12 | 21 | Greg Burri | * Core and GUI are independent. They communicate over TCP socket. |
| 13 | ** It is possible to launch the core without the GUI. The core does not depend of any kind of graphic library. |
||
| 14 | ** If the GUI crashes then the core remains. |
||
| 15 | 22 | Greg Burri | * Designed for LAN usage (full trusted peers and very high speed transfers). |
| 16 | 37 | Greg Burri | * Efficient (very low CPU usage). |
| 17 | 18 | Greg Burri | * Distributed download (multi peer downloading and no central server). |
| 18 | 36 | Greg Burri | ** Quicker peer first. The speed of a peer is an average over a period of time say 5 min. The speed of an unknown peer is maximum thus it will be take first. If a downloading is too slow (like three time slower than the best known peer) then it can switch to a quicker free peer. |
| 19 | 1 | Greg Burri | ** Rarest parts first. |
| 20 | 37 | Greg Burri | ** A part can be resumed from any peer which own a complete copy. |
| 21 | ** A file from a user is identified by its name and its folder. |
||
| 22 | 1 | Greg Burri | ** Fixed part size (2^24 B = 16 MB) hashed with SHA-1. Used to control the integrity of parts and to identify each part. If the SHA-1 of a part does not match the given SHA-1 then it will be re-downloaded entirely. |
| 23 | 37 | Greg Burri | ** The number of concurrent download is around 3 parts and the number of concurrent upload is unlimited. |
| 24 | ** Recursive folder downloading, in this case the path is recreated in the downloading peer. |
||
| 25 | 18 | Greg Burri | * There is a general chat. |
| 26 | 25 | Greg Burri | * Multicast UDP for services discovering (maybe UPNP). Each peer announces periodically he is alive with a multicast message. |
| 27 | 18 | Greg Burri | * MDI GUI with GTK2HS. |
| 28 | 1 | Greg Burri | ** A panel to view the current peers and their amount of sharing. |
| 29 | 39 | Greg Burri | ** A window to view the current downloads (leechage) and one for the current uploads (seedage). These windows are very similar. |
| 30 | ** A window for the chat. There is no private chat. The chat uses UDP multicast (if possible). |
||
| 31 | ** Some windows for each file browsing. The files and folders are seen like a tree (like in the Finder of Mac OS X) |
||
| 32 | ** Some windows for each file searching. The displayed list is identical to the browsing list. |
||
| 33 | 18 | Greg Burri | ** A modal window for the settings. |
| 34 | *** The shared folders. |
||
| 35 | 1 | Greg Burri | *** The incoming folders (take the first if enough available space disk otherwise the second and so one..). |
| 36 | 34 | Greg Burri | *** Bandwidth and CPU limitation with a single option (checkbox). |
| 37 | 1 | Greg Burri | * Using of "Thrift":http://incubator.apache.org/thrift/ for definition of the protocol between two peers and between the Core and the Gui. |
| 38 | * File list with name+size. |
||
| 39 | 39 | Greg Burri | * Non blocking search, the list is dynamically filled for each peer answer. |
| 40 | 1 | Greg Burri | * Using of systray (optional). |
| 41 | 39 | Greg Burri | |
| 42 | h3. Secondary ideas |
||
| 43 | |||
| 44 | 18 | Greg Burri | * Parse meta data like ID3tag when searching. |
| 45 | 39 | Greg Burri | * Graphics of the transfer rate over time. |
| 46 | * Free space management. |
||
| 47 | * Private chat |
||
| 48 | * Automatically detect a running game and set the limitation flag. |