So far i ve been developing network games using the old fashioned io+net technique.
I ve read some texts recently, which say that nio is far better choice for this.
I would like to know your opinion about this.
Thx.
IMHO, NIO is better for performance but the API is at times a pain in the rear, though it tends you towards writing more scaleable code. NIO also has a few bugs which can be pretty annoying (search for any post here by BlahBlahBlah). If you’re not intending to support lots of users (>20) then you can probably carry on using IO+NET without much penalty.
Kev
It also pushes you towards better-designed code, since NIO’s approach to abstracting I/O is much much better than the old I/O’s ways.
However, there are sufficiently many serious bugs in Sun’s NIO implementation that I personally am seriously considering pulling some of my NIO projects off NIO until Sun pull their thumb out and fix their fscking code. It’s been out for 4 years now, there’s no excuse for having this many bugs still in the code.
NB: if you’re lucky, you may never encounter any of them. I’m not that lucky / I use NIO too much (so that sooner or later I hit at least one bug on each project). So, YMMV. but, yes, I am fed up with Sun’s NIO implementations 
Especial pity because the API they designed is sooooo much better than anything in C or C++
From a beginners point of view the bugs in NIO aren’t too bad - but the ridiculous lack of any clear documentation is. Regular socket-ed networking is pretty damn easy (both conceptually and to code) that you can get something working rather quickly. Trying to get NIO networking up and running feels too much like guesswork at times.
Regular networking however usually involves mucking around with a whole bunch of threads. Still thats pretty trivial as long as you’ve done multi-threading stuff before.
Well, i have much experience with multithreading but the thing is:as soon as you have, lets say 100+ threads running, performance of operationg system degrades a lot. There are some experimental os-s that can menage 10000+ threads without performance issue. But still experimental…
So, i guess that i ll try using nio then…
My 2 cents…
If it aint broke don’t fix it.
java.net is fine for a realtively small numerb of simultaneous connections.
Which means its basically fine for clients as anyclient that has to keep a large number of connections open at once
is most likely mis-designed.
For servers that are going to have to scale to large numbers of simultaneous collections though, NIO is a must.
And they are usually OS-specific. This means, for instance, that if you’re only using one OS, you could well get lucky and hit very few bugs. For the server, this can be fine if you are testing + developing on the same OS you are ultimately deploying too. Obviously, it’s not so true for the client - if you hit a client-side bug in NIO you’re in a lot more trouble (although I’ve not really seen anything in NIO that would concern me on the client - it’s mostly performance-sensitive stuff that only matters when you’re tryign to be as efficient as possible, which you’re not doing on the client, you’re only doing on the server).
So…YMMV, but you could have an easy ride with it.
Odd. SGS uses NIO. I develoeped originally under Win32, deployed for demo under Solaris, and later mvoed to Linux for furterh development./
So far I havetn had to change any code at all…
The quickest way to find out is to read through the bugfix-lists for each of the minor (“build”?) version increments of the JRE - many things such as (IIRC!) “Windows can’t have more than 64 Channels in existence at once”.
EDIT: and, again IIRC, “linux WRITE states are permanently set, even when they shouldn’t be” (which, of course, makes it impossible to actually make use of that selector at all!)
Obviously that doesn’t tell you what’s still broken, and what’s unreported but causing problems 
but it at least gives a concrete flavour of where the problems have been (and continue to be).
In a beginng point of view I whould use a framework permiting me to make my owns PDU and don’t bother with the sucky Java network API (old NIO is too slow and NIO is buggy & documentation less)
Try the MINA framework, it’s quite easy to use and got good performance and maintenance : http://directory.apache.org/subprojects/network/getting_started.html
Can you quantify this statement?. Ive write a LOT of network code and never noticed any significant API induced latency.
By way of annecdote, the prototype SGS server used java.net.* to talk to a remtoe TimesTen database and, inclduing databse lookup and de-serialization,. mytotal copst to retrieve a single serialized Java obejct was in the low tenths-of-milliseconds.
Docs and exampels are here.
http://java.sun.com/j2se/1.4.2/docs/guide/nio/
http://java.sun.com/j2se/1.4.2/docs/guide/nio/examples
I’ve written a fair bit of NIO code so far and had no bug problems. Doesn’t mean they don’t exist but Ive never seen them and would love to see an actual list.
NIO is not EASY to use. Among other thnsg you need to take seriously the warnings that the selector mechanism is not thread safe. But with some work on my part, its worked fine for me to date.
For small numbers of conenctions though its definitely more work then its worth, use java.net.*
If you are doing large number of conenctions, and there is a library that “tames” NIO from your perspective and makes it easier to use while not costing you costs you cant afford to pay, then by all means use it. IOd strongly cuatio n against any luibrary with its own native layer (DLL on windows, .so on LInux) as you will throw your portability out the window in using such,.
[quote=“Jeff,post:11,topic:24050”]
No they aren’t I get “Page Not Found” for that examples link.
This is a good starting point for NIO docs http://java.sun.com/j2se/1.4/nio/index.html
(This main link above, without the ‘/examples’ also works.)
[quote=“swpalmer,post:12,topic:24050”]
Typo, try this 
Firstly, I think the OP was decrying the lack of manuals, user-guides, general documentation. You pointed to an API difference. There is a huge world of difference between the two. All the fuss by hundreds (probably thousands) of people about “no NIO docs” is not that we don’t know where the API reference is, but that the rest of the docs, the most important parts (according to some; I sit on the fence; their point being that the method meanings can be inferred from their names, but that the user guide can’t be inferred except by painful trial and error), are missing.
Those examples you point to IMHO aren’t even worth the electrons it takes to download them ;). They are the famous examples that have spawned hundreds of forums threads (google finds many of them) about things like “I dont’ understand - why is it that none of this code waits for WRITE readiness?” and the long rambling uncertainty and FUD spread from that silly “clever trick” someone did when writing the example and didn’t document. That’s just one example of what’s hopelessly wrong with those examples (maybe this has been fixed for 1.5.0_04, but I doubt it, IIRC checking 1.5.0_0 and these examples were still next to useless, apart from the fact they did some synchronization. Wow). In summary: they are toy examples that don’t even cover the merhod’s used in real-world situations, let alone try to be realistic, and the contain several dirty hacks and shortcuts that should never be in such example code (and are not explained or justified in comments).
Maybe it’s just me. But Sun’s forums (the main java ones, not these) and google suggest otherwise…
MINA use nio, no native DLL and it’s licencied under ASL v2 terms
Me three :). There’s also very poor standardization in x-platform standards in asynch libraries in C and C++ - there isn’t a native equivalent of NIO, so you end up having difficulty finding libs that work x-platform, and a lot of pain if you try and DIY in C - you have to rewrite from scratch for each native platform