NIO Article: RFP

General Discussions
#1

I’m trying to decide what to include in an article on NIO. Here’s a provisional list of the topics I think people probably want to know about (and which I can write on :)). Each would easily be an article in it’s own right.

EDIT: I’m only talking about using nio for networking…
EDIT: When I say “IO” below, I mean “networking using the old IO routines and classes”, which means "java.io.* and java.net.". Much of the java.io. stuff is replaced with java.nio.* stuff, but the java.net.* stuff is replaced by stuff in the java.nio.channels.* package (there is no “java.nnet.*” package, which might make things a bit more obvious here! The .net to .nio.channels change makes sense because networking and file I/O have been unified a bit more, so it’s no longer appropriate to speak only in terms of net)

[]Using NIO in a game: Where, How, Why
[]Should I use NIO, or just plain IO?
[]Patterns/architectures for NIO servers
[]Gotchas, bugs (in nio), platform-dependencies, etc
[]Useful dev and debugging tools (specifically for NIO development - i.e. not IDE’s, but e.g. stress-testing tools)
[]Introduction to planning your server for a game: Mesage-protocols, msg-formats, transport layers, app-layers, app-layer semantics, distribution architectures (p2p, c-s, etc)
[*]Attaining peak performance with NIO

…if you could let me know which of those is most useful to you, I’ll get writing. Equally, any other suggestions, comments, etc? Maybe there’s something else you want to know, more useful than what I have included in that list?

I’m not expecting that people want to know how to get a basic NIO server running - that’s the ONLY part of NIO that’s adequately covered by millions of free tutorials on the web. However, if people have trouble finding them, or running them, perhaps I could pull together a small set of examples?

#2

NIO is “New” I/O using the ByteBuffers and deriviatives.
What is an NIO server?

Aren’t you talking about networking and isn’t that still the net package and independant of NIO? How does NIO change server architexture?

Thanks for any infos! :slight_smile:

#3

I’m a little confused about this as well. Which leads to a great topic to include in the article. How/When/Why you’d use NIO for networking rather than just .net?

#4

[quote]NIO is “New” I/O using the ByteBuffers and deriviatives.
What is an NIO server?

Aren’t you talking about networking and isn’t that still the net package and independant of NIO? How does NIO change server architexture?

Thanks for any infos! :slight_smile:
[/quote]
Thanks, guys, it’s great to know what you don’t know ;). It’s also good to get a heads-up on what aspects of the vocab I (ab)use through laziness or familiarity, and need to be more careful with…

You can’t do much real (certainly you can’t do non-HTTP) networking in java without heavy use of java.io. When I say “NIO vs IO” I really should say “NIO vs (IO + NET)” (thanks for pointing that out :)), but the name NIO often makes people talk of it in contrast to IO (by which they typically mean “IO = java.io + java.net” when talking about networking).

NIO-networking classes (java.nio.channels.*) fundamentally alter the architecture of a java server. It’s a bit like the difference between Java pre-Collections and post-Collections… It’s a switch from an API which gives you little or no control over how your connections are being handled, how they are prioritized, how they are arranged etc, to one which (when it works) gives you (some) control over all of that.

Note: that’s a gross generalization. You can, for instance, use the java.nio classes in a traditional net/io server without any architectural changes. I’m trying to just give you a taste of the differences here :).

One example of how it changes the playing field is that it has the potential to allow several thousand simultaneously connected TCP clients (in theory, up to about 20 thousand on a typical PC…but I’ve not checked if Sun’s umplementation can currently go that far ;)).

With standard io and net, you are effectively limited at 500 odd clients, although some tricks (e.g. using non-standard OS upgrades, like recent work on linux threading) can get you much higher.

#5

[quote]I’m a little confused about this as well. Which leads to a great topic to include in the article. How/When/Why you’d use NIO for networking rather than just .net?
[/quote]
Sorry, that’s what I meant when I said “NIO vs IO”.

I should also be explicit and say that I’m only going to consider NIO for networking - i.e. not file I/O etc. There seem to be very few games devs here who need help with nio file stuff compared to those that would benefit from nio networking (channels) stuff.

