Discussion about client.connect timeout

[JAndrassy]

Some libraries implement client.connect timeout. I think it is a very useful feature because if the remote device (server) is out of reach the connect can wait many seconds (18 seconds in WiFiNINA).

But the implementations are very different and many of the are in conflict with Stream::setTimeout(). Stream::setTimeout is a timeout for Stream class timed read operations. All public functions in Stream (with exception of the pure virtual once and the timeout getter and setter) use timed read. The timeout is in milliseconds and the default value is 1000.

Ethernet library has setConnectionTimeout introduced in the 2018 2.0.0 version by Paul Stoffregen. It is used in client.connect and in client.stop().

The Mbed Core WiFi and Ethernet libraries have setTimeout which set their timeout value used in connect. But this shadows Stream:SetTimeout. (issue)

The new Renesas core for C33 had setTimeout, but it is now changed to setConnectionTimeout based on my issue report.

The esp8266 WiFi library uses the Stream's timeout for connect. That is not ideal. The connet timeout should be seconds while the read timeout can be less than a second. (discussion).

The esp32 WiFi library has it worst. They have setTimeout in seconds which shadows Stream:setTimeout and set WiFiClient timeout and Stream's timeout from this value. (issue)

WiFiNINA, WiFi101 and WiFiC3 don't have connect timeout yet, but my PR with setConnectionTimeout are waiting.

The ESP32 WiFiClient has timeout as additional parameter for connect. I like it, but I don't like that it sets the timeout field so it overrides the value set with setTimeout. As I user I would not expect that.

Questions for discussion:

Should networking libraries implement timeout for connect if possible?

If yes, should they:

• have a parameter of connect? If yes should it be used only in the current invitation of connect or stored and used in other functions?
• have setConnectionTimeout?
• use timeout from Stream?