DatagramPacket delivery system (UDP in Java)

I want to use UDP for my game networking. The problem is that I need all packets to arrive and I need them in the order they was sent. I started writing my own code that does this, but it’s tedious. Then I got to thinking, “Hey, this is Java and the year’s 2009 - this wheel should already be invented!”. There should already be a ready-to-use “DatagramPacket delivery system” somewhere that I don’t know about.

So, is there any such thing? Like a class that I just give the bytes that should go into a packet and who should get that packet, then it sends that packet and automatically handles flow control, resends (guaranteed delivery) and order-of-delivery.

My hope is high. :slight_smile:

Try JGN. (google a bit)
It does what you ask for, really.

Anyway, at the risk of disappointing you again, I’d advice you to stick with TCP. Even modern MMORPGs like WoW are written in TCP. Very often, you’ll be amazed of what TCP pulls off.

If you’re going with UDP regardless, you’ll find yourself trying to make UDP as reliable as TCP. Lots of people have done that, even big game studios, and in all those years, nobody really pulled it off decently.

Best way to get the best of UDP and TCP in your game, is to use them both, where they fit.

Uh, use TCP?

Why exactly do you think you need to use UDP?

Yes we call it Transmission Control Protocol.

failing there is SCTP but I don’t know how finished http://openjdk.java.net/projects/sctp/ is. No experience with it.

Hi,

There’s JeNet https://jenet.dev.java.net/. This is a java port of enet

Maybe you could use this though the project seems to be abandoned.

+1

UDP => unconnected => packet are sent “like email” and can be received in a different order or can even never been received
TCP => connected => packet are received in the same order they are sent and they are all receved, this is the main reason why TCP is slower than UDP cause if a packet is missing it cause the whole stream to be delayed until the missing packet arrive.

ususally you will use UDP when you dont care to lose one or two packets as in a streaming video/audio and you will use TCP when you want to be sure to receive all packets and in the correct order.

The thread got filled with “use X instead of Y”-replies, who would have guessed it? :slight_smile:

I made a simple network game using TCP before, it was easy to do and turned out very great (100% synced). I was like, “Maaan!” when I figured I would have to change to UDP.

