Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

FreeRTOS_connect(): reusing socket after connection timeout not possible?

Posted by rbos36 on January 17, 2018

I have a client socket on which I use FreeRTOSconnect() with a five second timeout. In principle, the code should loop, trying to connect, until it has a connection. The way I thought I could do this, is to call FreeRTOSconnect() on 1 and the same socket, until it returns 0.

When the other side does not accept the connection, FreeRTOSconnect() returns -pdFREERTOS_ERRNO_ETIMEDOUT as expected. However, when I call FreeRTOSconnect() again on the same socket, it returns -pdFREERTOS_ERRNO_EINPROGRESS; however, I expected to get a timeout again.

Is this expected behavior?


FreeRTOS_connect(): reusing socket after connection timeout not possible?

Posted by heinbali01 on January 17, 2018

Hi Ronald, I am not sure what the BSD rules say about this, but I would always create a new client socket for each attempt to connect() to a peer. So once connect() has returned an error, close the socket, and start with a new one. More in general: a socket only has one life cycle. One exception is possibly a socket that listens and calls accept(): it can be used for ever as it always stays in the same listening state.


FreeRTOS_connect(): reusing socket after connection timeout not possible?

Posted by heinbali01 on January 18, 2018

Here is some more information about the behaviour of FreeRTOS_connect() :

FreeRTOS_connect() starts by looking-up the MAC-address of the target. If the IP-address has an entry in the ARP table, this happens very quickly. When an ARP look-up is needed, it will take at least half a second.

The number of attempts ( sending a SYN ), and the time-outs between them are fixated in the library source code:

~~~ 0.000 sec SYN-1 3.000 sec SYN-2 9.000 sec SYN-3 ~~~

You can either connect() to a remote device in a blocking way, or by polling.

Blocking: the socket option RCVTIMEO determines the maximum time that FreeRTOS_connect() will wait for a connection:

~~~ /* Wait at most 5 seconds. */ TickTypet xTimeout = pdMSTOTICKS( 5000ul ); FreeRTOSsetsockopt( xSocket, 0, FREERTOSSORCVTIMEO, ( void * ) &xTimeout, sizeof( BaseType_t ) ); ~~~

Mind that a useful value for RCVTIMEO is either +/- 2, 5, or 11 seconds.

When using FreeRTOS_select(), a successful FreeRTOS_connect() will be notified as a eSELECT_WRITE event. A successful acceptance of a new client triggers a eSELECT_READ event. You can find complete examples of using FreeRTOS_select() in the "protocols" directory ( FTP and HTTP server ).

When using "non-blocking" ways to connect, you can call this function to see if a connection was established:

~~~ /* returns pdTRUE if TCP socket is connected */ BaseTypet FreeRTOSissocketconnected( Socket_t xSocket ); ~~~

You may also call FreeRTOS_recv() before the connection is established, to see any errors that might occurs.

If you do not want to block on FreeRTOS_connect(), and you don't want to use FreeRTOS_select(), there is a third way. Let your task block on a semaphore, and bind that semaphore to all sockets that it owns:

~~~ /* Define this in you FreeRTOSIPConfig.h */

define ipconfigSOCKETHASUSER_SEMAPHORE 1
/* Bind a semaphore to a socket. */
FreeRTOS_setsockopt( xSocket, 0, FREERTOS_SO_SET_SEMAPHORE, ( void * ) &xMySemaphore, sizeof( xMySemaphore ) );

~~~

The semaphore will be given to for every event of interest: RX, TX, connect succeeded, acceptance of a client. The same semaphore can be "bound" to many sockets of all types.

I attached a working "hello world" example of this method: "socketusingsemaphore.c"

Attachments


FreeRTOS_connect(): reusing socket after connection timeout not possible?

Posted by rbos36 on January 18, 2018

Thanks Hein for the confirmation that this is indeed expected behavior.


FreeRTOS_connect(): reusing socket after connection timeout not possible?

Posted by kenchang1 on January 29, 2018

Hello Hein,

I have a question that is related to the question above. When I use FreeRTOS_shutdown() to close a TCP connection but I don't close the socket, can I use the same socket to reconnect?

When I reboot the remote side, my device running FreeRTOS+TCP thinks it is still connected and +TCP refuse to reconnect. The only solution is closing the socket?

regards, Ken


FreeRTOS_connect(): reusing socket after connection timeout not possible?

Posted by kenchang1 on January 29, 2018

I have solved the issue with ipconfigTCPKEEPALIVE = 1. The connection will be closed automatically and I can reconnect again without closing the socket.


FreeRTOS_connect(): reusing socket after connection timeout not possible?

Posted by heinbali01 on January 29, 2018

I have a question that is related to the question above. When I use FreeRTOS_shutdown() to close a TCP connection but I don't close the socket, can I use the same socket to reconnect?

That is not possible. I think that other OS's have the same behaviour in this respect.

When I reboot the remote side, my device running FreeRTOS+TCP thinks it is still connected and +TCP refuse to reconnect. The only solution is closing the socket?

I have solved the issue with ipconfigTCPKEEPALIVE = 1. The connection will be closed automatically and I can reconnect again without closing the socket.

Ah yes of course. I was assuming that your application is sending data continuously. The peer only gets a chance to send a RST when it receives some data.

Personally I prefer to check the liveliness of a connection by sending AYA ( Are You Alive ) messages to the other application, as real TCP data. In some rare cases, a low-level KEEP-ALIVE messages is understood and responded to, while the application is not able to send data for whatever reason. But often we are only developing one side of the communication, the other side being a "black box". In those cases, the ipconfigTCP_KEEP_ALIVE option is very useful.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Webinar

"OTA Update Security and Reliability" webinar presented by TI and AWS. Register here.


Careers

FreeRTOS and other embedded software careers at AWS.


Latest News

FreeRTOS kernel V10.0.1 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner