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:
Martin Šrámek and
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
- Tazup home page
- Download: Tazup file sharing – source code
- What Martin Šrámek wrote about TazUp
- What Jakub Vaňo wrote about TazUp
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.
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.
Because the files are downloaded by parts it is enough to add a new thread to download that file from other peer.
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 🙂