Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patterns/best practice for reconnect-after-failure? #219

Open
PeterGrace opened this issue Sep 3, 2023 · 2 comments
Open

Patterns/best practice for reconnect-after-failure? #219

PeterGrace opened this issue Sep 3, 2023 · 2 comments
Labels

Comments

@PeterGrace
Copy link

I'm utilizing tokio-modbus with tokio-retry to do exponential backoff on a tcp-based modbus connection.

This connection can be inconsistent and the tcp stream can fail. When this happens, I get an indication in the form of an Err() that I can parse to figure out that we've lost the tcp stream entirely.

My question: What's the best practice on disconnecting and reconnecting to the same socketaddr/slave_id that was being used in the context prior to a disconnect? I'm trying to do a ctx.disconnect() followed by creating a new ctx object with a fresh connection via tcp::connect_slave() call but I'm wondering if there's a better/more expected way to handle this scenario?

@dr-kernel
Copy link

I would very much like to know this too.
Currently I'm doing the same as Peter.

@1787611685
Copy link

I also want to know how to gracefully determine that the connection has been lost and exit the loop reading to re-establish the connection when the Modbus TCP connection is lost. The reconnection mechanism I am currently using is the same as yours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants