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:
// I have separated 'connector' thread for this
checkForNewMessages(); // using available & read
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