Slashdot Mirror
UDP - Packet Loss in Real Life?
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?"
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.
this is the most important sig ever! In your face 446154!
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.
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.
I don't care if it's 90,000 hectares. That lake was not my doing.
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.
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?
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.
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.
"I have never let my schooling interfere with my education." - Mark Twain
As a rule, people who build acknoweldgements into their UDP based protocol should have used TCP.
-bugg