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.

Big news today, not just for Niagara, but for the whole Mac Bittorrent community - Protocol Encryption has been added to Niagara!

I’ve just committed  revision 133, which adds a new protocolencryption.c function library to libniagara, as well as slight modification to the handshake code in peer.c to accommodate the slightly different process. I’ve also extended the stream socket class to incorporate inline RC4 encryption and decryption.

All the crypto functions are from OpenSSL, so the added functionality adds no bloat to Niagara (OpenSSL is installed by default on OS X).

Of course, the big question is “When can I play with it?” The code in SVN isn’t quite ready for primetime yet. Revision 133 establishes a full encrypted connection with compatible clients, but I haven’t quite figured out the finer points of then carrying on with the higher level Bittorrent protocol. The fallback code also isn’t as robust as I’d like. However, given that it took me 4 days to get this far, a release with MSE fully functional should be out the door by this weekend.

You’re welcome to take a look at the changes over at the SVN browser, but please note that unlike the rest of libniagara, the protocol encryption library is licenced under the GPL, rather than the LGPL.

Stay tuned!

 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). Read the rest of this entry »

I noticed a few issues with some of the more experimental block allocation code I’d written, so for the moment I’ve reverted to the older stable code. I’ve also put in a few minor visual improvements.

Grab it at SourceForge or let Sparkle take care of the update for you.

I’ve decided that few enough show-stopping bugs are left in the code currently that I can push a release out, and hopefully garner a bit more exposure (and perhaps even a new developer or two…).

The main new features in this release are:

• Peer Exchange (PEX) for public torrents (uTorrent protocol)
• Massively improved interface with a lot more information
• Sparkle and Growl support
• Performance and memory use improvements
• Lots and lots of bugfixes

 Take it for a spin and see what you think. Feel free to post feedback here, or on the niagara-devel list.

I’ve decided to switch from the 0.0.x versioning to a 0.x alpha as I feel that most of the 0.1 functionality I want is in place, and I’d really like some help and feedback on getting the basics stable before tackling some of the advanced features I’m planning a bit further down the track.

Things have been pretty quiet lately in terms of releases as school has been keeping me pretty busy, but behind the scenes, SVN has been pretty active. I’ve accomplished the following:

• UDP and multitracker support thanks to Kevin Smather’s updated libbt code
• Ratio and stat tracking support
• Far more stable torrent class
• Growl support for notifications
• Sparkle support for version updates
• Peer Exchange (PEX) support, which has been backported to libbt.

Things are coming together quite nicely, and I’m hoping to release 0.0.6 pretty soon, once I’ve completed the seeding ratio system. After that the next feature priorities are the interface and bandwidth throttling.

Keep an eye on SVN, and the intrepid can try a few builds, as the engine itself is pretty stable currently. You can also subscribe to the mailing list, which I’ll post a release announcement to. The SVN builds will autoupdate to the 0.0.6 release when it is released, so you can stay current that way too.

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.

It’s nuts how hard it is to find an accurate (and more importantly complete) guide to creating a secondary .nib to hold a secondary window and controller in XCode/IB.

I stumbled across the SimpleMultiWindow example in XCode’s Sample Code (/Developer/Examples/InterfaceBuilder/SimpleMultiWindow), and it contains all the pieces, as well as how to send messages and call methods between windows. Handy as a guide to work from.