AdOS-Assignment 2: Mini-Torrent File Sharing System Solved

In this assignment you will be implementing a functional torrent system including your own tracker system (albeit with a much smaller feature set).

 

How torrents work ?  

 

For the uninitiated, bittorrent is a P2P file sharing protocol which accounts for over 25% of traffic on the internet.

 

In peer-to-peer file sharing, a software client on an end-user PC requests a file, and portions of the requested file residing on peer machines are sent to the client, and then reassembled into a full copy of the requested file.

 

Part 1 - Creation of torrent file at client 

 

Normally the bittorrent systems work via sharing a “.torrent” file which contains the metadata related to the file being shared in plaintext format. For this assignment you will develop your own format of .torrent file called the “.mtorrent”. 

 

It should contain the following fields:

Tracker UR L1: The url of the tracker server1, i.e. tracker1 IP & port ● Tracker URL2: The url of the tracker server2, i.e. tracker2 IP & port ●  Filename : the name with which the file would be saved on disk.
Filesize : Complete file size
Hash String: String whose length would be a multiple of 20. This string is a concatenation of SHA1 hashes of each piece of file.
 

Taking SHA1 hash of files: 

You have to divide the file into logical “pieces” , wherein the size of each piece should be 512KB. 

 

Example: Suppose the file size is 1024KB , then divide it into two pieces of 512KB each and take SHA1 hash of each part, assume that the hashes are H1 & H2 then the corresponding hash string would be H1H2 , where H1 & H2 are 20 characters each and H1H2 is 40 characters.

Your program will create a <filename>.mtorrent file whenever it shares a file on the tracker (signifying that it is a seeder for that file).

Part 2 - Torrent tracker 

A ​tracker is a special type of server, one that assists in the communication between peers using the BitTorrent protocol.

The "tracker" server for your assignment will keep track of all the available peer machines on which the files or its parts reside.

After the initial peer-to-peer file download is started, peer-to-peer communication can continue without the connection to a tracker.

Implementation Specification for tracker  

Start Tracker using:
./tracker            <my_tracker_ip>:<my_tracker_port>     <other_tracker_ip>:<other_tracker_port> <seederlist_file> <log_file>

                        ○    seederlist_file: contains list of all the available seeders.

                        ○    Both trackers should be started separately  using the above command.

Tracker should be able to handle multiple requests at once.
Have an “share” functionality for the torrent clients via which they will notify the tracker of existence of files.
○ Example: Suppose a client shares a file named “A.txt” then tracker should store the following :-

                                        ■    Filename

                                        ■    Hash string of the pieces in the file

SHA1 hash of hash string which is used in .mtorrent file. ■ Client IP & Listen Port
Have a “seederlist” functionality for torrent client when a file is requested for downloading. This will return the list of all available seeders for the given file.
Have a “remove” functionality to allow removing shared file.
Your tracker server should be fault tolerant, run two copies of the tracker which should be synchronized. The logic for synchronization should be at tracker level only.
Seeder information should be updated if the tracker goes down as soon as it comes back up.
Part 3 - Torrent Clients 

For the final part you will be further extending your client from part 1. In a nutshell, your torrent client should have the following functionalities:

 

Share files to the tracker and generate a corresponding “.mtorrent” file ○   You have already done this in Part 1
Retrieve peer information from tracker upon providing a “.mtorrent” file.
Download files from multiple peers simultaneously, same goes for upload.
Maintain mapping of paths of files and related .mtorrent files- this should be persistent across runs.
Implementation Specification-  

Start client using - ​./client <CLIENT_IP>:<UPLOAD_PORT> <TRACKER_IP_1>:<TRACKER_PORT_1> <TRACKER_IP_2>:<TRACKER_PORT_2> <log_file>

When the application starts, the available .mtorrent files and related files will be checked and request to add the client name in respective files on tracker server will be sent.

The client will have a menu driven interface to do the following:

Sharing a local file​:
                        ○   Command​: share <local file path> <filename>.mtorrent​ 

                                        ■    The file path can be absolute or relative.

○ The application should then create a .mtorrent file according to the specifications specified in part 1. This .mtorrent file can be shared manually among clients. This .mtorrent file should never be shared to the tracker.

○ Use the “share” functionality of tracker to notify it about the shared file. (Refer Part 2)

                        ○    After sharing, the client should start seeding the file.

 

Downloading a remote file:
                        ○    Command: ​get <path to .mtorrent file> <destination path>

                                        ■    Path can be absolute or relative.

                                        ■    This cannot be a blocking command.

■ Your client must also able to download multiple files simultaneously. (this will be done using multiple get commands)

○    Use the “seederlist” functionality of tracker to retrieve the peer list from where the file can be downloaded.

■ Seeder list once retrieved should be treated as static until the file is downloaded or cancelled downloading. No need to poll continuously for new peers of the file.

○          Your client ​must​ download the same file from multiple peers simultaneously ■ Think in terms of “pieces”.

                                        ■    Peers may or may not have the complete file, i.e. all the pieces.

■ Consider provided list of pieces from clients to be static. No need to poll for update on availability of pieces.

Seeding a downloaded file: ​As soon as file has begun downloading, it should be notified to the tracker and the client should be able to start seeding that file. Seeding multiple files, and same file to multiple clients is possible.
 

Show downloads: 
                        ○    Command: ​show downloads

○    This will list out the files that are downloading and files that have finished downloading.

○    To differentiate, downloading files will have [D] and downloaded files will have [S] before the file name.

Removing a shared file: 
                        ○    Command: ​remove <filename.mtorrent>

○ This should remove the file information for that file from the tracker and from the persistent file database along with the .mtorrent file but not the actual file.

                        ○    Remove only when file has been 100% downloaded.

Close application: ​When the application is closed, a request should go to the tracker to remove the client from the seeder list of all files it is present in. Assume that application will only be closed when there are no ongoing uploads or downloads.
 

Bonus: ​Ability to remove file or close application when a file is being downloaded or uploaded. This should have a graceful handling of connection if another client is getting the file that is removed.