First, the current default is insensible, as it doesn't set any timeout which means it will block forever. This is a real problem for protocol such as UDP where no acknowledgement is promised. This caused a bug in my program and it was pretty hard to trace it. I think that to make the library more user friendly and require less internal knowledge of the library internals it would be better to set reasonable timeout and let the user optimise it if needed.

This is only because context.Background() was used, no? Would have adding a sensible timeout to the context passed to the function solved this issue for you?

I used a context without that timeout property. When I added timeout it solved the issue, yet that feature is not that well documented in the library. Digging into the code discovered it. I think that a less experienced developer will tackle this and wouldn't find how to unblock the function call.

Second, the context setting is for the whole function call, and the response specific timeout is more granular.

Is there a real-world scenario why such a granular setting would be required? (I would simply like to avoid making the API surface larger if it can be helped).

Right now I have reason to believe it is enough, yet I think that just like retry count the timeout of web request should be set to some default and be tuned in case it is required.

The real issue here is the missing default and, in my opition, it would be harder to enforce default value as context property.

For compatibility, I set the default client timeout to 0 (no timeout) it should be changed to a reasonable value.

Fixes issue #78

I saw this option before I opened this issue. Although it is possible solution, there are some problems with it:

First, the current default is insensible, as it doesn't set any timeout which means it will block forever. This is a real problem for protocol such as UDP where no acknowledgement is promised. This caused a bug in my program and it was pretty hard to trace it. I think that to make the library more user friendly and require less internal knowledge of the library internals it would be better to set reasonable timeout and let the user optimise it if needed.

Second, the context setting is for the whole function call, and the response specific timeout is more granular.

Fixes Issue #78

Enhancement: currently after RADIUS request is sent (via Client.Exchange()) the response to the requests blocks. In order to allow the response to timeout, a ReadTimeout can be set on the connection.