This is mainly supposition on behalf, but AFAICS any games devs using nio file reading/writing know what they’re doing very well already? Bearing in mind it’s considerably slower to use nio for file io unless you have VERY big files or extreme memory-copying situations (e.g. sending megabytes of data directly to a video card, via a memory-mapped file IIRC)…

#6

Wow, I get to be a newbie asking for help for a change!

I’d like two things out of this. NIO is badly documented leading most devlopers, including myself, to completely missing the point. Actually I shouldn’t say that. I cannot find good documentation for NIO.

Two, why should I use it? It seems fundamentally different from the “old” way and I’m not sure it does anything for me.

#7

The only good documentation for NIO comes from books you have to buy as the Sun documentation is horrible in this regard.

NIO’s claim to fame in the server space is that it allows non-blocking IO with the use of selectors. Traditional designs spin up a thread for each user connecting to a server and this is resource intensive. With NIO selectors can be set up to send and receive data when channels (a new concept with respect to IO) are read to send and receive data. Since you aren’t spawning a thread for each client you can clearly have a much more scalable architecture. If you’re only trying to connect onesie - twosies to a server then NIO is NOT the best option for you as it does incur some overhead of its own - but if you’re looking to do a traditional 32 person game - you will quickly find that blocking IO and spinning up threads per user will pretty much kill your performance.

NIO is one of the most important but least understood APIs that came along for the ride with JDK1.4. In my shop we build massively scalable servers (for obvious reasons) and without NIO life would absolutely suck. It does take a while to get used to, but if you’re using NIO to talk ByteBuffers with JOGL or LWJGL, there is very little that you need to deal with in order to transfer that knowledge into the network world. In fact all of the relevant IO classes in 1.4 received the .getChannel() method so that you wouldn’t have to change your code too much.

#8

[quote]The only good documentation for NIO comes from books you have to buy as the Sun documentation is horrible in this regard.
[/quote]
Nod. My sarcastic comments on the state of NIO docs from Sun are legion :).

The architectural/design changes are also a major improvement. Code is cleaner, easier to maintain, debug.

In most cases, you are NOT going to notice any performance difference with 32 players between NIO and IO/net/. No modern OS should have issues with anything less than several hundred threads (although if pressed I’d err on the safe side and assume it could only handle a hundred :)). There are libraries on linux (not yet standard) that allow 100,000 threads with litle or no performance degradation - and this is being used specifically in server development. Although I’ve not tested the claim, 10,000 threads with little/no performance loss is certainly believable.

Solaris also provides good examples (at similar numbers of threads) of what performance you can get out of massive multi-threading on a production OS.

The issues involved in choosing NIO or not are a little more complicated than you make out, although as a quick summary it’s fair enough.

I agree with your sentiment, hence I want to correct the situation. However, the getChannel() method has some major issues. It isn’t actually fully safe. If you want an example, use getChannel to try using Socket’s generated by an SSLSocketFactory with nio. (hint: it doesn’t work - this is covered in the API docs IIRC, which specifically state that just because you can call the getChannel method doesn’t mean it has to return a valid channel).

Would you like to collaborate on producing an example/article that shows how neatly networking can mesh with things like JOGL, using NIO? I’m still only dipping my toes in the water with JOGL at the moment, so…

#9

Well it really depends on what you have those threads doing. I don’t want to elaborate too much on architectures, but if you’re doing an asynchronous response architecture (like a P2P or chat system) - the idea of spawning a thread for each client should send chills down your spine :slight_smile: It won’t scale well at all.

If you’re UDP no - if you’re TCP and high traffic yes. Without NIO you have to use the nasty IO stream semantics to write to the sockets and that will dog performances as opposed to slapping together a packed with NIO and sending raw byte buffers over the wire.

While it isn’t 100% safe - for general use and porting, unless your SSL heavy (and who here is SSL heavy) - you can plug NIO into your existing server framework within a weekend in many cases.

