Hi Peter,

I’ve been thinking what should we pass to the TrackerManager::start() member function. We actually need only list of tracker URIs (doesn’t matter if they’re from standard tracker or from normal peers using DHT) and info hash from the torrent metafile. I’m not sure whether we’ll need something else in the future though.

However, there is an issue with multi-tracker torrents (containing announce-list) - according to the specs, the announce-list format (tiers of announce, likes [[a,b],[c,d]]) is relevant and it needs to be passed to the start() function as is, e.g. QList <QList <Uri>>, because there are tracker URIs movements in these tiers according to the success of the connection to the tracker. This would make the TrackerManager forced to use this format, but with DHT there is no such thing and the announce-list (called “nodes” there) is only a simple QList <Uri>.

My question is: how should we solve this? One possible solution (and the simplest one I think) could be pass only QList <Uri> to the start() function (multi-tier announce-list would be flattened) and ignore specs in this particular case. I think you’ve already suggested this solution once (BitComet), so I just want to be sure that we make the right decision with all facts/problems known. There should probably be no problem with flattening the announce-list, so the only thing that worry me is that we won’t conform to the specification, but maybe this is not that big deal since it’s only optional and in the specs there is written that “This extension is not official as of this writing.”.

And the second part of my question is (as written above): should we pass only a list of tracker URIs and an info hash or a complete Torrent object to the start() function? My suggestion is the former solution because we’d be able to flatten the announce-list (if we choose to do so) before passing it and the TrackerManager would not need to know the ways how/from which place peers are get (e.g. standard tracker/DHT).

What do you think?

Regards,

Petr