Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  DatagramPacket delivery system (UDP in Java)  (Read 5876 times)
0 Members and 1 Guest are viewing this topic.
Offline M2009

Junior Duke





« Posted 2009-06-21 15:22:25 »

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

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2009-06-21 15:34:55 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #2 - Posted 2009-06-21 15:50:24 »

The problem is that I need all packets to arrive and I need them in the order they was sent.

Uh, use TCP?

Why exactly do you think you need to use UDP?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mr_Light

Senior Duke


Medals: 1


shiny.


« Reply #3 - Posted 2009-06-21 16:07:46 »

There should already be a ready-to-use "DatagramPacket delivery system" somewhere that I don't know about.
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.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Stranger

Senior Duke


Medals: 7



« Reply #4 - Posted 2009-06-21 16:26:43 »

Hi,

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.

There's JeNet https://jenet.dev.java.net/. This is a java port of enet
Quote
which allows reliable/unreliable/sequenced/unsequenced packet sending on top of UDP

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

Anton
Offline DzzD
« Reply #5 - Posted 2009-06-21 17:28:40 »

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.

Uh, use TCP?

Why exactly do you think you need to use UDP?
+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.

Offline M2009

Junior Duke





« Reply #6 - Posted 2009-06-21 19:10:02 »

The thread got filled with "use X instead of Y"-replies, who would have guessed it? Smiley

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/topics/udp-vs-tcp-ip/608/view.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.

http://www.gamasutra.com/features/19990903/lincroft_01.htm
+ 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.

http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
+ 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. Smiley

Offline DzzD
« Reply #7 - Posted 2009-06-21 19:26:20 »

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/topics/udp-vs-tcp-ip/608/view.html) I will tell you my motivation of using UDP in short (you did ask why).
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
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.

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2009-06-21 19:42:01 »

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 Smiley

Offline M2009

Junior Duke





« Reply #9 - Posted 2009-06-21 20:20:39 »

this is not... but you ask to do exactly what a TCP stream do, but ok let's forget about TCP [...] 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.

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.

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 Smiley

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

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 #10 - Posted 2009-06-21 22:04:20 »

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

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.

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

Senior Duke


Medals: 1


shiny.


« Reply #11 - Posted 2009-06-21 23:01:44 »

What's good about having UDP doing exactly what TCP does is that you can remove/add fetures if you like.
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.

(supposedly, I have of course not made any tests myself) make the UDP packets get lost more often.
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
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!
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.
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?
'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

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


It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline M2009

Junior Duke





« Reply #12 - Posted 2009-06-22 00:00:09 »

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

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.

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

[...]

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.

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2009-06-22 09:17:36 »

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 Smiley

Offline sunsett

Senior Duke




ribbit!


« Reply #14 - Posted 2009-06-22 13:40:46 »

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

Junior Duke





« Reply #15 - Posted 2009-06-22 17:32:25 »

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

Offline sunsett

Senior Duke




ribbit!


« Reply #16 - Posted 2009-06-22 20:09:27 »

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

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #17 - Posted 2009-06-28 14:54:47 »

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.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline M2009

Junior Duke





« Reply #18 - Posted 2009-06-29 18:17:47 »

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.

Offline DzzD
« Reply #19 - Posted 2009-06-29 18:23:41 »

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

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #20 - Posted 2009-06-30 07:27:48 »

Quote
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

I was able to drop a large part of my "abstraction" pretty easily when I was able to assume reliable, ordered transport. My game side packet headers also got smaller. Switching back to UDP would require quite different assumptions and a bigger "abstraction" since there are packets that need ordering and some that don't and some that need reliable transport and some that don't. If this not the case. ie you need everything to be ordered and reliable --like I assume now, there is really no reason to move to UDP. 

I think for getting things starting a network "abstraction" that assumes reliable orderd transport is fine. You can always add all the extra stuff that UDP makes hard/lets you do when you need it. The difference is, you are adding to a code base that already is working. 

Always think, how can i get a playable version going easiest....

I have no special talents. I am only passionately curious.--Albert Einstein
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2009-06-30 11:00:42 »

It has to be said that the Q3 network model is specifically designed to only work when packet delivery is slightly unreliable and out-of-order. It won't be nearly as efficient running over TCP and may even be worse (but you'd have to check that, of course)

Cas Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #22 - Posted 2009-06-30 11:55:01 »

Quake is a special case really. It is a perfect example of when UDP is the right choice.

But they have no reliable delivery code and they don't do resends on undelivered packets.  Every game frame the full game state is sent at a fixed rate. Thats it. The clients only care about the latest game frame and ignore everything else.  All the flow control and reliably ack packet complexity simply does not exist. UDP really makes scene when you can do this. 

But this won't work for MMO or RTS where the game state is too large for a packet. At that stage loosing a packet can matter.

ps. I often tunnel Q3 over ssh TCP as a fake VPN. It plays just fine.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline DzzD
« Reply #23 - Posted 2009-06-30 12:17:24 »

UDP can be a good choice in any case you got keyframes & intermediate frames as in video, but this can also apply to a lot of game


ps. I often tunnel Q3 over ssh TCP as a fake VPN. It plays just fine.
hehe this just mean that Q3 is well programmmed and that it network architecture doesn't blowup as we may have expect in such case (tunneling), but in another hand tunneling via TCP just make all your UDP packet reach their destination and in the correct order that why I guess there are few resent and why the tunnel doesn't explode, but anyway.. why are you doing that !?


Offline Mr_Light

Senior Duke


Medals: 1


shiny.


« Reply #24 - Posted 2009-06-30 20:04:16 »

hehe this just mean that Q3 is well programmmed and that it network architecture doesn't blowup as we may have expect in such case (tunneling), but in another hand tunneling via TCP just make all your UDP packet reach their destination and in the correct order that why I guess there are few resent and why the tunnel doesn't explode, but anyway.. why are you doing that !?

it might just as well simply work because of they way the tunnel or rather how udp over tcp was implemented if you simply drop incomming udp packages at the start of tunnel if the tunnel is congested... - you can because udp doesn't have to be reliable. So you end up with the situation that the udp packages to be send never end up in the tcp stream.

well that and the much simpler explanation: typical bandwidth has increased by at least 10 fold or something over the years. q3 dates from a time 56k wasn't uncommon.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
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.

Longarmx (45 views)
2014-10-17 03:59:02

Norakomi (36 views)
2014-10-16 15:22:06

Norakomi (27 views)
2014-10-16 15:20:20

lcass (31 views)
2014-10-15 16:18:58

TehJavaDev (61 views)
2014-10-14 00:39:48

TehJavaDev (61 views)
2014-10-14 00:35:47

TehJavaDev (51 views)
2014-10-14 00:32:37

BurntPizza (67 views)
2014-10-11 23:24:42

BurntPizza (39 views)
2014-10-11 23:10:45

BurntPizza (81 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!