Problem with request timeouts about gosnmp

[wdreeveii]

The changes can be found here:

wdreeveii/gosnmp-sonia@9b60403

Unfortunately I can not submit a proper pull request because of the way I had to 'fork' this repository. :(

[codedance]

I understand your use case. I do however disagree with this change. The timeout should be for the blocking API call as a whole, not what happens at the implementation layer.

There are two setting:

1. Timeout - this blocking request will take no longer than X.

2. Retries - SNMP sits on UDP and we must implement our own retry logic to cover packet loss. IMHO this is really not a "user setting" - Just like we really never change our TCP stack's default retransmission settings.

The statement:

The next problem is that the timeout is divided among retry attempts. If you have a
large amount of retries, and a relatively small timeout, your effective request timeout
is extremely small.

is not quote correct. The current code stores the request IDs for all requests that have been set. If the first one (or any retry request) was to arrive in any order, the response would be used and returned. At the API level, the effective request timeout will be equal to the timeout as set.

The design is analogous to that used in net-snmp and snmp4j.

The point you raise about library usability and default timeouts is a good one. I agree that the default timeout should be increased.

In walkexample.go you'll see the following code, just for this reason!

gosnmp.Default.Timeout = time.Duration(10 * time.Second) // Timeout better suited to walkin

The current default is only 2 seconds. snmp4j for example has a default of 60 seconds. I'd like to put a stake in the ground and say 30s would be a better default. @soniah and @virtuallynathan would you agree?

[soniah]

Thanks @codedance . I had surgery last Friday, so I'm a bit "out of sorts" :-/

[wdreeveii]

OK, I understand how this is supposed to work now. I will need to change the way I am thinking about this because with the timeouts I was using, there is unnecessary load on the network.

The timeout supplied to this library should be [maximum allowable network latency] * [retries].

[codedance]

@wdreeveii Do you agree that the default timeouts should be increased? What are your thoughts on what a logic timeout would be for your use-case?

[wdreeveii]

I think 60s is a good timeout. That is what I am currently using for
bandwidth constrained high latency satellite links. We allow 15 second
timeout per transmission with 4 retries.

On Wed, Sep 3, 2014 at 8:23 PM, Chris Dance [email protected]
wrote:

@wdreeveii https://github.com/wdreeveii Do you agree that the default
timeouts should be increased? What are your thoughts on what a logic
timeout would be for your use-case?

—
Reply to this email directly or view it on GitHub
#31 (comment).

Whitham D. Reeve II
907-764-5263

[soniah]

Thanks Chris @codedance, I'll have a think later. Just been catching up on some other pull requests...