Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Packet
Message
 
To
01/12/2005 13:37:29
Hilmar Zonneveld
Independent Consultant
Cochabamba, Bolivia
General information
Forum:
ASP.NET
Category:
Other
Title:
Re: Packet
Miscellaneous
Thread ID:
01073757
Message ID:
01073881
Views:
13
>From what I have studied (general overview, no specific details), I understand that the ACK also tells the sender you to continue transmitting from byte #x. For example, if each packet has 1000 bytes (to simplify calculations), and you send three packets, you might receive an ACK, which tells you to continue sending from byte #4001. On the other hand, if packet #2 is lost, the ACK will tell you to continue sending from byte #2001.
>
>I don't remember reading anything about a NAK, and a quick search in the document RFC 793 (TCP) shows that, apparently, NAK isn't mentioned.


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.

>
>That is what it looks like, if you are creating your own CRC, and send an ACK!
>
>Anyway, I would search if there is a possibility of handling TCP at a higher-level, which doesn't force you to analyze or assemble the bytes in the individual packages.

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.

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

Einar
Semper ubi sub ubi.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform