TCP driver reconnect time

[zimri-leisher]

F´ Version	3.5.1
Affected Component	TcpClient

---

Problem Description

We are now having the following issue:

1. Given a TcpClient set up to send to an IP which is not currently running a TcpServer
2. When we invoke the send port of the TcpClient
3. We see it make a call to connect every time
4. This delays the calling thread by 10-20 ms, which at the rate we are scheduling it, quickly causes the rate group queue to overfill and assert.

For some reason, we were not seeing this issue before we updated. Perhaps it was only occasionally trying to reconnect?

Context / Environment

Execute fprime-util version-check and share the output.

Operating System: Linux
CPU Architecture: x86_64
Platform: Linux-5.15.133.1-microsoft-standard-WSL2-x86_64-with-glibc2.35
Python version: 3.10.12
CMake version: 3.22.1
Pip version: 22.0.2
Pip packages:
    fprime-tools==3.5.1
    fprime-gds==3.5.1
    fprime-fpp-*==2.2.1
Project submodules:```

[LeStarch]

Part of the TCP refactor was to add connect/reconnect capability on the send side of the TCP library as well as on the recv side. The reason is that we had issues where send would fail if the read reconnect had not happened yet.

For use cases such as this, it is expected that you connect before attempting to send and thus ensure that the connect/reconnect does not happen yet.

You can also set reconnect = false in the configure call to disable all reconnect behavior.

[zimri-leisher]

Ah, I see. That makes sense. Maybe we could consider adding a timeout to the connection attempt? It makes a lot of sense to attempt to connect, but it violates the assumption we made that setting a timeout in the ::configure method would put a bound on the execution time of the send port. I can make a ticket and look into implementing that if interested.

[LeStarch]

We could add a connection timeout, and I wouldn't be opposed to it. However, I think the preferred method would be to turn off auto-open, and handle the connection off the critical thread.

I don't know if a timeout will properly bound that call anyway because you have two timeouts: SEND, and RECV. The connect call would be composed of n number of send an receives to establish the connection.

The best way to get a pseudo-bound on the send is to not connect on send. Then it will be limited to 1 iteration of the send timeout.

F Prime does not currently support send timeouts. You have to address the socket directly for that. If this feature is needed we can consider adding it.

All in all, let me know how you'd prefer to proceed with this ticket: is this still worth considering, or should we polish the alternatives.