As the original poster who stirred up the hornet's nest, thank you to the group for the informative discussion.
I won't be concerned about these "errors", since they are normal. Could the BasicWeb.c code be modified to avoid leaving the lingering TCP connections? I will resume my original quest: trying to figure out how my simplistic TCP server is killing the BasicWeb.c webserver from its normal operation. My TCP server receives a simple, short command, then responds with a short (28 byte) message and leaves the TCP connection open for subsequent command/response sequences from the same TCP client. I have a TCP client program that simply opens a TCP stream connection, sends a command then waits for the expected response. It repeats this sequence once per second and leaves the connection open until the program is manually terminated. My TCP server and TCP client test program seem to run properly by themselves and I don't see any errors showing up in the lwip_stats. If I start my TCP client program after the BasicWeb.c program is running and refreshing a web page every 5 seconds, then as soon as my TCP client program operates, the BasicWeb.c program fails to see any additional connections. The response to the web browser seems to include TCP flags of ACK and RST. This I suppose is a connection abort. Anyway, I am hoping that the problem can be resolved by adjusting some parameters in the lwipopts.h file. I will post a pitiful plea for expert guidance once I can properly describe my operating scenario with some specifics. My thanks again to a very knowledgeable and helpful group. Dave Squires ----------------------------------- SQUIRES ENGINEERING, INC. 2604 Lowell Circle Melbourne, FL 32935-2215 phone: (321) 242-8611 fax: (321) 242-0949 website: http://www.squires-eng.com ----------------------------------- > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Bill Auerbach > Sent: Friday, February 08, 2008 4:05 PM > To: 'Mailing list for lwIP users' > Subject: RE: [lwip-users] BasicWeb.c behavior > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] 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 > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
