Okay guys, I've finished the first demo, but there are some serious bugs in the system. I met my goal of finishing it by the end of the weekend, but unfortunately the finished state kind of sucked. :-p I've learned a lot in this iteration and I think I know how to solve all the problems I'm currently seeing except one. The scariest problem I'm currently having is that after running for a certain period of time the VM just completely pauses and never recovers. It's not throwing an error or anything. I end up having to end the task (anyone know anything that would cause a VM hang?). I'm starting a re-write of the API for the…well…I don't know how many times this will be, but this will hopefully be the last time for quite a while. :o
Something I would like some insight into is just how often players positions are typically updated in an FPS game? I've been doing ten times per second but I'm just curious on what is typical.
Sorry for the continued delay, I'm as ready to be done with this as anyone is to see it done. :-p
darkfrog
darkfrog said:
anyone know anything that would cause a VM hang?
Sure, a simple infinite loop in the jME update thread should suite ;)
Or a deadlock with any other thread :P
Or - most nasty - a mutex that is acquired too long! This causes many JDK versions to hang up completely -> synchronized blocks should be left in ms time scale!
Okay, I’ve gone back and re-thought the whole API the past couple days and have completely re-written JavaGameNetworking and jME-Physics Networking. JavaGameNetworking is finished, tested, checked-in, and has sample code available for it (http://javagamenetworking.dev.java.net). The previous version was functional but could be a pain to use. I completely re-structured the API and now it is extremely simple to understand and use.
As for the physics networking API I am testing it now and writing some examples for it. It’s not nearly as easy to test as the JGN project was and the project itself is actually quite a bit smaller since it is relying on the new JGN api. I know I promised this last weekend, but given the bugs I was dealing with I’ve been spending a lot of time on this and will hopefully have Roll-A-Rama available to try out by this weekend.
darkfrog
This is very good news. Seems you have been working very hard on this.
Can't wait to see it in action. I'm sure it will ROCK…
Good luck with this
The JavaGameNetworking API uses UDP and provides two objects that can be extended: Message and CertifiedMessage. Either can be extended with getter/setters standard to a bean and those values will be transferred over to the receiving machine and re-applied. Message is standard UDP, the message will get sent but you have no guarantee that it will be received on the other end. CertifiedMessage on the other hand sends and then waits for a Receipt letting it know it was successfully received. If it is not received in a certain amount of time (abstract long getReceiptTimeout(), which is part of CertifiedMessage) it will send the same message again.
All these benefits are provided to the physics networking API since it's just an extension of JGN. Currently it has a few threads that execute on their own but I intend to offer the ability to use NIO in the future so you can do it all in the graphical thread if you want to. Personally I think it still makes sense to keep it in its own threads, but that's just my opinion. ODE has serious problems if you try to update physics information while it's stepping, so I created listeners that queue the messages up and the update method needs to call the update method of the API to apply the physics messages.
darkfrog
Cool thanks for the info.
I sure hope so, but I guess we'll just have to wait and see. 
darkfrog
Is this reliable UDP and does it use threading? Does it require its own loop or does it hook cleanly into JME? I can't download it at work but I was just wondering. 
Getting a chance to play with it. So far so good, but am a little confused about the proper way to get the messageserver to send a message to all it's clients, rather than relaying one from one client to the others.
My best guess was to do it the similar to the way the clients do in your example
BroadcastMessage message = new BroadcastMessage();
message.setMessage("FPS:"+timer.getFrameRate()+" Step:"+interpolation);
JGN.sendMessage(server, message, InetAddress.getLocalHost(), server.getPort());
fails:
java.lang.IllegalArgumentException: Port out of range:-1
as does hard coding in that port number.
java.lang.NullPointerException
at servertest.ServerListener.broadcast(ServerListener.java:49)
because Client is c is null.
What am I missing? Do I need another MessageServer in my server running on it's own port that I use to send messages?
-edit-
Oh, a test for null in ServerListener makes it work fine, but still, is this the correct way to have the server send it's own messages to it;s clients?
Well, the way I designed this was without the requirement of a client/server architecture. I purposefully left that out of JGN in case someone want to do P2P or something even more advanced. The MessageServer is just that, a server that listens for messages. The client and the server need an instantiation of that. When sending a message you must give it the MessageServer of the sending machine so that it can tell the remote machine where to send responses to that message. The best way to deal with multiple clients is to manage their information yourself similar to the way I do in the Chat Test. If you would prefer something built into JGN that would manage that for you I would consider doing that.
The Port out of range problem is a bug actually. I noticed it before and haven't been able to look into it further yet. I reference DatagramSocket's port that it is bound to, but for some reason it always seems to return -1. I'll let you know when that problem is solved. As for the test for null, you would only have to do that if it's not receiving a ConnectMessage first. I'm assuming you just copied the code out of the Chat Test? The ConnectMessage is responsible for instantiating the Client and assigning the remote address and port of the remote machine so it can be looked up when a message is received. The only reason Client should be null is if the client never send a ConnectMessage before broadcasting a message.
darkfrog
UPDATE
Okay guys, I was hoping Roll-A-Rama would be done by now, but alas it is not. I probably could have had it done except I spent that time on a couple tests inside the physics networking API. The first is crates respawning in random places controlled by the server and a client box that jumps to four corners of the screen. Both run at the same time and let you see how closely they are synchronized. The second test is an extension of the CarTest that allows for multiple clients to connect and ram each other with the jeep. If anyone is really ready to start using the API let me know and I'll make it available immediately. At the moment I'm not really sure where to put it. I had originally registered http://odenetworking.dev.java.net project, but it's jME-Physics specific now and doesn't really fit there.
Anyway, the API seems to be working extremely well and haven't had a VM crash yet since the re-write, so this is good news.
darkfrog
This cries for another jmex - package in jme-cvs imho ! - (as does jme-physics)
I don't need it now but would like to take a look at the tests
That's the plan for Roll-A-Rama. To let people have a peek at the technology without having to worry about downloading and configuring anything. I'll try to do a few screenshots of the tests tonight if you'd like to see those. I could put the client and server screens side-by-side to show you how closely in sync they are. The car test is just cool. :) I'll hopefully not be too much longer on getting Roll-A-Rama available for use. It's this whole working for a living thing that keeps getting in my way. :-p
darkfrog
Well, if it's not too long then i'd prefer to wait for the real thing.
… so keep it up
Glad you're working away and this and it's coming along well. Good luck with it. I'm wondering, you mentioned that you have the Message and CertifiedMessage classes. Why not use the standard java classes to deal with UDP and TCP respectively? TCP already guarantees delivery of the message. Is CertifiedMessage using UDP? If so, what advantages does it hold over TCP? Has it been shown to use less bandwidth/cpu time than TCP?
Nyphur,
JavaGameNetworking API deals entirely with UDP underneath, but abstracts it away so all you have to be concerned with is creating beans and sending them and a listener picks them up on the other side. It makes networked games far easier, but without the overhead of any other serialization system I've ever used. The reason that I am not using TCP is primarily because I didn't want to add a requirement of the server/client to have to open more than one port on their machine add any additional complications when working with it. CertifiedMessage is UDP with delivery confirmation. I'm not sure if it would be faster than TCP, but I would suspect it couldn't really be much slower since when the message is received it sends back a receipt that contains a byte and two longs.
darkfrog
UDP packets are much shorter. but with confirmation - you require several.
UDP will make transactions more complex, great for fire and forget messages.
There is a bit of a multicast movement going on - i must catch up on the progress, some servers were offering a guaranteed delivery mechansim for Multicast, you send then the message and they broadcast.
I have built an NIO server for TCP/IP, its pretty good. just use state to track the client. Have built in load balancing and fall over into it to, if you go down that route let me know
Kidneybean,
The way I'm doing it is a single response. Yes, it's slower than messages that don't require guaranteed delivery, but sometimes it's necessary. I provided this feature for things like chat messages, connect messages, etc. that are not necessary real-time needs, but need guaranteed delivery. Most aspects of a game should be written to not care about an unreceived message and in such a case Message should be used.
I've read a bit on multicast, but need to learn a lot more. I'm planning on adding NIO support but haven't gotten there yet. I would be interested in seeing what you have developed but I'm still not really sure if TCP offers much if any advantage to this system. If you could explain further any advantages you see in TCP I would be very interested.
darkfrog
Swings and roundabouts - horses for courses.
TCP - advantages
Guranteed delivery
Guranteed order
Automatically retrieves lost packets
Able to tell if user is actually connected - its a connection
More secure for trapping spoof messages, hacking. Can build on to detect hacks.
TCP - disadvantages
Larger packages -
Is a stream
Chat messages and simple movement is great for UDP. Larger messages - updates on environment or live graphics are bad with UDP as you need all the packets for the required data
I need to check on packet size, but i think its inefficient to send very large packets via UDP
IMHO, you need all if you want the be all and end all engine, you need to classify the message as to what delivery is most suitable. UDP is preferable, but not always suitable
I have a few graphics problems to get over in the next few weeks. Have got a christmas deadline 
, but after that, ill make a simple NIO model. It has a state assigned to each client so it makes it easy to relay messages ( push and pull and receive ).
UDP integration will be very simple
Okay, so I got the CarTest networking demo written last night and seem to have stumbled across a potential problem in my architecture. Something to do with the synchronization of the chassis and wheels from the client to the server is causing the server's ODE environment to kill off the entire physics object, so as soon as I make the car move it waits for just a few seconds and then gets completely removed from the server and doesn't appear anymore. I think it has something to do with positioning on objects that are connected to other objects but I'm going to abandon this for now and focus on Roll-A-Rama so everyone can see this thing in action. I'll revisit this later as this is a very big potential problem for connected physics objects.
darkfrog