Is there an existing issue for this?
Current Behavior
I am using Middleware V8.2.0 and I think I may have discovered a bug in the TCP/IP stack, specifically net_tcp.c. My application is sending "heartbeat" data via BSD send() after each recv() socket timeout (20s).
When I remove the Ethernet cable between my router and internet, I expect the socket to abort/close causing recv() to return an error. This happens, but the time varies due to the stack's dynamic retry mechanism.
However, sometimes the time is excessive and I suspect this is due to a bug in the Network Component.
I have noticed from the TCP/IP stack trace that if I call send() during the retries from the previous send(), then the retry counter is reinitialised.
Please see the attached stack trace below (I modifed net_tcp.c to add additional information). You can see that my HTTPS client initially sends a frame, and that at 56.0 retries are initialised to 5 (TCP_MAX_RETRY). It retries at 056.9 (4 remaining), 058.7 (3 remaining), 062.3 (2 remaining), 069.5 (1 remaining) and then my HTTS client sends another frame. This causes the retry count to be initialised back to 5 at 076.0 and more retries occur at 076.9, 078.7, 082.3, 089.5, and then my HTTPS client sends another frame but this time the retry count is not reset as the socket is locked (096.0). Retries continue at 103.9 and then expire at 132.7, concluding with a BSD_ECONNRESET. In total there were 10 retries instead of the expected 5. Note that the re-initialisation of the retry counter in this case occurs in net_tcp.c, net_tcp_send(), line 500. Please see attached file for trace,
tcp_retries.docx
Expected Behavior
I expect send() not to reset the retry counter from the previous send(), and for retries from the previous send() to continue, causing BSD_ECONNRESET if they expire.
Steps To Reproduce
call send() and cause a broken connection (e.g. from router to internet) - TCP retries will occur
call recv() with 20s timeout (BSD_RECEIVE_TOUT)
call send() again
The stack trace shows the retry counter being re-initialised
Affected components
Version
Middleware 8.2.0
Network Component 8.2.0
Blocker
Is there an existing issue for this?
Current Behavior
I am using Middleware V8.2.0 and I think I may have discovered a bug in the TCP/IP stack, specifically net_tcp.c. My application is sending "heartbeat" data via BSD send() after each recv() socket timeout (20s).
When I remove the Ethernet cable between my router and internet, I expect the socket to abort/close causing recv() to return an error. This happens, but the time varies due to the stack's dynamic retry mechanism.
However, sometimes the time is excessive and I suspect this is due to a bug in the Network Component.
I have noticed from the TCP/IP stack trace that if I call send() during the retries from the previous send(), then the retry counter is reinitialised.
Please see the attached stack trace below (I modifed net_tcp.c to add additional information). You can see that my HTTPS client initially sends a frame, and that at 56.0 retries are initialised to 5 (TCP_MAX_RETRY). It retries at 056.9 (4 remaining), 058.7 (3 remaining), 062.3 (2 remaining), 069.5 (1 remaining) and then my HTTS client sends another frame. This causes the retry count to be initialised back to 5 at 076.0 and more retries occur at 076.9, 078.7, 082.3, 089.5, and then my HTTPS client sends another frame but this time the retry count is not reset as the socket is locked (096.0). Retries continue at 103.9 and then expire at 132.7, concluding with a BSD_ECONNRESET. In total there were 10 retries instead of the expected 5. Note that the re-initialisation of the retry counter in this case occurs in net_tcp.c, net_tcp_send(), line 500. Please see attached file for trace,
tcp_retries.docx
Expected Behavior
I expect send() not to reset the retry counter from the previous send(), and for retries from the previous send() to continue, causing BSD_ECONNRESET if they expire.
Steps To Reproduce
call send() and cause a broken connection (e.g. from router to internet) - TCP retries will occur
call recv() with 20s timeout (BSD_RECEIVE_TOUT)
call send() again
The stack trace shows the retry counter being re-initialised
Affected components
Version
Middleware 8.2.0
Network Component 8.2.0
Blocker