Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Network engines  (Read 2077 times)
0 Members and 1 Guest are viewing this topic.
Offline Tomas

Junior Member




Agency9


« Posted 2005-01-02 12:32:05 »

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

CTO Agency9
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2005-01-02 16:44:31 »

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).

malloc will be first against the wall when the revolution comes...
Offline Tomas

Junior Member




Agency9


« Reply #2 - Posted 2005-01-02 20:29:37 »

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.  


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.


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).


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

CTO Agency9
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #3 - Posted 2005-01-02 20:56:28 »

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.

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). Smiley

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Tomas

Junior Member




Agency9


« Reply #4 - Posted 2005-01-02 22:10:15 »

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.





CTO Agency9
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2005-01-03 02:49:58 »

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.


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).

malloc will be first against the wall when the revolution comes...
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #6 - Posted 2005-01-03 07:25:43 »

Quote

The user group are skilled developers, students or graduate students.


Isn't 'skilled' and 'student' mutually exclusive? Grin
(excuse me, just kidding)

Quote

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.


Maybe the HeadQuarter (part of DRTS) system is worth a look?



HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Tomas

Junior Member




Agency9


« Reply #7 - Posted 2005-01-03 09:32:41 »

Quote
 Isn't 'skilled' and 'student' mutually exclusive


That was why I used punctation in the sentence  Wink
"...skilled developers, students or graduate students..."

I'll check HeadQuarter, thanks.

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.  


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.

Quote

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.


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.


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


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.


CTO Agency9
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2005-01-03 12:01:54 »

Quote


No, no and no.  Middleware is not evil, bad middleware is.


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.

Quote

 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.


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.

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.
...
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.


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 Smiley (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.

malloc will be first against the wall when the revolution comes...
Offline Tomas

Junior Member




Agency9


« Reply #9 - Posted 2005-01-03 12:37:47 »

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 Wink 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.

CTO Agency9
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2005-01-03 13:26:41 »

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.


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 Sad 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.

malloc will be first against the wall when the revolution comes...
Offline karmaGfa

Junior Member




Miaow


« Reply #11 - Posted 2005-01-08 17:29:01 »

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

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline vrm

Junior Member




where I should sign ?


« Reply #12 - Posted 2005-01-09 09:56:45 »

nety is prolly fine (except you are like blah³ and like to implement evil protocol  like http 1.1+ for a simple game Tongue) 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.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (35 views)
2014-07-24 01:59:36

Riven (36 views)
2014-07-23 21:16:32

Riven (24 views)
2014-07-23 21:07:15

Riven (26 views)
2014-07-23 20:56:16

ctomni231 (56 views)
2014-07-18 06:55:21

Zero Volt (48 views)
2014-07-17 23:47:54

danieldean (39 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!