In this article, the author will cover both the client and server side as he describes how to create non-blocking secure connections using the Java Secure Socket Extensions (JSSE) and the Java NIO (new I/O) library, and he will explain the traditional approach to creating a non-blocking socket, as well as an alternative (and necessary) method if you want to use JSSE with NIO.
The easy way to non-blocked sockets
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I just finished writing a connection tunneling program in java last week, I had to multi-thread it because of blocking socket calls. If I only would have known about this article earlier my life would have been much easier….oh well.
Is there a similar article for say Python or Ruby? (Note that I said nothing against Java, “Rebort abuse” abusers.)
why ?
It’s not like threads are hard to do in java
I just finished writing a connection tunneling program in java last week, I had to multi-thread it because of blocking socket calls.
Perhaps you should look into synchronous I/O multiplexing… there are many ways of handling multiple connections with a single thread besides non-blocking I/O.
Non-blocking I/O is largely useless, as it merely converts what would be a blocking operation to an error. When such an error occurs, it means you were doing something wrong to begin with (writing to a socket whose buffer is already through)
Readiness for a particular operation should be determined through a multiplexing operation, not by throwing data at a socket’s buffer and seeing if it accepts it.
The only non-blocking operation that’s particularly useful is a non-blocking connect, in which you invoke connect then test the socket for writability (when the socket becomes writable the connection has been established) This allows a connect() operation to occur in conjunction with other socket operations within a single thread, so that thread can continue processing I/O events on other sockets even while a connect() is taking place in the background.
Writing to an inputStream you get from a socket will block until the write is completed(That is: All data has arived at the recipient), so for that you need either non-blocking sockets or threads if you want more then one connection.
Martin Tilsted
Writing to an inputStream you get from a socket will block until the write is completed(That is: All data has arived at the recipient), so for that you need either non-blocking sockets or threads if you want more then one connection.
I am coming at this from a C perspective, but I would assume the issue here is using a buffered writer. I find it hard to believe that Java does not provide an atomic write operation. write() in C will place as much data into the kernel’s input buffer as it can hold (up to the total amount of data passed by the call). In this way, a programmer can then wait until the socket is set writable again before making another write() call.
Bascule wrote that “non-blocking I/O is largely useless”. I disagree — it’s quite useful if you need your thread not to block. For example, say you have 50KB of data that you want to send over the socket. Your socket may indicate that it is ready to accept data, but how much data should you pass to it? If you are in blocking I/O mode, the only way to guarantee that you won’t block would be to pass the socket a single byte at a time, and after each byte was sent, test the socket to see if it can accept more — obviously, a very inefficient way to do things. In non-blocking mode, you can offer the whole 50KB of data in one call, and the socket will take as many bytes as it can hold, and immediately return, telling you how many bytes it took. You can then go back to your multiplex-call (select() or whatever the Java equivalent is) until one of your sockets is ready for more data.