Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (542)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (604)
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  
  Who needs UDP?  (Read 5051 times)
0 Members and 1 Guest are viewing this topic.
Offline Jeff

JGO Coder




Got any cats?


« Posted 2006-07-11 21:08:33 »

Okay,

I KNOW this is an old debate but I foudn some interesting information lately.

We did a survey of MMO connection techniques in Project Darkstar to understand where best to fcus initial efforts.

Guild Wars is pure TCP.  No UDP at all.  Cool

Edit: By the way if you want all the data, I can dig up the email and post it.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline kevglass

« JGO Spiffy Duke »


Medals: 221
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2006-07-11 22:20:04 »

Why, oh why, oh why, oh why - did you have to start this again?

Kev

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 849
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2006-07-11 22:52:03 »

My guess is he's trying to find a reason not to implement a UDP-layer in the SGS.


To answer the question:
there will always be someone that demands UDP for some very good reason.

These days TCP is good enough for almost everything...

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #3 - Posted 2006-07-11 23:09:22 »

My guess is he's trying to find a reason not to implement a UDP-layer in the SGS.

It's already there, i'm using it atm Smiley

Endolf

Offline Jeff

JGO Coder




Got any cats?


« Reply #4 - Posted 2006-07-12 19:43:47 »

Naw.  We're serious about UDP support in the SGS

The industry still needs UDP. it is very good for *some* things,.

But clearly for MMOLRPGs its a whole lot less necessary then some people believed Cool

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline kevglass

« JGO Spiffy Duke »


Medals: 221
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2006-07-12 20:23:45 »

Quote
But clearly for MMOLRPGs its a whole lot less necessary then some people believed Cool

Which people were those? I thought the resolution of most of the discussions here at least (including the behmoth made sticking in this forum) was that UDP was appropriate in some cases - not so much in others?

Or are you saying something more "you can write a MMORPG without using UDP"? I don't think thats exactly rocket science or that it's ever been disputed.

Kev

Offline sunsett

Senior Devvie




ribbit!


« Reply #6 - Posted 2006-07-13 14:56:54 »

I would say there can be some definite advantages to UDP even in a MMORPG as the TCP route can have serious lag issues.  Even though UDP gets around that by being a lossy messaging system the benefit still exists when it doesn't particularly matter whether all messages arrive or not.  I was re-evaluating this myself when I started writing JGN 2.0 and I think the greatest use of UDP in my system is something I call a RealtimeMessage.  It has an incrementing value and a groupId associated with it and has a special message queue that holds it.  The message queue will only keep one RealtimeMessage for a specific groupId at any given time and if another is attempted to be added it will figure out which one is newer and discard the other.  This keeps the outgoing and incoming queue from stacking up more than one of this type of message at any given time.  It is partciularly useful for synchronization information since you don't really care to apply old synchronization information, you only care about the newest one.  Apart from RealtimeMessages I think the major benefits of UDP in games lie in the use with synchronization.  I think this is also a useful feature in a MMORPG as well.  I think a good networking system will utilize both UDP and TCP for their strengths when designing a game.

Just my thoughts on the subject. Wink

-Matt Hicks
Offline Jeff

JGO Coder




Got any cats?


« Reply #7 - Posted 2006-07-13 20:55:28 »



Or are you saying something more "you can write a MMORPG without using UDP"? I don't think thats exactly rocket science or that it's ever been disputed.

Kev

Hmm. Seems to me it has been

Skipping to the next message...
Quote
I would say there can be some definite advantages to UDP even in a MMORPG as the TCP route can have serious lag issues. 

Whelp I have yet to see a real lag effect in GW or hear any big complaints about one. *shrug*

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline sunsett

Senior Devvie




ribbit!


« Reply #8 - Posted 2006-07-14 12:30:07 »

Whelp I have yet to see a real lag effect in GW or hear any big complaints about one. *shrug*

The key there is "I".  Wink

