Friday, August 6, 2010

Interaction with Firefox Download Manager

I would like a torrent download to be managed by the Download window for stopping/pausing/progress/opening-file. To this end, it appears nsIDownloadManager.addDownload would be appropriate. But there be dragons.

The method requires the passing of a URI to be downloaded, but that doesn't quite fit with the manner of Bittorrent. Perhaps an appropriate URI would the location of the .torrent file, but that isn't true - for one, if this was used the Download Manager would just download the .torrent file, and I can't link this to the download of the 'real' torrent, so hitting pause/stop/etc. will not have a connection with the real torrent download.

A second issue is that the addDownload method takes a destination file. It's rare to see a torrent contain just one file, so this again is an impossibility. I expect the download manager is expecting a nice channel to read from and then feed this into one file. Not so good for my situation.

So, I have an idea. One part is the representation of a torrent by using a URI in the form of a magnet-URI. This way, I can pass the nsIDownloadManager a magnet: URI which will get the Download Manager to call the magnet protocol handler which will feed the Download Manager data from the real torrent. Yay, just need to implement a magnet: protocol handler.

This however doesn't help with the one destination file problem. So, the second part of this is to split a torrent into multiple URIs. So, given the example of this torrent:
  • The current magnet URI is magnet:?xt=urn:btih:25H6RSS2GDS4BT235LTX7IE4UMNOCEM7&tr=
I'm offering the following URIs for the individual files in the torrent:
  • magnet:/01%201%20Mist.mp3?xt=urn:btih:25H6RSS2GDS4BT235LTX7IE4UMNOCEM7&tr=
  • magnet:/2%20Vietcong Blues%20.mp3?xt=urn:btih:25H6RSS2GDS4BT235LTX7IE4UMNOCEM7&tr=
  • magnet:/3%20Chill%20Song.mp3?xt=urn:btih:25H6RSS2GDS4BT235LTX7IE4UMNOCEM7&tr=
  • etc.
So now when a torrent is opened, each item will appear in the download window. This would work well for interactions with the addDownload call to nsIDownloadManager: each item has a unique source and destination address. Also, it provides an easy manner for removing files in a torrent without another GUI.
But... this isn't a normal magnet URI, it contains paths (which given a bittorrent source, seems reasonable... though again this isn't normal). As it is used in a closed system maybe it's okay...

Thoughts? Hmm? The key problem I see is that if I start using magnet URIs, I probably need to support them properly, at least for the ones related to Bittorrent. But that's a lot of work, as it requires implementing BEP 0005, BEP 0009 and BEP 0010.

Thursday, August 5, 2010

Tad tired with Bittorrent/Firefox

Last night added:
  • timers to keep in contact with Tracker after first call (prior to this, called Tracker once)
  • set a minimum interval for the above to 2 minutes, otherwise uses the interval received from the tracker
  • will now retry a disconnected peer if it appears in a tracker response received after a 10 minute cool down.
  • notification on completed torrent (alert)
  • if Firefox is shutdown, saves state of torrent download to a status file in the folder the torrent is downloading to
  • if a .torrent is opened, and then chosen to download to a folder with a status file that matches the infohash of the torrent, it will resume from the state in the status file.
  • timer for keepalive with peer
  • used existing counters for download/upload/remaining bytes
  • informing peers of completed pieces (sending it on keepalive, only informing if the peer doesn't have the piece)
Obvious missing things:
  • Listening to port (no server started or even implemented yet). Would like to listen on one port for multiple torrents.
  • No ability to control downloading (ie. stop it) except closing browser. Would like to use download manager.