profile
viewpoint

ofirm93/SoftwareProject 1

My final project at the Software Project course

ofirm93/CarAssistant 0

Car Assistant app is you car voice assistant supporting hebrew. Make phone calls with your voice only.

ofirm93/CAT 0

CAT - the Configuration Assistant Tool for Enterprise Wi-Fi networks such as eduroam

ofirm93/core 0

:house_with_garden: Open source home automation that puts local control and privacy first

ofirm93/eks-workshop-sample-api-service-go 0

Sample Kubernetes service used in the EKS Workshop CI/CD CodePipeline module

ofirm93/freeradius-server 0

FreeRADIUS - A multi-protocol policy server.

ofirm93/Moviez 0

Moviez - movies recommendation app

ofirm93/radius 0

a Go (golang) RADIUS client and server implementation

ofirm93/rtl8812au 0

RTL8812AU/21AU and RTL8814AU driver with monitor mode and frame injection

issue commentlayeh/radius

Allow radius response to timeout

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.

ofirm93

comment created time in 2 months

issue commentlayeh/radius

Allow radius response to timeout

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

ofirm93

comment created time in 2 months

PR opened layeh/radius

Add read timeout

Fixes issue #78

+44 -3

0 comment

4 changed files

pr created time in 2 months

issue commentlayeh/radius

Allow radius response to timeout

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.

ofirm93

comment created time in 2 months

PR opened layeh/radius

Add read timeout

Fixes Issue #78

+44 -3

0 comment

4 changed files

pr created time in 2 months

issue openedlayeh/radius

Allow radius response to timeout

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.

created time in 2 months

create barnchofirm93/radius

branch : add_read_timeout

created branch time in 2 months

startedlayeh/radius

started time in 2 months

more