Tazup – File sharing protocol with client application

Introduction

On some subjects the output is a project. Specially, Tazup is the output of the subject called Computer Networks at FMFI UK.
Tazup is a peer-to-peer sharing protocol which we tried to introduce. After we thought about theory and the main points of the protocol we started to write down some lines of a client which implemented the protocol.
Our developer team had three members:
Peter Csiba,
Martin Šrámek and
Jakub Vaňo.

Intent

Develop a application which performs:

Sharing files through the network
Adding peers-friends from which you can share
Searching the network with file keywords
Downloading the file parallely from peers which have it

Links & Downloads

Implementation

For the ease of the development we choosed Java as the main programming language. Also we used SVN for manageing the last versions of the project.
We divided our work:

Peter Csiba – Implemented downloading modul and a part of gui.
Martin Šrámek – Implemented peer management and a bigger part of gui.
Jakub Vaňo – Implemented network communication, console interface and search modul.

In the release version we have 73 class files.
The application runs in many threads so we had to resolve many concurrency issues. For example, each of modules and each of file download or upload runs in a different thread. Because the code is relatively large, we will just describe what is executed in the next two examples.

UDP is used in the most of the communication. TCP is used only when downloading / uploading.

Run app, search file and download it

When application is started, the thread of each module is started also. Then the .ini files where peers, shared and downloaded files from the last run of the program are loaded.
After the app is initiated it is checked if the peers are online (and that check is repeated often). Also a broadcast is sent to discover other local peers.
The user can search file by keywords or hash. More results can be returned and all are stored in the search results database.
If the user wants to download the searched result (possibly from several peers) then which each peer a new communication in a new thread is initiated. After the initial handshake the download per file parts runs. It is often backuped – so if the program crashes or user pauses the download progress can be resumed later. The progress of all downloaded files can be viewed in the terminal interface.

Share file and upload it

The user adds the target file into your database and compute a sha1 hash of it (it will be the unique identifier of that file).
When it is shared and some other user requests it for download, then after the initial handshake the requested parts are sent.

Applicability & Examples

We hope that our application will be used for very easy file sharing in our campus. For public release we need an even easier to use version on windows.

Example will come soon.
Typing help in the application will output the available oppurtunities.

Hot spots

Multithreaded application

We mainly use synchronized keyword to lock parts of the program and achieve atomicity. The threads are usually decoupled and if they want to interact they use BlockingQueues. Messages from the network are stored and are ready to be taken by the corresponding modules.

Local peer discovery

Implemented with a broadcast ping.

Parallel downloading

Because the files are downloaded by parts it is enough to add a new thread to download that file from other peer.

Conclusion

It was a remarkable project from my point of view.
First, because I coded in a team and resolved bigger issues with my teamates. Also it involved to think about shared bugs, notes and todolists which was sometimes even fun 🙂
Second, we used threads and so I get the look and feel of multithreaded systems. After I though about them a bit I have seen them also everywhere in the real world.
For me it was a great experience and I hope that my team mates see it similiary 🙂

Screenshots

Comming soon!