SOMETHING MOST OF US CAN RELATE TO
Without coming across as too harsh, it’s probably fair to say that if you haven’t heard of the bittorrent protocol, the word “torrent” as is used in general speak amongst pirates.. of the founding fathers known as Napster, Limewire, and kazaa - or, as P2P (filesharing), an acronym to completely encapsulate all of the above - you might be living under a rock. For those of you who were around to remember what things were like just a year or so short of the millenium.. A time when when there was a very real public fear surrounding technology such as the fallout of the Y2K bug approaching and when disdaine shitheads targeted individuals of a mass just to make an example in illegally downloading content.
I’m doing my best to just write about my personal findings and not go into technical details around DHT and bittorrent in an attempt to allow this post to be a bit more readable to the average person.
THE EXPERIMENT
Every good paper comes with data. I self hosted a service that probed the Bittorrent DHT at regular intervals while saving the hits and their data in an sqlite3 database via [magneticod](https://github.com/boramalper/magnetico). This service was effectively recording all relevant torrent data as it cralwed the DHT by means of “peers”, or other people on the network serving torrent data. Think of it this way: the resulting database wilwouldl store unique data sets, accessible by means of a key - the key being the result of a hash function preformed on the data itself. With this ‘key’, should it be offered on the network, the rest of the information and corresponding files can be understood built. This is why you need only an infohash to reproduce an entire torrent file from a magnet. So long as someone on the network can provide the meta data associated with the infohash, one doesnt need anything more than the infohash and some index pointing them to peers who have the data - in part or full.
This was deployed on my server with an internet connection rated at 40GbE/s and enough anticipated bandwidth both up and down - at least for a substancial amount of time. I allowed the service to run 24/7, having made cron jobs to reset the service in any event such as a server reboot, or for whatever reason the service may stop, and ensured this was checked every hour ust in case using the script below:
|