please wait
- Forum
- General C++ Programming
- Testing Integrity of a Packet
Testing Integrity of a Packet
Sep 21, 2009 at 12:36am
I already know how to send information across a network, but I'm not quite sure on how to make sure that the information sent is correctly since I'm using UDP. Here are my current ideas:
-Parity of the Information
One of my thoughts was to send every message with the same parity, and test the parity when the message is received on the client. If the parity is wrong, then have the server send another message. While this would ensure at least some of the corrupted packets to be detected, there's still room for error.
-Information Mode
My other thought was to send 3-7 packets of the same information and have the client use the mode of the information. This would be much more secure, but it might take longer. Also, there's still a small chance that all of the packets would be corrupted, and the information would be wrong anyways.
What would be the best one? Or would neither be the best way to check integrity?
Then again, what are the chances of the packets getting corrupted? I'm guessing it would depend on how far the packet traveled and the quality of the connections. Is it even worth testing the integrity?
-Parity of the Information
One of my thoughts was to send every message with the same parity, and test the parity when the message is received on the client. If the parity is wrong, then have the server send another message. While this would ensure at least some of the corrupted packets to be detected, there's still room for error.
-Information Mode
My other thought was to send 3-7 packets of the same information and have the client use the mode of the information. This would be much more secure, but it might take longer. Also, there's still a small chance that all of the packets would be corrupted, and the information would be wrong anyways.
What would be the best one? Or would neither be the best way to check integrity?
Then again, what are the chances of the packets getting corrupted? I'm guessing it would depend on how far the packet traveled and the quality of the connections. Is it even worth testing the integrity?
Last edited on Sep 21, 2009 at 3:10am
Sep 21, 2009 at 3:05am
Are you talking TCP/IP using a TCP (as apposed to a UDP) socket?
If so then there is no need for all this extra checking and stuff
If so then there is no need for all this extra checking and stuff
Sep 21, 2009 at 3:09am
I'm using UDP, not TCP/IP. I thought I mentioned that, sorry. I'll edit the post.
Sep 21, 2009 at 12:29pm
UDP has a 16-bit checksum feature which is enabled by default. Is this not sufficient?
Sep 21, 2009 at 6:53pm
But couldn't the checksum itself be corrupted? Or would the packet just never reach its destination if this happened?
Sep 21, 2009 at 7:41pm
You could have a look at hamming code which uses several parity bits if you really want to delve into error checking
Sep 21, 2009 at 7:58pm
You can't tell the difference between a corrupted checksum in an otherwise valid packet, a valid checksum
in an otherwise corrupt packet, or a corrupted checksum in a corrupted packet, but in any case you'd want
to drop the packet anyway.
in an otherwise corrupt packet, or a corrupted checksum in a corrupted packet, but in any case you'd want
to drop the packet anyway.
Sep 21, 2009 at 9:54pm
That's what I thought, I just wasn't sure if a packet would be redirected because of a corrupt checksum. Thanks.
Topic archived. No new replies allowed.