Is this applet implementation for the Go-Back-N ARQ protocol correct?

Question

I was reading a textbook describing the Go-Back-N (GBN) protocol with Finite State Machines as pictured below:

$\Lambda$ just means "initial state" or "no action", depending on the context. My questions are

1. This is the interactive animations link to GBN https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/go-back-n-protocol/index.html. Let's say we are sending packet 0, packet 1 and packet 2, and packet 1 is lost beforen it arrive receiver. So when it is timeout, GBN will make sender re-send packet 1 and packet 2, And I found an interesting thing which is,if you try the link with above scenario and you send packet 3 just before timeout occurs,this action reset the timer, because you can see the timeout is postponed(otherwise you will see packet 1,2,3 flying in screen).But according to the sender's FSM, after you send packet 3, timeout occurs immediately, then the sender will re-send packet 1 and packet 2, but it didn't happen as timeout is postponed, which contradicts the fact that time is only get reseted when base = nextseqnum?

2. On the receiver's FSM, why it needs to set expectedseqnum = 1 and make a packet based on it? why we cannot set expectedseqnum = 0 as the only initialized action?

Answer 1

I'll address question 2 first, since it seems easier than the other one. The answer is simply because both transmitters begin tagging their payload messages from 1, namely with nextseqnum = 1; you can see this is so for the sender from the top-left corner of the image you posted. Don't be misled by the fact that the receiver issues the sndpkt = make_pkt(0, ACK, checksum) at the outset; that first packet is only crafted, but not sent (it would if the receiver hit the default state). On the other hand, there might be an inconsistency in the way the applet enumerates its packets, since it starts from 0.

---

Question 1 seems to ask: if a sequence of packets 0, 1, 2 is sent and

• Packet 1 is lost
• A new packet, 3, is sent just before the timeout

then no timeout occurs, although no instruction seems to be encoding for that. Although I counted the passing of time with my hands, your observation seems to be correct: given the above conditions, upon sending a new packet, the events associated with a timeout do not manifest. This could be due to a small bug in the applet, although I would ascertain more before contacting the book authors.

which contradicts the fact that time is only get reseted when base = nextseqnum?

Beware! The timer is also reset upon receiving an acknowledgement that is not the last one, as shown at the bottom of Figure 3.20. However, I do not think your experiment is affected by this behavior since the triggering conditions aren't met.