[En-Nut-Discussion] TCP uses to much memory with zero window?

[Bernd Walter]

On Mon, Jun 29, 2009 at 07:41:44PM +0200, Harald Kipp wrote:
> Bernd Walter wrote:
> 
> > There is a memory protector in the receive, which keeps 2048 Bytes free.
> > Don't know why it doesn't protect my system from failing - maybe
> > the memory is too fragmented - 2048 is not very much.
> 
> Definitely. It had been 8k some time ago, but under certain conditions
> applications may run well at this limit so it had been changed. Anyway,
> it is not expected that an application will still run well. It's just a
> last try to stop TCP from eating up all resources.
> 
> The better solution will be to change the strategy in that way, that
> incoming packets are processed by the receiver thread and outgoing
> packets will use a dedicated thread. This had been discussed some days
> ago (too lazy to locate the thread) and I think it is a good solution to
> several problems.
> 
> > But it is not the right answer, because at some point it just ignores
> > incoming packets and therefor ZWP probes are not answered, which then
> > makes the peer drop the connection.
> 
> In this low memory situation the connection may not make sense at all.
> However...

It does make sense, because I should have enough memory free.
It is the problematic behavour in ZWP which creates the low memory
condition.

> > What do you think about to change that to something like this:
> >                 if (th_seq < thq_seq && nb->nb_ap.sz <= thq->th_win) {
> >                     *nbqp = nb;
> >                     nb->nb_next = nbq;
> >                     break;
> >                 }
> >                 if (th_seq == thq_seq || nb->nb_ap.sz > thq->th_win) {
> >                     NutNetBufFree(nb);
> >                     sock->so_tx_flags |= SO_ACK | SO_FORCE;
> >                     NutTcpOutput(sock, 0, 0);
> >                     return;
> >                 }
> 
> As it doesn't really need that much heap, I think this should be
> implemented. It will help to recover from temporarily low memory situations.

That's not the purpose - it is to avoid a TCP socket to claim unlimted
heap space.
ZWP show two problems in current code.
1. it sends payload beyound receive window, which ethernut doesn't enforce
2. it send 1 byte payload only, which is stored very inefficiently.
The above is to enforce the receive window, so we don't store more data
then allowed.

> Many thanks, Bernd. Your detailed description of the problem really
> helped me to get back into this stuff again. I'm not yet able to tell,
> how the dedicated transmitter thread will change the status quo. But
> I'll keep you informed about its progress.

Thank you.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.