Blog

2011
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2010
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2008
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2007
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2006
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2005
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

Posted 2006/03/28

TychoTorrent screenshot

Over the weekend I rewrote the brains of TychoTorrent. This evening I have created an AWT based front end to it. Here is an update including a description of TychoTorrent running and a list of what needs to be done to finish this work.

I have provided a simple API to use TychoTorrent as I want to be able to easily embed it into other software. A bonus is it was easy to write a couple of interfaces for it, the curses one (command line) was developed along side the main code. The AWT GUI is so I can bolt TychoTorrent into my game middleware which already has a GUI, I think it is important to take a little bit of effort to make things look nice since this case study will likely be demoed at the end of the PhD.

In the Bittorrent world we have peers which upload and download files simultaneously to/from each other. When you first publish a file it is called seeding. Each file is divided into chunks of an arbitrary size which are downloaded by the peers. The aim is to share the work of distributing the file amongst all peers as opposed to a more traditional mechanism where all peers would download from the original seed (webserver, web browser).

In the screen shot you can see three programs, they were started in chronological order, from top to bottom and show (from the top):

Peer 1: The curses client seeding a file.
Peer 2: Another curses client downloading the file from peer 1.
Peer 3: A GUI client downloading the file from both peer 1 and 2.

Click for big

You can see from the upload and download counters that there are 50 chunks in this particular file and that peer 3 downloaded around half from peer 2.

To complete the implementation I need to add a retry mechanism to chunk requests between peers. The current way I do it prevents bi-directional downloading between peers, for example if at some point peer 2 runs out of chunks peer 3 needs, peer 3 will then ignore peer 2 as a download source for ever. This is incorrect behaviour because at some point in the future peer 2 may get some new chunks peer 3 needs.

The GUI also needs to be attached to the game middleware and the torrent implementation needs to be benchmarked. Which order these are done in, how much effort is put in has yet to be decided.