3.4.6 Describe suitable methods to ensure data integrity in the transmission
of data.
Teaching Note:
Error-checking codes such as check sums (Block_ProIT-1haracter checks)
and parity checks must be understood. The reasons for retransmission
should be understood. The quality of communication
lines should be considered.
Sample Question:
In relation to data transmission across a network:
...
(b) Explain a way to ensure data security. [2 marks]
JSR Notes:
Here then is an expansion on some of the specific ways networking software does what it does - in accordance with 3.4.5.
Note that "check digit" is the one that's missing in the text at this point, but is explained later on as part of 3.6 - Errors.
Meantime, though, you've got parity checking and check sums. Though perhaps not diagrammatically beautifully done in the text book, it's right on with its explanation, so there you go: "Check" it out.
But all of these work on the same basic principle. If we are transferring a bunch of information from one device to another, we are hoping that exactly the same data will arrive as is sent. If we perform some sort of specific calculation on the data before it is sent, and do exactly the same specific calculation on what should be exactly the same data, we should get exactly the same result. If we don't we know there has been an error in transmission. So: calculation before, then transmission, then re-calculation, and a check to see if it's the same result. If not, a request for re-transmission.
And here is one part to clarify with check sums. And it comes back, during 3.6. But, here is another situation where modulus division comes in handy. So why? The thing is that when doing the BCC, we put the calculated number in a space that is limited. If we are dealing with successive bytes of information, it is the byte which is the limit on which our check sum should be; we'll most often want to save it in the same space that we're saving the values we're checking. And that space is one byte. Well, one byte can hold 256 unique things. So if our check sum is going to be a number, that number has to be between 0 and 255. If we're adding up, say, four bytes worth of values, we're most often going to get a sum that is greater than 255. What to do? Well, it just so happens that doing remainder division (modulus division) with 255 will yield 0 to 255. So that's the value we'll put in the BCC. Could we do modulus division by some other number less than 255? Yes, but by using 255, we'll maximize the number of unique values we can work with, thereby maximizing the chance of success, catching an error when the calculation is done again at the receiving end.
Do note as well that the teaching note says a couple of extra things. Firstly, "The reasons for re-transmission should be understood." Well, it's really only one reason: the recalculated result is different than the original calculated result, indicating an error in transmission. So we are re-transmitting so that we get the correct data.
And, the quality of communications lines should be considered. Hmmm... The better the quality of communication lines, the better the chances of successful transmission?? Yep. Though there's a bit more to it, in that there are lots of different kinds of wired and wireless communications lines that can be used; some are faster, some are slower, some are more secure, some less. Generally you could say you get what you pay for, so a WAN with dedicated fiber optic connections would be a better - though much more expensive - option than using old, crowded public telephone lines for your information transfer.