Many of us have the benefit of pretty reliable internet connections while others are destined for a harder life with a constant hate relationship with the L-word.  Yes, in most cases TCP can be relied on without seeing much of an effect (particularly if the programmers can do a good job of hiding lag with dead-reckoning, disregarding old messages, etc.), but I believe MMORPGs could still benefit from UDP.  I'm not referring to Good and Bad, but Good and Better.  In a game like GW I do agree it is much less an issue though than it would be for a first-person shooter style game where fast-paced information has to be synchronized at all times.  It just seems logical that UDP is still the logical choice in some situations above TCP (when available).  Do you disagree?

-Matt Hicks
Offline shawnkendall

Senior Devvie





« Reply #9 - Posted 2006-07-14 18:32:15 »

<Obligatory troll>
The only person who needs UDP, is the person implementing TCP!
</ot>

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2006-07-17 09:48:02 »

Yes, in most cases TCP can be relied on without seeing much of an effect (particularly if the programmers can do a good job of hiding lag with dead-reckoning, disregarding old messages, etc.)

Out of interest, how exactly do you disregard old messages?

malloc will be first against the wall when the revolution comes...
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 849
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #11 - Posted 2006-07-17 11:17:11 »

Yes, in most cases TCP can be relied on without seeing much of an effect (particularly if the programmers can do a good job of hiding lag with dead-reckoning, disregarding old messages, etc.)

Out of interest, how exactly do you disregard old messages?

In the API layer, retreiving a lot of packets before processing them, then checking for double 'types' and removing the old ones. Then process the remaining packets.

It certainly can't be done in the TCP-layer.

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2006-07-18 11:17:00 »

Yes, in most cases TCP can be relied on without seeing much of an effect (particularly if the programmers can do a good job of hiding lag with dead-reckoning, disregarding old messages, etc.)

Out of interest, how exactly do you disregard old messages?

In the API layer, retreiving a lot of packets before processing them, then checking for double 'types' and removing the old ones. Then process the remaining packets.

It certainly can't be done in the TCP-layer.

How would you ever have a disregardable old message in TCP, seeing as you are guaranteed it's going to arrive, why would you ever resend it?

malloc will be first against the wall when the revolution comes...
Offline sunsett

Senior Devvie




ribbit!


« Reply #13 - Posted 2006-07-18 14:24:29 »

How would you ever have a disregardable old message in TCP, seeing as you are guaranteed it's going to arrive, why would you ever resend it?

Synchronization messages are disregardable since you only care about the newest message.  If a situation occurred where you received two synchronization messages in the queue for the same object then the older of the two could be disregarded instead of applying an old synchronization message to the object.  Make sense?
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2006-07-18 16:52:56 »

How would you ever have a disregardable old message in TCP, seeing as you are guaranteed it's going to arrive, why would you ever resend it?

Synchronization messages are disregardable since you only care about the newest message.  If a situation occurred where you received two synchronization messages in the queue for the same object then the older of the two could be disregarded instead of applying an old synchronization message to the object.  Make sense?

No, because *why would you ever send the second one* ?

First rule of application protocol: never send data that contains no information. All you're doing is wasting electricity

malloc will be first against the wall when the revolution comes...
Offline kevglass

« JGO Spiffy Duke »


Medals: 221
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #15 - Posted 2006-07-18 17:09:26 »

Quote
Quote
Quote
How would you ever have a disregardable old message in TCP, seeing as you are guaranteed it's going to arrive, why would you ever resend it?
Synchronization messages are disregardable since you only care about the newest message.  If a situation occurred where you received two synchronization messages in the queue for the same object then the older of the two could be disregarded instead of applying an old synchronization message to the object.  Make sense?
No, because *why would you ever send the second one* ?

First rule of application protocol: never send data that contains no information. All you're doing is wasting electricity

