- Computer communication usually involves transmission of
very large data files.
A file cannot be sent in a single message (for practical reasons)
- A sender will typically send a sequence of messages to a receiver.
The ordering of these messages must be maintained for the receiver to reconstruct the entire file.
- We say that the file transmission was
reliable if and only if:
- The messages sent by the sender were received
exactly ONCE
by the receiver (i.e., cannot be lost nor can a message be
received twice)
- The messages sent by the sender were received in the same order as transmitted
- The messages sent by the sender were received
exactly ONCE
by the receiver (i.e., cannot be lost nor can a message be
received twice)
- The main purpose of the datalink layer is to ensure
reliable delivery of frames from one node
to its neighboring node
- There is more than what meets the eye in accomplishing this....
- A (length) message is usually transmitted in multiple frames
- In order to receive the message reliably, each frame of the message must be delivered exactly once and in the correct order
- Let us consider the following simple protocol that
attempts to ensure reliable delivery:
- Sender transmits a frame and wait for an acknowlegdement
of its reception
- Upon receiving an acknowledgement, the sender transmits the next
frame
- If sender does not receive an acknowledgement for some (pre-defined) time, it times out and retransmits the same frame.
- Sender transmits a frame and wait for an acknowlegdement
of its reception
- Here is a figure showing how it would work when there are no
transmission errors:
- You see that the receiver will deliver the frames in the right sequence.
Let us see how this protocol will hold up in the face of transmission errors...
- Suppose a message from the sender was not received,
can this protocol recover from this type of errors ?
- Sender-side error: data from sender is lost
- Conclusion:
-
The protocol is able to recover from sender-side errors
- Conclusion:
- Suppose an ACK message from the receiver was not received,
can this protocol recover from this type of errors ?
- Receiver-side error: data from receiver is lost
- Conclusion:
-
The protocol is NOT able to recover from receiver-side errors
(Because the receiver will accept the message "xxx" twice !!!)
- Conclusion:
-
How can we fix this problem ???
- Solution:
- We add an sequence number
to the message HEADER (in the message
sent by the sender)
- The receiver also has a sequence number,
and this sequence number identifies the next message
that the receiver will accept.
- A message with a wrong sequence number is NOT accepted (will be discarded)
- We add an sequence number
to the message HEADER (in the message
sent by the sender)
- How it works with the fix:
- Solution:
- Question: will it ensure reliability ???
Nope, there is one more problem....
- We are not out of the woods yet, there is
once more type of errors to consider...
- After the sender send a message, it wait for an ACK from
the receiver.
The receiver may be very busy and could not send the ACK immediately...
So the receiver send the ack a little bit later than normal...
- This event will cause duplicate ACK errors:
- The sender will assume that the second ACK was intended
for frame 1
So sender believes that frame 1 was received correctly, while in fact, it was NOT
Error ! (not reliable)
- The dupplicate ACK error is caused by an ACK mistakenly
acknowledge the wrong packet.
- To avoid this error, we must include information in the
ACK packet to convey which packet the ACK
is acknowledging.
- Solution:
The resulting protocol is called the "Stop-and-wait" protocol:
- Sender and receiver first agrees on a starting sequence number
X
- Sender transmits a frame labeled with sequence number X
and wait for acknowledgement for X
- Upon receiving the acknowledgement ACK X,
the sender increments the sequence number to
X+1 transmits the next frame labeled with the new sequence
number.
- If sender does not receive an acknowledgement for some (pre-defined)
time, it times out and retransmits the same frame (with the same
sequence number).
- If receiver has the sequence number X and the receiver
receives a message labeled with sequence number X,
the receiver transmits ACK X and increment
its sequence number by 1 to X+1.
- If receiver has the sequence number X and the receiver receives a message labeled with some other sequence number, the receiver transmits ACK X and DO NOT increment its sequence number.
|
|
- Acceptable for low speed links
- Wasteful of bandwidth on high speed links
To achieve better performance, we must use the more complicated Sliding Window methods.