RE: [lwip-users] BasicWeb.c behavior

[Bill Auerbach]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf
> Of Jonathan Larmour
> Sent: Friday, February 08, 2008 3:55 PM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] BasicWeb.c behavior
> 
> Pettinato, Jim wrote:
> > I think the issue they're expressing is that the PCB memory pool's
> > associated stats.err member gets incremented in this case even though
> > the fail/kill/retry sequence ends up being successful?
> 
> OIC.
> 
> In my opinion, I think the current behaviour is correct though. lwip _did_
> have an allocation failure, and it had to take special and non-standard
> action (killing off a pcb in TIME WAIT) in order to continue operating. It
> was an error, just one it was able to work around; a "near-miss". I think
> hiding this fact would be incorrect. It's good to know about these sorts
> of problems so you know that you are skating on thin ice.

These are PCBs that have been closed through tcp_close but not been closed
due to a TIME_WAIT.  If one were to keep refreshing a page (longer than it
takes to "gracefully" close the PCB), then it's possible to need 100's of
TCP_PCBs, wasting memory.  I think what might be better is a forced close
when e.g. tcp_sent is called with nothing left to send, which is where the
close is occurring in one scenario.  Like an SO_NOLINGER with a timeout of
0, which does that same thing (closes the socket immediately).

If we call tcp_kill_timewait and it doesn't free a PCB, then we do have an
error.  In what we're seeing, the socket has been closed (and everything
sent because tcp_sent is called with 0).

> What you could argue, though, is that it may be useful to know about the
> times there's an error it recovered from and when it couldn't. Perhaps
> there should be an extra stat?

That would be useful as then it wouldn't affect the error count that I think
is more important to avoid.

Bill