Um - bit patronising - but also you might end up with mutliple sync messages in TCP if the remote entity had changed multiple times and multiple update messages had been sent, recieved and buffered on the client before the client came round to check the buffer. (*scenario below)

In most games this sort of disregarding of update messages doesn't work very well except in extreme cases - it causes jumps - "normally"2* you'd just playback the updates faster than normal to cause catch up. It "normally"2*only makes sense to disgregard if the time between between the updates is huge - i.e. the client is lagging with burst traffic or the game the client is just running really slow.

Kev

2* Normailty from my perspective obviously.

* Scenario - assuming the data is full overrite - say x,y,z positions for elements

1 ) Server Entity Updated - Message sent
2 ) Client Recieves and buffers
3 ) Client loop comes round, processes network buffer - great.
4 ) Server Entity Updated - Message sent
5 ) Client Recieves and buffers
6 ) Server Entity Updated - Message sent
7 ) Client Recieves and buffers
8 ) Client loop comes round and now has two messages to process - but since the early one is now redundant - it *could* disregard.

Offline bahuman

Junior Devvie





« Reply #16 - Posted 2006-07-18 22:15:03 »

I think I'm with Kev on this one.
In UDP, you might actually be reading the "newer" state before you read an old message from the buffer. In such cases, you would have timestamped the packages and, when comparing the older timestamp of the last package, with the newer timestamp in your gamestate, you can decide to drop this message.

In TCP, when everything arrives neatly in order, it doesn't make sense to "scan ahead", just so you may skip some of the messages if they are invalidated by some of the other waiting messages in the buffer. In fact, since TCP garantuees both delivery AND order, you can use this to delta-compress your messages. Your packages will typically be smaller, but you can't afford to skip any. Your total bandwidth usage should drop considerably, though. If you're "stuck" with TCP, might as well make use of its properties   Roll Eyes
Online CommanderKeith
« Reply #17 - Posted 2006-07-19 05:42:20 »

How would you ever have a disregardable old message in TCP, seeing as you are guaranteed it's going to arrive, why would you ever resend it?

Synchronization messages are disregardable since you only care about the newest message.  If a situation occurred where you received two synchronization messages in the queue for the same object then the older of the two could be disregarded instead of applying an old synchronization message to the object.  Make sense?

No, because *why would you ever send the second one* ?

First rule of application protocol: never send data that contains no information. All you're doing is wasting electricity

This is just a misunderstanding, sunsett knows that TCP gaurantees delivery & order.  In the above I think he's talking about UDP or maybe some wierd TCP setup where multiple threads are sharing the same port or something....

Offline Jeff

JGO Coder




Got any cats?


« Reply #18 - Posted 2006-07-19 06:57:10 »

Jm... its a misunderstanding but I dotn think its sunsetts.

The reason AIU him is that you are pumping packets out at a discrete rate, whoever on the RECIEVIGN end you may get jammed up and then geta bunch of packets all at once,.  In that case processing the past ones is pointless and you can just throw them out and process the last one as  long as the last one correctly reflects all the previous information in its state.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #19 - Posted 2006-07-19 09:40:55 »

Jm... its a misunderstanding but I dotn think its sunsetts.

Yeah.

Basically ... I didn't see how "not rendering stupid stuff on the screen" reduced the effects of lags enough so as to make them tolerable. My misunderstanding was that I was thinking at a different perspective - I'd assumed no-one would ever even *think* of rendering stuff in this day and age that caused entitites to rubber-band all over the place - and so I thought the OP was talking about the harder problem of working-around latency/drops.

OP:
"Yes, in most cases TCP can be relied on without seeing much of an effect (particularly if the programmers can do a good job of hiding lag with dead-reckoning, disregarding old messages"

IMHO you still see a big effect if a game lags, no matter how much rendering you do - you need to do cleverer things that just rendering to have "[not] much of an effect". Hence me misunderstanding and thinking you were talking about such things.

