Continuous ConnectWithRetries

[Exergist]

Would it make sense to create a ConnectWithRetries that has no timeout limit? If so though there would probably also need to be a way to terminate the connection attempt process.

Sure this could be achieved in practice with some looping and exception handling, but a native solution might be nice.

[jchristn]

Hi @Exergist personally I feel it's an awkward workflow to try to implement generally since each use case is going to be different.

Realistically you could call public void ConnectWithRetries(int? timeoutSeconds = null) with a ridiculously large number (it is an int32 so... 2^32 - 1) and it would take 2147483648 seconds to time out, which is 35791394.1333 minutes, which is 596523.235556 hours, which is 24855.1348148 days, which is 68.0962597666 years.

[Exergist]

@jchristn I noticed that giving ConnectWithRetries a value of (int)Math.Pow(2, 25) - 1 (which evaluates to 33554431) produces the following error:

And then providing ConnectWithRetries a value of -1 produces this error:

[jchristn]

Hi @Exergist yes - the value specified in ConnectWithRetries is seconds.

Task.Delay (which I am using to determine the timeout) expects milliseconds. Therefore the supplied value, multiplied by 1000, must remain an integer and not exceed int32.max.

I'll amend with a new version to use milliseconds everywhere shortly to make it consistent.

Cheers, Joel

[jchristn]

Try this and all should be well

NuGet: https://www.nuget.org/packages/SuperSimpleTcp/2.4.0
Commit: 7bbfd15

[Exergist]

@jchristn So now that we may pass a max of 2147483648 ms (24.9 days), do you still view that as "long enough" to be an effectively ~infinite timeout for ConnectWithRetries? Again, there are ways around this, but ~25 days of native timeout seems much less than ~68 years. I'm probably making a mountain out of a molehill, but I figured I'd inquire.

Also what is the right way to gracefully terminate the ConnectWithRetries process if a connection has not yet been made? Would calling Dispose do the job?

[jchristn]

Definitely not infinite, but I generally don't think it's a good idea to write code that waits for a socket to open for very long. For me, I'd likely build systems in a way that, if a client were unable to connect over a span of a few minutes, and the expectation is that is should be able to connect, the system would fire events/messages to notify me.

Calling Dispose will cancel the cancelTask within ConnectWithRetries, so it will cause a TimeoutException as if the client had retried the entire time, so that will work.