Logout

3.1.7

Explain why protocols are necessary.

 

Teaching Note:

Including data integrity, flow control, deadlock, congestion, error checking.

 

Sample Question:

sdfsdfsf

General Rational for the Existence of Protocols:

Protocols, in general, exist to provide standard ways of communicating and interacting. Recently I heard a funny piece by Lucy Calloway of the BBC World Service bemoaning the fact that there are not strict international protocols about greeting each other in a business situation. So for example at an international gathering, some will try to kiss others three times on the cheek, others will bow, others will shake hands, all of different durations of shaking, and so on, causing nervousness, misunderstanding, and wasted emotional engagement when each should be more worried about establishing the business relationship.

 

General Rational for the Existence of Network Protocols:

So for network functioning, there are many protocols agreed upon used by computers of the world. TCP, and IP are two that you may have heard of in association with the Internet (commonly termed, together TCP/IP). They exist so that devices on networks can communicate properly with each other.

 

Specific to the Teaching Note:

Note that, in fact, a great way to address this assessment statement is to list and explain what is stated in the Teaching Note:

So your answer for, say, 2 marks only, would be: "Protocols are necessary so as to assure data integrity, manage the flow of data, prevent congestion and deadlock, and supply an agreed upon way of error checking".

But if it were a question worth more than a few marks, or if any one of those was asked details of, here is each one tweaked out a bit:

 

data integrity - The "correctness" of information, meaning what is sent is what is received. In fact, this is part of what error checking is for. Refer to the error checking section below - but the point is that the protocol needs to have ***some*** way of assruing data integrity. (When playing "telephone" as elementary students, there was not good data integrity with the passing on of the message by whispers from student to student.)

flow control - Protocols dictate the ways servers/switches/routers are able control the flow of traffic through a network. For example, a network protocol can be made to ensure that no more than 100 MB/per hour of data can be uploaded by any device within the school's network between the hours of 8:00 and 15:00.

The good anology here for contolling flow would be how traffic is controlled though a city. Some of the rules:

These in the world of networks. In a network, such flow of control rules could be:

Flow of control is all about traffic. The same sorts of traffic issues cars and buses have in a city, data also has when moving around a network.

network "emergency" interrupts must take priority over regular network traffic

(research actual strategies for controlling flow)

congestion - when everything in a network slows down due to the amount of traffic going through particular paths. Congestion can be relieved by re-directing network traffic alternative routes which are not necessarily the shortest. Switches will do the actual routing, but they do so based on what is possible as dictated by the network protocol. Different protocols offer different approaches to reducing congestion.

One approach for relieving congestion is to not allow data to be sent at exactly the same time. Rather you should stagger sending pieces of a big file. Flushing of the network at certain points of congestion and request re-sending. "Even"/"odd" licence plates strategy

deadlock - this is when traffic on the network grinds to a halt, due to levels of traffic that the server cannot handle. One way a protocol can prevent deadlock is by requiring the network server to re-start when a certain threshold of traffic is crossed, there-by chucking everyone off - our Internet server at the school will do this. So the protocol in fact prevents deadlock, and possible freezing of the server, just before it would happen, by restarting. "Gridlock" in the automotive traffic analogy which refers to a situation in which there is such a high level of traffic congestion that no car can move. (One rule for preventing traffic deadlock is to not let people stopo in the middle of intersections.)

Note the related cyber attack strategy: DDOS (Distributed Denial Of Service attack) - When a lot of requests are sent to a network serve by many computers - often these computers are infected or controlled by the bad guy. If enough requests are sent, the server can freeze.

error checking - the protocol will dictate the use of some sort of error checking algorithm to help assure that what was sent is what was received. Common error checking algorithms include parity checking and check sums. (See below for more details.)

To reiterate this is to assure data integrity.

 

Do note that each network protocol will specify particuar ways of working with all of these things, deadlock, error checking etc. So TCP/IP may use weighted check sums, and another protocol like UDP does not; it may use unweighted checksums.sskdjaksdjfkasdjfka


 

 

 

 

 

 

A Bit More Details on Error Checking

This may very well be going BEYOND what THE ASSESSMENT STATEMEN and teaching note are about, but to give you a better idea of what error checking means, I'll cover a few different approaches/algorithms. Error checking, in general, is the processes of checking to see if there was an error in transmission. Usually this will be because of some sort of electromagnetic interference, which causes a bit to be "flipped". So before it was sent, it was a 1, but upon arrival at its destination, it is a 0, or vice versa.

Parity Checking

Parity checking is a system in which the number of binary 0s or the number of binary 1s in message ("message", in the case of network activity is a packet) are calculated before the message is sent, and after it is received. That number should be exactly the same if no errors occurred during the transmission. If it is not the same, it means there (was at least one) error. So re-transmission is requested.

