TODO list for client
====================

ADD urn:sha1:<HASH> and urn:tree:tiger/:<HASH> to QRT

Fasttrack:
==========
 * Add more headers to GET requests
 * Fifo to reconnect to clients PER FILE, limited by the number of currently
    downloading clients

 * Problem with files containing corruption. Clearly, there is a bug
    somewhere, either in mldonkey, or in kazaa (bad implementation of
    pipelining ?). Or buffer_writes ?
  
Corruption ?? What to do to avoid it ? Maybe enter a special mode where 
every byte must be downloaded from different clients to be sure ? This
could be done by keeping the chunk in memory (9 MB is not big :) ), or just
the diff (ie we have downloaded it once, it is corrupted, so we have:
 * ranges which are similar to those written on disk
 * ranges that are different

What is this UDP message for :
EmuleReaskFilePingUdpReq 40351E4E097708BCBDEB336CDDAEE092

Associate kinds with networks, and only download useful urls



Let's schedule our work:
------------------------

For 2.5:
  - Fasttrack plugin
  - GUI:
      * Add columns for tags (or display tags in the margin)
      * Give more information on why a connection failed

For 2.6:
  - Save the URN computed for all files.
  - Gnutella:
      * Upload: use CommonUploads queues
      * Send more information in HTTP/1.1 headers (alt-locs, thex)
  - Misc:
      * Interactive downloads (popups for one file with progress bar)
  - Searches:
      * Make difference between Subscribe and Submit searches clear
      * Why doesn't filter_search work correctly with tags

For 2.7:
  - Gnutella:
      * THEX corruption detection
      * deflate-style compression
  - eDonkey:
      * Source management should be shared by other plugins
          DonkeySources3 --> CommonSources
      * Use CommonSwarming to choose ranges to download

For 2.8:
  - Download one file on two networks

For 2.9:
  - Gnutella:
      * Act as an ultra-peer
  - eDonkey:
      * export_temp so that they can be used from emule/edonkey
      * Share eDonkey partial chunks on Gnutella
  - Misc:
      * Implementation of sparse-files
      * CD get and Collections

For 2.10:
  - WinMX and Piolet

Bittorrent:
-----------
* Content-Encoding: gzip
* bt 3.2 ... a want= and have= parameter 
* Check that after the commit, we don't call the tracker, except if we continue
  to share the file
* started and completed should only be sent once
  * Pause/resume file
  * Reserve upload slots
  * Share downloaded files
  * Commited or not

* Use threads to copy files from temp to incoming

*******************
Before 2.4 :)
*******************

