Jump to content

Force Torrents with identical hashes to exist as seperate "torrents"


SilentFury

Recommended Posts

Posted

This is my first post here, so forgive me if I'm a little out of the loop. I looked around in search and found an old topic describing the issue but nothing requesting any changes be made.

An option for forcing a a torrent with multiple trackers to run as separate torrents with a single tracker would be very helpful.

I think it will make more sense If I describe the problem I'm having. What I want to do is be able to upload the same files to(or seed the same torrent from) multiple trackers. However the trackers in question(which I understand are not to be mentioned) keep track of ratios and require you report accurate statistics pertaining only to transfers to and from peers from their own respective trackers. Right now if someone has uploaded the same torrent to both trackers when you go to download them uTorrent combines the two into one "torrent" (is the a more specific word for this?) with multiple trackers. This causes you to report the same(combined) stats to both trackers. Such as:

up down

Tracker A 10MB 5MB

Tracker B 40MB 0MB

Reported(both) 50MB 5MB

If you are uploading the files then you can change the piece size to force a new hash as a sort of work around but if the torrents with the identical hashes are already hosted on each site you have no way to download/seed both without reporting wrong statistics unless you want to run multiple instances of uTorrent which obviously is a big hassle.

In general I'm hoping a solution to this problem can be implemented. I have a few suggestions which may or may not be feasible.

1) An option to force uTorrent to keep two "torrents" with the same hash separate. Perhaps in the window where it normal asks "the torrent you are trying to add is already in your client..." and option for "force new torrent"

2) An option to report statistics only for peers that were given out by their respective trackers.

3)Some sort of option when creating a new torrent to force it to have a unique Hash. This wouldn't solve the seeding problem but it would be a little more convenient than the piece size work around.

4)Anything other solution anyone can think of. I'm not picky.

Posted

Yeah that was what I meant by running a separate instance of uTorrent. It just seems like an awful lot of work for something that is becoming increasing common in the bittorent communist.(Swapping files between private trackers).

Changing the piece size of the torrent works well if you are the original uploader. It will let you(and anyone else who downloads your files) keep the two torrents separate. But it only helps if the uploaders had set different piece sizes for each torrent. The odds of this happen go from unlikely to impossible as you increase the number of trackers you want to seed to. And if they didn't the only solution is multiple copies of uTorrent.

It's also a feature that would serve to increase the strength of the bittorent community as a whole. Allowing People to easily swap files between trackers leads to greater access to files for everybody. I mentioned swapping them between private sites. But really, as long as even one tracker keeps a ratio it expects to be accurate it can be 1 private and 1 public site and you have the same problem.

I was a little worried about how difficult it might be to implement. I'm honestly not too knowledgeable about the inner workings of uTorrent. But I thought it would be a good idea to at least bring it up. Even if it seems too difficult to implement now. Something to think about for future versions.

  • 9 months later...
Posted

Nope. How would you propose that µTorrent differentiate between traffic intended for one torrent instance vs another? There is nothing in the protocol to provide for for such a provision (same peer IP:port, same infohash, multiple instances), and it most likely won't happen either.

  • 2 months later...
Posted
How would you propose that µTorrent differentiate between traffic intended for one torrent instance vs another? There is nothing in the protocol to provide for for such a provision (same peer IP:port, same infohash, multiple instances), and it most likely won't happen either.

I'm not sure how rtorrent does it, but if I had to guess, I'd say it's using multiple ports. Either way, though, it's not an OS-related limitation.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...