In the he case where a particular protocol uses Even Number of Zeros Parity Checking, the number of 0s in a packet are counted up, and if that number is odd, another 0 is added as the "parity bit" to make the total number of 0s even. And if the number of 0s is even, then it is kept even by adding a 1 as the parity bit. When the packet arrives at its destination, the number of 0s is added up, and if it's still even, than no error is assumed to have occurred, if it's odd, then an error must have happened during transmission, and re-transmission is demanded by the protocol.

Check Sums & Weighted Check Sums

Parity checking is not so sophisticated, and what happens if two bits get flipped?? An alternative approach is to use check sums. A check sum is some sort of value that is calculated using a specific formula before and after transmission. As with parity checking, that number should be exactly the same if the message was un-altered during transmission. A simple example is as follow: add up the ASCII decimal equivalents of all the characters in the message, and see if it is the same after transmission. In order to be able to keep a check sum to one byte, what you do is take the remainder of that value divided by 255, rather than the full number (which would be over 255 for all but the smallest messages.

Check Sum Example:

ABC: that's 65 + 66 + 67 = 198 % 255 = 198. So what is sent is ABC198

If received without an error, the recalculation is:

ABC: 65 + 66 + 67 = 198 % 255 = 198 (So check! it's the same; 198 == 198, so everything is assumed to have been transferred correctly.)


But in the case of it being sent with an error occurring, say the last 1 of the C is changed to a 0:
0100 0001 0100 0010 0100 0011 -----------> 0100 0001 0100 0010 0100 0010

So what is received is ABB198, and the check sum calculation goes:

ABB: 65 + 66 + 66 = 197 % 255 = 197 - ERROR, ERROR (because 197 != 198, the check sum before sending) RE-TRANSMIT!


Weighted Check Sum:

The problem with the check sum is that two letters could be transposed, and the sum would be the same, so for example ABC would yield 198, but so would BAC. Each letter is therefore weighted by multiplying its ASCII value by the number which represents its place in the message.

ABC: that's (1 x 65) + (2 * 66) + (3 * 67) = 398 % 255 = 143

BAC: that's (1 x 66) + (2 * 65) + (3 * 67) = 397 % 255 = 142, and 142 != 143, indicating the error in transmission.

 

Jose: What could cause bits to get flipped and other corruption of data in transmission: one example is magnetism or electromagnetism affecting the wire/wireless signal; another more esoteric example is what's termed a "single event upset" caused by cosmic particles.

 

JSR Notes - FORMER CURRICULUM - 6.4.4 Outline the need for protocols in packet switching.:

With this assessment statement, the emphasis is not so much on the protocols themselves as the need to have them in the first place.  So this is a **protocols** assessment statement more than it is a TCP/IP one.

Look through the text on 344 and 345 to remind yourself what TCP and IP are, and on which levels of the OSI (Open System Interconnection) model they are found.  And also remember that the OSI model is just that, a model.  To fully understand all of what makes TCP/IP work within the full context of networking would take a couple of advanced degrees.  And neither TCP nor IP necessarily fit perfectly into one of the seven layers of that model.  And that’s not the point.  The point is the ‘P’ in each of these, the protocol; the idea that however this networking is going to work, the computers on either side of the connection had better agree on the ways to proceed.

And in terms, then, of what is to be agreed with TCP, think of the postal analogy; the way in which these packets are to be transported, both sent and received, must be agreed on from both ends.  To take a simple, extreme case with the analogy, there would be no sense of sending a parcel air mail to a place with no airport.  And oh yeah, don’t forget that it is “Transmission” Control Protocol.  In other words what are the rules and regulations for the actual control of the transmission of the packets through the network.

And with the IP part of it, again think of the postal analogy.  This is the “inter-network” set of rules for how the packets will be addressed; the format of the “where they are coming from” and the “where they are going to”.  Does the postal code need to be included, and how many numbers and letters should it have.  Actually IP is pretty easy compared to all of the non-standard postal address configurations out there; it is simply four 8 bit numbers separated by points, from 0.0.0.0 all the way up to 255.255.255.255.  And remember the interesting fact that this makes for around 4 billion possible IP addresses (in IP version 4).

It wouldn’t hurt to also remind you that Domain Name Servers (DNS servers) keep a list of all the IP addresses out there with their corresponding short-cut domain name.  johnrayworth.info, for example is actually the IP address 195.250.148.236.

But anyway, much of this is beyond the point of the assessment statement; in packet switching systems, such as the one used for the Internet, there are certain protocols that once chosen must be followed; certain ways to, among other things, transmit packets and address them.  Without agreement on and adherence to these rules, these protocols, networking, in this case, would not work.