RE: [lwip-users] BasicWeb.c behavior

[BMW Cyclist RR]

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: address@hidden
> [mailto:address@hidden 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: 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
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>