BT Questions

[Xollence]

Is there anyway to track the ip of leechers using bt?

[Legendary Nin]

Maybe through PeerGuardian.Dunno,haven't used it yet.

[hiroshi]

You could use the command prompt and type "Netstat" to give you a list of your current connections, port, IP address, type of connection, etc. No doubt you know about this though and it isn't sufficient enough.

Sometimes clients can give you the ability to find out each persons IP Address... oh yeah that's right. I just remembered. As stupid as i am lol =P

I think the trackers supply the ability to see all the IP Addresses of each leecher using that specific tracker for such a specific torrent too, because i got there once. It was a webpage, which updated every 5 seconds with a list of everyones IP Addresses, with mine at the bottom. If i stopped the torrent my IP would disappear and if i clicked and started the torrent again my IP would re-appear. But i have no idea how i got there now that i actually try to look for it. >_O;
I got there by mistake through Animesuki. It was possibily for a fansub group on the scarywater tracker.

[BadGuy]

It depends on the tracker. Monitorring IP's etc isn't really part of the bittorrent protocole 'suite'. But knowing who is connected to your machine obviously is valuable information and can be viewed quite easily. I don't know if the standard bt client does this. But I'm quite sure very other client does.

The nature of bittorrent is opensource. There are alot of trackers out there and I bet there are some which can monitor leechers. I have seen administrative action been taken due to leeching. However as far as I know it was an admin that just looked at who shared what and who leeched what and with that information decided to ban certain ip's from the site and the tracker. Don't know which tracker it was or if it was just a custom one.

I am quite interested in the tracker and I'm thinking of writing one myself. Need to see how that will work though. Is anyone else interested in this?

So in short. Only the tracker (server) software can see who leeches what and how much. The speeds can't be seen ofcourse due to the p2p nature of the torrents.

[sarf]

Hmm... I just checked how track.py (the default tracker) was coded in BitTorrent... it seems as if the tracker only knows this :

1. What clients are connected to the tracker (IP and port)
2. How many bytes each client has left

The information about what pieces of a certain file a certain client has seems to be transferred only when two BitTorrent clients "talk" to each other (so that they can know what pieces they want to request from one another).

Basically, the tracker can't know if a certain client is a cheater (my definition: cheater is a leecher who never wants to upload anything), and a client can't know if a certain client is a cheater. If you could somehow combine both into one, however, you would be able to find cheaters. In that case, you'd simply keep track of how long a certain client has been connected to the torrent, periodically check how many bytes they have left as well as how many completed pieces of the file they have and finally, how much they are downloading from you. Then, you simply does a few checks - does the "bytes left" reported by the client mismatch the "pieces completed" the client reports? Have the client downloaded more than two pieces and still reports no completed pieces and/or still the same number of bytes left et cetera... The problem with this approach is that one type of user might be penalized by it : the user with an unstable connection who does not get uncorrupted data. I would personally think that it would be an affordable prize to pay, howver, as any other means of solving the problem seems cumbersome and/or requiring a new protocol specification (or rather, an extension) to be created and complied with.

Of course, I'd recommend that the tracker and the "client-spy" be run on different IPs and even subnets, if at all possible (so to defeat clients that spoof you by checking your IP and delivering data to IPs that seem to belong to an "authority" such as the tracker) - this is basically the same issue I had with my DirectConnect client (DC++k) - some people would run the share checker/verifier from the same computer as the hub (and/or as OPs) and the more advanced fakers would respond in a different manner because of that.

Sarf
---
If it were easy to understand, we wouldn't call it code.