Non-blocking blocking I/O?

[blahblahblahh]

I have a "not-so-off-topic" question:
Many people claim, that prior to JDK 1.4.0 all IO operations were blocking and there was no way to avoid thread-per-client model. This I cannot really understand, because:

- ServerSocket.accept() really blocks, but it is not a problem, it is possible to have one thread just for accepting new connections, and one thread for handling all existing connections
- InputStream.available() does not block, so it's possible to have non-blocking reads, if you call available() first
- OutputStream.write(byte[]) does not seem to block either, at least as far as I know. In fact it does not provide any output, I've never seen it to throw an exception, even when the connection was closed. I really don't think it blocks. Correct me please, if I'm wrong.
(I'm talking about Socket TCP connection)

I have implemented this, and it seems to work without a problem. I'm thinking of switching to NIO, but I'm not convinced it could bring any real advantage - can someone please try to convince me?

[blahblahblahh]

I have a "not-so-off-topic" question:
Many people claim, that prior to JDK 1.4.0 all IO operations were blocking and there was no way to avoid thread-per-client model. This I cannot really understand, because:

The only way around this was to use JNI. There were a few asynch/NIO alternatives before 1.4, at least one of which was a major influence on 1.4's design.

- InputStream.available() does not block, so it's possible to have non-blocking reads, if you call available() first

Read the javadocs for it. InputStream always returns 0 for this method. Do you see a problem ?

BufferedInputStream simply returns 0 + however many extra bytes it has accidentally read in on the last read and not surrendered yet.

I'm afraid I can't give you a definite answer, because it's so long since I was using I/O, but off the top of my head the available method either returned 0 or "guessed" (this was a known problem and I have a vague memory that Sun used to say it was a "guideline" figure rather than necessarily accurate, because I/O wasn't attempting to provided non-blocking capability).

IIRC this is another example of where the general API allows you to try to do something that a particular implementation won't - InputStream was NOT designed just for networking, and some of it's subclasses can actually return a sensible value for available (not to mention that you want the method in the superclass for type reasons)...but that doesn't mean that just because you have an object of that type and that the method exists that the method will actually be *valid* in that situation.

So, you could call this method, but it had no meaning.

- OutputStream.write(byte[]) does not seem to block either, at least as far as I know. In fact it does not provide any output, I've never seen it to throw an exception, even when the connection was closed.

Some of us believe this is a fatal flaw in Sun's API design - it cannot throw an exception because it actually doesn't transmit data, it just shunts it onto a queue and then when that data fails it can't get a notification because the API doesn't have callbacks. IIRC a JVM engineer told us that you would get the IOE on the NEXT call to the method, which is insane and stupid and I have trouble believing.

I have implemented this, and it seems to work without a problem. I'm thinking of switching to NIO, but I'm not convinced it could bring any real advantage - can someone please try to convince me?

Go to JGF (link in my signature below), go to the articles section, and read the NIO articles. That should convince you...

[Matlu]

Read the javadocs for it. InputStream always returns 0 for this method. Do you see a problem ?

So, you could call this method, but it had no meaning.

I have read relevant javadoc many times   InputStream.available() is really said to return 0, but it is an abstract class. If you call Socket.getInpustStream() you will get an instance, which behaves correctly. I have tried it today with both 1.3.1 and 1.4.1 (from sun for ms windows) and it seems to works fine. As I said before, I have  programmed multiplayer game using this approach, and it works more then just fine.

Some of us believe this is a fatal flaw in Sun's API design - it cannot throw an exception because it actually doesn't transmit data, it just shunts it onto a queue and then when that data fails it can't get a notification because the API doesn't have callbacks. IIRC a JVM engineer told us that you would get the IOE on the NEXT call to the method, which is insane and stupid and I have trouble believing.

I myself am quite happy with this behavior of "write". I don't mind that write doesn't provide feedback, because if anything went wrong, I will learn about it when I call available() or read(). They *will* throw an exception. I do this at the beginning of each "heartbeat" - so I learn about broken connection fast.
My algoritm is very simple:

while (true)
{
    checkForNewConnections();
      // I have separated 'connector' thread for this
    checkForNewMessages();    // using available & read
    processMessages();
    createStatusUpdateMessage();
    sendStatusUpdateMessageToClients();
   sleep(~500ms);
}

the only problem is, that in extremely bad case (when message is delivered just after checkForNewMessages) it takes 2 heartbeats before response is sent. I think that this could be improved with NIO.

Go to JGF (link in my signature below), go to the articles section, and read the NIO articles. That should convince you...

I have read all your articles yesterday, while reading TCP vs UDP thread They are really extremely helpful, good work. I think I will definitely try to implement it with NIO... and... I will see

Games published by our own members! Check 'em out!

[Rob Grzywinski]

I will confirm Matlu's statement about using Socket.getInputStream's available().  I have used it many times in the past to do "non-blocking" IO with standard IO.  It works very well in a game environment since you have a polling situation (you just check it every pass though the game loop).  It's a serious pain in the butt when you don't (e.g. most enterprise applications).