Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

UDP - Packet Loss in Real Life?

Cliff posted more than 12 years ago | from the network-intricacies dept.

Programming 127

PacketStorm asks: "There's always an argument between TCP and UDP users. TCP users complain that UDP is non-determinstic and lossy, while UDP users complain that TCP is slower and nobody needs all the features anyway. So the question is - has anyone actually seen/experienced UDP loss in high-traffic environments? Is the degeneration of UDP any better or worse than TCP in a congested environment? TCP also craps out in times of congestion, but at least you know - or do you? Experiences?"

Sorry! There are no comments related to the filter you selected.

Snot! (-1)

Anal Cocks (557998) | more than 12 years ago | (#3861973)

I'm covered in TACO SNOT!!!

Trans. From the Host Geek Pt. 1 by poopbot (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3861984)

Credits: BankOfAmerica_ATM

SUBJECT: GREAT STOCK OPPORTUNITY!!! help me Get Big Brands on eBay I DON'T KNOW WHERE I AM! PENTIUM III CPU's IN STOCK
Begin Fwded Message:

If someone is listening out there, HELP! I'm trapped, and I don't know where I am. I know this sounds fucked up, but I started reading about this ATM 73.9GB SCSI SCA-2 LVD 3.5 X 1.6 80-PIN 5.7MS 4MB CACHE 10,000RPM HITACHI HARD DRIVE - $269.00 - only 1 left! ITEM#... DK31CJ-72MC http://www.hardwarest.com/product.asp?sku=DK31CJ%2 D72MC+&dept_id=7 online. Yeah, not like withdrawal or anything, but this was an actual ATM, and it was alive, and posting messages to this educational website that I visit from time to time.

Pretty soon, I realized that not only was this ATM visiting the same site I liked, but (believe it or not) this ATM was conveniently located near me!!!!! is to take advantage of the current climate in the telecommunications industry!!!! In every industry downturn, opportunities can present themselves for a small aggressive company like GloboPhone to develop relations with corporations that have networks, infrastructure, and personnel but lack sufficient customers. This is GloboPhone's advantage.

I don't have to tell you, this was no ordinary ATM. Actually this ATM had the power to transfer its consciousness into your mind. I know it sounds ridiculus, but...it used the magnetic strip to actually go inside your mind. Well like any computer lover I am always wanting to try the new technology, so If you are ready to become the biggest man you can be, then order your supply of Magna-RX+ today! See for yourself, what thousands of satisfied men (and their lovers) have already discovered: Magna-RX+ is the world's #1 Best-Selling Penis Enlargement Formula for one very simple reason: IT WORKS AND NOTHING ELSE CAN COMPARE! I went to where the ATM told me to (his inclosure) and swiped my card.

I blacked out and when I awoke, I was in a new place. Yeah, that's right, the ATM had actually taken ahold of my body. It had done stuff like buy a bunch of magazines and alot of candy. It was like, he and I were different partitions on my brain's hard disk,. Anyway, he took control of my body in order to topple this great conspiracy called Project Faustois-an who doesn't want to stick it to the man? This is when all the trouble started...

So now, after a few motnths of letting him use my body (although I quit for awhile) he's gone and done this to me. Normally I "wake up" from his using my body in a convenience store near my house, and it's no trouble getting home. But this time I'm trapped in We will be on the East Coast later this year.
---------------
- Tuesday June 24, 6pm - 7:30pm


Apple Store at South Coast Plaza, 3333 Bear St., Costa Mesa, CA 92626
714-424-6331


Mac Experts, 2300 Lincoln Blvd, Santa Monica, CA 90405
310-581-1500
---------------
- Tuesday July 9, 6pm - 7:30pm


Apple Store at Fashion Island, 367 Newport Center Drive, Newport Beach, CA 92660
949-729-4433
---------------
- Tuesday July 16, 6pm - 7:30pm


Apple Store at Northridge Fashion Center, 9301 Tampa Ave., Northridge, CA 91324
818-709-2253
---------------
- Tuesday July 23, 6pm - 7:30pm

Apple Store at Glendale Galleria, 2148 Glendale Galleria, Glendale, CA 91210
818-502-8310
trapped in a strange place. Not a good place either. This makes me think of like, 2001 or something. But like creepy. See it's all this white under fluorescent lights and I can't see any windows or even doors. All that's in here is this old-ass terminal. Man, what the fucked happened? Then I remembered: I "picked up" the ATM on my way home from work, but I forgot that it was the fourth Thursday of the motnh. Usualy the day I host D & D for the guys. The ATM must have ben there in my body when my frends came over. Wnoder what happened then?

Some point later, I'm here in this white room. It's scary at first, I know they're watching me. All I have in this room is this computer terminal. This has got to be the Project Fastus that's what the ATM has been trying to get inside all along. So I guess it's great that I'm (and he???) is insid, it's like I'm in the frickin' Death Star or something, but I don't see any garbage chutes or anything.

After a few hours of clicking through on thiscomputer terminal (looks like they're running some old-ass *NIX : ) these two guys in suits come into my room from my room. Now it's serious.

They drag me into a room full of all this really sciency equipment-you know, blooping and bleeping gadgets, big cold noises from the air conditioner. I thought I was in 2001 for a second, except instead of HAL, there's this big bald guy. He's red and pretty sweaty despite the massive air conditioning. He barks a few words to the suited guys and they go away.

"So you've been harboring our little ATM problem," says the man nonchalantly. I don't say anything (I'm nervous). He restarts his spiel a few seconds later, this time with a bit of veins comung out of his neck.

"Joel Shane Cross. That is your name, isn't it?" The guy went from good cop to bad cop pretty quick-which was really disturbing. I was already out of sorts with reality, waking up in nowheresville, this odd place. He just kept talking, and I started to get scared, and actually kinda angry. "We know all about you, Mr. Cross. We know that you've been allowing the ATM to inhabit your body for some time now. You've been mislead, Mr. Cross. Working for the wrong people."

"I belive the ATM!" I told him, stickin to my guns while Istuck it to the man.

"You'll learn in time," the red and sweaty man said it from his mouth, but the noise of his voice was all over the place. And then he was gone. Not by turning around, by like, vanishing. And the sciency room was gone too, replaced by the big white place I was stuck in. I don't know where I am. But this shit is If you are ready to become the biggest man you can be, then order your supply of Magna-RX+ today! See for yourself, what thousands of satisfied men (and their lovers) have already discovered: Magna-RX+ is the world's #1 Best-Selling Penis Enlargement Formula for one very simple reason: IT WORKS AND NOTHING ELSE CAN COMPARE!
crazy. If someone gets this message...please help.


END TRANSMISSION.

- poopbot: because even your grandmother can use lunix

UDP packet loss (2, Interesting)

fraxas (584069) | more than 12 years ago | (#3861989)

I don't know if it means anything, but I have experienced UDP packet loss on a regular basis -- playing online games. Unit positions are most often tracked over UDP because it doesn't really matter if things warp around a little when the client receives an update that puts a unit somewhere other than where the client extrapolated it was. There was a big fiasco at launch-time for Anarchy Online -- they used TCP and not UDP for about 8 hours, during which time the game was unplayable because the servers couldn't maintain all the TCP connections. Interpret this as you will.

Re:UDP packet loss (3, Informative)

Polo (30659) | more than 12 years ago | (#3862110)

Hmmm... it's LOTS easier to write an application to handle UDP than to handle TCP.

With TCP, you have a listening socket and then a socket for each client. Each socket has a file descriptor, and you have to select() on all of them to check for activity. There is a lot of housekeeping to do - though it is a solved problem - all webservers solve it. Timeouts are harder to determine from the application's perspective because there can be retransmits and stuff going on that you have no idea about.

However, with UDP, it's laughably easy. You just do one recvfrom() and you get a packet and it also fills in a data structure to tell you where it came from. No filling in fd_set structures and no running out of file descriptors. When you got the packet, you got it.

Most online games and stuff would really like to know when packets were sent, when they were received and if packets are being dropped. With UDP you can usually find out these values directly. With TCP I think it would be more like an educated guess.

One drawback is that UDP is quite easy to spoof. I can send a packet and it is up to the application to figure out it has been spoofed.

If I were downloading a patch to a game I think TCP would be the better choice. It already has the smarts to pace the connection, transmit the data reliably and prevent spoofing.

Re:UDP packet loss (5, Insightful)

Jeremi (14640) | more than 12 years ago | (#3862327)

However, with UDP, it's laughably easy. You just do one recvfrom() and you get a packet and it also fills in a data structure to tell you where it came from.

... or maybe you don't get the packet, because a router was loaded down and had to drop it. Now you gotta implement a timeout and retransmit protocol. Not to mention that packets may arrive out-of-order from the way they were sent, so you if ordering is important (and it usually is) you have to implement some sort of sequencing tag systems too. A few dozen hours later, you find out you've implemented something that looks suspiciously like a primitive version of TCP... :^)

Re:UDP packet loss (3, Informative)

Polo (30659) | more than 12 years ago | (#3862511)

Well, in relation to the post about anarchy online I replied to, it seems like TCP didn't work.

I would think SOME game data would need to be reliable, but most isn't. The problem with TCP for an online game is that you can never THROW AWAY data that's too old or unnecessary. It will be transmitted and retransmitted further delaying current data. At some point, things will become unusable.

I don't think you could play a multi-user game for over an hour and not run into this problem. I think on lower-bandwidth connections, you might never be able to catch up once you fall behind.

Of course, you could do what microsoft does with DirectPlay: open multiple connections, sometimes on multiple protocols, some of them asymmetrical, while ignoring silly details like firewalls and NAT.

I think the initial handshake for dungeon siege was something like:

first packet: udp my_ip:6073 to server_ip:6073
reply packet: udp server_ip:6073 to my_ip:2302 (what!?!?)
next packet: udp my_ip:2302 to server:6073

or some garbage like that. I think the dungeon siege guys just changed it.

Re:UDP packet loss (2)

Jeremi (14640) | more than 12 years ago | (#3864434)

The problem with TCP for an online game is that you can never THROW AWAY data that's too old or unnecessary

Well, that's not entirely true -- while it is the case that once you have called send() on the data, it can't be thrown away, it's also true that if you are maintaining an outbound message queue (to avoid blocking on a filled TCP send buffer), then you can remove or replace data that is in the outbound message queue, that hasn't been sent yet. I have used this technique with reasonable success.

I do agree that UDP has its place, however.

Re:UDP packet loss (3, Informative)

crisco (4669) | more than 12 years ago | (#3862753)

Many games are designed to not care about the dropped packets. Sure, they can be unplayable if packetloss gets too high but the occasional dropped packet doesn't matter.

Some tasty articles from gamasutra (might require a login, you might also find these in Google's cache):
"TCP is evil. Don't use TCP for a game. [gamasutra.com] You would rather spend the rest of your life watching Titanic over and over in a theater full of 13 year old girls."
article [gamasutra.com] on WON's servers for Half-Life.
Dead Reckoning [gamasutra.com] Latency Hiding for Multiplayer Games.

Other software might need the benefits of TCP, but game development is one familiar illustration of where UDP often wins out.

Re:UDP packet loss (0)

Anonymous Coward | more than 12 years ago | (#3865858)

a) It really is less than a few dozen hours to implement the TCP protocol over UDP, which in game development terms is nothing. TCP is staggeringly simple.
b) You then have control over the timeouts. Why should all players wait 40 seconds for the TCP timeout when only one player has gone bye bye.
c) Many things do not need reliablity (as has been reported below).
d) If you are writing a MMORPG you might even consider writing your own TCP/IP stack for high availability, reduced likelyhood of DOS.

What I'd really like to see is more user control over TCP connections:

such as being able to set the timeout

being able to drop data

i.e. to query the highest received SEQ and

move the ACK marker forward.

Why? Because UDP cant get through 99% of NAT's and firewalls, while TCP will.

Re:UDP packet loss (1)

biscuit67 (517991) | more than 12 years ago | (#3871095)

Well, I've been working on an online game for the last year or so and we're definitely using UDP. Mainly because we can decide on re-transmission on dataloss in a deterministic manner. One of the other disadvantages of TCP (correct me if I'm wrong) is that packet sizes are non-deterministic. Sometimes you can receive all the data sent, but essentially it's just a stream with you getting as much data has been acquired at that time. This results in having to do some local buffering to get all of the packet that was sent! Didn't have to do that with UDP.

both are usefull (4, Insightful)

f0rtytw0 (446153) | more than 12 years ago | (#3862009)

UDP for streaminig video and games and other sorts of things where it doesn't matter if you miss a couple of packets and TCP where you can't miss packets such as file transfers. There everyone happy go home now.

Parts of the Internet currently collapsing? (4, Funny)

Anonymous Coward | more than 12 years ago | (#3862010)

Check the Internet Traffic Report [internettr...report.com]

I've noticed quite a bit of packet loss (-1, Redundant)

Anonymous Coward | more than 12 years ago | (#3862014)

But this is with IR devices in development. That's not quite the same situation, though...

Re:I've noticed quite a bit of packet loss (1)

DJ Uptime (584555) | more than 12 years ago | (#3862578)

Oh, I thought you said package loss [wavcentral.com]

diagrams (-1, Offtopic)

Horny Smurf (590916) | more than 12 years ago | (#3862049)

There's some good tcp/udp data loss idagrams here [mythunderdome.com]

Parent links to porn... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3862297)

Normal hot chick porn, mind you, but still porn.

Re:diagrams (-1)

Anal Cocks (557998) | more than 12 years ago | (#3862369)

"There's some good tcp/udp data loss idagrams here [smutserver.com] "

I just lost something, but it warn't no packets. It was hot and sticky. Any idea what it was?

Why UDP in games, TCP for bulk tranfer (5, Informative)

MonMotha (514624) | more than 12 years ago | (#3862055)

UDP is commonly used in games and other time sensitive environments precisely because it lacks reliabilty. With time sensitive data (such as streaming video or unit positions in a game), if the data gets dropped it's not worth it to retransmit, because it woudl be out of date. Therefore, the program just transmits the next update and the user sees a small skip. This is better than getting "out of sync".

TCP is designed to make unreliable networks (like the internet, which only gives "best effort delivery") reliable by ensuring that a stream can be reassembled, in order, with no missing pieces. Read the RFC for more info here. This reliability makes it good for things that need zero corruption (file transfers for example), and aren't time criticial.

Hope this helps.

--MonMotha

Re:Why UDP in games, TCP for bulk tranfer (2)

Electrum (94638) | more than 12 years ago | (#3863178)

This reliability makes it good for things that need zero corruption (file transfers for example), and aren't time criticial.

TCP and corruption is an interesting subject. TCP's error detection is only designed to solve the problem of data not being delivered. It is not designed to stop data corruption. If the transport layer corrupts data, then eventually, TCP could deliver incorrect data.

What happens if data is corrupted so that a corrupt checksum matches corrupt data? Eventually, from a probability standpoint, there will be undetected errors.

Interestin paper on Checksums, CRCs (4, Informative)

d-rock (113041) | more than 12 years ago | (#3863358)

This [nec.com] is a very interesting paper on why things don't always work like we think they should...

Derek

Re:Why UDP in games, TCP for bulk tranfer (1)

MonMotha (514624) | more than 12 years ago | (#3865796)

Sorry about the confusion there, I meant to say that it protects againts corruption due to out of order packet assembly, not packet "damage".

--MonMotha

Re:Why UDP in games, TCP for bulk tranfer (2)

stilwebm (129567) | more than 12 years ago | (#3870945)

It is *very* unlikely that a chucksum being corrupted will match the checksum of corrupted data. Possible yes, but you're looking at very small fraction there.

greek to me! (-1)

Horny Smurf (590916) | more than 12 years ago | (#3862068)

Christ, I love Greek! Women just don't seem to understand that a
man can find just as much pleasure in the warm confines of a
well-muscled ass as they can in the satin embrace of a well-wetted
cunt. Maybe we men have conditioned them too well to ignoring one
hole for the other: nonetheless, every man I've talked to about it
loves Greek and every woman who I've talked to about it has been
less than enthusiastic. So imagine my surprise last weekend when
Jenifer treated me to the joys of anal sex in what must be the
first time in five or six years.

The night started our strangely. Jenifer had just finished re-
arranging her large library and was exhausted. As suits my
biological clock, I was just coming awake at 10 PM when she was
turning in. She invited me to bed and I politely declined: I was
horny as usual and told her I'd keep her awake. After a couple of
more requests from her, I stripped and crawled in beside her.
Jenifer loves to snuggle and wasted no time in curling her small body
up next to mine. I turned and kissed her. She was oddly
responsive for her tired state, and teased me with a hint of
tongue in her kisses. I reached down to feel her muff and found it
just beginnin' to revv as her right hand slipped down her belly to
her clit.

I took up what has become my customary position between her legs -
kneeling and using my cock as a sex toy to tickle her lower labia
and the entrance to her cunt. But this time I let my aim wander
lower to the wonderful curve where ass, crotch, and leg meet. I
rubbed my cock against this soft crescent and expanded the stroke
to brush against the entrance to her ass. I noticed that every
time that my prick touched her rosebud, her strokes on her clit
quickened. It wasn't long before I was pressing the tip of my cock
against her asshole.

Surprise! My cock slipped easily into her ass until the entire
head was buried inside, and just as I was about to pull out and
apoligize, she handed me a bottle of sex lubricant and said "What
the fuck? Why not?". I pulled back and poured the lubricant on
my hard cock and noticed her pussy was swollen and very wet. I
worked my cock back into her tight asshole. It was so easy. I
could feel her ass muscles relaxing and opening for me. I eased
ever so slowly deeper. Such heaven! Like a warm, wet hand
gripping all around my prick - so much tighter than pussy, and
delightful in an entirely different way. I could feel her hips
grind against me as I worked the last of my seven-plus inches into
her tight ass. Realizing where I was and how long it had been
since I'd known this pleasure, I had to fight to pull the reigns in
on my orgasm.

It seemed like forever - my slow rocking pulling my cock almost
full-length out of her ass before easing it back in until my balls
rested against her firm buns. Her right hand furiously massaged
her clit and her left hand played at the entrance of her cunt,
pressing on the full length of her labia. And all the while my
cock was enveloped in a firm net of gripping muscles that wrestled
to bring the cum from me. "It's so weird," she said as she
searched for the grip on her own orgasm. Suddenly, it was upon
her. I felt her ass open up like a mouth that was just to blow up
a ballon. "Are you close?" she hissed. "No," I grunted.
She was close, tho'. Too close to stop. I felt her stiffen and
lurch under me. "Uuhhhh! Come on you bastard! Fill my ass!" she
yelled as she dug her nails into my back. Amazing what a little
dirty talk will do - from that special nowhere where good men hide
their orgasms until their lovers are ready, my load bolted from my
crotch to my brain and back to my flushed balls. I gripped the
pillow with my teeth and jerked my neck back and forth
and tried not to deafen Jenifer when my cum blasted out of my cock
like water from a firehose. The rush of jism racing up my tube
seemed to last for stroke after stroke until sweaty Jenifer
gasped, grunted, and pushed me from on top of her. Since I have a
little anal experience myself, I knew the sudden discomfort of
having something in your ass after you've orgasmed. I
considerately slipped out of her despite not having finsihed my own
orgasm to my complete satisfaction.

I kissed her and thanked her for her special gift, but she pushed
me away. "Go wash off and fuck my pussy," she said " I feel like
something's undone." So after a quick and thourough shower, I
returned to the futon where her dripping, swollen twat waited for
my not-quite-recovered cock.

And that's another story...

UDP Experience (4, Interesting)

mchappee (22897) | more than 12 years ago | (#3862183)

I'm firmly in the UDP camp. About 4 years ago we replaced our timeclocks at work (manufacturing facility) with hardened, wall-mounted PCs. I wrote a GTK app that started at boot up that takes the users card swipe, grabs their name from the database (for display only), and sends the clock number via UDP to the timeclock server.

During my initial proposal I mentioned to the PHBs that I would use the UDP protocol. One of my colleagues, wanting to sound important, said that UDP can be lossy. He went on to explain packet loss to the befuddled crowd. Well, the PHBs latched onto the term "packet loss". Packet loss this, packet loss that. They had no freakin' clue what it was, but it sounds pretty cool.

Anyway, I had to set up a test in which I had all of the timeclocks start a program at the same time. This program went into a tight loop of sending UDP packets (clock numbers) across the network to the server. Each one sent 1000 clock numbers, and every single one made it across. Obviously our 100mb network and proper use of subnets helped, but we haven't experienced any packet loss in the four years that these things have been running. So there. :-)

Matthew

Re:UDP Experience (1, Insightful)

Anonymous Coward | more than 12 years ago | (#3862209)

Unless an entire transaction fits in a single packet, you made a horrible decision.

Even if it does, it's still not a great decision.

Re:UDP Experience (1)

Yottabyte84 (217942) | more than 12 years ago | (#3862282)

Peharps he implemented dilevery confirmation at the application layer.

Re:UDP Experience (0)

Anonymous Coward | more than 12 years ago | (#3862536)

I have a +1 posting bonus, but it's off by default.

I have a +1 penis length, but it's off by default.

Re:UDP Experience (0)

Anonymous Coward | more than 12 years ago | (#3862587)

Only +1? Poor guy.

Re:UDP Experience (1, Informative)

Anonymous Coward | more than 12 years ago | (#3862313)

#1. Does the entire payload fit in 1 UDP packet ? If not, does the other end know how to assemble the 2+ packets correctly ? Do you have in-UDP sub-data that instructs it how to reassemble it ? If so, didn't you just re-invent the wheel (ehm. TCP ?)

#2. Within your LAN is something, out in the big bad internet is something else.

Re:UDP Experience QWZX (5, Insightful)

Anonymous Coward | more than 12 years ago | (#3862389)

/me bangs his head on his desk over and over at the sheer stupidity of this.

Dude, I hate sound flame-y, but do you have any understanding of what you implemented? That you got lucky and it "works" is totally irrelevent to the fact that it's completely unreliable. All it takes is one flakey piece of Ethernet dropping packets to SCREW UP FREAKING TIMESHEETS.

This reminds me of the morons who use MySQL for financial transactions (i.e., no transactions, no foreign keys, etc) who justify their ignorance with "well, it works so far!!"

They point isn't whether it works or not, the point is that when it fails, it fails spectacularly. Like your system. Just because you can keep spinning the chamber and the russian roulette gun never goes off doesn't mean it never will.

Seriously, you screwed up bad. These are the kinds of stories that really make me think that programmers should have some sort of licensing.

Re:UDP Experience QWZX (3, Insightful)

RobinH (124750) | more than 12 years ago | (#3866752)

Dude, I hate sound flame-y, but do you have any understanding of what you implemented? That you got lucky and it "works" is totally irrelevent to the fact that it's completely unreliable. All it takes is one flakey piece of Ethernet dropping packets to SCREW UP FREAKING TIMESHEETS.

Ok, calm down...

Now, I agree that UDP is built to be a fast, not-so-reliable protocol. One would initially presume that this is not the best thing to use on a punchclock system.

However, you have to look at the whole system.

First of all, if you put all the punchclocks, and the servers on the same subnet, then you've eliminated dropped packets due to routing.

Secondly, if you send an acknowledgement back to the clock, then it can display to the user "OK, you're signed in" or "ERROR, please retry". If you lose either the "sign-in" packet, or the acknowledgement packet, then all the user has to do it swipe again to retry.

Thirdly, these kind of systems always (should) have a manual backup, so if, for some reason, the system records Buddy punching in at 7 am, but never punching out, then a supervisor can go in and manually update the database to fix the problem.

Just remember that programs like this don't exist in a vaccuum; they are always part of a larger picture, and they need to function in that framework.

Re:UDP Experience QWZX (3, Insightful)

bugg (65930) | more than 12 years ago | (#3867154)

Secondly, if you send an acknowledgement back to the clock, then it can display to the user "OK, you're signed in" or "ERROR, please retry". If you lose either the "sign-in" packet, or the acknowledgement packet, then all the user has to do it swipe again to retry.

As a rule, people who build acknoweldgements into their UDP based protocol should have used TCP.

Re:UDP Experience QWZX (2)

pthisis (27352) | more than 12 years ago | (#3867628)

As a rule, people who build acknoweldgements into their UDP based protocol should have used TCP.

Not necessarily. A better rule is that people who build sequencing and acknowledgements in should have used TCP. But if you can do without one or the other then sometimes UDP is worth it, but not often.

Sumner

Re:UDP Experience QWZX (2)

RobinH (124750) | more than 12 years ago | (#3869901)

Not necessarily. A better rule is that people who build sequencing and acknowledgements in should have used TCP. But if you can do without one or the other then sometimes UDP is worth it, but not often.

I agree. In this case, you don't need sequencing, because there's only ever one transaction out there from each client at any given time. The transaction is as simple as "12345"->"OK". The UDP protocol is so much simpler to program (and you don't have to worry about managing connections) that for this particular application, it certainly seems worthwhile.

Re:UDP Experience QWZX (0)

Anonymous Coward | more than 12 years ago | (#3867571)

First of all, if you put all the punchclocks, and the servers on the same subnet, then you've eliminated dropped packets due to routing.

Perhaps due to routing, but you have NOT eliminated dropped packets. If you have a busy LAN and the Ethernet card can't get a turn at the wire, it will eventually drop the packet. Some cheaper cards drop it immediately if it can't send it.

Secondly... Thirdly... various gyrations...

So exactly WHAT is the advantage of using UDP rather than TCP in this instance? Why go through all this crap when you can just use TCP?

Re:UDP Experience QWZX (2)

fwc (168330) | more than 12 years ago | (#3868579)

So exactly WHAT is the advantage of using UDP rather than TCP in this instance?

I of course don't know about the original poster's actual implementation.

I'm making the assumption timeclocks themselves are very lightweight (or thin) devices, CPU and memory wise.

The problem with TCP for a truly embedded application is that you have to play a lot of keep-state programming to implement even a minimal TCP stack.

A minimal UDP stack is much smaller. Everything you need to do with UDP is rather stateless.

Ignoring ARP and ICMP for a second (which is the same for TCP and UDP), sending a single message via UDP consists of encapsulating the packet and sending it. With TCP you have to send a SYN, then wait for a SYN-ACK, then send an ACK back (possibly containing data), and then you have to deal with closing the connection.

Maybe a better way to describe this is that UDP is a DATAGRAM protocol. I.E. you format a datagram and send it. By contrast TCP is designed for a mostly-reliable almost-serial-like stream, with congestion control, retransmission, etc. etc.

I was going to try to make a case for TCP in the timeclock example where a larger machine is available. I just can't see a good reason for the TCP overhead in this app. I mean, what exactly are they going to be sending... Something like "Employee 308 clock in", which the server is going to say "Got it, employee 308"?

If you haven't written low-level embedded networking code you really don't realize how much overhead is in TCP. Heck, just to get a TCP session set up and torn down you need 7 packets:

--> SYN
<-- SYN-ACK
--> ACK

(Session Established)

<-- FIN
--> ACK
--> FIN
<-- ACK

With UDP you only need 2 (1 each way) to send your message and get it acknowdged.

Don't get me wrong, I'm a fan of TCP in the right places. Any message over the ~1400-1500 MTU size of a UDP packet should probably be sent via TCP.

Re:UDP Experience QWZX (2)

RobinH (124750) | more than 12 years ago | (#3869954)

I was going to try to make a case for TCP in the timeclock example where a larger machine is available. I just can't see a good reason for the TCP overhead in this app. I mean, what exactly are they going to be sending... Something like "Employee 308 clock in", which the server is going to say "Got it, employee 308"?

Actually, the timeclocks he describes are fully fledged PCs, I believe, and they do support a full TCP stack already. However, considering the differences in complexity of the server, I still would favour a UDP solution.

As an example, for the server to implement TCP, you would need to listen on a port, deal with an incoming connection (maybe fork off another process), deal with connection timeouts, etc.. With UDP, you can just have one single procedure that's called when a packet arrives. The procedure parses out the employee number from "Employee 308 signing in", updates the employee database, and sends a UDP message back, i.e. "Employee 308 signed in". This tolerates dropped packets (the employee just swipes again), and most importantly, the implementation is practically stateless, and that's a much simpler architecture. Never underestimate the KISS principle.

Re:UDP Experience QWZX (2)

Wonko42 (29194) | more than 12 years ago | (#3869722)

This reminds me of the morons who use MySQL for financial transactions (i.e., no transactions, no foreign keys, etc) who justify their ignorance with "well, it works so far!!"

When was the last time you used MySQL? MySQL now supports several table types other than the default MyISAM type, including types with full transaction support.

Re:UDP Experience (1, Insightful)

Anonymous Coward | more than 12 years ago | (#3862586)

Thats crazy. A few dropped packets and those PHBs are going to be pretty pissed. UDP has its place but depending on it for people's timesheets isn't one of them. Its just a matter of time before you get someone who punched in at 8am and never punched out. What are you going to tell the PHBs then?

Re:UDP Experience (2)

mgblst (80109) | more than 12 years ago | (#3862822)

What is a packet became corrupted, something that will happen. YOu need to build reliability into the application layer, whereas with TCP it is there already.

So, what you're saying is... (4, Funny)

Wonko42 (29194) | more than 12 years ago | (#3863102)

I'm a skydiver. I never use a parachute. Instead, I just jump out of planes and hope that I land on a large air mattress. It's worked perfectly so far. Why should I switch? All you silly fools using parachutes make me laugh.

Re:UDP Experience (0, Redundant)

bellings (137948) | more than 12 years ago | (#3863142)

wh00t! You're the best troll here, dude! Using UDP for financial data! ROFLMAO at your lovely troll, dude!

And you got a lot of bites, too! A lot of people on Slashdot are so stupid, they actually believe there's a human on the planet who would use UDP for a timeclock! Ha ha ha! Stupid Slashdoters. They'll bite on the stupidest, most inane claims.

Re:UDP Experience (1)

Tto (52964) | more than 12 years ago | (#3865133)

Well the main problem on TCP, will be the scalability. Few, small transactions on a LAN can work correctly, so if your application ever will run on that environment, then everything should be OK.

Problem would arise if the system would increase the number of transactions, the size of them, or the area of the network (From LAN to MAN, or WAN).

From experience, I worked on "debugging" an small database application that used UDP. They added remote dial in clients. While it worked smoothly on a LAN, with few routers, at the moment that dial in customers started trying to update data on the system the fun started :). The original developer, assumed that they'd never change the environment, and had an scheme for fix retransmitions that worked OK on the LAN, but constantly gave the dial in clients a bad time.

Re:UDP Experience (1)

phanki (531123) | more than 12 years ago | (#3868917)

But what you are talking about is an application that sends the clock number. The number of packtets hitting the time server though many would not be very big. This means that the load may not be very much. Whereas when we talk about a gaming application the payload *can* be heavy. In which case there are chances of packet loss.

Re:UDP Experience (1)

AngrySpade (592351) | more than 12 years ago | (#3871244)

Within our company we have done extensive testing on this. We found that if UDP packets are sent consecutively under 5ms intervals the loss is approximatley 3-5% (if this is the only network traffic!). If you decrease the interval, you will notice a logarithmic increase in packet loss.

Definitely (5, Informative)

austad (22163) | more than 12 years ago | (#3862252)

I run a cluster of high volume mail servers that use syslog-ng to log to a remote syslog server. This reduces disk IO for each message and actually gives a very noticable performance increase. However, I noticed under periods of very high volume, I was losing nearly 50% of my log entries. Syslog-ng has the ability to use TCP for logging, so I switched, and I haven't lost any entries yet.

UDP is great for things you that aren't useful if retransmitted later, like real time apps (Quake, video streams, audio streams, etc.) But to ensure no loss at all, you need to use TCP.

What argument? (4, Insightful)

jkujawa (56195) | more than 12 years ago | (#3862257)

Jesus. Both have their uses. You use TCP if you need the reliability, and a stateful connection. You use UDP if it doesn't matter that a packet gets dropped here or there. Things like games and streaming media are good examples. This is rather like comparing Pepsi to milk. They both have their place. It's the job of a good engineer to determine which is most apropriate.

Re:What argument? (1)

Phosphor3k (542747) | more than 12 years ago | (#3862287)

This is rather like comparing Pepsi to milk. They both have their place. In my belly?

Re:What argument? (2)

Muad'Dave (255648) | more than 12 years ago | (#3866419)


Along with some <FatB*stard> Baby - the other, other white meat!</FatB*stard>

Re:What argument? (0)

Anonymous Coward | more than 12 years ago | (#3862432)

No, it would be like comparing Pepsi to Coke, especially on Slashdot. An artifically coloured can of acid has nothing to do with cow juice.

Re:What argument? (0)

Anonymous Coward | more than 12 years ago | (#3863124)

The main ingredient is IP, uhm I mean water. What was your point?

Re:What argument? (3, Funny)

tunah (530328) | more than 12 years ago | (#3862437)

This is rather like comparing Pepsi to milk. They both have their place.

Except for pepsi.

Re:What argument? (1)

Icculus (33027) | more than 12 years ago | (#3863383)

This is rather like comparing Pepsi to milk. They both have their place.
Except for pepsi.

And milk [notmilk.com]

Re:What argument? (2)

4of12 (97621) | more than 12 years ago | (#3863962)

Seems like UDP would work OK on an unclogged network and have the benefit of adding less congestion compared to TCP with all of its handshaking.

For an low traffic, more or less isolated network, UDP might be a simple solution. OTOH, with PCs with 100 Mb cards so cheap these days, people could probably afford the extra buzz of TCP without noticing any appreciable degradation of performance or incurring great cost.

The day the network starts to become the least bit congested and any UDP packets get dropped, then everyone shifts to TCP and things start to really get congested.

A binary QoS mechanism exhibiting an inherent problem.

yet another stupid slashdot question (0)

Anonymous Coward | more than 12 years ago | (#3862295)

never seen udp packet loss over local networks, over the internet, it happens all the time.

why didnt the question asker open his/her copy of stevens ? anyone doing network programming has it on their bookshelf

Re:yet another stupid slashdot question (0)

Anonymous Coward | more than 12 years ago | (#3862626)

Well all the internet is just one big local network. Sure if you have a few computers on a switch you aren't going to see any packet loss, but given enough stuff in between, it'll happen. And what happens when the customer/phb/whatever who said the application will never be used over the internet changes their mind? (Oh yeah, customers and phb's don't change their mind...)

Re:yet another stupid slashdot question (0)

Anonymous Coward | more than 12 years ago | (#3862650)

To add to that, what happens when one of your hubs or switches starts to die. I've seen hubs dying that still kinda worked only you got about 70-80% packet loss. With UDP you'd be screwed, with TCP you'd be able to stay up and running until you got the hub replaced.

I wouldn't know. (2, Funny)

Wakko Warner (324) | more than 12 years ago | (#3862316)

The only protocol I ever use is ICMP.

- A.P.

Re:I wouldn't know. (0)

Anonymous Coward | more than 12 years ago | (#3862460)

Why is this comment rated 2? You need to you ip/tcp/http to be posting to slashdot.

Re:I wouldn't know. (0)

Anonymous Coward | more than 12 years ago | (#3862603)

Why is this comment rated 2?
It wasn't rated 2. The parent poster has a high enough karma to post at a default 2. You obviously must be new around here. To look at the moderation just click the comment number.

Re:I wouldn't know. (0)

Anonymous Coward | more than 12 years ago | (#3862836)

Me either. What a sorry excuse for a rap group.

The question is: (1)

Cuthalion (65550) | more than 12 years ago | (#3862539)

Alright, if you're doing anything over the real internet, you will encounter packet loss. So what do you want to happen when packet loss occurs? Here are your options:
  1. Automatically and transparently timeout waiting for the packet, and ask for retransmission. In this case, use TCP.
  2. Anything else. In this case, use UDP.
As an example of "Anything Else" maybe notice that a packet is missing, ask for a retransmission, and draw a little rendered animation of a gerbil chewing on a length of cat5utp in the corner of the screen.

non-determinstic ? (2)

heliocentric (74613) | more than 12 years ago | (#3862641)

Could you please elaborate on that for me? I always though NTM's (non-determinstic Turing Machines) were so powerful since they always made the "right" decision and didn't need luck or a specific rule set, they just non-determinstically chose the right path.

If you have a network that is just sending packets correctly with out decisions then all the better and we should take it on tour. Maybe, however you're refering to the complete broadcast mentality that packets aren't sent to specific hosts as required but to all hosts since this is how non-determinism is typically simulated, but simulated non-determinism and true non-determinism are a tad different.

Maybe it's just that I don't really know a lot of networking theory, but that term just sort of jumped out at me. I've often equated non-determinism with magic...

Re:non-determinstic ? (1)

ultima (3696) | more than 12 years ago | (#3873887)

In the context of networking, TCP can be considered deterministic because the output of the connection on the receiving end will be identical in all ways to the input of the connection on the transmitting end. This is not the case in UDP, where it is possible for packets to arrive in a different order than they were transmitted, or not at all. This is the heart of determinism: a deterministic algorithm has one and only one possible path for each possible input.

A deterministic system maps input to output in 1:1, non-deterministic maps input to output in 1:some_number

Note that TCP isn't really deterministic: What if all the routes between the source and destination go down? The packet won't be received. It's just that it's more likely to be deterministic. And anyway, TCP packets get dropped just like UDP packets; it's just that TCP packets get resent.

btw, this has nothing to do with the "magic" that non-deterministic systems exhibit (these systems can work by looking for a specific output for a specific input out of all the outputs that can be generated from that input).

Multicast (2)

stere0 (526823) | more than 12 years ago | (#3862890)

I used to work with a company that sent data (mostly video) to all customers via satellite, in multicast. The uplink went through the terrestrial network. IIRC, the whole traffic was sent over UDP.

real life experience (1)

cheezehead (167366) | more than 12 years ago | (#3863131)

As some people have pointed out, both UDP and TCP have their advantages. Note though, that for some applications you don't want retransmission at all! What's the point in having part of an audio stream retransmitted, or a video stream for that matter? It only makes things worse.

An excellent example comes from my own experience. Years ago we built a system that needed to synchronize system clocks between a server (hooked up to an atomic clock) and a bunch of workstations (I know about NTP, it was just too complicated for our humble needs). The server would broadcast the time over UDP every 30 seconds, and the workstations would synchronize their system clocks. This is a typical example where you don't want retransmission of lost packets, since the data (i.e., the system time) has become invalid in the mean time. Better to wait for the next update, since the system clocks will drift only microseconds in 30 seconds anyway.

Before implementing this, I sort of tested UDP reliability. I was warned about dropped packets, corrupted packets and packets delivered out of sequence. The test consisted of pumping out as many packets as possible, and see what happens. I never ever saw a single corrupted packet, or a packet delivered out of sequence! The only errors I could force were dropped packets, basically by overflowing the socket buffers on the receiving end. This test brought the network (10 Mb/s Ethernet LAN) completely to it's knees, by the way (got me the honorary title of "the network killer"). Millions and millions of packets sent, only dropped packets, never anything else.

Now, this was an isolated LAN (more or less) without crazy geeks downloading DivX movies, but the hardware wasn't all that spectacular either (SparcStation 10 server, 64MB RAM, SparcStation 5 workstations, 16MB RAM -- no typo!).

I ran some more tests with more 'normal' network loads, and I never, ever, detected a single problem.

So, your mileage may vary, but I think that problems with UDP typically would happen under circumstances (i.e., severe network congestion)that would also affect TCP.

Silly idea: you could use UDP with Forward Error Correction if your data is important. Plenty of textbooks about coding theory that explain the theory behind it, and how to design your customized error-correcting code. As long as you stay within the Shannon limit (i.e. don't try to exceed your channel capacity), you can make the error probability arbitrarily low. Doesn't help with disconnected cables an the like, since your channel capacity is zero then... Oh well, you can't win...

Re:real life experience (2)

iangoldby (552781) | more than 12 years ago | (#3863480)

On a simple network, you won't get out-of-sequence packets with UDP.

Out-of-sequence delivery happens when there is more than one possible route for the packet, such as occurs over the internet. On the internet, routing is done on a case-by-case best effort basis. It's possible then for the first packet to be sent via a longer route than the second and therefore for the second packet to arrive first.

So remember - UDP across a LAN is quite a different beast to UDP across the internet.

Re:real life experience (1)

cheezehead (167366) | more than 12 years ago | (#3865080)

That's an excellent point. I sort of meant to hint at that, but I guess I should have put more emphasis on our particular setup.

Anyway, it's a relevant point to the original question: it's not just the applications and network load that matter, it's also the network topology.

Lemme get this straight. (3, Funny)

FreeLinux (555387) | more than 12 years ago | (#3863747)

NTP was too complicated(??) so, you designed built and tested your own homegrown version of NTP??????

To quote Dr. Evil, "Riiiight...".

Re:Lemme get this straight. (1)

cheezehead (167366) | more than 12 years ago | (#3865056)

Whatever. All I can remember that in those days we looked at NTP (or maybe it was NNTP??), and did not like the idea of going through and possibly maintaining 40,000 lines of C (that's the way it was in '94, or at least that's how I remember it).
Our "homegrown NTP" as you call it wasn't even close to that. All we needed was a simple way to keep system clocks in line, with an accuracy of a few tenths of a second. We accomplished this in a few dozen lines of C++ (a generic message broadcasting mechanism over UDP was already implemented).

In hindsight you can always question decisions like that, but bottom line is that we had a simple problem, and we fixed it with a simple solution.

And the software (control system for rocket launches) has been in operational use since 1996, without any major problems, thank you.

Re:Lemme get this straight. (2, Funny)

schon (31600) | more than 12 years ago | (#3865082)

All I can remember that in those days we looked at NTP (or maybe it was NNTP??)... All we needed was a simple way to keep system clocks in line, with an accuracy of a few tenths of a second.

Ahem.. you were going to use usenet posts to synchronize your system time?!?!?!

Bwahahahahah...

(wipes tear from eye)
*sigh*, that was a good one - To quote FreeLinux, 'To quote Dr. Evil, "Riiiight...".'

Re:Lemme get this straight. (1)

cheezehead (167366) | more than 12 years ago | (#3865169)

Ok, you got me. I made a mistake. This was 8 years ago, we looked at something which sounded similar to 'NTP'. I can't remember what it was called exactly any more, and I'm not gonna waste more time on it. All I know is that we analyzed the problem, evaluated what was available, and made a decision.

Re:Lemme get this straight. (1)

cheezehead (167366) | more than 12 years ago | (#3865215)

Hah, OK, I've found it. It was called 'xntp', where the 'x' apparently stood for 'experimental', rather than 'X' as in 'X-server'.

Multicasting MPEG (2)

Martin Spamer (244245) | more than 12 years ago | (#3863156)

One of the points for using UDP over TCP is where 'guaranteed' data data delivery is not a 'hard' required. i.e. It does not cause a catastrophic failure.

We use Multicasting (IGMP is built on UDP) to 'broadcast' MPEG Video over an IP network for an Interactive DTV (www.kitv.co.uk) project.

This functions largely without problems, because maintaining an MPEG steam is highly time sensitive but it is not catastrophically sensitive to lost or dropped packets. These lost/dropped packets lead to video artifacts and not total loss of data, because the video stream can continue from the next received packet.

The quality issue is governed by *minimising* the lost packets not 'guaranteeing' them

packet loss expierenced using tcp (1)

NateSac (579551) | more than 12 years ago | (#3863220)

packet loss expierenced using tcp A while back i was getting alot of CRC errors with tcp transfers. Just to give you an idea how bad it was if I downloaded 40 - 15 meg files, at least half would have CRC errors. I never recieved any error messages during the transferes and I used multiple protocols, client apps, even diffrent computers on my lan. I isolated the problem by replacing siemens speedstream nat router with a custom built router, and I've had no crc errors yet.
My point... I thought tcp wasnt supposed to let that happen, then again, maybee i should just blame the router. Has any one else have simular problems with cheap nat routers or is this post on topic?

Re:packet loss expierenced using tcp (2)

Jeremi (14640) | more than 12 years ago | (#3864618)

Just to give you an idea how bad it was if I downloaded 40 - 15 meg files, at least half would have CRC errors [...] I thought tcp wasnt supposed to let that happen, then again, maybee i should just blame the router. Has any one else have simular problems with cheap nat routers or is this post on topic?

Alas, I've seen this too. I wrote a file sharing program that uses TCP for file transfers, and has a download-resume feature that does an md5 checksum of the user's local file portion, and only starts the resume if the local file portion matches the corresponding portion of the uploader's file.

Every few days, I would get complaints from users that the auto-resume wasn't working. It was refusing to resume because the two file fragments' hashcodes didn't match. After going over all my checksum code checking for bugs, I finally got paranoid and added an application-computed checksum every so often to my TCP data.... and sure enough, in some cases the TCP data I sent would arrive at the downloader's machine with a checksum mismatch. Unfortunately, I haven't been able to finger a particular piece of software or hardware that causes this, but I can confirm that it does sometimes happen. :^(

Re:packet loss expierenced using tcp (0)

Anonymous Coward | more than 12 years ago | (#3864938)

It's called WINDOWS.

Re:packet loss expierenced using tcp (2)

Jeremi (14640) | more than 12 years ago | (#3866999)

It's called WINDOWS.

Doubtful, in this case.... this program was only available for BeOS.

Wireless (2)

epsalon (518482) | more than 12 years ago | (#3863221)

Also, there is an issue of IP over wireless, where packet loss is a given, at quite high rates. Thus, if you need the reliability either use TCP or add a reliability layer over UDP.

In most cases using UDP is a loss (4, Informative)

WolfWithoutAClause (162946) | more than 12 years ago | (#3863251)

If you have very special requirements, or very non special requirements, or you simply can't use TCP for some reason, then UDP can give you better performance. But it usually won't.

About the only reason for using UDP is if you deliberately want to circumvent the congestion avoidance protocols that are built into TCP. So, if you are playing a game, and you need the packets to get through at all costs, but you aren't sending many packets- by using UDP you can agressively defend the small amount of bandwidth you need- any TCP connections around will tend to back off and get out of your way; and that's reasonable if you code it carefully. But writing the protocol to do that is hard, you have to understand not only UDP but also TCP, as well as your game requirements.

And that's the real problem. In most cases people think that waving UDP at the problem will solve their problems- in fact it makes them worse; and TCP has solutions to problems only PhDs have even thought of, and the solutions are built in.

As an example, somebody I know implemented a tftp protocol using UDP. The guy is off the chart in his software abilities (trust me the guy is amazing, he's in the top 2 percent of software engineers according to the tests). Anyway in a back-back comparison against a standard ftp protocol- the tftp protocol loses by a factor of 10 or more (on a network with some congestion, I expect a quiescent network would have been much more level). Of course tftp isn't supposed to handle congestion. But that's the problem- UDP can't handle network congestion out of the box... indeed if anything it tends to create network congestion.

The main algorithms in tcp include 'slow start' and 'exponential backoff'. Both of these are missing in UDP, and both improve the network performance enormously. If your application doesn't affect network performance and doesn't worry about packet loss much, then UDP may be the way to go, otherwise stay away from UDP.

Re:In most cases using UDP is a loss (2)

sudog (101964) | more than 12 years ago | (#3865299)

You don't know what you're talking about.

You started out okay and then sank into total bullshit land as soon as you mentioned your uber-friend's tftp implementation. Newsflash: tftp is UDP from the get-go. That's the whole point. And since tftp is a request-response type protocol, of *course* it's going to see less performance out of your networks than ftp. On the other hand, try these guys. [dataexpedition.com] They built a faster-than-tcp implementation of a streaming protocol using UDP and it outperforms TCP on high-path networks and does *at least as well as* TCP on the LAN.

There is no way to "aggressively defend" your bandwidth if (for example) you're playing a game. If someone else comes along with their own UDP application that doesn't back off when detected packet loss gets extremely high, you lose out just as much as they do. There is no defence in this case, there is only *higher packet loss.*

And claiming your friend is "off the chart" like that--what is that supposed to do--lend credence to your exaggerated and false claims about UDP? Bzzzt. Nobody cares about test scores--especially for someone who re-implemented a trivial file transfer program using the very protocol it was designed for to begin with. Tell you what--you show us something impressive he did and we'll be impressed. Don't beak off about "trust me" and "he's in the top 2 percent". That's just crap--you didn't even tell us what the tests were or who administered them!

Finally, UDP wasn't designed to handle congestion. But that doesn't mean it can't. Counter-example: build congestion avoidance into your application.

Readers, don't listen to the parent of this note, he doesn't know what he's talking about. Anything TCP can do, UDP can do--the problem lies in how much work you have to do to implement it. TCP is convenience because all the work for a streaming, in-order, semi-reliable, congestion avoiding protocol has been done for you. Unfortunately you can't turn the major features you don't want, off.

Yeesh. Someone mod parent down, it's really not worth a 4.

Re:In most cases using UDP is a loss (2)

WolfWithoutAClause (162946) | more than 12 years ago | (#3865571)

Newsflash: tftp is UDP from the get-go. That's the whole point. And since tftp is a request-response type protocol, of *course* it's going to see less performance out of your networks than ftp.

Precisely! It's supposed to be a lightweight protocol, which is one of the reasons people choose UDP, but it turns out to be slower in this case. And it's because of what's been left out of the UDP protocol stack; UDP isn't inherently bad because of this, but usually you would want what's been left out. Right now I would not want to deploy tftp ever, it lacks passwords, and it's performance is poor on a congested network.

Finally, UDP wasn't designed to handle congestion. But that doesn't mean it can't. Counter-example: build congestion avoidance into your application.

Absolutely, but then you have to implement it yourself! And it is very much not simple.

There is no way to "aggressively defend" your bandwidth if (for example) you're playing a game. If someone else comes along with their own UDP application that doesn't back off when detected packet loss gets extremely high, you lose out just as much as they do. There is no defence in this case, there is only *higher packet loss.*

Being aggressive does not guarantee more bandwidth. But in most situations most other people are using ftp/http etc. they normally will back off and you will get more bandwidth if your protocol is aggressive. Of course if everyone is aggressive, especially inappropriately- you and everyone else ends up losing worse than if you'd have used TCP; it's rather like real life. It probably only makes sense in cases where you only need a small amount of bandwidth; but you NEED that bandwidth. If you start to lose packets due to congestion, you are supposed to send more slowly. However, if you increase the rate you send, you end up with a bigger slice of the pie; if the slice is then enough for what you need, you can control your bandwidth to some extent. However, ultimately you can't send more than your pipe will take, so really heavy congestion will still kill you.

Anything TCP can do, UDP can do--the problem lies in how much work you have to do to implement it.

Yes. Exactly. It's often a lot more work, and unless you really, really know what you are doing UDP is likely to be the wrong choice.

UDP can be made to go as fast or faster than TCP (2)

Great_Jehovah (3984) | more than 12 years ago | (#3865854)

I just finished writing a UDP file transfer protocol that goes just as fast as TCP on a clean network and handily outperforms it on noisy ones.

Exponential backoff is braindead when you need good thoughput on a fat but noisy pipe. The reason TFTP gets lousy throughput is not because it uses UDP but because it waits for every ACK before it sends the next packet rather than having a receiver window feature like TCP does.

Apparently you have to be smarter than mister Top 2 Percent to make this work.

Here's some links for you:

Re:UDP can be made to go as fast or faster than TC (1)

sudog (101964) | more than 12 years ago | (#3865979)

Good luck with that. Try and see whether your custom application works so well with extremely large files where the packets are delivered out-of-order. Use two dummynet's connected end to end--after you're done testing with the dummynet's, come back and let us know whether it really does outperform TCP for extremely large files. (Like, tens of gigabytes.)

Re:UDP can be made to go as fast or faster than TC (2)

WolfWithoutAClause (162946) | more than 12 years ago | (#3866231)

Apparently you have to be smarter than mister Top 2 Percent to make this work.

Actually he's very capable of doing this kind of stuff right. More or less he had to follow the tftp spec, so what's he gonna do?

But my real point is still that most people don't know enough to do it right.

You certainly sound like you might have your head around what TCP does, so probably your protocol works very well.

Exponential backoff is braindead when you need good thoughput on a fat but noisy pipe.

Yes, you are optimising your protocol to deal with cases where packet loss is caused by noise. The internet is built mostly on the assumption that packet loss is caused by congestion, so of course TCP will perform more poorly, and a more tailored protocol is a win, and UDP allows you to do that.

I do wonder if your protocol might trigger congestion collapse, but I have no doubt you've designed against that and tested for it too.

UDP and TCP flow control (1)

Mr. Shiny And New (525071) | more than 12 years ago | (#3863309)

Since TCP has flow control and UDP doesn't, you can actually cause your network connection to saturate with a couple UDP connections and then you won't be able to make any TCP connections. UDP doesn't play very well with others. I believe there is a new protocol in the works that is like UDP but plays better with TCP.

Also, some TCP stacks are implemented in a way that if you start TCP connections one-after-another, after you let the latest one peak in its bandwidth usage, the third or higher TCP connections will not be able to grab any bandwidth. This is appearantly a problem with windows 9x and some ADSL connections. The TCP flow control lets the first two connections split the bandwidth between each other, but the third connection can't ramp up enough bandwidth and just chokes. Appearantly this problem is mitigated by using different types of network connections or different operating systems.

Re:UDP and TCP flow control (2)

kevin42 (161303) | more than 12 years ago | (#3864027)

UDP does have flow control, as does all IP traffic. Unfortunately the sockets API don't consistently support it. It's called an ICMP source quench message, and it tells the sending application that the receiving side couldn't keep up (or a router in the middle couldn't keep up). It's not UDP's fault that the APIs don't support flow control well, it's the fault of the OS and the sockets layers that it's not easy to use.

Re:UDP and TCP flow control (1)

Mawbid (3993) | more than 12 years ago | (#3864842)

Source quench sounds like a wonderful DOS tool, which is probably why a couple of netfilter guides I've read recommend you drop those packets.

Tricker to shape UDP (1)

Sits (117492) | more than 12 years ago | (#3863602)

When things get rough sometimes it can be difficult to reign back a UDP stream (in comparison to a TCP one) if bandwidth is being shared. UDP streams are often unresponsive and having the odd packet dropped here and there simply will not cause the rate of packets to be slowed down (there are various solutions to this though).

However as others have pointed out, which you use should depend upon the situation. If getting packets out of sequence is not so important (e.g. video streaming) then great but if reliablity is absolutely essential then TCP is probably better (plus TCP tends to still work when computers are stuck behind restrictive stateful firewalls).

Coding philosophy (3, Insightful)

kevin42 (161303) | more than 12 years ago | (#3863976)

I've spent the past several years writing networking applications, and this is my philosophy: Anytime there is *any* chance of a packet being lost or arriving out of order, you must write code that assumes every packet has a high probability of being lost. I've seen people make assumptions that since it's running on an ethernet lan they will never lose UDP packets, then their app becomes very unstable. Even when sending UDP packets to localhost they can be lost. When designing UDP software it shouldn't be a matter of how often packets are lost, but how well your code deals with lost packets.
Now if only someone would standardize a reliable datagram protocol implementation. :)

Re:Coding philosophy (1)

Bryan Andersen (16514) | more than 12 years ago | (#3867709)

I've spent the past several years writing networking applications, and this is my philosophy: Anytime there is *any* chance of a packet being lost or arriving out of order, you must write code that assumes every packet has a high probability of being lost. I've seen people make assumptions that since it's running on an ethernet lan they will never lose UDP packets, then their app becomes very unstable. Even when sending UDP packets to localhost they can be lost. When designing UDP software it shouldn't be a matter of how often packets are lost, but how well your code deals with lost packets.

This is vary true. You must code UDP applications to deal with packet loss, and yes packets can be dropped when going from localhost to localhost. Overfill the network transmit or receive capacities or use up all buffer space, packets will be dropped. There is no way around that without changing the UDP protocal. Afterall if your application sends out 10,000 UDP packets per second and the network can only handle 2,000 per second, the other 8,000 are to be dropped. For TCP connection loss is all you have to code for.

Packet loss == upgrade network (2)

bluGill (862) | more than 12 years ago | (#3864080)

OKay, a very small amount of packet loss can be normal and should be ignored. However if you have anything other than a tiny amount of packet loss your network is in trouble, and in serious need of upgrades. Remember packet loss starts to casscade, because the droped packets have to traverse the network two or more times, and each time it crosses the network it uses some bandwidth. One droped packet, but when it is re-transmitted some other packet is droped and re-transmitted, and as a result your network gets really slow. In theory tcp will just slow down, but users will re-start the slow jobs trying to get a fast connection.

Sure, TCP will get through even when you have 85% packet loss, (I had a customer who had 85% packet loss once, a babybell I won't name) but your applications will often start timing out in other areas. In theory things should still operate, but they just get slow, but many programs have their own timeout outside of tcp so they can detect when the connection when down.

Don't use tcp where you don't need it though. I once had to debug a heartbeat for a failover system, where the system only provided tcp packets. When there was a failure in the network we could switch the network easially enough, but then we had a lot of code to try to figgure out if the heartbeat that just arrived after the network switch was old (and contained invalid information about the failed node), or correct. It always seemed to work, but I didn't sleep well many nights knowing that a customer could lose a critical computer because of code that I was supposed to make work.

So in theory you can say TCP is better when there is expected to be packet loss, and UDP is better when lost packets should be ignored. In parctice though, if you have significant packet loss you need to upgrade the network.

Yep. (1)

gfilion (80497) | more than 12 years ago | (#3865019)

Yep, I did.

In one of our course, we had to do a network game in Java and we decided to use UDP. When we where using it in the university Labs (130 boxens, 100 Mbps) we had a packet loss of about 5%. Mainly caused by ethernet collisions I guess.

tcp vs udp.. (2)

josepha48 (13953) | more than 12 years ago | (#3865055)

you may or may not know when one craps out. That all depends on the programmer and what they check for. In the case of tcp / ip if a programmer assumes that all is okay they can keep sending data to a connection that is failing. If they do not check for certain statuses then it could fail and you wont know it. Same is true I'm sure for udp.

The best method is really a send / reply setup in your code. You send data and the other side replys with I got it (or something). Like what is done in RFC 821 - SMTP.

SCTP (1)

dolt (23627) | more than 12 years ago | (#3865119)

Read about SCTP, Stream Control Transfer Protocol, RFC2960 [ietf.org] , which combines the best of TCP with the best of UDP. SCTP is a protocol (that is, it doesn't run over UDP or over TCP), and provides the following features:

acknowledged error-free non-duplicated transfer of user data,
data fragmentation to conform to discovered path MTU size,
sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,
optional bundling of multiple user messages into a single SCTP packet, and
network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

Implementations are already available or becoming available, on various OSs. Although designed for transporting real-time telephone signalling over IP (as stated in the RFC), it is applicable to anything else with similar requirements.

What is UDP good for? (2)

Nyarly (104096) | more than 12 years ago | (#3865214)

In what really ought to be called the Slashdot Effect, I've just read 50 or so comments where the most useful 5% all said the same thing: if you're writing a game or streaming video, use UDP, otherwise stick to TCP. But, what bugs me is that this is a very narrow view of the differences between the two protocols.

Frankly, the single most important use of UDP is for sending singleton datagrams. Not to be pissy but, um... duh. Consider how DNS works: queries are sent as UDP, and if the reponse is small enough it goes back in a UDP packet. If it's too big, it's sent as a TCP stream. Prime example of what UDP is good for.

Frankly, as far as UDP streams are concerned, I've never found a use for them that didn't involve a realtime response on the receiving end. Network gaming and video streaming is one idea, but certain kinds of telecontrol are another.

The thing that bugs me most is that, by trade I am not a network programmer. I have done network stuff in the past, but it upsets me that the sum of information in all the commentary on Slashdot is more and more frequently less than I already knew about the topics.

Maybe Bruce Perens [slashdot.org] is right.

Perhaps the dumbest ask slashdot all day... (0)

Eliza Troll (589949) | more than 12 years ago | (#3865721)

What the hell is a "TCP User" or a "UDP User"? I've never heard of someone classifying them into one camp or the other. What do you think this is, the next religious war? Emacs! Vi! TCP! UDP!

pr0n suckage causing crc errors? (2)

LWolenczak (10527) | more than 12 years ago | (#3866611)

I have a fairly high traffic enviroment.... (my boss pulling pr0n from news servers on our internet connections constant......) Most days.... I see about 97% usage of the connections... Scarry huh? I haven't noticed many UDP dropped packets.... Infact... I think I'm seeing more mangled UDP packets that are failing the crc test then packets being dropped. I do have QoS enabled, which allows my web browsing... or software downloads to take his bandwidth right out from under him.

NFS uses UDP. (2)

Jason Pollock (45537) | more than 12 years ago | (#3867641)

Everyone's arguing back and forth about which is better, UDP, TCP, some are even presenting other protocols such as SCTP. None of it matters, because the protocol you use depends on what the problem is.

From what I understand, UDP will lose packets in a congested environment when passing across a router. Your stack will guarantee that the packet gets onto the wire, if it gets onto the wire, it will make it onto the other machine if it is on the same wire (subnet) (barring sunspots). As soon as it hits a router, then it can be dropped.

TCP has some nasty timers in it that make it entirely unsuitable for real-time traffic. It assumes that a packet was lost because of congestion, and backs off on the retry, rather than retransmitting immediately. In modern corporate/telco IP networks congestion simply isn't the case. What really is bad is having to wait up to 4+minutes to find out the connection is dead.

UDP allows you to do what you want, and avoid anything you don't need. However, if you need things like in-order, reliable transmission you are probably better off with TCP. If you are simply providing a response, then you should be fine with UDP.

If you are after high-traffic, high connection, high throughput, UDP seems to be the way to go. If you are after easy programming and guaranteed in-order delivery, TCP is your tool.

As someone pointed out, there is a new player in town, and that's SCTP. It was invented specifically because TCP is bad for low-latency transmissions (such as Telephony!). It is used in the SS7 over IP protocols, such as M3UA, SUA, etc.

That is why you will see a mix of streams in various protocols. H.323 uses TCP for control, and UDP for speech/video. SIP allows you the choice of UDP/TCP for call control.

Jason Pollock

Re:NFS uses UDP. (0)

Anonymous Coward | more than 12 years ago | (#3871019)

I've worked in many a code shop where the client server SCM solutions like CVS were unheard of (CVSW uses TCP connections for file transfer BTW) and some scheme using either RCS or SCCS over NFS was in place. They were always unreliable. You could occasionally demonstrate it using something like:

ls /some/nfs/path/to/code/repository
and every once in a while ls would report an error that the directory did not exist or that it contained no files (when it fact it had several dozen). The caching mechanisms inherent in most NFS clients are such that the glitch will go away on retry. You can always spot such shops as the just try to rebuild it and see what happens type of place. On the second build attempt no code has been changed but the faulty distribution mechanism (over NFS) seems to work the second time.

NFS is the buggiest piece of unreliability ever foisted on the computing world, specifically because it trades TCP reliability for UDP speed: just say no

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?