I did find my problem, and as usual, it was of my own making.... I mis-read the PIPE UDP help, and had specified 514 as the sending port, rather than specifying 0 and allowing it to choose a port above 1024. I can fix this....
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...² 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? -- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/7/08 7:39 PM, "David Boyes" <[EMAIL PROTECTED]> wrote: > > >>> >> Also: If I violate this using Pipe and the UDP stage, why don¹t I get a >>> >> non-zero return code? > >> > Because there are no guarantees in the IP protocol specifications that UDP >> packets are ever delivered. UDP was designed to have those semantics, > and >> thus if you use UDP, you're expected to handle missing packets yourself. If >> you want guaranteed delivery, you're expected to use TCP. > > Direct quote from the RFC: "UDP does not guarantee reliability or ordering in > the way that TCP does. Datagrams may arrive out of order, appear duplicated, > or go missing without notice." > >
