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. 8)
Edit: By the way if you want all the data, I can dig up the email and post it.
Why, oh why, oh why, oh why - did you have to start this again?
Kev
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…
It’s already there, i’m using it atm 
Endolf
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 8)
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
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. 
-Matt Hicks
Hmm. Seems to me it has been
Skipping to the next message…
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”.
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
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?
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.
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.
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 :
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…
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.
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?