>The ACK message in this context is a custom ACK message (which also includes a 16-bit CRC) that is sent from the device to the PC, it does not really have anything to do with what protocol is used. Immediatly following the ACK packet the device might or might not send a data packet (depending on what command I sent the device). The NAK packet in this context is also custom and is designed to let the PC know that the command it just sent to the device was not valid (CRC failed or other encryption failed).
>The ACK and the NAK (with CRC and encryption) is supposed to be above and beyond the prtocol choosen for transfering the data. I was just hopeing that the TCP protocol (in particular, I know UDP works in a disconnected fashion) would ensure that the packet was delivered without being "distorted", which would result in a NAK reply.

TCP and UDP work quite different in this context. TCP is a connection-oriented protocol. If you assemble all the packets yourself, perhaps you would be better off using UDP, but I am not sure. If you do use TCP, I think the idea would be, more or less, to give some built-in TCP function a stream of data, and let TCP take care of the ugly details. (However, I have never done any programming at this level; these explanations are simply based on my understanding of the general principles involved.)

>I have to assemble the data received from the device because that is where the information is byte for byte (and sometimes bit for bit). The reason I added CRC to all packets is to prevent someone tampering with the system. It is also possible for one PC to communicate with several (10 or more) devices.

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.

>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.