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.