Hard-coded timeout in WiFiSocket::Connect() results in watchdog timer resetting MCU

[S2Doc]

WiFiSocketClass::connect() has a hard-coded loop in which includes the following:

while (_info[sock].state == SOCKET_STATE_CONNECTING && millis() - start < 20000) {		
	m2m_wifi_handle_events(NULL);
}

if (_info[sock].state != SOCKET_STATE_CONNECTED) {
	_info[sock].state = SOCKET_STATE_IDLE;
	return 0;
}

_info[sock].recvMsg.s16BufferSize = 0;
_info[sock].recvMsg.strRemoteAddr.sin_port = ((struct sockaddr_in*)pstrAddr)->sin_port;
_info[sock].recvMsg.strRemoteAddr.sin_addr.s_addr = ((struct sockaddr_in*)pstrAddr)->sin_addr.s_addr;
recv(sock, NULL, 0, 0);

return 1;

}

Note that the while loop takes 20 seconds to time out. For those using SAMD21 or SAMD51 MCUs, which have a 16 second maximum on the watchdog timer, this can cause the device to reset if a connection is delayed.

A simple solution is to substitute a smaller value for the timeout, say 10000 ms. This allows the routine to proceed without triggering a reset. I suspect that is a connection is not established in 10 seconds, it is not likely to respond bu waiting long.

A much more user friendly solution is to create a new public function, say SetConnectionTimeout(uint_16 timeoutVal) which would then set a private variable used for the timeout value in this function. The default value can still be 2000, if that is desired for some reason, but users of the library can then set it to the value they need without meddling in the library code.

Changing the timeout from 20000 to 10000 stopped a highly annoying intermittent reset problem I spent quite some time wresting with. The function now happily co-exists with the SAMD51 watchdog timer.

This may explain the problems seen by others in issue #211 and #181.

I note that the WiFiSocketClass::bind and WiFiSocketClass::listen also have hard-coded timeouts, although not as long. In general, hardcoding these values seems like a bad idea.