Go back n on server side

Question

I am implementing a UDP based go back n example and I am a bit stuck on how the server should respond to packets.

If my client has a sliding window of say 5, it can send 5 packets to the server without waiting, and any time it receives back an ack lower than its highest window value it will retransmit all packets from that point on (I think I understand this correctly). So for example:

• Server sends: 1, 2, 3, 4, 5
• Gets Ack: 3
• Server sends: 4, 5, 6, 7, 8

What I cannot understand is whether the server is supposed to be maintaining a window itself and only responding when it receives 5 packets, or whether it should respond to every packet received?

Wikipedia suggests the window is only ever 1 for the receiver which would imply it responds to every incoming packet but the requirement I am following asks for the server to remember the window size and take this into account when acknowledging, would this be cumulative acknowledgement?

I need to understand how the server should respond so any help is appreciated.

Answer 1

assuming that the client only sends and the server only receives and acks:

(1) the server may or may not contain a buffer. Go-Back-N will function perfectly, if there is a buffer for only one packet on the receiver. However, you could include a buffer (which comes with a window) as an optimization.

(2) the server should not memorize the sender window, or do anything. if you choose to do so, it should go the other way around. the server informs client about how much it can receive

(3) the server needs to track last in-order received packet (or next expected in-order packet). when this packet is received, the server processes it, and sends an ACK. After this happens, the server increases last in-oder received packet. Thus the window (of potentially one) also slides at the receiver. receiving one slides the window to two, receiving two slides the window for three, etc

here is a demo for situation without buffer: ARQ Demo

(4) whatever packet is received and whatever server chooses to do with it, it responds with a value that depends on last in-order received packet. (It depends on our ACK semantic, you can choose to ACK last in-order received, or next in-order expected). Sequence number of the first packet needs to be know, before transfer started. You can opt for well-known values (e.g., 1) or negotiate it during connection exchange.