> > If you have LwIP stats enabled, you can check the memory pools for errors > to figure out which one is failing. You should be able to resolve this by > sizing your memory pools to handle the number of supported connections. > For example if you only support 5 simultaneous TCP connections, then your > pools should be big enough to allocate 5 send buffers worth of segments. > This is how I configure my products, which typically have plenty of RAM. > Not sure what the recommendation is for very constrained RAM products.
Using LwIP stats I found that memory allocations from RAW_PCB failed. By increasing MEM_SIZE I was able to avoid the issue. I'm still unsure about a reasonable value here, given that we want to support up to 64 simultaneous TCP connections (MEMP_NUM_TCP_PCB==64). It is not a constrained RAM product, though. Yes there is, with SO_LINGER you can perform an abortive closure rather > than graceful by setting the timeout to 0. Typically this is a bad idea. > There’s a decent discussion here on stackoverflow: > > http://stackoverflow.com/questions/3757289/tcp-option- > so-linger-zero-when-its-required > We are using the default setting of LWIP_SO_LINGER==0. If I understand correctly, this already completely disables linger processing and should correspond to an abortive closure by setting the timeout to 0 as you suggested. Is there another way to tell LWIP to release any resources associated with a socket immediately? Even when increasing MEM_SIZE, I feel uneasy about misbehaving clients (ignoring retransmissions, reconnecting frequently) eating up all server resources over time. In the case of unanswered retransmissions, I observed that the TCP_PCB_LISTEN allocation counter is not decremented after close() for a long time (probably 25 minutes?). Daniel
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
