The problem with that is that the task is blocked here and as a result the keep alive counters are stopped and the connection never closes.
Is this the intent? Am I missing some concept? I would like the connection to timeout after such an event so the server is free again for another device
FreeRTOS+TCP KeepAlive behaviour
For a TCP connection socket, when disconnecting the other device, the stack sends 3 keepalive packets then closes the socket which is great.
The problem happens when the device itself is disconnected from the switch (pulled cable out – link down). The IP task detects the link down successfuly then calls the driver initialization function and blocks there until link up (this is the recommended behavior per a comment in the stack code): from FreeRTOSIP line 1332:
if( xNetworkInterfaceInitialise() != pdPASS )
{
/* Ideally the network interface initialisation function will only
return when the network is available. In case this is not the case,
wait a while before retrying the initialisation. */
vTaskDelay( ipINITIALISATIONRETRYDELAY );
FreeRTOSNetworkDown();
}
FreeRTOS+TCP KeepAlive behaviour
Hi Ben,
What platform are you using?
For a TCP connection socket, when disconnecting the other device, the stack sends 3 keepalive packets then closes the socket which is great.Just to make it clear, you mean physically disconnecting. The remote device is unplugged and it will no longer respond to the keep-alive messages. After a third message, the socket gets into a
eCLOSE_WAIT
state, i.e. the socket shall be closed by the application (without shutting it down).
In source code:
~~~
BaseTypet rc = FreeRTOSrecv( xSocket, pucBuffer, sizeof( pucBuffer ), 0 );
if( rc == -pdFREERTOSERRNOENOTCONN )
{
// The socket is not connected any more
FreeRTOS_closesocket( xSocket );
xSocket = NULL;
}
~~~
And now you unplug your +TCP device from the LAN:
…pulled cable out – link down. The IP task detects the link down successfully then calls the driver initialization function and blocks there until link up (this is the recommended behavior per a comment in the stack code)This was indeed how the IP-stack used to work, but since we have keep-alive packets, I tend not to use
FreeRTOS_NetworkDown()
any more. Once the +TCP stack is up, let it stay up.
It is important that xNetworkInterfaceOutput()
does not attempt to send data as long as the Link Status is low. That would lead to delays and errors.
FreeRTOS+TCP KeepAlive behaviour
Thanks Hein, Keeping the stack up seems to solve this. When the link is down I make xNetworkInterfaceOutput() return a _FALSE after releasing the packet buffer.
FreeRTOS+TCP KeepAlive behaviour
When the link is down I make xNetworkInterfaceOutput() return a FALSE after releasing the packet bufferAfter checking the value of
bReleaseAfterSend
, I suppose:
~~~
if( bReleaseAfterSend != pdFALSE )
{
vReleaseNetworkBufferAndDescriptor( pxDescriptor );
}
~~~
xNetworkInterfaceOutput()
is called from four different places, and the return value is never tested.
Regards.