When TCP only receives data and does not send data, the FreeRTOS-recv function cannot return for a long time

Libraries
1

FreeRTOS Kernel V10.4.6，FreeRTOS Plus TCPIP v3.1.0.
When TCP only receives data and does not send data, the FreeRTOS-recv function cannot return for a long time.
When I establish a TCP client or server and successfully connect to the computer, there is no problem when I perform a loopback test (when the computer sends it to FreeRTOS, FreeRTOS receives it and returns it to the computer),every millisecond when the computer sends 8000 bytes of FreeRTOS, it can return it to the computer. But if FreeRTOS only receives but does not send to the computer, then it is not a problem for the computer to keep sending small packets (such as sending 10 bytes every 20 milliseconds); If larger packets are sent, the FreeRTOS-recv function may require a delay to return. For example, if a computer sends 600 bytes per second to FreeRTOS for a total of 10 seconds (6000 bytes in total), it may receive 600, 1200, and later receive 3000, 6000, with a delay time of several seconds. At this point, FreeRTOS does not respond every time it receives a TCP segment. I want to know how to respond every frame received.
Is it related to the Nagle algorithm and ACK delay?
Or is it related to random numbers? The STM32F103VET6 I used does not have hardware random numbers, so it always returns 10000+138 * n (++) each time;

My current settings are as follows:
#Define ipconfigUSE.TCP_WIN 0
#Define ipconfigTCP_TX-BUFFER-LENGTH 1024
#Define ipconfigTCP_RX-BUFFER-LENGTH 1024
#Define ipconfigNUM-NETWORK BUFFER-DESCRIPTORS 16
#Define ipconfigEVEN_QUEUE-LENGTH (ipconfigNUM-NETWORK BUFFER-DESCRIPTORS+8)
#Define ipconfigTCP MSS ( ipconfigNETWORK_MTU - ipSIZE_OF_IPv4_HEADER - ipSIZE_OF_TCP_HEADER )
#Define ipconfigTCP_KEEP-ALIVE 1
#Define ipconfigTCP_KEEP-ALIVE-INTERVAL 20
#Define ipconfigTCP_HANG-PROTATION 1
#Define ipconfigTCP_HANG-PROTATION-TIME 30
#Define ipconfigIGNORE-UNKNOWN-PACKETS 0
#Define ipconfigSOCK-DEFAULT-RECEIVE-Block-TIME pdMSTO-TICKS (5000)
#Define ipconfigSOCK-DEFAULT-SEND-BLOCK-TIME pdMS-TO-TICKS (5000)

2

It should be that ipconfigTCP_TX-BUFFER-LENGTH and ipconfigTCP_RX-BUFFER-LENGTH are set incorrectly. Both of them are 1024 less than ipconfigTCP MSS (1500- ipSIZE-OF-IPv4_HEADER - ipSIZE-OF-TCP_HEADER). I now set ipconfigTCP MSS to 536, and set ipconfigTCP_TX-BUFFER-LENGTH and ipconfigTCP_RX-BUFFER-LENGTH to (2 * ipconfigTCP MSS), which can work normally when only receiving but not sending.
Will the connection socket created by TCP Server inherit the size of the receiving and sending buffer of the listening socket?

3

Will the connection socket created by TCP Server inherit the size of the receiving and sending buffer of the listening socket?

Yes, the newly connected socket will inherit the buffer sizes of the listening socket among many other things (refer: prvTCPSocketCopy)

Could you share the priorities of tasks in your system? Is IP task running at a higher priority than application tasks?

4

In my system, all tasks have the same priority and there is no time slice rotation scheduling enabled. Each task will abandon CPU usage through blocking events, and no task will occupy CPU for a long time

5

As @tony-josi-aws asked, can you try running IP task at a higher priority than other tasks?

What behavior do you observe when the device is only sending data? Is the application at the other end receiving data? Can you capture network traffic?

6

I think I have solved this problem, which is ipconfigTCP_TX-BUFFER-LENGTH and ipconfigTCP_RX-BUFFER-LENGTH are set incorrectly. Both of them are 1024 less than ipconfigTCP MSS (1500 - ipSIZE OF IPv4_HEADER - ipSIZE OF TCP HEADER)，

1 Like
7

Thank you for sharing your solution!