Functional definition¶

This page will describes the scope and utilization of Aybabtu.
Some sections will describe a particular window from the user interface, it may refer to the GUI page.

Description¶

Aybabtu come with two executable, the Core and the GUI. It possible to launch one of them alone or both together. The GUI is needed to command a Core, to tell it what you want to download, to share, to search, etc. To do that the user have to tell the GUI to connect to a given Core. The Core can be local or remote, by default the GUI will try to connect to a local Core. If the connecting attempt to a local Core failed it will try to launch a local Core.

The simple usage of Aybabtu is to launch the GUI which will automatically launch the Core. The user may not know there is two distinct process. The core will display an icon in the tray icon (if a tray icon exists). If the user close the GUI the core will continue to run, if he want to stop the core he have to invoke a contextual menu from the tray icon and choose Close the Core. The user can launch the core by double-clicking under the tray icon.

To connect to a remote Core, the user have to explicitly enter an IP address and a password. The password is mandatory for a remote Core. For one Core it cannot be more than one GUI connected (this limitation may be removed in further version of Aybabtu).

The GUI shows some default windows, a download windows, a upload window and a chat window. The others windows are the search window, the browse window and the options window. All of them are described in the sections below.
At the first launch of Aybabtu it will connect to all peers in the LAN and show them in a panel to the left. The informations show for a peer are its name and its amount of sharing.

The main window¶

The download window¶

• Quicker peer first. The speed of a peer is an average over a period of time say 5 min, it's computed by the downloader. 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.
  After A period of time without any download from a peer say 30min its speed is reseted to the maximum.
• Then rarest parts first from the chosen peers. If there is no rarest parts then the choice is randomly.
• A part can be resumed from any peer which own a complete copy of this part.
• 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 remote 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 (T) is alive with a multicast message. If we doesn't receive any alive message from a peer while 3*T we consider it dead and we remove it from the list.
• Tabbed MDI GUI with GTK2HS. See GUI for a preview.
  • 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 downloads then the incomplete ones with 0 peers then the current downloading files and finally the queued files and folders.
    The list can contains both file or folder, when a folder is downloaded its files and folders are retrieved from the peer and will replace the folder in the list (lazy download).
    There is a limit of the number of complete download. 500 for example.
  • 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.
  • A 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). If activated then downloading, uploading and hashing rates will be reduced.
• The files that are currently downloaded have the final size with a name like "movie.mkv.unfinished". The ".unfinished" will be removed when the download is finished. Maybe do the same thing for folder.
• Using of Thrift or Protocol Buffers for definition of the protocol between the 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. The search is active on files and folders name.
• Using of systray (optional).
• When you browse the files of someone you will see all its files with non-hashing files too.
  • The hashing will be created and sent when you decide to download a specific file.
• Support of UTF-8.
  • Creating many tests with special characters in the name of the files or directories
  • Maybe use of 'Distribution.Simple.Utils.toUTF8'
• Haskell language
  • A polymorphically statically typed, lazy, purely functional language. Very high level modern language.
  • Garbage collected.
  • Open source.
  • Efficient, native code compilation.
  • Can be use as script with a on fly interpretation. For configure/build scripts for example.
  • Good GTK-Binding : http://www.haskell.org/gtk2hs/