I am currently evaluating 3rd party network solutions. The intended use is for action like games such as FPS and Rally etc. Those that comes to mind are.
[] Netty2
[] QuickServer
Any other API that I should look into ?
Somebody with experinence of these ?
// Tomas
c.f the other thread re Netty.
As for quickserver, well…the fact that they “are thinking about” using NIO sometime in the future pretty much says it all really - useless. If it doesn’t use NIO, I wouldn’t trust the authors: you simply don’t ignore NIO if you’re doing non-trivial networking.
Networking in java is pretty simple, so it’s not like the C/C++ world where you desperately need a complex layer to do lots of work for you, just to get started. In java, you only want something if it’s going to do something extra, beyond the standard stuff, for instance implement a TCP clone using UDP, or have some clever engine architecture.
There’s not much in java that does these things whilst simultaneously being marketed as a general purpose networking layer; most are either crap and do bugger all, or else they do loads of stuff but are marketed at rich customers (e.g. the MMOG middleware companies). Or…they do a very small subset of things, which may or may not be enough for your use-cases.
If you’ve got a list of requirements, I can probably conjure up some slighty odd java networking layers that might do (I’ve encountered a lot of niche solutions in the last few years whilst looking at game networking layers).
[quote] As for quickserver, well…the fact that they “are thinking about” using NIO sometime in the future pretty much says it all really - useless. If it doesn’t use NIO, I wouldn’t trust the authors: you simply don’t ignore NIO if you’re doing non-trivial networking.
[/quote]
They don’t use NIO then its just to remove them of the list.
[quote] Networking in java is pretty simple, so it’s not like the C/C++ world where you desperately need a complex layer to do lots of work for you, just to get started.
[/quote]
True, although it is time consuming even to do simple things. What I am looking for is an API or engine that can be used in teaching and rapid prototyping of fairly simple apps and games.
[quote] If you’ve got a list of requirements, I can probably conjure up some slighty odd java networking layers that might do (I’ve encountered a lot of niche solutions in the last few years whilst looking at game networking layers).
[/quote]
The user group are skilled developers, students or graduate students on time constraint. The application that is being developed is a application, prototype or an assignment. The area of use is some kind of “virtual reality” be it a game or somtehing else. The developer challange of the application is not in the network layer but rather in algorithms, design or HCI.
It should have low entry bariers. With a few lines of code you should be able to have a couple of clients that can interact with each other.
Mange basic things such as connection, time-out, ping etc,
It should be efficient since real time beahviours are important.
Number of connected clients can vary, but roughly in the span of 3-100 users.
Well documented and stable.
// Tomas
[quote]The user group are skilled developers, students or graduate students on time constraint. The application that is being developed is a application, prototype or an assignment.
[/quote]
Bah, regular Java 1.3 networking was easy enough when we had a uni assignment that needed it. I’d wager that only about 5% of our bugs were due to low-level networking issues, the majority being (game) logic bugs (and learning to hate multi-threaded programming). 
Probably much easier just to provide a couple of simple example pieces of code (I seem to remember ours grew out of a telnet echo example) and leave it at that. And I’m sure they’d rather have some experience with an actual API rather than some obscure 3rd party stuff.
You are missing the point. The user group I am talking about often know java networking (except for the student category perhaps). The issue is not the networking like reading or writing, but the small little things that you have to do to make it work. Pooling threads and NIO buffers, manage connected client list etc. These things might not even be hard to do but can be time consuming. Let me explain:
Say that you are working on a small VR application and you have a project duration of 10 weeks. Then if you just could save 2 weeks by using a fairly simple API that manges your connection, have a working server and the only thing that you need to wory about is the logic. Then you are a happy camper thus by using a external API you saved 20% of the development time. Your boss/prof/lecturer would also be happier since you most likley ended up with better and more robust prototype with less errors.
[quote]You are missing the point. … The issue is not the networking like reading or writing, but the small little things that you have to do to make it work. …These things might not even be hard to do but can be time consuming. Let me explain:
…since you most likley ended up with better and more robust prototype with less errors.
[/quote]
In practice, no - the one thing you will NOT have is “better” or “more robust” code - it will tend to be worse, both lower performance and much harder to upgrade and add extra features too. Robustness will tend to be poor too because most tiny libraries like this tend to be very scantily programmed - they’re hacked together to do a job, not carefully designed.
(this is going on the examples I know of of things that fit your criteria)
Basically, it sounds as though the ones you mentioned are a good fit for you, but you do need to realise that the big loss you are taking (and, also, this is the reason why I don’t recommend using them in general) is poor performance and maintainability. If I were in your position, I’d be more interested in improving these two things, even if it meant increasing the API complexity a great deal, and increasing the learning costs (although this isn’t automatically going to happen - you can have your cake and eat it, although you probably have to pay for it if you want the vbest of all worlds).
Isn’t ‘skilled’ and ‘student’ mutually exclusive? ;D
(excuse me, just kidding)
Maybe the HeadQuarter (part of DRTS) system is worth a look?
[quote] Isn’t ‘skilled’ and ‘student’ mutually exclusive
[/quote]
That was why I used punctation in the sentence 
“…skilled developers, students or graduate students…”
I’ll check HeadQuarter, thanks.
No, no and no. Middleware is not evil, bad middleware is. Although even 6 month “hacked API’s” by developer with real newtwork experience have a tendency to be better designed and implemented than a quick 2 week hack by somebody that know networking but haven’t realy worked with it professinaly or dosen’t care.
Easy to use does not imply poor performance and maintainability, lousy design and implementation does. But then again then it isn’t a competent middleware.
[quote]If I were in your position, I’d be more interested in improving these two things, even if it meant increasing the API complexity a great deal, and increasing the learning costs.
[/quote]
That is not an option since it misses my target audience. They are not intresseted in networking, to them networking is necessary but not important.
[quote] although this isn’t automatically going to happen - you can have your cake and eat it, although you probably have to pay for it if you want the vbest of all worlds
[/quote]
I’m more that happy to pay for good middleware, if it solves my problems and lowers my development cost. Although it is my customers that pay and it is their cost that is lowered.
My point was that stuff aimed at the scope of your problems tends to be poor. The problems are far too simple to interest anyone who’s heavily into this, and networking is too easy in java for it to be commercially viable for companies to sell simple networking layers - they’re not adding enough value (hence the ref of C, where a “simple” networking layer involves a heck of a lot more work than the equivalent in java, mainly due to lack of standardized cross-platform fully working free networking libs). That’s not to say they couldn’t sell it, at a profit, but the number of sales combined with low profit margin mean it’s not really worth bothering.
IMHO that’s not true: anyone can make a custom NIO networking solution for any simple problem quickly and easily, and it’s not going to be inferior to a general-purpose one put together by someone else unless the someone else is investing a vast amount of time and money into making a really good general-purpose API. c.f. the problems of Netty - it tries to make a generic protocol handler, but fails miserably because protocols are often fiendishly complex, bursting through 2 or sometimes 3 or 4 of the OSI layers, and that means that making generic handlers is a real bitch. Netty’s generic handler is WORSE than something most people would put together themselves, in ignorance, first time they try to use NIO assuming they had any non-trivial protocl (and, let’s face it, most useful protocols are non-trivial). Netty forces you into a narrow tunnel which you can’t get out of without dumping Netty, which AFAICS discards all the advantage you were getting in the first place.
Maybe I’ve misjudged the profitability here; I’d assumed far too few people would pay enough to make it commercially viable to produce small, simple network layers in java. Maybe it wasn’t, but is now. Maybe I’m just totally ignorant of your market (and others?). But none of the purchasable java networking layers I’ve seen are worth any money; all the good work (As previously noted) has gone into the monolithic things which just happen to include a proprietary networking layer too.
I haven’t a clue about nettys abilities or not, I don’t even know if it is easy to use or not since I haven’t tried it yet I just popped into mind since I have heard other that are happy about it, although it looks like it has hit dead end since what I’ve heard trustin isn’t longer commited to maintaning the library.
So if we focus on the issue, what I am looking for is an API that saves you coding and debugging time and allows you to implement fairly simple things from a network aspect.
It’s great if it can handle very complex things aslong it doesn’t do it on the expence of easy use.
BTW What is limiting Nettys abilities, that you couldn’t extend by yourself, from what I have seen it just doing simple message passing.
[quote]BTW What is limiting Nettys abilities, that you couldn’t extend by yourself, from what I have seen it just doing simple message passing.
[/quote]
As I said, all the problems with protocols that are not trivial enough to be simple message passing. For instance, HTTP requires that all communication be FIFO, and maintain an in-transit queue of requests and responses. This imposes considerable extra requirements on any multithreaded back-end, and you need to use techniques from non-clocked logic, like readiness notification, completion events, or similar.
Then again, most gaming protocols are “anti-FIFO”, they have a non-deterministic ordering - it’s a requirement that each response be processed and returned as fast as possible, which often means the ordering will scramble. Just the FIFO-queue maintenance from an HTTP-compatible networking layer would add unwanted and perhaps unacceptable overhead.
…and there are plenty of others. Tunnelling, for instance, can throw up several thorny issues which require wide-ranging support in the network layer logic, and yet it is used all over the place in networking, from stream-alteration (compression, encryption) to transparently simulating protocols you don’t understand and can’t interpret, but which you need to carry.
I made a solution for these problems for the GrexEngine (although I don’t recommend doing this from scratch; it’s a lot of effort to get right 
even though it’s not much code), that basically comes down to a server that is constructed like lego, using lots of little pluggable modules that each handle different parts of the processing. Certain combinations (like the collection of modules that go together to perform FIFO queuing as requird by HTTP) are frequently needed and can be stored as pre-built large blocks; some modules (like the ones dealing with UDP packet handling) are nearly always combined in radically different ways, so there’s no large-blocks that you can usefully build from them; you may just have to manually assemble the UDP component anew each time you create a server for a new protocol. We briefly considered licensing this (the pluggable mini-modules that you assemble to make full protocol servers) separately but didn’t think there was any demand, although now I’m wondering whether it’s worth offering it and seeing if we get any takers. We never looked into this too deeply, so I don’t have any idea how much it would cost to package it up as a separate bundle.
FIY, there is starting from now soon “JNAG” (http://jnag.dev.java.net).
For now, there is just a prototype, so I guess it won’t fit your immediat needs.
Come back in 1 or 2 months, you may be interested by it.
Vincent
nety is prolly fine (except you are like blah³ and like to implement evil protocol like http 1.1+ for a simple game :P) it’s not buggy, PRETTY SIMPLE (the killer argument for me) and documented. It’s really perfect for prototypes who need more than RMI. BTW it’s no more developped, but it’s in maintenace mode (they only fix bugs) since the dev moved to a new project (Apache Seda implementation). For me it’s not much a problem I don’t really see what you need to add as feature in such a simple tool.