RE: [lwip-users] BasicWeb.c behavior

[Bill Auerbach]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf
> Of BMW Cyclist RR
> Sent: Friday, February 08, 2008 1:50 PM
> To: address@hidden
> Subject: [lwip-users] BasicWeb.c behavior
> 
> I am running lwip v1.2.0 with FreeRTOS 4.2.1 on a AT91SAM7X-EK board with
> an
> X512 chip. I have been actively adding UDP and TCP application programs
> with
> only minor issues, but when trying to resolve a resource (memory) issue
> I've
> dropped back to running just the standard BasicWeb.c webserver so I could
> better understand what the lwipopts.h values actually do in terms of TCP
> internal data structures. I am able to do source level debugging with
> Eclipse and the Amontec JTAGKEY along with OpenOCD.
> 
> What I've noticed when running just the Webserver application with my
> other
> tasks disabled (all other FreeRTOS tasks are not created) is that the
> lwip_stats.memp[3] statistics show that the number of TCP_PCBs used seems
> to
> keep getting bumped everytime the webserver returns a webpage. I've got
> MEMP_NUM_TCP_PCB set to 10 (in lwipopts.h) and I see that memp[3].used and
> memp[3].max keep climbing with each web browser connection until the limit
> of 10 is reached. Then I see memp[3].err get incremented while the
> memp[3].used and memp[3].max stay at 10. The webserver continues to
> operate,
> seemingly normally. Is this due to previous TCP connections (i.e..
> webserver) hanging around for a while and continuing to tie up TCP_PCBs?

In tcp_alloc, if memp_malloc returns NULL then tcp_kill_timewait is used to
kill an old PCB.  I would think the error should be reversed when the next
memp_malloc succeeds, or, we need a memp_malloc_try which doesn't count the
error on a fail, but allocates one if it can.

Bill