* Force connect to friends from time to time to see the shared-file lists.
   [ Bug #2504 ] 
* Try to display more information on where the memory is used... in the GUI ?
    with shared files ?
* Upstats doesn't work very well in GUI, More stats ?
* nu= (download = 0) mld becomes stalled
* We should be careful with remove: can a client still be in a queue for
   another file when removed ? Add a counter to the source !
* Comments propagation
* Error Not_found in udp_handler
* Add Offline status for bad connection
* Temp files could be saved with other names
* I have more clients than in the sources
* try to ensure that clients that have a pending slot are correctly
   added/removed.
* Replace network column by network icons, file state by icons too
* tty mode in telnet ?
* Sort commands for ?? like options
* Button "New Shared Directory" in upload
* Apply some pango's patches:
  * lots of obsolete parameters in "08_better_default_parameters"
  * Remove "a la mldonkey" source propagation
  * have a look at reliable_sources

Core:
=====
* One list of downloading files per user (downloaded common)
* SIGSEGV in MD4Transform

Edonkey + Overnet:
==================
* More Emule packets

  OP_REASKFILEPING (0x90) (size=16)
  OP_QUEUEFULL (0x93)
  OP_REASKACK (0x91) (size=2)
  OP_FILENOTFOUND (0x92)
* MLdonkey client generates "Exceeding Block Boundaries" errors which loses
     bandwidth
* Extended search doesnot work after connect because no ping was sent.
* Option to clear the server list at restart or when a new list is received
* Cancel and Redownload doesnot work
* What happens when a shared file cannot be read ?

GUI:
====
* GUI: strange bug: pausing on one file pause two of them...
* In gpattern, if an item from the selection is removed, the selection is
     not updated
* Some toolbars are not correctly updated between text, text+image, image
* Add an option tab similar to the one of mldonkeywatch
* Send all the locations to the GUI with their chunks
* Hide already downloaded files

Opennap:
========
* share files

Soulseek:
=========
 + Implement more of the protocol
 + Directory download in subdir ?
 + Check that we don't download several times the file list of friends.
 + Add a button in the tab_result to add to friend a file source (gui
      protocol -> file sources)
 + Use (file_name, size) keys for files_by_key, and iter on the table on
       upload requests to find the correct file.
 + Very long messages (several Megs) for shared file lists...
 + Remove all downloads from a given user
 + Display the number of new message per room

Direct-Connects:
================
* How do you know your IP in Direct-Connect if you are behind a firewall
* Send replies to active searches
* When a download is finished, can the link be reused ?
* Don't always download from incoming peer the files list
* Reply to active search requests
* For some reason, mldc cannot talk on some servers... France AVI for example.

GUI:
====
 * Change the color of tabs when things change

net/:
=====
* Socks 5 support

opennap/:
=========
 * Register files on server
 * Reply to upload requests

For 2.1:
  - What about having one result per file ?
  - Incomplete files can be automatically deleted when too old (7 days)
  - Add a "cp" function to change the temp directory without breaking
       the sparse file format (ie without increasing the size of copied files)


*********

Later:
  * Plugins.
  * Correct display of availability.
  * Popup
  * Keep (server_ip, server_port, id) for indirect connections.
  * Manager of shared files/directories.
  * Add Friends in console and WEB. 
  * Allow hostname instead of IPs in servers and friends.
  * Queue uploads per chunk.
  * Add prefered servers.
  * Save options in a modular way (each server in a file ?).
  * Recommandation for upload.
  * Download priorities (what does it mean ?).
  * Use source groups for local downloads.
  * Use a cache of data to help diffusing files.
  * Check that program exists before trying to execute.
  * Clean the clients_by_num table from clients which are not useful anymore.
  * remove locations of downloaded files.
  * check that 'cancelled' files cannot be shared also in incoming/
  * don't add sources to files already downloaded.
  * efficient management of buffers
  * background searches: 
   - search and automatically download files
 + remove unused sources (cleanly remove them at least once per hour)
 + commit page to select saved name
 + Imported files should have permission 644.[ Bug #420 ]
 
TODO list for server
====================
* Send a ping to all clients every minute
* Implement the whole protocol for TCP clients
* Implement the whole protocol for UDP clients
* Implement the protocol for UDP servers
* Implement indexation
* Implement localisation

KNOWN COMMENTS (from savannah and forum):
========================================
Browser: Mozilla/4.75 [en] (X11; U; Linux 2.4.17 i686; Nav) On the help page, it still says you can't set uploads
under 1K. 
If a server IP along with a colon seperated port number
is specified in the Server IP box, and enter hit, then
it gets added. This would make copy/paste from a list
of servers lots easier. Saving upstats would be nice, as well as some way of
resetting it, to get a better idea of which files to
keep shared. The downloads panel is a little busy, and not good for
small screens (some people still have to use 640x480) Perhaps move the 'save files' to an incoming tab?
(which can flash when it's got files in) On the same lines, why not show the filename/details
(the one above the colour bar) in a line, with name in
one box, size in the next (perhaps with bytes/Mb
added), and the format in another, with the colour bar
as the last item in the line, taking up the whole width
of the client, with the 'connections' panel only
popping up over the right-hand-side of the screen when
a filename is double-clicked (or when show connections
is picked from the menu)
The MD4 recover might move to the incoming tab, and the
ed2k file to below the filename/colourbar line, and
automatically change when a new file is clicked,
to show the ed2k: link.
Maybe the cancel/retry-connect could move to the
connections panel? On the search results tab, it would be nice to indicate
number of results per file, to give at least an
indication of availability.




GENERAL: 
- What ever happened to the 'collection' files from edonkey? I would like mldonkey to have that feature, so people can share collections of entire series. 

WEB INTERFACE: 
- Any chance of adding a graph to the web interface to show download/upload for a set period of time? that would truley rock. 

(21:36:13) pango: b8_bavard: first bug is that our pings lack an 0xe3 byte prefix
(21:36:37) pango: b8_bavard: should be 0xe3 0x96 (4 random bytes)
(21:37:06) pango: b8_bavard: second, the pings aren't sent at the right port; They're sent at server_port instead of server_port + 4
(21:37:57) pango: b8_bavard: I also asked some informations about the "Lugdunum server ping extension"
(21:39:03) pango: b8_bavard: if the last two random bytes are 0xaa 0x55, the server should reply with a longer packet; The 4 additionnal bytes return the maximum number of users allowed on the server
(21:39:41) pango: b8_bavard: I don't know if we could have a use for that...
Post subject: MLDonkey Core <-> Gui communication Reply with quote
Hi Core Developers, Simon, Pango and so on icon_wink.gif

Since some versions the core sends many file update messages to the gui.

thats a problem, because the core send many kb to the gui. (i thing about 25 MB / h)

i normaly connect my core per LAN or per Internet. Per lan is ok, but per internet is very bad, because i have only 32 kbs upstream (20 kbs for donkey) the other 12 kbs needs the core <-> gui communication.

so i think a good idea could be that the core don't poll the fileinfos so often, or that the gui could setup, polling off (new opcode, that when i connected with lan polling on, with inet off)..

so the gui must request the fileinfos with an interval.

i think don't polling the file infos should enough. i don't know how much needs the userinfos and user<>file mapping.

ps. sorry for that silly text i'm a bit confused at the moment icon_wink.gif

bye suxxx

