> But, while I understand that, once a UDP message leaves my hands, there is no guarantee of > delivery, I would think that the RFC would kick in once the message had actually been sent. > The fact that the failure was still inside my box, and completely detectable, bothers me. > Is it really right to say "Oh, it's a UDP message, so I won't bother to check any return > codes from anything I do, 'cause the RFC says I don't have'ta care..."
That's the way it works because there's no other way to do it if you use UDP. If you use UDP, the U stands for user - it is *your* problem. The only thing the API return code can tell you in a UDP-based application is that the stack accepted the packet - which it did; the packet was accepted by the stack, and you got a RC=0. UDP does not offer anything else, and there is no mechanism in IP to tell you anything else. How is the API supposed to return anything else? > If you were reading a disk file, and writing the records out to another machine via UDP, > and there was a disk failure, should you just ignore it because the RFC for UDP says that > there's no guarantees? Are are you responsible for checking for disk errors, because your > message isn't actually out on the wire as yet? You are completely responsible for *all* the application function. UDP guarantees *nothing* other than the packet is constructed and handed to the stack. Take a look at the way NFS is constructed - all the timeouts, responses, error checking, etc is ALL in the application. Anything above the physical act of transferring data is done in the RPC layer, and everything in NFS is stateless to allow it to fit in the UDP "cast it out in the void and pray" design model. So, yes, working as designed. You want guarantees, use TCP. You want lightweight transport without the TCP overhead, you gotta do the work yourself if you want more reliable semantics.
