A Couple Questions with regards to the NIO tuts

Networking & Multiplayer
#1

Over the last couple of days I’ve been using the NIO tutorials to attempt to implement a basic client login setup, (they send me accountname/password, I check this against my stored names and verify). Basically, my question is with regards to the following code contained in the method ‘protected void processReadableKey( SelectionKey key ) throws IOException’:

int numBytesRead = rbc.read( inputBuffer );

        if( numBytesRead < 0 )
        {
              // This is an undocumented feature - it means the client has disconnected
              key.cancel();
              closeChannel( key.channel() );
              return;
        }

where RBC is a ReadableByteChannel. My primary problem is when the client is shut down, the key relating to that channel is a isreable() == true key that hits the line ‘int numBytesRead = rbc.read( inputBuffer );’ and throws a ‘java.io.IOException: An existing connection was forcibly closed by the remote host’. I was under the impression that the code given should prevent this, but it just quits out of the loop and the key is constantly passed back into the iteration.

My second question is with regards to the method closeChannel(SelectionKey), above, the tutorial doesn’t explain this method at any point, and I was wondering what exactly is required to close a channel using NIO.

Thanks for any response, let me know if you need further details, as it’s very possible that I’ve just made a stupid mistake somewhere and due to inexperience havn’t noticed it yet.

#2

I just wrote a long and detailed response to this. Unfortunately, Mozilla bitch-slapped me (stupid moronic key shortcuts handling, and whilst I was trying to fix what it just did to me it crashed before I could hit “Post”) and I haven’t the time left to rewrite the whole thing.

So, in brief:

  • part of the problem is that the tutorial code is actually wrong. Trust me, I wrote it ;D
  • this is Sun’s fault, not mine. They have NOT documented what “actually happens” nor “how you should use this”. As a result, I had to use trial-and-error to work out many of the details. Their JVM was broken (1.4.1 and also the first 1.4.2 IIRC) and I accidentally coded these tutorials to work with the BROKEN behaviour of specific versions of Sun’s JVM. Because they didn’t document this, I didn’t find out until some aspects of our production code stopped working when we tried upgrading the JVM.
  • …but it didn’t hit us hard, because the real code that I used as a basis for the tutorial has a LOT more defensive programming in it, most of which I stripped out for the tutorial to make it clearer and easier to read. None of it was “essential”.
  • However, until now I completely forgot that the tutorial would need updating too!

Specific fixes:

  1. In the block where you deal with the “undocumented feature” which is still in the latest Sun JVM (and you HAVE to support even though it’s undocumented), I have a better approach now. Instead of the code in the tutorial, just use the line:

throw new ClosedChannelException();

  1. …because Sun has fixed their JVM, which used to NEVER throw this exception, but now it does. Often. So you have to catch it anyway, and if you’re doing that, you might as well use it. However, they haven’t quite fixed all their bugs, because there are occasions when you get the -1 read INSTEAD of a ClosedChannelException - but I believe from reading between the lines Sun intended to throw that exception. Hence my recommendation that you do it yourself.

  2. Modify your code to catch those CCException’s. It’s pretty obvious what causes them - the other end of the connection has disappeared for any of a variety of reasons, so take whatever actions are appropriate in your game when someone disconnects.

I would almost bet money that doing this will catch that IOException you are getting ;D.

If you follow the above advice, you’ll be deleting the “closeChannel ( … )” code, but FYI since you asked I just had a pretty boring method that did little more than Channel.close().

The reason I had the method is that there have been changes from version-to-version about what happens when you try to close channels - and, again, Sun has failed to adequately document what you ought to do. So I had that method so I could tweak it each time they changed the JVM behaviour :). Nowadays, I find that just catching the CCExcepiton is enough, and don’t normally need to close anything manually.

EDIT: two more things to add.

  1. The above advice may be wrong. If a Sun engineer came to this forum and said so I would be overjoyed. For the 3 years or so that NIO has been around, I have never seen or heard of any human who claims to know how NIO works (and I’ve scoured the web many times looking for all the info I could find anywhere on NIO). I think Sun decided they “knew too much” and executed them as soon as they’d finished their work, just like Pharoahs and their pyramid-builders.

I’d be even happier if he/she also explained WHY and gave us some documentation for this API!

  1. I haven’t bothered reading the 1.5.x API docs yet - I’m waiting until 1.5 goes gold (at the moment it’s still beta and subject to change). It could be that there are wonderful detailed API docs for NIO that explain all this.

If so, my apologies for misleading you. However, there are several servers on the net at the moment using my NIO libraries that have been serving games for months at a time without restarting the JVM, so you can rest assured I actually use this stuff in real life :). Unlike Ron Hitchens (author of the ONLY NIO book) whose book is a nice introduction to NIO, but makes it look like he’s never used the API himself!

#3

Excellent, my code works now as it did with using threads, thanks for the quick reply, and I anticipate when you get around to finishing your tutorials. I’ll certainly keep them bookmarked and check back again.

#4

Which tutorial is this? ;D

#5

http://javagamesfactory.com/articles.html

(halfway down page)