ResponseTimeout is not configurable on per message basis about go-coap HOT 5 OPEN

Also, I can notice that in the example/obsclient we are trying simple Receive() which timeouts observation after 2 sec: https://github.com/dustin/go-coap/blob/master/example/obsclient/obsclient.go#L37

This timeout must be modifiable, as we might decide to wait on receive for a long time in a separate goroutine (we observe some value and we do not know in which moment the value will come - after 2 seconds or after 10 minutes...)

from go-coap.

Hi,

I generally don't contribute to github, so I am not sure how it all works.

I have my own fork where I have addressed the issue, because our solution requires a control over response timeout at client level.

Here is a single commit where I address the issue. I have added a test case to verify that I have addressed timeout:

kulak@4ac9ea7

The solution I chose is backwards compatible, but it introduces new variant of Dial function. I added a variable to track timeout parameter. I have renamed original ResponseTimeout to be DefaultResponseTimeout, because I wanted to make sure I've got all use cases and because its meaning is to be the default.

I am personally not sure if it would've been better to request for timeout as an argument to Send call. Compatibility and simplicity of API won over and I added response timeout to Connection structure instead.

If there is an interest in merge, I will request a pull for merge.

from go-coap.

from go-coap.

Context is a very good approach. I did not even think about it as I don't usually use it because of similar reason of code base older than context. I've used context concept in .NET apps and it is a great solution to many issues with logical operation context.

from go-coap.

@dustin I definitely agree that utilizing context.Context is the way to go here. You can model it after what net/http does and make the context a part of the coap.Message. Handlers would be expected to respect ctx.Done() as they are in HTTP these days.

from go-coap.