Why UDP is a retarded network transport protocol for SL

Well,
my patience is now very fragmented and that is making me EXTREMELY grumpy. Why? Because I still fail to see the benefits of using UDP in this environment.

I agree that UDP is good because it is a connectionless protocol, and have lower overheads, as well as the fact "if ou lose a packet it doesnt matter" sort of broadcasting.

And thats where the problem lies. SL runs very nicely if you have SDSL, cable, or something that that is capable of a good upload as well as download.

However I'm not - I have ADSL, abd only have a meagre 64k/s upload - and I CANNOT afford to upgrade, so dont say it.

I regularly have to reconnect to SL 30-50 times a day, not because of crashes, but because the SL server floods me with UDP crap every time I fly over an area with "corrupt objects/textures" that my client cant read.

"[INFO] Discarding duplicate packet from 66.xx.xx.xx" is the debug flood.

disconnect, restart, alls happy again.

Also see a lot of [INFO] UDP sequence out of order.... messages.

For flippies sake, if you are going to need packet ordering, use damn TCP - thats what it was made for.

Conclusion - SL its bloody tedious for users with Assymetrical bandwidth, where the upload capacity is low.

*grumble*

*edit* I also live in .au, so I dont get the nice latency and stuff you US people have

This method of packet-transfer is crucial to SL. With TCP, it doesnt matter if the packet was sent 1 second ago, or 5 minutes ago. UDP solves many problems because it allows for streaming of realtime data, if one packet is discarded, it doesnt matter. If you tryed the same thing with TCP, a lost packet, by the time its resent, is already stale, outdated data. I agree with you that *certain* data should always be sent, reguardless of age, but this is where the similarities in our opinions end, UDP is good for some of SL, and TCP is good for some of SL.



Not necessesarily. I have 128kbps upload speeds, and still occasionally get the problems you describe.



That's sort of my opinion as well. Certain valueable messages should be sent to the client via TCP, and discardable, crucially realtime ones sent via UDP.




Why do users need good upload capacity for a protocol that uses "if ou [sic] lose a packet it doesnt matter" broadcasting?

In fact, if you consider the alternative, TCP, you actually use equal upload bandwith as you do download, since your client needs to send a "packet recieved" message for *EVERY* *SINGLE* *PACKET* the server sends to the client. These "packet recieved" messages are unnecessarry in UDP, therefore, theoretically, a UDP protocol should actually use *less* upload bandwith then a TCP protocol would.

==Chris

True, as stated, TCP has more overheads due to acks - but at least you remove the packet ordering issues, and those UDP "floods" described would be gone, because it could acknowledge the packet rather than send and send and send.

I agree, there should be a better mix of protocols. TCP is better suited towards the download of objects/textures. UDP is better suited towards movements, perhaps display data (then use TCP to download if obect/texture not found), and generally stuff that is not critcial to the performance of the client.

Other way around.

TCP for packets that are critical:

Object Rez/Derez (but not properties contained therein, if they dont fit in one packet)

