Home¶

Brainstorming¶

• Core and GUI are independent. They communicate over TCP socket.
  • It is possible to launch the core without the GUI. The core does not depend of any kind of graphic library.
  • If the GUI crashes then the core remains.
• Designed for LAN usage (full trusted peers and very high speed transfers).
• Efficient (very low CPU usage).
• Distributed download (multi peer downloading and no central server).
  • 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.
  • Rarest parts first. If there is no rarest parts then the choice is randomly.
  • A part can be resumed from any peer which own a complete copy.
  • A file from a user is identified by its name and its folder.
  • 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.
  • The number of concurrent download is around 3 parts simultaneous but not more than 1 per peer. The number of concurrent upload is unlimited.
  • Recursive folder downloading.
  • The paths of the files are recreated in the downloading peer.
• There is a general chat. There is no private chat. The chat uses UDP multicast (if possible).
• Multicast UDP for services discovering (maybe UPNP). Each peer announces periodically he is alive with a multicast message.
• MDI GUI with GTK2HS.
  • A panel to view the current peers and their amount of sharing.
  • A window to view the current downloads (leechage) and one for the current uploads (seedage). These windows are very similar. The list is ordered, first the complete download then the current downloading files and finally the queued files.
  • A window for the chat.
  • Some windows for each file browsing. The files and folders are seen like a tree (like in the Finder of Mac OS X).
  • Some windows for each file searching. The displayed list is identical to the browsing list.
  • A modal window for the settings.
    • The shared folders.
    • The incoming folders (take the first if enough available space disk otherwise the second and so one..).
    • Bandwidth and CPU limitation with a single option (checkbox).
• Using of Thrift or Protocol Buffers for definition of the protocol between two peers and between the Core and the GUI.
• File list with name+size.
• Non blocking search, the list is dynamically filled for each peer answer.
• Using of systray (optional).
• Haskell language
  • A polymorphically statically typed, lazy, purely functional language. Very high level modern language.
  • Open source.
  • Efficient.
  • Good GTK-Binding : http://www.haskell.org/gtk2hs/

Secondary ideas¶

• Parse meta data like ID3tag when searching.
• Free space management.
• Private chat.
• Automatically detect a running game and set the limitation flag.
• Automatically detect CPU/bandwidth usage and set limitation flag.
• Protect some sharing by a password / user rights for shares.
• Statistics window with graphs.

Functional¶

• Functional constraints
• GUI
• Logo

Technical¶

• Study of the BitTorrent protocol
• Study of UPNP
• Study of UDP multicast
• Study of Thrift
• Study of Protocol Buffer
• Libraries
• Protocols
• Prototypes
• Guidelines