Ron Hitchens

I did, and thanks for the pointer.

Thanks for inviting me. It was a pleasure visiting the JavaRanch.

Are you expecting to receive the same packet you just sent? Or is someone else sending you packets? You're using a broadcast address as the destination, perhaps you don't have privilege to broadcast.
Rather than spinning in a loop, I suggest you setup a Selector which will wait for something to appear on the socket. In any case, you should check the return value from receive(). It will be non-zero when a datagram has been received.
I have some code that uses DatagramSockets among the example code for my book. You can download it from
here.

I think the most important aspect of NIO is the introduction of Selectors. Selectors make multiplexing of large numbers of sockets very easy. They also push most of the hard work down into the OS where it belongs. You can read the Selectors chapter of my book online at O'Reilly's website to get the full story.

Channels and Selectors. That covers a lot of territory. First of all, let me point out that the Selectors chapter of my book is available online from O'Reilly's site.
Channels: The notion of a channel is new with NIO. It's essentially a new metaphor that represents a pathway to an I/O service of some kind.
Traditional Java I/O is based on the stream, or pipeline, metaphor where data flows in one end and out the other. With a stream, there are no structural boundaries within the data and the stream may be unbounded.
Streams are a very useful metaphor but not all I/O fits that mold. There is also the concept of block-oriented I/O - most commonly associated with disk files. Most OSs operate most efficiently on blocks which are multiples of the virtual memory page size.
There are also some common I/O operations which don't involve any data transfer at all - such as obtaining a file lock for example.
A channel is a nexus, or connection, to some I/O service such as a socket or file. Channels transfer data to or from buffers which are containers for blocks of data. There are no API calls to read or write individual bytes with channels.
Some channels (specifically socket channels for now) may be placed in non-blocking mode. This allows a thread to poll a socket to see if data is available on it but never get blocked if the socket is empty. Non-blocking mode enables polling, but polling can be wasteful if you have lots of sockets.
Selectors: The Selector class performs a very useful function - readiness selection. This means that a Selector can examine a large number of sockets and select the subset of those which are currently ready. This means you don't need to waste time polling empty sockets, you can be notified when new data arrives, which is what you want to know. You save a lot of fruitless effort if you don't need to poll idle socket connections.
That's a sort of whirlwind summary of channels and selectors. If you have further specific questions, please post them.
[ April 17, 2003: Message edited by: Ron Hitchens ]
[ April 17, 2003: Message edited by: Ron Hitchens ]

Sure, you can always write some JNI glue to get down to the bare metal, but that's not NIO. Prior to 1.4, this was the only way to get to such functionality. Unfortunately, JNI code is by definition OS-specific and non-portable.
NIO is the standard set of APIs to do this sort of thing. A common set of classes and interfaces for which the system-specific glue code has been packaged into the system-specific JVM.
I understood the original question to be whether NIO could be used with 1.3. The answer to that question is no, because NIO depends on 1.4.

Well, as the author of an NIO book, I don't want to discourage anyone from learning more about NIO. But I'm also a pragmatist.
If you're primarily writing webapps which run inside a container then your primary focus is going to be on interfacing to the container and leveraging the services it provides. That doesn't mean NIO has no interest for you, but in such an environment NIO is probably most profitably applied to improving the container rather than the contained apps. Although you could certainly find uses for the file-related aspects of NIO, for example.
I see NIO as similar to Reflection or Weak References: important building blocks of the Java environment and something every professional Java programmer should be familiar with. But not something that most will use on a daily basis. At least not in all application arenas.

Non-blocking and selectors are the primary justification for NIO. Without them, building industrial-strength, enterprise-class applications is tough. Considering that server-side is where Java has really taken root, it is indeed surprising that it didn't happen sooner.

Sockets represent network connections maintained by the operating system. Java Socket objects are abstractions within the JVM that provide a one-to-one mapping - each Socket object encapsulates an OS network connection.
In the traditional Java socket implementation, Socket objects are always blocking. That is, when attempting to read data from a socket, if no data is available on the corresponding network connection then the thread attempting the read is put to sleep until some data arrives. This is fine if the only thing you're doing is processing data from that one socket.
Most operating systems provide for sockets being placed into non-blocking mode. In non-blocking, a read will either return some data (if available) or return nothing - but it always returns immediately. This means the invoking thread will never get stuck. One thread can sequentially poll any number of sockets looking for those with data available. Unfortunately, the Java abstraction of a socket, prior to NIO, did not allow you to request that the socket be placed in non-blocking mode - even if that's supported by the OS.
Java never automatically created a thread per socket. This is a programming technique to manage multiple sockets necessitated by the limitations I just described. Because a thread would be forced to wait if it attempted a read on an empty socket, the only way to manage multiple sockets was to dedicate a thread to each. As data became available on a given socket, its thread would wakeup and complete the read.
This thread-per-socket scheme is not scalable for several reasons. First, the JVM thread scheduler becomes stressed as the number of threads grows large. This slows everything down because all those sleeping threads must be managed. It also incurs a lot of context switches as control flip-flops among the threads. Also, all these threads usually must coordinate concurrent access to common objects. The locking overhead becomes signficant and the potential for thread races grows. Plus it's complex and error prone.
So no, threads are not created behind the scenes with NIO non-blocking sockets. Quite the opposite, the need for spawning a thread per socket is eliminated. This allows a single thread to service many sockets without being concerned that it will get stuck if one of them has no data to read. Additionally, NIO includes a new object named Selector which can tell you which of a group of sockets have data to read - eliminating the need to poll each one to check for data.
I hope that sheds a little light on the subject.
[ April 17, 2003: Message edited by: Ron Hitchens ]

David: You can do it either way. You can either fully drain a channel using repeated reads or you can take one bufferful and then go back around the select loop. In that case select() will return immediately because the channel will still show as ready to read.
Jim: Yes, I agree the return value from select is confusing and not very helpful. It's semantically different than the POSIX select() call. My recommendation is to just ignore it are iterate over the list of keys returned (which could be empty).

Well, there's also my Java NIO book site.
Also, O'Reilly provides the Selector chapter of my book online with the catalog entry for my book.
If you still have specific questions, post them here and I'll try to answer.

No. Because there is no backward compatability. NIO is an integral part of the base 1.4 Java platform. It cannot be used independently because much of it is implemented in the low-level plumbing of the JVM itself.
If you make the decision to use NIO, you're committed to 1.4 - there's no going back. I think this is one reason many people are hesitant to use it extensively yet. I personally got burned on this. A client committed to using 1.4 and I used a few NIO features in the code. They then decided that they still needed to support 1.3 and that stuff had to be backed out.
[ April 16, 2003: Message edited by: Ron Hitchens ]

It's always been my opinion that NIO's greatest impact will be mostly unseen. It's the app servers and similar high-end products that will use NIO under the hood to improve scalability and performance.
In a J2EE environment, most of the stuff that NIO is useful for is handled by the container. Servlets and EJBs may still make use of some NIO features but doing so in the near term restricts deployment choices.
If I can drop my generic EAR into the latest version of JLogicSphere and automatically get a boost from its use of NIO then I win even though I don't use NIO directly.

Post a question about something relating to NIO. Otherwise your chances aren't very good.

Interestingly, the formatting and parsing API's were left out of NIO in 1.4. These are intended to be similar to printf/scanf in the C world.