On Thu, Jan 5, 2017 at 4:43 PM, Joel Cunningham <[email protected]>
wrote:

>
> RAW_PCB exhaustion is most likely unrelated to the problem you’re seeing.
> When TCP segments are allocated in tcp_write() (with TCP_WRITE_FLAG_COPY
> specified) there are two allocations: PBUF_RAM (coming from LwIP heap,
> controlled by MEM_SIZE) and struct tcp_seg (coming from MEMP_NUM_TCP_SEG
> static memory pool)
>
>
You're right, I made a mistake when tracing the pool names. It's not the
RAW_PCB pool that exhausted but the LwIP heap. So that seems clear to me
now.


> In order to size these two pools according to what your connections can
> handle, you can use a worst case calculation where you assume all
> connections have a full send buffer worth of MSS segments.
>
> MEM_SIZE: should be at least MEMP_NUM_TCP_PCB * TCP_SND_BUF with some
> extra space for miscellaneous heap allocations
>
> MEMP_NUM_TCP_SEG: should be at least MEMP_NUM_TCP_PCB * (TCP_SND_BUF /
> TCP_MSS)
>
>
 Thank you for this information! I came up with the same calculation for
MEM_SIZE, but did not yet consider MEMP_NUM_TCP_SEG.


> I haven’t used LWIP_SO_LINGER in my port, but when not enabled, you get
> the default TCP closure behavior which is a graceful close with a 20 second
> timeout (see LWIP_TCP_CLOSE_TIMEOUT_MS_DEFAULT)
>
>
I observed that this timeout does not occur when the send buffer of the
socket is full when it gets closed. In my case where the peer does not
respond, the TCP_BCP is released only after all retransmissions failed,
which takes pretty long with the default setting of TCP_MAXRTX==12.

What state is the PCB in after closing the listener?  That sounds strange
> that this would pcb would hang around
>
>
Here again, I did not correctly trace the pool name. It's TCP_PCB instead
of TCP_PCB_LISTEN, so I understand that the TCP_BCP structure hangs around
during retransmissions.

Daniel

Joel
>
> _______________________________________________
> lwip-users mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to