Hi Peter,

I’ll refer to my last changes in this post.

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.

Ok, I’ve modified it towards this approach.

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).

I’d maybe name the first two sessions SingleTrackerRequestSession and MultiTrackerRequestSession (according to these specs, there is also written “multitracker”). What do you think?

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.

I see.

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.

I’ve implemented the latter variant for now - the TrackerRequestSessionFactory produces only created sessions and the TrackerManager then calls session->open() to establish the session. I’ve renamed the TrackerRequestSessionFactory::closeSession() to TrackerRequestSessionFactory::destroySession() so it will better correspond to the implemented behavior (TrackerRequestSessionFactory takes care only of creating and destroying sessions).

You can see my current approach from the TrackerManagerImplTest class, but in brief: TrackerManager implements TrackerRequestSessionFactoryStatus interface and every TrackerRequestSessionStatus notifications will be “catched” by the TrackerRequestSessionFactory (it will internally store a list of pairs: session+it’s status notifier) and “forwared” to the TrackerManager via the implemented interface. The rest can be seen from tests.

Let me know what do you think about this approach!

Regards,

Petr