Im going to do a project for school in which i'll do some research on various client synchronisation / prediction techniques. Since i'll (try) to implement various demo's demonstrating the effect using different network models (client/server, peer to peer) and protocols (tcp/ip & udp, i'm searching for a generic library that saves me from developing the network communication part.

MINA is cool! It uses NIO as underlaying protocol. Seems pretty fast, though I didn'tdo a speed test.

I also use MINA in some little project. It's an interesting library if you would like to build a custom protocol layer over TCP/IP.Actually I can say it have some limits due to the fact that isn't so stable; documentations isn't clear (sometimes is simply too old) and there isn't a "state framework" that help to build a statefull client/server interaction (not a problem if you don't need it... and nothing soo difficult to write).Do not seems to have speed issue (of course, I use it only in little environments).I think is a good idea to take a look about it.

Also, the ODENetworking project has been abandoned in favor of jME-Physics Networking (which is available for download at the JGN project as well). I originally created ODENetworking to create an abstract physics networking API for use with any games that utilize ODE but since I develop exclusively on jME and jME-Physics has some proprietary changes to ODE internally it wasn't possible to do this and remain compatability with jME-Physics. I have been seeking someone to take over the ODENetworking project and port jME-Physics Networking to ODENetworking, it technically shouldn't take too much effort, I'm just not willing to take the time to do it.

That to me seems a few too many things to keep track of. Further, the ChatClient is part of the project itself, so assuming this was a custom implementation where they were creating this from scratch it would also need something similar to the ChatClient implementation I'm assuming:

Here's an example using JGN for the client aspect assuming there is a server to respond (I make the same assumption for yours):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

NetworkingClientclient = newNetworkingClient();if (client.connectAndWait(address, port)) {Threadt = newThread(client); // This is simply for convenience, in most cases you would call client.update() in your update method instead - it handles sending Noop to the server to let it know its still connectedt.start();client.addMessageListener(newMessageListener()) {publicvoidmessageReceived(Messagemessage) {}

This chat implementation can maintain any number of chat channels. e,g. 1 working C/S sending messages to all and another P2P. This needs some setup.

The chat client buffers messages for most client won't be able to deal with asynchronously arriving chat messages.

chat message senders can be anonymous, a string or an Identity (preferred, who says there has to be a name?). I'd normally assume that a players name is stored as a shared property in the Property subsystem and does not need to be transmitted with every single message.

Networking or network message formats don't shine thru to the application. In fact, a HQ application doesn't really know wether it works across JVM boundaries or not.

Until now, there is no message that may get lost and order is important (or at leas useful)..

HQ heads for minimal network traffic which almost always requires reliability. This issues are discussed in other threads I think. Implementations using other protocols are possible but currently not on the @todo list.

UDP is significantly faster than TCP and much lighter. I agree, the disadvantage to it is not having guaranteed delivery and not guaranteed order. However, I have resolved these problems with CertifiedMessage (guaranteed delivery over UDP), and OrderedMessage (which extends CertifiedMessage and also guarantees the order of delivery).

As for your statement of my creation of ChatMessage being much longer than yours, that is just not true. You have one line of code there, but under the hood you do this:

If I were to count (which I have been known to do on occasion - hehe) I think I come up with the same number. Sure, I could create a little static method in ChatMessage sendMessage(String sender, String text) and that would offer the same benefit. I wrote it this way to show how much more simplistic utilizing JGN in the same example is.

I'm not looking for competition though, I'm looking for cooperation. My hope is that you'll see the advantages of JGN and hopefully want to help out. I have no desire to maintain the project all by myself and the goal is to provide a standard that the community can rely on.

I just didn't dare to create a reliability protocol on my own. I was afraid of having to send too many UDP packets forth and back destroying the UDP advantage quickly while not being able to profit from vJ compression.

So HQ could operate with CertifiedMessage. But as long as TCP performs well esp. on thin-line scenarios....

Well, I created JGN and PhysicsNetworking (an extension of JGN for physics synchronization in games) primarily focused towards first-person shooter style games where speed is key.

I have been considering adding the ability in JGN to use TCP as well, I just haven't had a need since the extensions I've written on UDP seem to fill all of my gaps. The real place where UDP shines is when you're sending messages that are real-time messages like, "this player is in this location with this rotation". I also introduced something called a PerishableMessage that is not guaranteed delivery. In fact, if it doesn't get to its destination in a timely manner it gets rejected entirely. The whole send and forget ideology works extremely well with UDP. This is particularly useful for my PhysicsNetworking that sends PhysicsMessages that simply get sent 10 times per second and if one gets lost it doesn't matter because there's another one right behind it more correct anyway.

I did quite a bit of research into this when I first started looking at designing an API and the reason I decided to write my own was because all the fast-paced games seem to use UDP and nearly every API in Java I've found uses TCP.

The discussion slips into the UPDvsTCP direction again so I will not continue that after this final comment on HQ's philosophy here.

HQ won't send messages that could be dropped. The real place where TCP/reliability shines is when you're sending messages that are real-time messages like "this player is in this location with this rotation". HQ uses dead-reckoning to only send the bare minimal amount of data. For dead-reckoning, you compare the actual local position with an estimated remote position. In order to be able to do a valid estimation, guaranteed, timestamped message delivery is mandatory. This way, when moving in a predictable way, NOTHING is send over the line which in all situations is better than any however-optimized message format. Sending 10xsec brutally always was a no-go for HQ for it overcommits any line introducing higher packetloss and additional latency. You just cannot serve even a handfull of objects (HQ doesn't have a term like 'player') on an ISDN line with an update rate of 10/sec. In FlyingGuns e.g., 1-2 updates/sec occur although the dead-reckoning treshholds are much tighter than necessary for a feasable gameplay.

Message compression does not make much sense for HQ, for currently all message formats are densely packed and (in particular) not self-descriptive thereby avoiding any overhead. The clean notion of Identity prohibits redundency. vJ just drastically reduces TCP overhead (from 40 to 3 bytes or so) whereas it cannot do anything about UDP overhead (20bytes). Everything in HQ is heads for *not* sending data on high-level in favor of sending it effectively on low-level.

Ok now, for me this is the end of TCPvsUDP before blah³/persson kills us here for being off topic.

My original concern was to point to HQ as an information backbone that is able to deal with shared states over a network. (BTW, HQ does not NEED to work over a network, it can be used locally as well. When FlyingGuns is configured to hold the 'server' within one client, this client and server don't even use loopback to communicate saving a lot of overhead again). HQ is totally agnostic of running C/S or P2P or both. Besides it's basic infrastructure, it offers proven out-of-the-box services like clock sync and some specific shared states. The basic design allows for many improvements (high-level protocols, range-based services, automatic routing, object ownership, access rights....) that pend to be implemented.

Then I'd say I get a last rebut against your statements. The packet size of TCP is much larger than that of a UDP message. Further, your premise of "HQ won't send messages that could be dropped" in so much as TCP messages can be dropped as well, it's just the protocol handles the resending. In UDP JGN handles that instead of the protocol. It's probably not as efficient or as fast, but it works.

In JGN I can reliably send more than 2,000 messages per second, so 10/second per player isn't bad for me. If you're talking about a first-person shooter you just have to update that frequently or you are no in sync with the server reliably. Look at games like Quake, Unreal, Battlefield 2, etc. and I believe you'll find updates at least that frequently. One of the features on its way is prioritized update messages that send updates to clients less frequently depending on distance from the object. That is a feature explicitly part of the PhysicsNetworking.

Something I haven't yet added is clock sync, but it shouldn't be too difficult to add. I would be interested in how you went about implementing this?

No grudge held on my part. My API will stand or fall based on its merit. I would say you'd be hard-pressed to find many first-person shooter games that use TCP for their primary communication though. :-p

I can always appreciate some good competition, but my goal in creating this API was to get collaboration so there isn't 50 mediocre networking libraries but just one really awesome one.

From all the research I've done UDP is the undisputed champion for game development. Hey, I'd be interested in a stress-test challenge. Would that forever resolve the UDP dispute? :-p

Herkules, I think your API has some really good ideas in it. I would say the biggest drawback to using it though is the learning curve it takes to understand all of those aspects. It seems pretty flexible though, which is great, it's just creating a custom message seems to take a lot of code to make happen. If you could resolve that I would see a lot more usefulness to your API.

Something I haven't yet added is clock sync, but it shouldn't be too difficult to add. I would be interested in how you went about implementing this?

Can be complicated, but in HQ its done very simple (hence not exact). It measures the time a message needs to go to the timeserver and back and the answer contains the timestamp from the server when it sent the answer. When the client receives the answer from the server, it assumes current time now is servertimestamp + roundtrip/2 and adjust the clients clock accordingly.

The key in fact is not that protocol but having an adjustable clock (package de.hardcode.time)

I was planning on implementing a similar concept but have a time sync and then create a conversion value for when messages are sent to that remote machine. So it would say, "the time is +500 ms on the remote machine, so take my current timestamp and add 500 milliseconds to it before sending".

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