Sorry. IMHO, though, its still just plain foolish to be sending redundant data down a TCP stream - it's artificially increasing your latency, and how many of us work on platforms where there is so little RAM and CPU at either end that we can't afford to buffer and remove outgoing duplicate messages?

malloc will be first against the wall when the revolution comes...
Offline sunsett

Senior Devvie




ribbit!


« Reply #20 - Posted 2006-07-19 14:23:43 »

Sorry. IMHO, though, its still just plain foolish to be sending redundant data down a TCP stream - it's artificially increasing your latency, and how many of us work on platforms where there is so little RAM and CPU at either end that we can't afford to buffer and remove outgoing duplicate messages?

I agree....the RealtimeMessage in JGN 2.0 is handled in both incoming and outgoing queues in order to remove duplicate messages in the outgoing queue so multiple redundant messages don't get sent, and in situations where multiple messages do get received before the remote machine can process them the extras are also discarded.  This puts it off on the developer to handle good synchronization.

If they don't want jumps in the graphical positioning they need to implement functionality to animate them from their current position to the new position, I think it's a bad idea to try to handle that in the networking.

UDP is definitely the place where this gives the most benefit, but it also has a place in TCP I believe.  Say for example I have two players in an first-person shooter that are connected to a server and sending packets to the server announcing their position in-game.  The server validates that information and passes it on to the other players.  There is a big possibility of lag spikes on TCP that would cause a bunch of synchronization messages for the same player to be received at once on the client or server.  It would be a waste of time and a bottleneck to process all of these messages (and slows down the process of getting back in sync after a lag spike).  If I instead disregard all the old ones and take only the most recent I'm back on track without any problems.  I do agree that you don't want the whole issue of players bouncing around the screen in a lag spike though, so you may want to inject a positional synchronization system to take their current position and gradually adjust them to the new position to get back into sync, but that's outside the scope of this discussion.

To get back to the main topic of this discussion, with positional synchronization I think UDP has major advantages over TCP as you don't have guaranteed delivery, so if you stop receiving synchronization messages for a minute and then just receive a few at once you can simply grab the newest and disregard the rest.  In that case you aren't even having to process the hundred of messages that were sent, but only those that were able to be received after the connection fault which is going to be the newer information anyway.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #21 - Posted 2006-07-19 16:49:21 »

There is a big possibility of lag spikes on TCP that would cause a bunch of synchronization messages for the same player to be received at once on the client or server.  It would be a waste of time and a bottleneck to process all of these messages (and slows down the process of getting back in sync after a lag spike).  If I instead disregard all the old ones and take only the most recent I'm back on track without any problems.

I still don't get this - when has this ever been a bottleneck? We're talking about a gigahertz processor dealing with message frequencies in the 0.01Hz to 0.1 Hz range - the processor will do literally several hundred million things in the time frame individual message are arriving.

IMHO, you are gaining nothing significant to try and be clever about your TCP queue, whilst you are losing a lot that is very significant by not running over an out-of-order protocol.

FWIW, I completely guess that the reason people get away with TCP is simply that POTS-based DSL lines are very predictable, *and* such high bandwidth that even background email sends, site surfing, daemon updates etc don't impact the game traffic.

malloc will be first against the wall when the revolution comes...
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.

CopyableCougar4 (14 views)
2014-12-28 02:10:29

BurntPizza (17 views)
2014-12-27 22:38:51

Mr.CodeIt (13 views)
2014-12-27 04:03:04

TheDudeFromCI (17 views)
2014-12-27 02:14:49

Mr.CodeIt (25 views)
2014-12-23 03:34:11

rwatson462 (56 views)
2014-12-15 09:26:44

Mr.CodeIt (46 views)
2014-12-14 19:50:38

BurntPizza (92 views)
2014-12-09 22:41:13

BurntPizza (113 views)
2014-12-08 04:46:31

JscottyBieshaar (86 views)
2014-12-05 12:39:02
How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!