Non-blocking sockets

As a case study I wrote a server which accepts client connections over socket and caters to the request over a thread. I want to close the connection if the socket is idle for a long time(for performance). However, everytime I try to read from the socket, it gets blocked until it gets data/ times out. Can I implement non-blocking sockets so that I can continue if there is no data to be read?
------------------
Shubhrajit :-)

See Socket.setSoTimeout(). For an all-singing all-dancing non-blocking socket implementation you'd want to use the nio packages in JDK 1.4, but if all you need is a simple timeout this should do.
- Peter

Along this line, is it more advisable to go with threaded socket implementations or non-blocking (assuming 1.4 or simply using timeouts in it's absence) and why? I written more than my fair share of threaded socket code, but recent UNIX exposure has introduced me to the world of non-blocking I/O and I'm just wondering as to their individual strengths and when I should use what.
------------------

For non-blocking I/O, there is no alternative to the J2SE 1.4 new I/O APIs. All you currently have is socket timeouts and you are likely to end up burning an awful lot of CPU cycles polling your sockets.
At the moment, a typical server application will use a master thread listening on a ServerSocket. Whenever a client connects to this ServerSocket, it spawns a handler Thread or, if connections tend to be short-lived, pull one from a thread pool. This thread is exclusively dedicated to that one client until the connection is closed.
Problem is that threads are a precious commodity. Depending on your OS, hardware, the JVM, and the phase of the moon, you can create a few hundred or a few thousand of them before performance starts to collapse. The key observation that leads to the solution is that almost regardless of the kind of server you implement, the handler thread is likely to spend a lot of its life blocked on socket I/O, waiting for client communication to arrive or waiting for its response to drip into the network.
With non-blocking I/O, you are able to use a single thread to wait for events on a large number of sockets (using a Selector object). When something happens on the sockets you're watching, the Selector wakes up your thread and gives you a list of sockets that need your attention.
Once a request had come in, you would still use a handler thread to perform all but the most simple operations. But you need far fewer of them because they don't waste their time blocking on sockets (or file I/O or...). And the number of handler threads you use merely limits the number of requests that can execute concurrently, not the number of clients that can connect. A server application using non-blocking I/O can scale to a far larger number of clients.
So to answer your question directly, I think non-blocking I/O will become the preferred way to implement most servers, and certainly any server that should scale well.
For more detailed information on the nio APIs, you may find this article by John Zukowski a useful read. And of course Beginning Java Networking discusses it in its chapter on JDK 1.4 networking.
- Peter
[This message has been edited by Peter den Haan (edited December 11, 2001).]

Thank you Peter for your valuable suggestions

------------------
Shubhrajit :-)