AIO4J = better NIO?

[Matlu]

there is one thing which I did not like about NIO since very beginning. Its interface is too cumbersome when you want to use it for game programming. I guess that most people need fire&forget. You want to create a message and call one method, which will post it. You don't want to bother with waiting till the socket is ready for writing, and then bother with checking whether it was really sent or not.

Searching on internet I found that there is "competitive" implementation - AIO4J from IBM. I haven't seen their interface yet, but they say it uses different paradigm to achieve same thing. Anybody tried it by any chance?

Interesting link: http://www.theserverside.com/news/thread.tss?thread_id=26732
Interesting quote:

As others have pointed out, this is not a replacement for NIO. It actually seems to be an implementation of (at least portions of) JSR 203. In pattern speak, NIO enables the Reactor pattern, while asynchronous IO enables the Proactor pattern. See POSA2. JSR 203 was originally supposed to be part of JDK 1.5, but did not make it. It will be part of a future implementation.

As Bruce points out above, AIO is a different paradigm to NIO (which is multiplexed non-blocking serial IO). The platform support for AIO in many operating systems enables scalability beyond that afforded by NIO for handling thousands of simultaneous connections with low thread count.

AIO is not intended to usurp NIO. AIO4J is regular Java and JNI code that will run on any compliant 1.4 JVM.

[Jeff]

there is one thing which I did not like about NIO since very beginning. Its interface is too cumbersome when you want to use it for game programming. I guess that most people need fire&forget. You want to create a message and call one method, which will post it. You don't want to bother with waiting till the socket is ready for writing, and then bother with checking whether it was really sent or not.

Searching on internet I found that there is "competitive" implementation - AIO4J from IBM. I haven't seen their interface yet, but they say it uses different paradigm to achieve same thing. Anybody tried it by any chance?

Nope, but I question the need for ANY of this in game clients.  They dont generally have enough sockers open simultaneously for it to matter much.  (ANd if they DO its generally a bad mis-design... like the way EQ  opens a different UDP socket for each communication partner. Silly and wasteful of resources.)

Servers are a different story.  Until this becoems aprt of a JDK release, i myself would be wary of it because ist one more third party port I have to count on being avaiable if I shift platforms and I havet had any problems with NIO.   That may or may not matter to you.

[blahblahblahh]

there is one thing which I did not like about NIO since very beginning. Its interface is too cumbersome when you want to use it for game programming. I guess that most people need fire&forget. You want to create a message and call one method, which will post it. You don't want to bother with waiting till the socket is ready for writing, and then bother with checking whether it was really sent or not.

Yes, you do. You want to do your entire game in one thread, for a myriad of reasons. You don't have to, but it makes life easier. So, in fact, you want to do exactly what NIO does for you.

Game programming is ALWAYS more cumbersome than normal programming, coming all the way back to that annoying gameloop thingy - it *enforces* a more cumbersome programming style. Fundamentally, it's forcing you to do non-transparent scheduling, whereas modern programming generally uses transparent scheduling.

Nope, but I question the need for ANY of this in game clients.

Yeah, not worth it for performance reasons, but for code readability and reasoning as noted above...