Recall that after developing the rdt2.1 protocol, we decided that it had a fatal flaw. The sender and received for rdt2.1 are shown below. Show that the sender and receiver can enter into a deadlock state, where each is waiting for an event that will never occur. (Note: in some cases in the FSMs the variable "sndpkt" is misspelled as "sendpkt". Also, in both the sender and receiver the function make_pkt is being used to initialize sndpkt - the sender and receiver FSMs use different syntax however.) rdt rev (revpkt) && notcorrupt (revpkt) && isACK (revpkt) A rdt_rev (revpkt) 66 (corrupt (revpkt) || isNAK (revpkt)) udt send (sndpkt) rdt send (data) sndpkt-make_pkt (0, data, checksum) udt send (sndpkt) Wait for call 0 from above Wait for ACK or NAK 1 Figure 3.11 rdt2.1 sender Wait for ACK or NAK 0 Wait for call 1 from above rdt send (data) sndpkt-make-pkt (1, data, checksum) udt send (sndpkt) rdt_rev (revpkt) && (corrupt (revpkt) |I isNAK (revpkt)) udt send (sndpkt) rdt_rev (revpkt) && notcorrupt (revpkt) 66isACK (revpkt) A rdt_rev (revpkt) 66 (corrupt (revpkt) || has_seql (revpkt))) compute chksum make_pkt (sndpkt, NAK, chksun) udt send (sndpkt) rdt_rev (revpkt) && notcorrupt (revpkt) 46 has_seq0 (revpkt) extract (revpkt, data) deliver_data (data) compute chksum make_pkt (sendpkt,ACK, chksum) udt_send (sndpkt) Wait for 0 from below Wait for 1 from below rdt_rev (revpkt) && notcorrupt (revpkt) 46 has_seql (revpkt) rdt_rev (revpkt) 66 (corrupt (revpkt) || has_seq0 (revpkt))) compute chksum make_pkt (sndpkt, NAK, ch udt send (sndpkt) extract (revpkt, data) deliver_data (data) compute chksum make_pkt (sendpkt, ACK, chksum) udt send (sndpkt) Figure 3.60 An incorrect receiver for protocol rdt 2.1