Hi,
I have established five TCP socket connections using the Network and RTOS libraries.
uint32_t tcp_cb_func (int32_t socket, netTCP_Event event,const NET_ADDR *addr, const uint8_t *buf, uint32_t len) { switch (event) { case netTCP_EventConnect:break; case netTCP_EventEstablished:break; case netTCP_EventClosed:break; case netTCP_EventAborted:break; case netTCP_EventACK:break; case netTCP_EventData:break; } return 1; //1 - incoming connection accepted. } void Send_Message_To_TCP(int S){ uint8_t *Mem; if (Socket[S].SCK >= 0) { if (netTCP_SendReady (Socket[S].SCK)) { Mem=netTCP_GetBuffer (TCP_Size); if(Mem==NULL) { return; } Socket[S].sendbuf = Mem; memcpy (Socket[S].sendbuf, TCP_MSG, TCP_Size); netTCP_Send(Socket[S].SCK, Socket[S].sendbuf,TCP_Size); osDelay(5); } } } __NO_RETURN static void app_main (void *argument) { // //Other Codes // //each 30ms for(i=0;i<5;i++) { Send_Message_To_TCP(i) } }
The system functions correctly until a TCP connection is disrupted, either by disconnecting the Ethernet cable or by suddenly powering off the device. For instance, when Socket 4's Ethernet wire is disconnected abruptly, the timeout counter starts counting down from 60 seconds. Meanwhile, when a new connection for Socket 3 is accepted and its state changes to 'Established,' it sends only one packet and does not transmit any further data during the timeout period.
As the new connection (Socket 3) begins counting down its timeout, sometimes, the timeout for the previously disconnected Socket 4 is reset to 60 seconds. Consequently, the new connection is disconnected more quickly than the timeout for the previously disconnected socket. Upon investigation, I found that the netTCP_SendReady function only operates after the acceptance of a new connection. After that, it returns false during the established connection, which explains why only one packet is sent.
Socket 4
I also checked the thread priority, and all of them work fine.(I've disabled round robin)
What is my mistake? Any help would be appreciated.
Dear Franc Urbanc,
Thank you so much for your response.
I’ve been thinking about your explanation, and I realize that this issue will affect all MCUs with SRAM memory smaller than the PC TCP window(256Kbyte)
I’ve searched quite a bit online, but I haven’t found any effective ways to control the TCP receive window in Windows when using different software.
It’s frustrating because this situation leads to network interruptions for a simple disconnection, especially when the device is working as an IoT device. These interruptions can cause many problems.
Do you know if there's a solution to this problem? I would appreciate any advice you can provide. Thanks again for your help!
As already mentioned, TCP is a complex protocol. The default configuration is good enough for optimal performance, i.e. up to 10 Mbytes/s in both directions. Of course, there are many factors that affect transfer speed, to name just a few: MCU speed, media speed (usually Ethernet), network topology, etc. For example, if a packet has to pass through several routers and gateways, the speed drops.
I suggest that you don't worry so much about the internals of TCP, but instead focus on using the socket. You could use the BSD socket interface instead. BSD is a layer of software that converts native TCP sockets to behave like standard BSD sockets. This allows you to use network sockets on a PC and on an embedded system in generally the same way.
Thank you again for your quick response.
Sure, but I need to know how to handle this scenario. Because the memory is limited, the timeout should be about 60 seconds, and during the interruption in one socket, the other sockets should continue working.
Do you have any suggestions on how to bypass this interruption as quickly as possible and make the sockets operate independently of each other?
But sockets work independently. The Telnet server can be configured to accept multiple simultaneous connections, with each client doing something different. If you configure it for three sessions, the server can accept three simultaneous clients. They do not interfere with each other, ok, maybe if the first user turns on the LED on the board and the second user turns it off.