Last Active: Nov 02, 2019
Threads: 18
Posts: 57
Reputation:
0
Oct 14, 2018, 10:15 am
(This post was last modified: Oct 14, 2018, 11:27 am by ID10TError. Edited 2 times in total.
Edit Reason: Added another question
)
Thanks Moe, so hidden truth table.(Unless blindly searching ip ranges or say pulling them from a correct magnet link(containing host info) or torrent file.)
Does anyone know of any code to connect an application to another in a distributed fashon?, i'd like to take a crack at the worlds worst distributed search engine, using the IE COM control from Visual Studio to do the actual loading of pages because i'm not hardcore enough to figure out how to subcontract mozilla or chrome to do so for me without it all being wrapped up in a nice bundle.
I know how to connect sockets but is there a DHT library i may use in any form on teh interwebz?(That ya know of anyway, I couldn't get much when I searched but this is pretty specific.)
Also given the current climate of pirate persecution is anybody else seeing lots of seeding support coming from russia(given the right torrent), havnt finished the download, but, well, seems legit! 
VOTE RUSSIA FOR THE WIN! https://drive.google.com/open?id=1j_8mEn...V3ieJkY_f3
Last Active: Jun 04, 2024
Threads: 157
Posts: 2,039
Reputation:
29
Am not entirely sure about what you are asking for.
If you are looking for implementations of DHT, you can have a look at libtorrent. It is written in C++.
Searching the Net for 'How to scrape DHT' will give you some useful results.
You can find some source code on github. There is a much simpler 'C' implementation which should give you an idea.
Offlinebay uses a NodeJS based library (?) to scrape DHT. The source code is available. You can have a look at that if you are interested in API level usage.
Torrents clients _usually_ 'enter' the DHT network, when we add a torrent with a tracker to the client. The tracker returns the first peer(s).
Once it 'enters' the DHT network, the protocol takes care of finding new peers.
Clients store these nodes in dht.dat (or similar) file. So, the next time you start your client it has a list of DHT nodes.
Hope this helps.
Last Active: Nov 02, 2019
Threads: 18
Posts: 57
Reputation:
0
Thanks for the info, I probably need to learn more about dht at the protocol level, i will take a look at the librarys you mentioned but expect they will be beyond my understanding. Thanks again to all those who posted.
Last Active: Nov 16, 2022
Threads: 44
Posts: 845
Reputation:
12
Nov 27, 2018, 21:17 pm
(This post was last modified: Nov 27, 2018, 21:24 pm by waregim. Edited 1 time in total.)
Let me see if I got this right.
DHT needs a minimum of a single tracker to help it find a DHT node. From there info on other DHT nodes is transferred, and it goes down the tree.
I have noted that adding new trackers can sometimes (not not always) kickstart a stalled torrent.
TPB supplies a magnet link to a DHT node that can and will find a tracker to connect it to other nodes, and on down the line. Plus a data file keeps basic node/tracker info.
Right????
Last Active: Jun 04, 2024
Threads: 157
Posts: 2,039
Reputation:
29
(Nov 27, 2018, 21:17 pm)waregim Wrote: DHT needs a minimum of a single tracker to help it find a DHT node. From there info on other DHT nodes is transferred, and it goes down the tree. DHT is trackerless.
It uses the bootstrap nodes, only during the very initial phase when it has yet to 'learn' any other DHT node (approx: another client running bittorrent client)
Not sure what 'down the tree' means.
A client tries to find peers for a given torrent. It puts out the info hash (BTIH) to the DHT nodes it knows.
In the process it learns new ones. The learnt information is nothing more than IP address + port.
These are stored in a file like dht.dat, so that it may be used the next time the client starts.
The method of finding/searching a peer is outlined in BEP5. (vide: nearness metric).
(Nov 27, 2018, 21:17 pm)waregim Wrote: I have noted that adding new trackers can sometimes (not not always) kickstart a stalled torrent. That is because no searching is involved and the tracker returns the peer info that is stored with it.
(Nov 27, 2018, 21:17 pm)waregim Wrote: TPB supplies a magnet link to a DHT node that can and will find a tracker to connect it to other nodes, and on down the line. Plus a data file keeps basic node/tracker info. TPB magnet links include some default trackers. The rest is as described above.
Disclaimer: Above info is to the best of my knowledge ;-)
Last Active: Nov 16, 2022
Threads: 44
Posts: 845
Reputation:
12
The method of finding/searching a peer is outlined in BEP5. (vide: nearness metric).
--------------------------------------------------------------
Is this the reason why switching to a VPN server halfway across the planet can often yield 'new' seeders/connections?
Last Active: Jun 04, 2024
Threads: 157
Posts: 2,039
Reputation:
29
:-) Am not sure. Seems like a yes and no question to me.
DHT to my understanding is supposed to find peers in finite time, but peering perhaps depends on other factors.
Eg., the other peer could have banned a certain IP or IP range OR perhaps port-forwarding was not setup correctly initially.
Sometime back utorrent (v 3.4) introduced 'canonical peer selection' . You could give that a read here. But am not available for questions on that. ;-)
Discussions are welcome and wide open though, within the context of the OP.
Last Active: Nov 16, 2022
Threads: 44
Posts: 845
Reputation:
12
Nov 29, 2018, 15:50 pm
(This post was last modified: Nov 29, 2018, 15:58 pm by waregim. Edited 1 time in total.)
Perhaps this applies only to BT/uTP and not DHT.
Is this issue at all related to the sporges with thousands of seeders/peers so often encountered?
I am also make the assumption that a hash found through nodes A->B->C->D would cause the client to connect directly to D , dropping ABC out of the picture for that particular file/hash.
If in this scenrario of using uT3.4 C were to become a bad actor, would not B ban it?
|
