[En-Nut-Discussion] TCP uses to much memory with zero window?
Harald Kipp
harald.kipp at egnite.de
Mon Jun 29 19:41:44 CEST 2009
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...
> 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.
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.
Harald
More information about the En-Nut-Discussion
mailing list