Additionally, I’d love to colaborate with you on NIO docs. Just send me an email.

#10

Some very good information from you guys…thanks!

Now if only Sun would cover this info in their java.net site!

#11

OK, I’ve started :). It’s rather hard to predict when and where my spare time occurs at the moment (we’re in alpha/beta test at the moment, so lots of spikes and troughs of activity).

http://grexengine.com/sections/people/adam/

So far, I’ve just got a very basic “Introduction to NIO Networking” up. It says not much more than we’ve covered already in this topic, but I’m not expecting to spend much time “introducing” NIO. I’ll see if I can another, more useful, article up later today :).

Any comments, suggestions, corrections, etc?

#12

[quote]Some very good information from you guys…thanks!

Now if only Sun would cover this info in their java.net site!
[/quote]
P.S. Assuming the quality is high enough, once these articles are done, I’d much prefer it if they were published on JGO (alongside all the other great resources here - forums, wiki, project-pages, etc); I’m just making use of some free webspace I’ve got at the moment, while it’s still a “work in progress”.

I’m kind of hoping to kick-start a flow of JGO articles from other people…

#13

Cool… I’m actually working on a reference based on JOGL, JInput, JOAL and hopefully we’ll be able to get all this on the Java.Net site.

#14

I am surprised that ‘traditional’ java.io based networking should be as fast and responsive as the a nio based. Some months ago I was involved in the development of a Java client of the popular board game Ursuppe (http://doris-frank.de/GamesUrsuppe.htm). A java-based server runs the game and communicates to the clients using a simple text based protocol. The client’s task was to win the game using its AI.
Our problem: In tournament games the clients were given a 1.5 seconds timeout to do a valid response. Our client was at first using the conventional socket and stream classes and often missed the timeout.
Fortunately I found IBM’s article to NIO and was able to rewrite the core component of our communications package. This modification really helped against the evil timeout problem.
From the logs of the other clients (there are 8 in total) we know that they had the same problem. As far as I know the server and the other clients used conventional io+net.

I admit that a tournament which consists of the server and 4 clients ran on a single machine (4x i686 - Linux) …

Can someone explain these discrepancies in performance to me?

To come back to the topic:
Although I have already done a clientside network component with nio I do not feel ready to create a full-featured networking package that can be used by a game. My main problem is that nio acts like an unbuffered input stream: you never know when you have gotten all of the bytes the other side sended. This should be highlighted more in an article.
Another story are these funky flip/mark/clear/limit Methods the nio-Buffers supports. Some images would be nice to describe their functionality to people who are not speaking english as their native language … :smiley:

Some info about proper character conversion using nio would be nice as well.

I thank you for reading my suggestions and writing such a hot article that everyone will be interested in!

#15

[quote]I am surprised that ‘traditional’ java.io based networking should be as fast and responsive as the a nio based. Some months ago I was involved in the development of a Java client of the popular board game Ursuppe
[/quote]
It is almost never possible to tell what the performance problem is without seeing the code :). There were flaws in io/net that used to be serious enough to be called bugs - especially in the DNS resolution (which was absolutely rubbish until 1.3.x IIRC). But nothing that couldn’t be worked around (except for the fact that you couldn’t interrupt an active Socket, IIRC).

So, do you mean the high-level / architectural issues? How to design your classes and methods to work together with this behaviour?

[quote]Another story are these funky flip/mark/clear/limit Methods the nio-Buffers supports. Some images would be nice to describe their functionality to people who are not speaking english as their native language … :smiley:

Some info about proper character conversion using nio would be nice as well.
[/quote]
Yeah, I’m currently projecting doing them in this order:

  1. introduction and brief background to NIO. Brief comments on why you’d want to use it. Explanations of core concepts - such as the differences between synch and asynch I/O.

  2. SelectableChannel, SelectionKey, and Selector - how to use them, how not to use them, what they’re there for, what the advantages are, some of the funky things you can do with them.

  3. Converting from IO to NIO - mainly featuring how to use Selector’s etc in simple ways in an existing application.

  4. NIO or IO? Which one is for me? Which one is for my current game? Why? …etc

  5. More detailed explanation of the ByteBuffers, how to use them, what to do with them, etc.

