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

Only connect TcpClient if not already connected #78

Closed
wants to merge 1 commit into from

Conversation

schotime
Copy link
Contributor

It appears we missed this one, but Connect needs to be called otherwise _frameBuffer and _networkStream etc won't get set.

@Apollo3zehn
Copy link
Owner

Thanks, I'll merge it on Monday :-)

@Apollo3zehn
Copy link
Owner

I am not sure if this is the right approach. The constructor accepts a TcpClient and an IPEndpoint:

public void Connect(TcpClient tcpClient, IPEndPoint remoteEndpoint, ModbusEndianness endianness)

So this constructor assumes that you are not yet connected and will connect on your behalf.

If you want to fully manage the TcpClient yourself, we would need another constructor overload which only accepts TcpClient (and ModbusEndianness).

What do you think?

Note: When we make new changes, I would also like to add IDisposable support ( #67).

@schotime
Copy link
Contributor Author

I agree with using the constructor. We should also do this for SerialPort. It did feel a bit weird passing it to the connect method.
Also agree with IDisposable.
Don't know if you wanted to make the Close/Disconnect methods the same name so it can't be invoked from the ModbusClient generically also.

@Apollo3zehn
Copy link
Owner

I have changed the constructor signatures in v5 (will be released today). Thanks anyway for hinting me into the right direction.

@Apollo3zehn Apollo3zehn closed this Sep 8, 2022
@schotime
Copy link
Contributor Author

schotime commented Sep 8, 2022

Just had a look, and looks ok to me other than, ideally the IDisposable would be on the base class ModbusClient so that it doesn't have to be cast again to dispose.

Also you might have to have an exception thrown somewhere if you try and reuse it after calling dispose as you don't disconnect/close each time dispose is called.

@Apollo3zehn
Copy link
Owner

I thought about putting it into the base class but the base class itself does not need to be disposed so from an idealistic perspective it makes more sense to put it into the implementing classes. However maybe it is different from a practical point of view. I am not sure how a use case looks like where one works with the base class ModbusClient. Is it common to have a List<ModbusClient> where both, ModbusTcpClient and ModbusRtuClient are being part of at the same time? If that is a real use case, I agree that it would be more useful in the base class.

I am not sure I fully understand your second point. I know I should throw ObjectDisposedException when trying to reuse the instance after disposing but I do not really see the point doing so because when I dispose my instance, it is to be thrown away. I am hesitant because it clutters the code and the benefit is small I think.

@schotime
Copy link
Contributor Author

schotime commented Sep 9, 2022

  1. I use the library to provide a generic modbus interface where the user can choose whether they're using TCP or Serial, and so its used generically after they're instantiated, hence why I also raised the Close/Disconnect naming disparity (which could be on the base class also).

  2. I agree with that statement, but you might as well just call Close/Disconnect everytime then, rather than checking whether its disposed or not. All I was really thinking was either a) mark as disposed and throw if reused, or b) always call closed on dispose.

@Apollo3zehn
Copy link
Owner

Thanks for the explanations, I`ll come back to you next week.

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

Successfully merging this pull request may close these issues.

2 participants