How to achieve resilience about knx-go

[vapourismo]

A resend interval and response timeout that large are not recommendable.
Imagine a frame is lost, that means it will be resend only a minute later.

And if the heartbeat fails during that time, the connection will be terminated.

From the protocols perspective, it is almost impossible to tell if the device is just busy, dead or there is a network issue.

The library is fairly low-level. It doesn't do reconnects.

I suggest building something on top which does rebuild the tunnel client when it fails.

[ferllings]

Thanks,

so I should use a shorter resendInterval (500 mili), and something like 2mins for the responseTimeout as the previous unclosed connection will only be released after 1 min.

Then handle the disconnect/unavailable gateway on my app.

[vapourismo]

I image it would be a channel-like abstraction on top of the TunnelClient that on repeated failure to send or on the inbound channel being closed (which indicates a closed connection) simply discards the TunnelClient and instantiates a new one. Possibly needs to make the errResponseTimeout error public so you can compare against it. That would be a simple solution.

I've had a bit of time to think about it and I think this can actually be integrated into the TunnelClient directly. However it wouldn't be too easy and I have neither the time nor the motivation nor the means to test it. In any case I am happy to accept PRs though 😄

[vapourismo]

Actually, I think the TunnelClient already tries reconnect: https://github.com/vapourismo/knx-go/blob/master/knx/tunnel.go#L508

However, it only retries once. So what is needed is to extend the TunnelConfig to support a reconnect attempt counter.