Cross Site/Tracker Seeding

[UsL]

Is this statement true for qBT:

you could simply seed the original torrent data files to another private tracker. If you do this you do not need a copy of the data files, so disc space is saved. However if all you do is simply add a second tracker to the first one, there will then be two private trackers connected to the same data.

Unfortunately that will not work as the ratio data for each tracker will be combined

Here is some sample ratio info as an example.
Tracker    Downloaded  Uploaded
Tracker 1    1.5GB        4.3 GB
Tracker 2    1.5GB          6.8GB

Tracker 1 and Tracker 2 would both see a total of 3.0 GB downloaded, and a total of 11.1 GB uploaded, both of which are incorrect. This is NOT ACCEPTABLE and may possibly, or even probably, get you banned from both trackers for cheating. ?

Or does qBT work differently? The scenario is that I have the exact same content on one tracker. Can I just add the second tracker and point it to the same content and start uploading after the hash check? Or is the statement above really true? I'm sleep depraved and can't think straight.

[ciaobaby]

Tracker 1 and Tracker 2 would both see a total of 3.0 GB downloaded,

Errrm ... No.

Trackers only 'see' what is downloaded from, or uploaded to, clients that connect from that tracker, BitTorrent clients do not report "overall totals" to all trackers for any particular info hash ID.

[loki]

I'm pretty sure you can't put multiple private trackers on the same torrent, even if it is exactly the same. That part might get you banned at one or both sites, that's if it even works as expected.

[UsL]

Okay, so which is one it? And why would it get me banned if the trackers can't see eachother? qBT has a separate torrent file for each of the trackers as far as can I follow.

How could they know of each other as Ciaobaby said? What I can understand is that the second tracker wouldn't see any leech ratio count being made. Only a seed all of a sudden.

I really want to wrap my head around this.

[ciaobaby]

That part might get you banned at one or both sites,

How??

A "private" flagged torrent only means that PEx and DHT are disabled, adding another tracker to the job, whether if it a 'private' one or not is not going to report that change to the original tracker or change the metadata at the source, if it is a magnet on either of the trackers and your client is one that serves the metadata to a new peer in either swarm that peer will see both trackers but you would have be fairly unlucky if they noticed it,

[fusk]

I tried this, adding a second tracker instead of adding the same torrent twice seeding from the same data, didn't work, the tracker never connected.
First i added the torrent from the second tracker, copied the url, removed torrent again, then added that to the trackerlist of the first torrent.

[ciaobaby]

Are you trying this with two jobs that YOU have created and uploaded the metadata to private trackers?

[fusk]

I don't know, just thought i'd try it as it keept crashing when i had the same torrent added 3 times seeding to 3 trackers.

[ciaobaby]

[quote="fusk"]I don't know, [/quote]
That will be a no then as I'm sure you would know if you had created the torrent in the first place


So this must be a job that you have loaded from a ratio enforcement site (or maybe from two different sites).

To be able to use ONE copy of the payload data and to make it available to more to peers from than one tracker is not exactly rocket science, practically,  EVERY user of ANY BitTorrent client is doing this without even knowing they are. Problems are going to occur when you try to seed a common payload as different info_hash IDs

[fusk]

I think i got that. Makes sense i wouldn't be able to add a second tracker if they have different info_hash IDs.
What i usually do after the download is done, is download the torrent from the other sites i want to help seed to, and let them leech the data of the one copy i already got.

[ciaobaby]

and let them leech the data of the one copy i already got.

Do you check the payloads first to ensure that the two are EXACT binary duplicates before doing that?
That doesn't just mean the file and folder names have to match, the two blocks of data have to exact copies down to byte level. If they are not, you are poisoning one of the swarms.

[fusk]

I usually let it run the check, and very rare is there any data difference besides the .nfo which can vary. I've not had problems with it in the past.

[ciaobaby]

If the re-check runs to 100% they are you can be fairly confident they are binary equivalents.

But if the .nfo file is 'different' even by one character in the file the two payloads are completely different.

Here's my "BitTorrent in a nutshell" and real world analogy.

BitTorrent clients do NOT have a concept of 'files', what they 'understand' is that the torrent is made up of equally sized pieces of data that fit together to create 'files', it's a bit like a jigsaw puzzle, but instead of a picture to work from, all the pieces are numbered and the client has a 'map' of where all the pieces fit into each other (the metadata) so the binary data that tells the disk filing system where all the parts of the file are and what 'type' the file is, goes back in the right order. On the disk all the parts of the file may not be in contiguous clusters anyway, but provided the bytes all go back in the same order it will work. When files are merely chunks of data that is a certain size and in a certain order, provided a chunk of suitably sized disk space is allocated (or can be made available) for the payload by the client and the OS, it does not really matter in what order the blocks are assembled, just as long as they are in the right order.
I suppose tiling a wall or a floor would be the best analogy. Lets say that each tile is EXACTLY 'N' long and there are 100 tiles in the row, you could start with tile 65 provided the leading edge of that tile was placed at 64N from the start, you could then place tile 64 or 66 next to 65 OR you could get tile 26 and place it at 25N. In computer programming parlance it is called offset addressing and offsets start at zero (0) not 1.

To "decide" which pieces to get first, the client uses the "rarest first" method and requests the ones that may not be available continuously, each piece is 'checked' against a checksum (Hashing) in the meta data to verify it is valid and no corruption has occurred during transport.

[sledgehammer_999]

Nothing wrong with what ciaobaby says, I just want to comment on different things.

2 torrents having different infohashes means that they represent different data(files). This is true even if the difference is only at one character of a text file.


This means that you can add the 2 torrents in qbt and point them to the same folder. If the different files(between the 2) are named differently you will not have any problems. qbt will download the different files and save them, while using the others that are shared between the 2 torrents. If the different files have the same filename all hell will break loose, because one torrent will overwrite the other.

If you add the second torrent and check "skip hash check", libtorrent will oblige if it finds the files with the same name. It will announce the swarm and tracker "hey guys I have all the pieces from this infohash". Then connections will be made to peers and will try to send pieces. However, libtorrent in this case verifies the pieces on read. If one piece fails the verification, then the entire torrents is hash checked automatically(it will change status). So at least you will not poison the swarm.  [this is my uderstanding of how libtorrent works, I may be wrong].

Of course  it goes without saying, that if you remove one of the seeding torrents and delete it's files, the other torrent will error out. AKAIK, there is nothing preventing you from deleting shared files.

[fusk]

It's true most of the times there'll be a small 50/150kb download when they rewrite the .nfo. But i've never had issues with them starting to error the torrent because of it. I supposed what happens on the other end is they just get 100kb of wasted data. I don't really know, and since i never had issues with it, i never cared about it.