[En-Nut-Discussion] TCP vs. Memory - a solution

[Harald Kipp]

Michael Jones wrote:
> This, proof of concept change seems to work:

before considering to apply your change I'd like to test it here.
However, I failed to reproduce the problem.

As you wrote, the remote peer will fill up the our local memory with
packets. But how can this be? Ethernut announces its TCP window size and
the remote will never send more than this amount without further ACK.

Nut/OS 4.9 announces a TCP window size of 3216 bytes. The remote (PC
running Windows 2003) runs something like

for(n = 0; ; n++) {
 sprintf(buffer, "%lu\n", n);
 send(sock, buffer, (int)strlen(buffer), 0);
}

and Nut/OS uses

for (;;) {
 NutTcpReceive(sock, buffer, sizeof(buffer));
}

Both loops are simplified. Actually I'm checking results and doing some
debug output.

Wireshark shows

PC: 2 bytes
Nut: ACK (win=3214)
PC: 132 bytes
PC: 6 bytes
Nut: ACK (win=3076)

...and so on. After a short time, as expected

Nut: ACK (win=570)
PC: 228 bytes
Nut: ACK (win=0)
Nut: ACK (win=598)
PC: 536 bytes
Nut: ACK (win=0)

Nut's memory never drops by more than 5k.

May be I have to find a way to force the PC to send smaller packets. But
how? As soon as Nut closes the window, the remote will collect all data
into one packet. When Nut opens the window again, the remote will send
the maximum in one packet. This maximum is limited by the newly
announced window size and the MSS.

Any idea how to reproduce the problem?

Harald

P.S.: I do remember the discussion about the zero window size problem
eating up all memory, which appeared here earlier and I'll look into
this as well.