Without further deliberately trying to make this thread into a “UDP Vs TCP/IP”-thread (like http://www.java-gaming.org/index.php/topic,608.0.html) I will tell you my motivation of using UDP in short (you did ask why).

I want to make a action game, and I want to transfer events of every time step from the server to the clients. I update the logic 50 times each second, which means I’ll transmit a DatagramPacket to all connected players 50 times per second. (If that later turns out to be too much I will lower the logic to 40 times per second I guess.)

The size of each packet that is sent will vary depending on the events that happened in the time step. Now, I’m new to this whole networking thing so I’m not sure if my approach is the best one, but I think it is better to send only events to all players and letting them simulate what happens from the events instead of sending the location and rotation of every object in the game. Or is it…? In any way I need to transfer a lot of data each second and they need to arrive on time. From what I’ve read UDP will do its job faster than TCP, unless of course it fails (packet loss). The UDP header is smaller so it will also save some bandwidth.

I have read a lot of text that recommends the use of UDP over TCP for games.

http://staff.cs.utu.fi/~jounsmed/mcg_05/

  • PDF slides, lectures (lots of other interesting stuff there).

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

  • One good reason to send game states instead of events is that you can fire and forget. Keep pushing not-acknowledged data until they get acknowledged is also pretty smart, even if it increases packet size.
  • These guys started with using TCP but realized that they had to change to UDP. They sent a copy of the previous packet along with the last packet, this will remove packet loss problems unless two packets are lost in a row. As soon as a packet arrives out-of-order (and it is not included in the latest packet), resend requests start going out for the missing packets. I liked this solution, even if it doubles the packet sizes.
  • This guy really pushes for UDP use in games, and explains why thoroughly. He does speeches about gaming, and writes his articles well. I recommend reading his “Networking for Game Programmers” series, they are well-written and actually FUN to read (that’s rare). One thing he mentions is that mixing TCP and UDP is not recommended since it appears to be more packet loss for UDP then.

Also not all but most real action games use UDP instead of TCP. There has to be a good reason for that, so might as well try and learn to do UDP right and get into the the “right pool”, so to speak. By using UDP I guess you also get a lot more control over exactly what is happening on the IP protocol.

Aaaanyway, I will check out javagamenetworking (https://javagamenetworking.dev.java.net/) and JeNet (https://jenet.dev.java.net/). I really don’t like how java.net is structured, I think their layout is hard to navigate (I guess the fault might be a bit more with the different project owners, but if java.net had given a proper structure template to begin with not so many project sites would be in the state they are in). JeNet sounds especially interesting, doesn’t seem so “bloated”. Thanks guys. Keep giving me posts if you have em. :slight_smile:

[quote]The thread got filled with “use X instead of Y”-replies, who would have guessed it?

I made a simple network game using TCP before, it was easy to do and turned out very great (100% synced). I was like, “Maaan!” when I figured I would have to change to UDP.

Without further deliberately trying to make this thread into a “UDP Vs TCP/IP”-thread (like http://www.java-gaming.org/index.php/topic,608.0.html) I will tell you my motivation of using UDP in short (you did ask why).
[/quote]
this is not… but you ask to do exactly what a TCP stream do, but ok let’s forget about TCP

[quote] I think it is better to send only events to all players and letting them simulate what happens from the events instead of sending the location and rotation of every object in the game
[/quote]
I dont think it is, and especially if you plan to use UDP, cause with UDP you will only care of the most recent pos of a player, so if an old pos arrive you can simply discard it or use it to better interpolate futur position.

UDP is a perfectly good choice for certain networking models. Take a look at the Book of Hook for a great explanation of how to do it all. You don’t really need anything more than the Java standard library. The game state stuff is up to you.

I’d combine it with a TCP connection as well, to send reliable control information easily, and just leave UDP for the realtime dynamic world updates.

Cas :slight_smile:

What’s good about having UDP doing exactly what TCP does is that you can remove/add fetures if you like. For example if it’s important that all packets arrive, but not important that they arrive in the same order, there is a down side with TCP since you have to wait for lost packets to arrive before receiving the ones that did arrive. I am however strongly thinking about sending the current game states each time step instead of the events that occured in the time step… then I can “fire and forget” the packets. But I still need some sort of way to send some packets with guaranteed delivery, for stuff like chat messages.

I’ve read that article (linked to it in the previous post), it’s good. The down side about using both TCP and UDP is that it will (supposedly, I have of course not made any tests myself) make the UDP packets get lost more often. Also you need to open another port then, right? Or can you have both UDP and TCP traffic in the same port? I don’t want to require the players of my game to open two ports instead of just one (“double the trouble”).

I have tried JeNet now, it was a pain in the neck since it relies to SIX different things which you have to browse around to get from the web yourself. One would think they could at least link to the dependencies on their site. Tried getting “apache-log4j-1.2.15.zip”, it wasn’t even a jar file. I’m not a big fan of using other people’s code unless it’s in a jar file since the project gets… well, bloated.

I really wish there was a simple way to do this but it seems I’ll have to code the ack/resend part myself. :frowning: Feels like I’m coding a tad out of my leauge, it wasn’t that long ago I started coding Java and I’m afraid I’ll code myself into a corner and then get stuck with flawed networking code and many wasted hours.

You asked for UDP + reliable delivery + in order deliver + already written. That defines TCP. How could you possibly not expect to receive that reply? ???

Now I’m all for UDP when used correctly, but you basically seem to have read a bunch of (out of date) articles and the only point you’ve gone away with is that UDP is a magical silver bullet of network code.

If coding up a simple ack/resend over UDP feels like “out of your league” then you definetly be able to produce a better alternative than TCP. TCP may be conceptually simple but under the hood it’s got a lot of flow control and heristics that make it very efficient. If you’re not going to code those yourself you will get worst performance.

The trick to getting good networking performance with UDP is to write your protocol with UDP’s limiations in mind. That often means something like the quake 3 networking model where you’re simply blatting out the latest game state for the contantly updating stuff (object positions/velocities) and a separate TCP stream for essential events (object spawn, player killed, game finished etc.).

From a practical point of view, it’s often much easier to get your game running over TCP to start with and then migrate what unreliable messages you can over to a UDP stream when it’s all working.

Then start using udp as soon as you figure out that you don’t need a certain feature of TCP. Moreover what usually the case is, is that you don’t need any of the features that tcp brings over udp.

If you structure your program like you should, replacing or adding udp-like stuff to it should be easy.

Back when dinosaurs still roamed the earth ppl might had to worry about that kind of thing. And even so who cares you have already indicated that you expect to have plenty of bandwidth. The unreal engine uses both udp and a tcp, so if the problem even existed; if epic can get away with it I’m pretty sure you can.

//edit having actually read the article you where referring to his numbers are very undefined at best.

[quote]UDP is an unreliable protocol. In practice, most packets that are sent will get through, but you’ll usually have around 1-5% packet loss, and occasionally you’ll get periods where no packets get through at all
[/quote]
if I would lose between 1-5% of my udp packages on avg and that it would be considered normal… it’s then time to take someone out back.

[quote]So if you have a 125ms ping, you will be waiting roughly 1/5th of a second for the packet data to be resent at best, and in worst case conditions you could be waiting up to half a second or more (consider what happens if the attempt to resend the packet fails to get through?) Fun times!
[/quote]
5 years or more ago 125 was considered a max number for allowing it to be considered playable, hell I have had better pings to American servers while connecting from Europe. 50-70 was typical 30-50 was good <30 great… etc. I’m not saying it’s not a valid problem, cause it is. But he brings it in a way that is kinda beefed up.

on the actual topic he simply said’s it’s complicated and points to a paper.
…reading the paper. Well actually you should(or at least the introduction), esp in the light of: [quote]I liked this solution, even if it doubles the packet sizes.
[/quote]
As the problem arises when you have a bottleneck along your path. I suppose Mr Jansen sums it up quite nicely: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/#comment-10342

Hmm I almost forgot these days everyone has IM and other stuff running which already have open TCP connections. (and no you typically don’t have control over the whole network stack)

Other ppl raise good points btw too:

[quote]In network protocol design, be careful to optimize for the “normal” case, not the error cases. Think about how often a packet is actually dropped, and whether it is your own fault. Do you want to buy into a lot of protocol design (no matter how much fun that might be) to support the few users that are stuck on a low bandwidth connection?
[/quote]
‘twitch’ games(fast paces fps) aren’t played by soccer mom’s and though I’m not a demographic expert or trend watcher or whoever does that kind of stuff, I still have a strong feeling that isn’t going to change.

Actually just forget what I said and read this reply: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/#comment-10808

[quote=“M2009,post:10,topic:33742”]
Most applications require around 5 ports to be opened and it’s not like complexity increases by the ports. Again, that being said, you can use one portnumber.

I see weight in you comment. (You folks sure like to link to that article btw.) :smiley:

You’re right, and maybe I should have read the comments for his articles too.

You know what guys? I’ll go with TCP after all. I could struggle with UDP for a long time and maybe by the end of the summer I would gotten a working reliable UDP system, but I think I rather want to have a working reliable game by then. If there are any problems with TCP I’m sure its for a good reason, and even if the headers are a little bigger that’s not a problem for tomorrow when the Internet will be faster than ever. Thanks for setting me straight.

It’s best to develop using TCP and then switch to UDP when the evil INTERNETS gets in the way. There’s no reason to use UDP in a LAN or localhost. So ideally you’d like a super thin API over the top of TCP and UDP that amounts to the same thing, and follow the Q3 network model.

Cas :slight_smile:

Honestly I’m not a big fan of the way that java.net is structured either, but almost everything for JGN is in the forum: http://forum.captiveimagination.com/

I’m the creator of JGN so I can tell you it’s still supported, although the API is pretty stable and hasn’t needed any changes for a while now.

Pleasure to meet you. Although I won’t use JGN for now I’ll keep that in mind, thanks. If the project is in fact still supported may I suggest you make some kind of update on https://javagamenetworking.dev.java.net/ so that the “archived due to no activity”-message will disappear?

Maybe you have something insightful to add to the debate concerning whether to bother to use UDP or not? I’m guessing there has been some work on reliable UDP transfers in JGN (haven’t checked though).

Thanks, I fixed the Java.net page.

I doubt I can really offer much, but I find both TCP and UDP very useful when developing networking games/applications as they are each well suited to particular areas. TCP offers guaranteed delivery and guaranteed order. When I send a message that absolutely must arrive (like a chat message for example) I use TCP. On the other hand, UDP offers benefits in its lack of both of those features. I know that probably sounds like an odd benefit, but in a case where you are doing something like positional synchronization you are constantly sending messages to tell where a specific object is in the game. This information isn’t critical that every message be received, so if one message is lost it’s really not a big deal. I find that UDP provides some significant benefits in this area particularly with respect to lag. For example:

In a TCP scenario if positional synchronization is being sent periodically and lag occurs the guaranteed delivery actually increases the lag because when the lag actually ends you have to “catch back up” by receiving all those messages that were backlogged. You end up either processing or ignoring a bunch of out-of-date messages.

On the other hand with UDP you lose a bunch of synchronization messages and then you immediately catch the next “relevant” message as soon as the lag or connection trouble subsides.

That is all to say that I think both are very useful protocols in their own way and I think most real-time games can and should make use of both.

I was a network engineer, back when I had hair :wink:

Using what other games use for an example of what to do only works if you look at how well it worked. Game forums are full of page after page of network issues. So take game examples with a grain of salt. princec as aways gives the best reason. Getting things going first should be priority one, and you won’t see a difference on a LAN between either.

But anyway… my 2c

I have just about finished my network implementation for a RTS game, and it is working far better than I could have hoped. I use TCP (the nio channels stuff in fact).

I started off undecided. It was pretty clear that a lot of folks ranting about UDP didn’t understand network congestion. So I got some pretty modern games and testing them with congestion. All of them failed with some sort of congestion collapse. They put in “reliable” transport but didn’t add any proper flow control.

When you have no flow control, the first thing that happens when some packets are dropped, is more packets per second are sent (request to resend and the resent packets). Which then induces more packet loss. Which means more requests to resend and more resent packets, until… collapse. In fact some games just locked up with quite modest packet loss. Perhaps even their “reliable” transport implementations aren’t reliable? Most seem to forget the two generals problem.

This happened with TCP back in the day before good flow control was implemented. The internet backbone would collapse under this. We learnt the lesson and now TCP has very good flow control.

Now i did some field test since the internet is quite a different place now than 10 years ago. Even from Austria to NZ UPD was never “faster” per round trip time than TCP nor less reliable. Things either didn’t work at all for both (40-60% packet loss via ping. bad router at the NZ isp) or TCP was “just as good”. Within the EU TCP was generally faster. Yes thats right, faster round trip ping times. Because its connection based some routers and firewalls (and NATs) can optimize packets that belong to an established connection (aka ppp tunneling header compression etc).

Generally start with the idea that TCP is the right choice. Then switch only if there is a compelling reason to do so (or as suggested, mix flavors). The internet is far better than it was 10 years ago. Games should not have the problems they seem to have if done properly.

My only real grip with TCP is that its stream based. I would like to see packet boundaries. But thats not a biggie.

ops… I though this was going to be short post.

Thank you for your two cents delt0r. It was a good read.

I have been reading a lot of articles lately, about different network strategies etc. All articles I found have been using UDP, I’ve been thinking about trying to get JeNet working after all and go with UDP. But I’m still not sure what to do. Having big trouble in deciding how my game “architecture” should look. Making a network game sure isn’t that easy, I need to find a structure I like and feel comfortable working with. I think I’ll try and make a server using TCP next, but single threaded and non-blocking, and see how that feels. You are right in that the Internet doesn’t have some of the problems it had before (I guess, sounds reasonable), and I hope TCP will work satisfactory. I read somewhere (I think it was a warning on one of Sun’s UDP tutorial pages) that some facilities block UDP traffic, which means making the game using TCP will make it playable in more places.

Thanks again fellas.

the first thing you should do is to abstract the network part, so you will be able to switch to UDP or any other network protocol pretty easily