Player Movement (if the KEY_UP command gets 'lost' then you go flying long distance. I'd actually prefer there was a constant stream of KEY_DOWN, rather than the current setup. Assume keyup if no response in 3 secs)

Avatar Entry/Movement

UDP for:

textures, sound, audio, - big data.

Where to begin, where to begin.

For those just tuning in, this all began as an argument on the Ouranos channel. We all agreed to ajourn our discussion to forums, so that we may carry out our incivility publically.

Some thoughts:
First of all, packet reording is TERRIBLE for TCP. Routers go out of their way to avoid packet reording.

This is because TCP will interpret out-of-order packets as loss, which it in turn, interprets as congestion. When TCP sees congestion, it cuts its CWND in half, cutting back its network usage.

Second, UDP definately has a place in SL protocol design. The second you start talking about low-latency requirements, such as avatar control, you want to build on top of UDP.

(SL design attempts to provide a framework for latency-sensitive tasks such as gunfights, or driving)

TCP has the semantic that all data must be presented to the application in order. That means packets containing useful information (I'm going to shoot someone) can potentially be blocked waiting for retransmission of less important datapackets (I look up, and then look back down again). Moreover, the state of the TCP socket is not generally well known by the application. "Will this data be buffered, or transmitted immediately?" This is why UDP is the protocol of choice for pretty much every FPS video game out there. The guys out there who write games - they're not stupid people. They did try TCP. And it didn't work out. Let's learn from their mistakes.

I won't talk about everything else mentioned here, unless someone wants me to specifically address it, but here are my final thoughts:
- The choice of UDP or TCP will both allow the design of an asymmetric protocol. The fact that you get flooded with messages occasionally is not indicative that UDP or TCP was a poor choice.
- As for the texture/object/sounds debate on whether that should go over TCP or UDP, it's an open argument. Choosing one over the other involves making tradeoffs, such as automatic bandwidth discovery/dealing with long-fat pipes/network friendliness and predictable bandwidth usage. Noone can be "right" in this argument without first stating the tradeoffs that they prefer. And so far, noone has.

The battle of the network engineers....

you tell me its occasional, how about you fly down here, and see how much you like restarting your client every time you fly into uncached land?

ok, I'll back down on the issue of blowing away UDP altogether, but I am standing fast with adam on a suitable mix of TCP/UDP protocols to enable better tranmission with assymetrical data connections

Here's a free hint to everyone. If your computer or internet connection suck, then it isn't LL's fault.
You can't expect LL to spend man hours reworking their code to account for people using outdated technology. That's like bashing John Carmack because Doom 3 won't run on a 486 like Doom 2 did!

I gots Betamax and that's the way I likes it, don't gimme no new-fangled VHS.

Heh I still have a working beta VCR and a bunch of tapes
Damn, that thing is HUGE!

*looks around confused*

um...did I wander into a smart people thread? I was looking for the drama. Oh, take a right? Thanks. Hope I can get out of here before I get an inferority complex.

Of course you dont actually have to use TCP to be sure data arives. Everything TCP does is just software. They can require certain data to send a ack back saying it was recieved and its as reilable as TCP. Theres nothing stopping them from having both TCP and UDP either.

The only problem I have is ghosting.. But one thing I dont understand is why does it need a responce from the server to know you deleted somethin, lol.. (I guess to be sure it got deleted?).. I just think its funny when you delete a prim and its still there.

Kassandra,

Don't feel bad, we just look smart, because this is what we do for a living. So of course we look like we know what we're talking about. I'm a graduate student - I study computer networks. Heck, I've even published a few papers on networking as it relates to gaming

Adam, I know runs an ISP in Australia, and does related consulting work.

I'm sure that you'd look very smart droning on about whatever your profession is

However, I still don't know what Chage is rambling about. Chage, both TCP and UDP do provide a framework that's quite suitable for asymmetrical networks. The fact that you're specifically targetting one should have no particular bearing on your choice of UDP or TCP.

Nah...I am an English major, I never get to look smart. Everyone can read.

Silly me,
fancy thinking I could have a rant in a rant forum, I must have made a mistake

Anyway, because it would appear that I am the only one with this rant opinion, it must be my fault, as so has been stated by the hardline SL'er

seeing I could argue this will ill-informed facts for the rest of my days - because many people cant replicate my frustration, lets just let this thread die quietly now

Hey, since you guys are all technical and smart maybe you can offer some possible solutions to my networking problem. I just changed dorm rooms for the summer and I can no longer get online. Well, according to my computer I am online but nothing is working but the school webpage. I can access things on the network but nothing off of it. I tried using the computer that comes with the room and it can access pages off the network but its a hunk of junk that is barely above of giant paperweight. I tried all the obvious stuff like rebooting, switching cords and plug it into the other hole, etc. The computer network guy won't be able to bother with the dorms for 2 weeks, I can't make it that long. HELP!

If your browser can access pages on the college network but not ouside it, perhaps you have your proxy configured incorrectly.

sounds an awful lot like a firewall and transparent proxy to me. I know my uni (ack 2 days before I leave uni forever hopefully) has a really tight firewall, and essentially you can only access the web from a "student" account.

From a practical point of view, you can consider that TCP runs over UDP. TCP simply offers extra services over UDP to make life easier for delay-insenstive, loss-sensitive data transfers.

You can see this very simply by looking at the headers. UDP header is simply IP header with port number tagged on. TCP header has things like sequence number to allow packets to be reordered and joined back together as a continuous bitstream.

You use TCP when:
- you dont want to have to code packet ordering and joining together yourself
- you want to use TCP's windowing, throttling and resend capabilities
- your data is not particularly time-critical

As a general rule you use TCP for most things LAN, and anything WAN which is sensitive to data-loss, eg file-transfer.

You use UDP for many things WAN where it doesnt matter if you drop packets here or there, eg audio, VoIP, video-streaming.

I guess that SL is being controversial in this thread because the data:
- is time-sensitive
- does contain data that cant be dropped

In this scenario you could run with TCP because it contains services to make sure all your data gets through intact, but you might decide to use UDP and to write your own flow-control and data retransmission code because TCP has been around for a while, since the days when transmissions were really slow and lossy, and because TCP is a generic protocol adapted for all kinds of connections, whereas your own rewritten protocol, which effectively replaces TCP for your application, can be optimized specifically for your own application, ie SL.

Concise conclusion: UDP makes perfect sense. TCP would probably not give better results. Consider investing in a better connection.

Azelda
ex-Cisco Certified Networking Professional and Cisco Certified Network Associate

As far as the other question appended to the end of this thread, first things I'd check are:

do "ipconfig /all" on the pc that works and the one that doesnt and compare the results
- check specifically the gateway address
- and the subnet mask

If either of them are different, go into your network properties in Control Panel and set the gateway address and subnet mask to be the same as on the computer it works (they're plugged into the same socket right? You're just switching the cable over? Just checking, on the offchange theyre connected to two different subnets...)

If they're the same, check you can ping the gateway

On each machine:

ping %GATEWAYADDRESS%
where %GATEWAYADDRESS% is whatever is the gateway address in ipconfig /all

If the ping works, try something like tracert forums.secondlife.com and check it displays the same thing on each PC. If its not, um, check the network properties (TCP/IP) a bit more between the two machines.

If thats all working, compare the proxy properties in Internet Explorer on each machine. (Tools | Internet Options | Connections, from within Internet Explorer)

If you did all that and both machines all look sortof identical and it's still not working, then get someone technical to come and look at the machines physically.

Azelda

Azelda, your suggestion got it working. For some strand reason when I did ipconfig /all the whole thing would close in a millisecond after openning, so I had to take a screen shot of them both to compare. I changed it all and now its works. Thank you so much. Thank you all for helping me! Now to see if I can get into second life.