Security with LimeWire/Gnutella
 

I am wondering the security prospects of LimeWire and Gnutella given Gnutella2. I have read through much of the LimeWire source code, and I think I am going to develop a secure client (the definition and breadth of "security" still need good definitions...) for the Gnutella network for my master's thesis. The network code I have read for (most) open source gnutella clients has been butchered in some sense, being just too thread heavy. Java nio exists now, and with some hacking, can be made secure. What are other's feelings on the feasibility and need for a client of this nature?

chris actually wrote an nio version of the code, but because limewire has to support users who don't have java 1.4, it needs some hoops... the nio version, instead of using 2 threads per connection, uses 1 master thread [in a nutshell -- it is more complex]. but the nio framework java provides is fairly buggy... in all, nio will probably make it into release code sometime far in the future.

i don't see how nio & security relate tho.

NIO/Security
 

No, they are not related, that is why NIO need be hacked to accomodate security issues. At the moment, I would not deploy LimeWire in a large organization since there is NO security at all. Adding some authentiacated Diffie-Hellman key exchange on top of secret-key encryption would ensure that two clients could transfer files to one another without the worry that a middleman could intercept the transmission. (Sender Y would have to agree to send content to user X of course.)

On the NIO mechanics, I am assuming that the "master thread" you speak of is used only to poll hardware for channels ready for I/O, not actually execute those tasks. If not, that thread is being VERY overwhelmed. One thread polling hardware and delegating work to a fixed-size thread pool is a much more efficient implementation. (Doug Lea's util.concurrent package has many executor implementations at gee.cs.oswego.edu) During the alpha and beta stages of the 1.4 VM, my working group was assigned to rigourously test NIO for months. We found bugs in the TCP side, yes, but they have been fixed in the 1.4.1 release. The only known NIO bugs right now appear when using DatagramChannels for UDP transport, which is of no concern here.

Some helpful literature:
1.) Concurrency:
Doug Lea's Station

2.) NIO tests:
PCES Project

i still don't understand why NIO would have to be hacked to be secure. security is on the application layer. nio is on the transport (or is it network?... took that class awhile ago) layer. the only difference between limewire's current code & future code of using nio would be how it handles the socket connections, and the underlying reading/writing of the data.

yes, the master thread would poll the hardware for i/o. more specifically, it would sleep (using Select) until there were some fd's needing a read or write. i also believe the current design would read & write the data too, since it essentially just moves it from one buffer to another. and, since it doesn't block, it is relatively quick. note that the master thread would *not* be handling the logic of understanding what the data is and routing it to appropriate places -- it would just handle the underlying read/write of the data.

you're welcome to take a look at the code, since it's all open source. i'm pretty sure chris did it under 'nio-branch' -- he has an explanation of it at: http://www.limewire.org/project/www/nio2.html

DatagramChannels for UDP will be a concern in the future, when GUESS is implemented. it uses a (guided?) walker approach & makes udp connections to other ultrapeers to find results. so yes, any bug with nio is a large problem.

Ahh, I did not understand what you meant by "how they relate." No, in the true sense of the word, no one need actually "hack" the VM source to secure NIO (which is the transport layer by the way :-) ), but something need be done to the data prior to writing the ByteBuffers to channel. That something should also be fast and unbreakable. That was all I was implying.

Thanks for the link.