Hi Petr,

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.

I think passing the Torrent object to start() gives us most flexibility. I could think that the Torrent object gets further passed to the session factory which would then look into the torrent and decide whether it is a DHT or a centralized torrent. Actually now I’m thinking we could even have three types of TorrentRequestSessions - CentralizedTorrentRequestSession (created if the announce key was set), TierTorrentRequestSession (created if the announce-list key was set) and DhtTorrentRequestSession (created if the nodes key was set). Each of the sessions would implement the connection/session establishment differently - Centralized* will attempt a single connection, Tier* will attempt to connect to a first tier tracker first, if that fails it will try with the next first tier tracker and so on with the next tiers. Once a connection gets established the Tier* session is established too. I don’t know how the DHT trackers work (could you pleas provide a reference to the docs? the official site displays other specs under the DHT specs) but I guess it could be implemented similarly to the Tier* one.

I read somewhere that BitComet is rather abusing client and it does violate the specs on purpose to obtain a higher number of peers from each of the individual trackers. We should stick to the specs and only query one tracker at a time.

I’m not sure whether we should require from the factory to establish the sessions or should just create them and let us we establish the sessions ourselves. Maybe you should try either way and see what is more intuitive and renders more coherent components.

Good night,

Peter