Kidneybean,
Well, you're probably right that eventually the JGN api should also handle TCP if it is desired by developers using it. As for now the API offers guaranteed delivery to those who want it and speed for those who don't. The most interesting aspect of this to me is if large packets via UDP are really slower than TCP. If so, that makes a very good reason to offer TCP. My goal in this release is to offer a stable API that I can utilize to write my games…currently it fulfills all the requirements I have as well as any that I currently know of (except for ordered messages, which I had considered implementing if someone needed it). After other people have seen its benefits I just assumed there would be others more interested in this than I am that would be willing to add to the project.
darkfrog
Its practically the same architecture pattern under NIO, still need to connect … It will just bolt on.
? are you doing UDP under NIO, is worth it.
? are you handling several messages at once under UDP - if part of one is received then another is sent before the first has completed.
Multicast is under UDP too. It really is the way to go super efficiency of the right messages.
Sounds like you know a few things I do not. :-p If you'd like to check out the project and make some modifications to it I'd be happy to take a look at them and if they are better all around I'll check them back in and use them…or even better, become a developer on the project and do it yourself. :-p
darkfrog
Alright guys, at long last…I’ll let you be the judge if it was worth the wait, but the first version of Roll-A-Rama is out for people to try out, so grab a friend and check it out:
http://www.captiveimagination.com/webstart/rollarama.jnlp
I believe it currently requires JDK 1.5 to run, but I haven’t decided if that requirement will stick around yet.
This is using my physics networking API and although the game lacks a LOT right now, it should be a good introductory technology demo. Your thoughts and criticism are appreciated, and I will be spending some time the rest of this week adding features to the game so it’s more than just a tech demo. :o
darkfrog
Let me make a quick side-note here. This is running off my DSL connection at home, so no complaints about network speed. :-p
darkfrog
It would be nice if You could provide a download somewhere so i can take it home on memstick (only have 56k conn at home)
winkman said:
It would be nice if You could provide a download somewhere so i can take it home on memstick (only have 56k conn at home)
Well, as it's a network game that connects to darkfrogs server, you won't have much fun with a download, either.
@darkfrog: I get a "Connecting to server..." only
Likewise ???
Connecting to server :(,
If you want to test - arrange a time when we can all schedule to get on
Well, You certainly have a point here 
, but i hoped for the sources to take a look at, at least.
I think having a dedicated response packet to UDP would remove the usefulness of UDP. You may as well use TCP. The only circumstances when UDP should incorporate a return verification is as part of a response. For example, the client can request a piece of info from the server using UDP because that'll be verified implicitly by the fact that you're waiting for a response. Client asks for a value x, if it doesn't recieve a message saying what x is in a certain length of time, the packet dropped.
I'm not sure if TCP would be more efficient or reliable, it all depends on how the API works and what the game is doing with it. I'm still inclined to use TCP because it's designed for reliability - data is guaranteed to be recieved.
Sorry about that guys…I just came in to check on the server and it had shut itself down with a NullPointerException. I fixed the problem and restarted it. Give it a try now, hopefully everything will work correctly.
Thanks,
darkfrog
Nypher
look at the headers of the UDP vs TCP headers
UDP is much lighter, and although you have to put youre own padding around UDP packets which are in TCP, such as message part, total message length, time…, you can at least use these purposefully.
the key is to cut down on bandwidth
kidneybean said:
the key is to cut down on bandwidth
And probably even more important: cut down on latency! That's why most games use UDP.
kidneybean said:
Nypher
look at the headers of the UDP vs TCP headers
UDP is much lighter, and although you have to put youre own padding around UDP packets which are in TCP, such as message part, total message length, time...., you can at least use these purposefully.
the key is to cut down on bandwidth
Yeah, that's what I'm saying. Is using a reply packet less bandwidth intensive than using TCP?
Good point for non fire and forget messages.
Anything transactional or critical, i would use tcp/ip for.
I'm still debating this question myself. You guys raise a very good point. There is a lot of things to have to support with CertifiedMessages going through UDP instead of TCP such as resendDelay, resendTimes (I need to add this feature…as of now it just keeps on sending forever - which is obviously a bug, particularly if the connection was lost), management of of resending, and if necessary ordering of messages. This would all be already implemented using TCP as well as connection lost. Currently I have good support for lost connections as the client is responsible for sending a message back to the server telling it that it's going to disconnect and if for whatever reason a connection is lost and that message doesn't make it (which it always should unless there's a crash since it's a CertifiedMessage), the server sets a client timeout that will automatically disconnect a client if they haven't been heard from within the timeout period.
The work seems a little redundant since TCP already support all of this for me, but at the same time I am very curious if the cost in bandwidth is greater for using it. I think what I'll do is provide a ControlledMessage or TCPMessage that people can extend that would utilize TCP instead of UDP. This way it can be a decision by the implementing developers to decide what is best for their circumstances. Thoughts?
darkfrog
Aye, a simple int within the message constructor or message definition to specify wether its ok for udp or tcp or multicast …
BTW, I was playing around with Multicast a bit and find it very interesting. I think there are some definite advantages to having that available in the JGN API.
darkfrog
the worst thing about tcp is the lag-spikes…since tcp will allways wait for package to get through, a delayed package will kill all communication until it gets through…lags of up to 30 seconds can still occur with tcp…that's not the case with udp…just send multiple packages, or resend if no answer…udp packages will take different routes and some will get there faster…with this you can also skip old messages…
multicasting is not recommended(yet) since lots of routers and other things on the net don't handle it correctly…only useful for LAN…
Not to sound like a broken record here, but anyone interested in helping with this project? :-p
darkfrog