This generally looks good, and sensible. There is only one piece that seems a little dodgy. Sending back out parts of pieces before you have fully received them.

I might be misunderstanding, but until a piece is fully received, you can't hash it and check it is right. This could therefore lead to many clients having partially incorrect pieces, if they keep passing it around.

I've found (and I'm not 100% sure why) that most bittorrent clients do find they get some number of dodgy pieces over time, so this isn't just a theoretical problem.

Just saw the surging traffic on our download site and noticed the link from HN.

Re: Aggressive sharing. Yes and no. If the torrent is encoded as a Merkle tree, you can verify subsets of a piece. For torrents that only include piece-level hashes, a BitMate client can upload an unverified piece. However, in our experience, its rare for pieces to be corrupted (unless the uploader is maliciously uploading corrupt pieces).

Please let us have your feedback regarding the performance and stability of the client since this our first (read: pre-alpha) release.

This has nothing to do with either performance or stability, but the big header saying "Downlowd link" spells download incorrectly.

> There is only one piece that seems a little dodgy. Sending back out parts of pieces before you have fully received them.

This is my concern too. The rest of it seems mostly compatible with BitTorrent (although I am a little concerned at there being multiple mechanisms by which this peer algorithm prefers itself, in this particular use case that behaviour seems justified and fair), but this is not playing nice.

One reason you receive incorrect pieces by the way is from people that have altered the files on their hard drive but still have their BitTorrent client running - a common case is MP3 player software rewriting the ID3 metadata, which WMP and iTunes do without asking.

If the assumption is that you will finish receiving the piece before you finish sending it out, you can start uploading mid-way. If you have a bad checksum, then o well, they fail too. The idea, however, is to maximize local-isp traffic so the more you send, the better.

This research seems quite interesting, however I see one problem here. The BitMate client is fairly heavy, the download ranks in at 18MB. Getting this out to users in low bandwidth areas becomes difficult due to this. Compare this to uTorrent, which is just a 387kB download.

18MB isn't that heavy, given that most users will want to download Gigs of movies / music.

It's not great, but I can't see it as a huge obstacle.

Yes it's not a huge obstacle. But this is targeted at users in Pakistan, where internet access is fairly limited, and it's mostly dial up/low speed in the areas that do have internet access. I can imagine the average user wanting to get his/her downloads started ASAP, a large client download will hinder that.

Thank you for this input. We didn't want to change much in the most popular Bittorrent client (Vuze) that we used for building this. You are right, we will work on releasing a light (perhaps sans-UI) version of this soon ..

Have you considered building it on top of a simpler open-source client, such as Transmission? Azureus/Vuze can single-handedly bring my modern desktop to its knees, so I can't see it working well on the older systems found in developing areas.

Perhaps you could compress it by releasing it as a patch to Vuze? That way people who already have Vuze (which is fairly popular) can get it faster.

Thanks, will do.

I may have to reverse the changes here and figure out how to apply it to the transmission torrent client.

I'm on horrible hotel wifi or find myself a late seeder next to massive seed boxes on whatever tracker I'm on. This would give a good bump in the ratio the new guys and even things out if it works in theory.

You would probably not have a lot of luck using this on private trackers, as Vuze isn't whitelisted on most of them, plus it's a modified version.

I am not sure what you mean by "reverse the changes", but if you want to improve upload contribution for a low-bandwidth node, it is built into BitMate (it improves both download performance and upload contribution of bittorrent). Actually, for low-bandwidth nodes, it could improve upload contribution by as much as 1000%! Please try out the client and let us know what you experience.

By "reversing the changes" I think the OP wants to add this in as a patch for the Transmission, which is a popular open source BitTorrent client.

In fact I'd love to do that as well, given the chance.

EDIT: Just found out that it's open source, details here: http://sourceforge.net/projects/bitmate/develop

Thank you for your interest. If you want I can upload the code as well to sourceforge. The changes in vuze are very simple and minimal for now.

It'd be a hell of a lot easier for the rest of us to deal with if you upload it to a more collaborative code hosting site instead (GitHub being the prominent example). Even Google Code wouldn't be bad, though; SourceForge is dead and gone.

My friends at sourceforge are going to be really sad to hear this after the last re-hall of the entire site. :-)

Probably a good way to get yourself banned from whatever tracker you run this on. If everyone ran this, download speeds would go down across the board.