Is NIO worth it?

Networking & Multiplayer
#1

Last time I tried some NIO networking ('bout over a year ago) I had a hell of a difficult time getting the code to work reliably, and the whole API seemed more than a tad fragile (poor docs, odd behaviour, much weirdness).

Given that I’m now looking at some networking code again, is it worth bothering with NIO? Regular threaded network code with sockets is (IMHO) dead easy in comparison and I never had any of the weirdness. And with my 'net access being sporadic at best hunting down tutorials and docs on NIO is going to be a pain.

I only really want a basic message passing system, with 2-8 players. Methinks it would be much easier to ignore it and possibly upgrade later…

#2

For 2-8 players, I’d probably ignore it as well. Most OSes these days have fairly good threading models, so the difference shouldn’t be too substantial. If you want to have 15+ concurrent clients, then I’d say it’s probably time to look into NIO. Either that or buy a Solaris machine for your server. :slight_smile: (Solaris has one of the best threading libraries, period, and can handle thousands of threads without even blinking an eye.)

#3

The real benefit of NIO is when you get heavy load, like hell of a lot small packages or fewer packages but big once. … and you probably end up with both pretty soon :wink:

#4

IMHO the “real benefit” is that its considerably easier to program, in terms of program design, once you’re comfortable with it.

Although I tried writing some NIO servers fast not so long ago, and realised that Sun hasn’t provided enough high-level constructs. One of the things I plan to release with my book is some open-source convenience constructs to make it easier to get new NIO servers up and running quickly.

Although I’m not sure how yet, without just stealing stuff from the GE ;).

#5

A package within HeadQuarter called ‘ObjectBus’ also is a convenience layer above NIO. There is also an tutorial written by a user (can check it into CVS this evening)

#6

I promise I shall try HQ next time I need a quick-to-write NIO server ;D. It just doesn’t usually occur to me in the minutes I have avaliable to decide how to do it.

#7

Oh no, please don’t! Your experience level is far above HQ! YOU should improve it - not use it
:-[

#8

/me sees Herkules running for complete the Javadoc comments before Blah² start inspecting his code ;D

#9

lol - exactly!

Its not the JavaDoc. Its more exception handling, thread treatment, notifications, server data distribution schemes…

I’m sure bla³ will encounter excatly the issues of NIO with HeadQuarter as well. And me looking studid. :-/

Man, FlyingGuns is a too big project for a single person (esp. such a lazy family father like myself). I just cannot manage to polish all APIs. My last action concerned the build system, now heading for 3D a bit again.

Then physics, then architecture, then databases, then gameplay, then networking again…

VOLUNTEERS NEEDED!!!

#10

[quote]Oh no, please don’t! Your experience level is far above HQ! YOU should improve it - not use it
:-[
[/quote]
Yeah, but the issue is that a full-fat “efficient, powerful, clever” NIO system is not always the right tool, and sometimes a very wrong tool, for the job at hand. If I could, I would use GE code for every piece of networking I ever did ever again, but GE isn’t free licensed and drags with it a whole architecture/framework, so that’s not tenable :).

And some parts of it are patented, so I can’t even legally re-implement them outside of Grex. LOL.

EDIT: which is not to say that HQ is inefficient, but more that the GE stuff aims to be excellent in every dimension at once, whereas HQ is narrower. In theory, given what HQ does, it ought to do it well without much difficulty?