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

Closing handlers and TCP connection state #48

Open
StevenResiot opened this issue Jan 19, 2022 · 5 comments
Open

Closing handlers and TCP connection state #48

StevenResiot opened this issue Jan 19, 2022 · 5 comments

Comments

@StevenResiot
Copy link

Whenever I close a handler, any open TCP connection underneath stays open (and times out after idling - default 60seconds).

As my program dynamically opens connections to different slave servers, and as a customer is running a Modbus server that only allows one connection per IP(ugh, I know), I find myself stuck in having a single connection that customers do not always have a reference to. Additionally, I have customers wanting to access the server with different timeout settings so I'm kind of stuck as connection settings cannot really be changed after a connection is open.

Long story short: I need to open connections, do my thing, and disconnect right away. The only way I found so far is to set an IdleTimeout of a few milliseconds, but this is far from optimal.

How do I close an open TCP connection? Closing the handler doesn't close its open connections, and there's no Close method for the Client object.

Cheers

@frzifus
Copy link
Contributor

frzifus commented Jan 19, 2022

Did you test this in an extra debug/test program or can independent/higher-level program logic cause this?

I wonder because the exposed close and internal closeIdle method of tcpTransport call the same internal close to terminate the TCP connection.

net.Conn close says:

// Close closes the connection.
// Any blocked Read or Write operations will be unblocked and return errors.
Close() error

@StevenResiot
Copy link
Author

I'm confident in my testing.
I create a handler, defer handler.Close(), and return modbus.NewClient(handler) after checking handler.Connect() doesn't return an error.
Now I have a closed handler, a derived connection from it which works for a minute but no way to Close() it.

@frzifus
Copy link
Contributor

frzifus commented Jan 25, 2022

Not sure if i understood your control flow correctly.

Does it look like this?
func newModbusClient() modbus.Client {
	h := modbus.NewTCPClientHandler("127.0.0.1:502")
	if err := h.Connect(); err != nil {
		panic(err)
	}
	defer h.Close()
	return modbus.NewClient(h)
}

func main() {
	c := newModbusClient()
	if _, err := c.WriteSingleRegister(0xFF, 0xFF); err != nil {
		panic(err)
	}
}

would be good if you could share some code and logs if available.

@frzifus
Copy link
Contributor

frzifus commented Jun 13, 2022

Is this still a thing @StevenResiot?

I create a handler, defer handler.Close(), and return modbus.NewClient(handler) after checking handler.Connect() doesn't return an error.

My guess is that your defer handler.Close() call will close the handler like in the example.

cc @Carelo @guelfey

@guelfey
Copy link
Member

guelfey commented Jun 14, 2022

@StevenResiot a minimal reproducing example code would indeed be very useful here, without this I don't know how to proceed here

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

No branches or pull requests

3 participants