Have a look at the early drafts of 1 and 3 that are linked to from the page I quoted above, and let me know what you think. I’m afraid it’s going to take a while before any are “complete” due to my work commitments at the moment :(.

Orangy Tang (thanks!) has given me source to a real game that I can convert from IO to NIO, so I may well rewrite number 3 to use that game as a working example. Need to read through the source and check it all out first though…

#16

The first article gives a good introduction to the topic. Nothing to complain. Good work!

The game example was a little difficult to follow but it reminded me of a real problem I had with nio: Writing to a channel is not always possible. I think this is really annoying when migrating to asynchronous io. Although the article touches the writing problem I did not really understand how to face it properly.

Yes but on a network library level. It would have helped me alot when JDK docs clearly stated that asynchronous io has to be supported by a sophisticated system of input and output buffers.
Maybe you could include these and other design considerations for people who want to use nio in their own network package (if not already planned :smiley: )

#17

[quote]1)

The game example was a little difficult to follow but it reminded me of a real problem I had with nio: Writing to a channel is not always possible. I think this is really annoying when migrating to asynchronous io. Although the article touches the writing problem I did not really understand how to face it properly.
[/quote]
…so, basically, you’d like to see a whole article explaining how to use Asynchronous I/O? (in a generic way - which doesn’t necessarily just mean NIO, but other asynch libs as well…)

There’s quite a few mistakes in 3 at the moment :), and it’ll change quite a bit as I try to make it easier to understand etc. What I want to be is “A worked example so that you can see very quickly roughly how much work is involvd, and roughly what are the issues (design etc) you have to face”. It intentionally glosses over the details, so that I can cover them elsewhere (e.g. explaining how to use Selectors/SelectionKeys/etc, and explaining how to use ByteBuffers/Charsets/etc).

So…any suggestions on how 3 could achieve that aim better (from your perspective)?

Thanks for the comments :).

#18

[/quote]
…so, basically, you’d like to see a whole article explaining how to use Asynchronous I/O? (in a generic way - which doesn’t necessarily just mean NIO, but other asynch libs as well…)

[quote]

Yes maybe this would be a good idea. Showing a general idea (the asynch io with all its pitfalls) and then presenting the specialized Java solution may the reader feel more familiar with terms like ‘selecting’ and ‘keys’.

I like the Java programming very much and help as I can to spread its acceptance. Commenting Java-related articles is a really small contribution but it helps. :slight_smile:

#19

I’ve just added (most of) the third article…although slightly confusingly it’s number 2 in the series :).

The index URL listing all of them is the same as before, i.e. (since it’s on the previous page :))

http://grexengine.com/sections/people/adam/

and the new article is at

http://www.grexengine.com/sections/people/adam/nio/SelectableChannel_SelectionKey_and_Selector.html

Comments and feedback still appreciated…Although I don’t really care about spelling mistakes (I’ll run through them with a fine toothcomb/spellchecker once they’re finished) - I DO want to know ASAP if there are any factual mistakes, and I want to know if there are any bits that are difficult to understand, or go into too little detail.

EDIT: The new article is titled “SelectableChannel, SelectionKey, and Selector (The Three Main Parts of NIO)”

#20

[quote]My main problem is that nio acts like an unbuffered input stream: you never know when you have gotten all of the bytes the other side sended. This should be highlighted more in an article.

Another story are these funky flip/mark/clear/limit Methods the nio-Buffers supports. Some images would be nice to describe their functionality to people who are not speaking english as their native language … :smiley:
[/quote]
I’ve just updated all three of the articles. You should find that both your problems above are quite well addressed now - have a look and let me know what you think.

(note: you may need to hit refresh on the pages for each article - the webhosting company is rubbish, and the pages are being cached for longer than they should be…on MSIE, you may even have to Ctrl-f5, unless they’ve fixed that particular bug by now - the one where refresh doesn’t always refresh, but ctrl-f5 does)