Hi, I'm one of the lead developers of freenet, more specifically the nio "expert" ;-)

I'd really like to see NIO in LimeWire as well! If you guys are interested in migrating, we could use some help in exporting our transport layer into a LGPL library for message-based transports so that everyone can use it.

Btw, there are plenty of bugs that we have discovered and worked around, some win-specific, others linux-specific. Basically the whole transport layer fits into 3 threads (could be easily decreased to 2), with file transfer being
pseudo-blocking (through our own emulation of PipeStreams) and message reading/parsing on one thread.

I'm posting the same thing to the dev list

Thanks very much for posting. We're actively working on NIO right now, and we should have it in LimeWire fairly shortly. I'd definitely be curious what bugs you've encountered, though. Are you using 1.4.2?? Have you done much testing on OS X?

Feel free to send me an e-mail directly if you like -- my user name here plus "limewire.com".

Hi Zab-

The motherboard recently died on my brand new machine, making my e-mail unavailable for at least the next week or so, taking your e-mail address with it. Can you send me another mail just so I have your address again?

Thanks very much.

Just curious--assuming NIO = New I/O for java (http://java.sun.com/j2se/1.4.1/docs/guide/nio/), I'd appreciate some sense of what might it mean for LW.

Thanks

NIO would basically allow LimeWire to use far fewer system resources to process network traffic. We'd be able to 1 thread for all TCP connection thraffic, as opposed to 2 threads per connection with the current scheme. This will also allow us to increase the number of network connections we use, which will open the path to several other potential optimizations.

I'll let Adam explain more, but to explain fully requires a bit of background ...

Handling a connection correctly requires reading data from the network and writing it to the network. Writing is dependent on how much data your computer's TCP buffers allow to be stored and how 'clogged' the networks are. If something is going slow, it might take awhile before a message can be written. Reading is dependent on the other side sending you information. The traditional 'blocking IO' means that when you make a call to 'write' to a stream, the logic simply stalls at that point until the message is fully written. With reading, you have to always try and read, and when a message is available for reading, the 'read' call will stop blocking and actually read a message. What this means for an application like LimeWire is that each connection requires two threads -- one for reading and one for writing. This is necessary so that one connection can't bring down the other connections. (The failure of Gnutella way back when was because many clients didn't correctly implement a two-thread-per-connection model, so slow modem connections could stall the flow of the entire network.)

What NIO "new IO" or sometimes "non-blocking IO" allows is a much more intelligent way of writing/reading. A "Selector" is used to keep track of connections that are available for reading or writing. This Selector blocks, waiting for something to become available. When it is, it notifies the appropriate components and a write or read is performed. If a message was only partially read or partially written, the Selector goes back to sleep, waiting for another notification that resources are available.

Ultimately, NIO will allow a single thread to read/write to all connections on the network, as opposed to now where two threads are required per connection (which, on ultrapeers, can cause 164 threads to be active simply for the network to function). This is a Good Thing (tm) because more threads require more context-switching, more synchronization, and each thread takes up system resources (causing the oft-seen 'too many open files' error).

Thanks for the speedy and clear responses (the history is much appreciated)!

So--Users might see twice the chance that up and downloads will start, half the chance that downloads and uploads will get stalled waiting for the "chunk" messages and an easier time using other programs when LW is running, if I've understood correctly.

Cool. (and maybe twice as many chances of new bugs )

Cheers

Well, the initial implementation isn't going to be for the HTTP traffic (uploads & downloads). It's only going to be for the gnutella message traffic. This is mostly because HTTP connections aren't a huge overhead, since they are mostly one-way communications (two threads aren't required because one side is either reading or writing, but never doing both). Gnutella connections, on the other hand, require reading & writing at the same time, and passing those messages on to other connections.

The thing that users will see is mostly a huge drop in memory requirements and increase in stability/performance.

Interesting. I've wrongly been thinking chunk management requires "gnutella messages" for swarmed files, resuming interrupted HTTP traffic and the like. (probably getting my terms mixed up). I thought this explained how ISP's were able to affect the HTTP transfer between two willing clients.

[aside--I probably should have said "half the bugs" earlier]

Thanks Sam