TCP 4.0.0 Network buffer exhaustion problem

Hi,
I created a task that only performs sending operations using TCP 4.0.0 with the Zynq card.
In this case, a problem occurs like this: In order for the sending process to be performed, the socket must be connected to a port. The opposite device can send data to this port. But I don’t listen to this port. I’m just sending. In this case, since I am not listening, the network buffer is not released. And finally it ends and the send process stops. What will I do in this situation? After all, I cannot control the other device. It can send to any port it wants.

1 Like

So you’re using only UDP and only sendto a host ?
How is ipconfigUDP_MAX_RX_PACKETS and ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS configured ?
See ipconfigUDP_MAX_RX_PACKETS and ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS for details.

Thank you for joining this forum!

I think that the behaviour is quit logical: when you refuse to read from a socket under eg. Linux, you’re also wasting resources.

The easiest way to avoid this problem is to call recvfrom() regularly.

Have you checked out ipconfigUDP_MAX_RX_PACKETS and the socket option FREERTOS_SO_UDP_MAX_RX_PACKETS ?

This option limits the number of UDP packets that are received/stored to the socket. I think that you can put it to zero with the socket option.

Please report back how it goes.

1 Like

Hi @htibosch,
first of all thank you for your answer.
I tried the secnd solution and it worked. I defined ipconfigUDP_MAX_RX_PACKETS and assigned the maximum value. (0xFFFFFFFF) Then I assigned the max packet value to 0 using the FREERTOS_SO_UDP_MAX_RX_PACKETS definition. When I checked, I saw that the network buffer was not reduced.

Also thanks to Hartmut, who answered just a minute earlier, and who pointed into the same direction.

Thanks for reporting back. I think that the post can be marked as “solved”. Can you do so @ahmetunal?

1 Like