School of Computing. Dublin City University.
My big idea: Ancient Brain
Machine A sends to B. Reliable, connection-oriented service.
NA = Network layer on A.
DA = Data Link layer on A.
NB = Network layer on B.
DB = Data Link layer on B.
DA gets packets from NA. Puts them in frame. Calls to_physical_layer to send frame. Hardware computes checksum, appends, and sends.
DB waits for data:
Instead of busy loop would be suspended pending interrupt.
When frame arrives, hardware computes checksum.
If error it generates event =
If ok, event = frame_arrival and DB can then use from_physical_layer to acquire frame. Strip down to packet. Pass packet only to NB. NB is never given any frame info. Frame format can be changed without Network layer knowing.
numbers frames 0 .. MAX_SEQ
and then back to 0 again
Packet here is of fixed length MAX_PKT
Frame has 3 control fields (header) and 1 data field (packet).
Header = (frame kind, sequence no, ack no)
Frame kind - some frames contain only control info. Their data field is not used.
For error recovery, we need acks and timeouts.
Need start, stop timer.
If timer already running, start_timer resets it to cause the next timeout after another full period.
If no reply after timeout, event = timeout
NA might not have packets ready to send,
or DA might not be ready to process them
enable_network_layer - NA can interrupt when it has a packet to send
disable_network_layer - NA cannot interrupt, can't send packets until DA is ready and enables again
Flow control - How to stop fast sender A swamping slow receiver B?
Sender code now has wait_for_event
Note sender does not even look at incoming frame - it is always an ack.
Note receiver does not put any particular info into ack frame. Its existence is enough.
Possible solution to errors: Add timer.
Receiver only sends ack if no error.
If no ack, sender re-sends.
Problem: Good frame sent and received, passed to NB. Ack sent, but ack lost. Sender sends same frame again. Don't want this to be passed to NB - NB already got it.
Solution: Sequence no. Can tell original frame apart from re-transmit.
The only ambiguity is between a frame m
and its successor m+1
Sender keeps sending m until gets ack
Then, depending on whether ack got through, it sends m or m+1
So only need 1 bit sequence no. and flip it between 0 and 1 to express the frame no. we're expecting right now.
Wait for ack before sending next item: PAR (Positive Acknowledgement with Retransmission) or ARQ (Automatic repeat request).
Receiver maintains frame_expected
Timeout should be chosen with the line in mind (allow enough time for frame to get to B and ack to get back). Again we see: Most of Data Link layer is hardware-specific, and it hides details of hardware from Network and higher layers.