Niagara

This is the fourth release of the Cocoa GUI client. The main new features in this release are Protocol Encryption (MSE) support, based on the Azureus/uTorrent specification, and support for banning peers that send bad data, and blocking peers based on the Bluetack IP blocklist. Changelog.rtf has the full list.

The Cocoa client requires Mac OS X 10.4, and is a Universal Binary supporting both the PowerPC and Intel architectures on Tiger and Leopard.

The SVN trunk has been capable of MSE for a week or so, but I only just now feel like I’ve got the more egregious bugs out.

 Take it for a spin, and let me know what you think! Next on the list are rate-limiting, and a big UI cleanup before a 0.1 release.

 The code below should give you an idea of what I’m doing about it.

#pragma mark Diffie-Hellman exchange

int mse_generate_public_key(btContext *ctx)
{
int checkcode;
BIGNUM *prime = NULL, *generator = NULL;
BN_hex2bn(′, safe_prime);
BN_hex2bn(&generator, safe_generator);

ctx->dh_key_struct = DH_new();
ctx->dh_key_struct->p = prime;
ctx->dh_key_struct->g = generator;
DH_check(ctx->dh_key_struct,&checkcode);
if (checkcode == 0 && DH_generate_key(ctx->dh_key_struct) == 1)
{
#ifdef MSE_DEBUG
fprintf(stderr, “Generated public/private key pair, length = %i bytes (%i bit)\n”,
BN_num_bytes(ctx->dh_key_struct->priv_key),
BN_num_bytes(ctx->dh_key_struct->priv_key)*8);
#endif
return 0;
}
return -1;
}

Hopefully landing in SVN in the next day or so, and I’ll be getting a release out this week.

I’ve just committed revision 128 to Niagara’s SVN, which reincorporates my updated block segmenting and allocation code. I’m happy to write a detailed comparison if anyone’s interested, but basically the old code stored a bitset for completed pieces (subsets of a block) and the index of the next request. This worked fine with a single peer per block system, but I noticed poor performance on torrents with large chunks (>1mb). (more…)

I’m pleased to announce the 0.0.5 release of Niagara.

This is the first release with a functioning Cocoa client. The interface and feature-set are spartan, however with the hard work of integrating the library into an interactive threaded client is over, and now refinement and enhancement of the feature set can begin. Check Roadmap.rtf for an overview of where Niagara is going.

The Cocoa client requires Mac OS X 10.4, and is a Universal Binary supporting both the PowerPC and Intel architectures. The commandline client and static library supports any recent BSD/Linux with OpenSSL.

Download

Feedback

Mailing list: http://lists.sourceforge.net/mailman/listinfo/niagara-devel Development blog: http://niagara.sourceforge.net

Known issues

• The Cocoa client is hard-coded to listen on port 6881, as I have not yet implemented a preference system. This is the first development priority following 0.0.5, and I will likely release 0.0.6 with this implemented very shortly. FIXED IN SVN
• The Add Torrent dialog experiences visual corruption when checking partial downloads. This dialog will likely be integrated into the main window in the next release.
• Completion data is only read at restart if the torrent was active when the client exited, and is not yet crash-resistant. - FIXED IN SVN

The basic concept for the Cocoa client is to wrap up a context and associated structures in a class (ContextInterface.h) then maintain a representation of the current context external to this class, to make it easier to update the interface as the context processes sockets. This takes the form of an NSArray of NSDictionaries, one dictionary per torrent.

I’ve had it in the back of my mind to convert the GUI over to using bindings instead of delegate / datasource methods, and now that the current svn code has a rudimentary level of state display (via stdout piping to a textview), I’m busy refactoring the code to use bindings.

There’s a very useful tutorial over at CocoaDevCentral which teaches the essentials of bindings, and makes understanding the class documentation much easier.

I’ve been making fairly steady progress on the GUI client. The current svn code can now add torrents from either the GUI or a disk cache, remove them from the active context, and most importantly, upload and download them. It still has a number of rough edges, and the UI isn’t the most appealing one. However most of the behind-the-scenes code is in place.

Things still to implement before 0.0.5:

(more…)

The fast resume code has proven stable over a number of torrents (>10Gb), so I’ve uploaded the code to the Sourceforge SVN repository, and released the library as 0.0.4. Take it for spin, and post feedback here or on the niagara-devel list.

I’ve been working slowly on the GUI client and the library. I’m currently on elective study in France, so things have been a bit slow. I have managed to add preliminary support for Fast Resume to the library, which will be available both in the command line and GUI clients.

The context created by the library stores the completion status of each tracked torrent, but this was not persistent between sessions. I’ve added support for saving and loading this between sessions. Hopefully this will make downloading large torrents more convenient.

I’ll upload it to SVN once I’ve tested it with a few more torrents, and look at releasing 0.0.4 shortly. Then I’ll be able to focus all my attention on the Cocoa client.

Though there’s nothing ready to release yet, I’ve made substantial progress with integrating the backend library into a GUI framework. The torrent data model is complete, and the libniagara port from libbt is functioning as a static library in Xcode. All that remains is to link the two so that the GUI can hand off torrents to the library. Once that’s done I’ll put out a 0.1 release and upload the code to SVN.

Keep an eye out, I should be ready to make an announcement on the niagara-devel list in the next fortnight or so.

I’ve now fixed the TCP subsystem so it correctly binds the BSD listen socket to your external port. The default is 6881, or set a custom one with export NIAGARA_EXTPORT.