>Yes TCP and UDP work differently in a lot of ways, but similar if you look at it from a "bird's eye perspective" (both send data from point A to point B <s>). UDP is slightly faster since there is less overhead (a connection does not have to be maintained), but TCP is more "reliable". I am using the built in functions of .NET to send my packets from the PC to the device, so I don't have to worry about the ugly details. My problem is that the data packet received by the device is sometimes "distorted".

OK; I thought you were fooling around with the TCP header itself.

>>TCP segments, UDP segments, as well as IP packets, contain header information, and then the "data". This data is more or less under your control. I think it should be possible to tell TCP, or UDP, to send "such-and-such information", you control, at the end-points, how the data is encoded and encoded, but the TCP or UDP installation will take care of other details, such as requesting a re-send.
>
>Yes, it is the "data" that is distorted in my case. I am not conserned with the header and stuff that is built into TCP and UDP (I just assume that that is working correctly). Earlier when I said I use 16-bit CRC and encryption I meant that I use 16-bit CRC and encryption on my "data" (same "data" as you refer to above). This is just added for additional secuity (so that someone can't use a sniffer to capture the "data" and then send the "data" from their application.
>
>>
>>>I guess my real question is: Is 2% failure rate acceptable when communicating like this? (If I use 2 or more rettries per packet my failure rate drops towards 0%) (percentages are calculated using over 1 million consecutive communications).
>>
>>I have never seen any "typical" statistics. However, I would hazard a guess that this is acceptable.
>
>Yeah that is what the engineers say too <s>. I might just be expecting too much when I want to lower it more.

It seems to me that there is indeed something strange here. If you use TCP, then most cases of data corruption would be detected by TCP, because the TCP CRC (or whatever it is called) doesn't match. In this case, the recipient would request the TCP segment to be re-sent. Or, they would not even reach the destination, because someone in-between (like a proxy or router) would reject the IP packet, whose CRC won't match either.

In other words, any data that actually reaches the end-point (after TCP processing) should be clean; you would not even notice that they were re-sent, unless you use some sort of packet tracer to analyze the individual packets (including the packets that would be rejected by the TCP recipient).