Resuming from Sleep and other connection fixes

[gbakeman]

Socket

• Simplified ConnectionStatus boolean property while maintaining null check
• Simplified NUT and Net version properties
• Removed redundant Socket object in favor of TcpClient for underlying socket management
• Removed unused SocketDisconnected event
• Simplify Connection logic to only do the basic work of establishing streams for reading and writing
• Gather version information immediately after successful connection, and within error tolerant try-catch blocks so as to bypass non-critical errors
• Login subroutine refers to instance fields instead of parameters (login info should never change during lifetime of the instance)
• Corrected LOGIN command syntax
• Disconnect subroutine is more likely to dispose of all related objects when called
• Support NUT network version 1.3

UPS Device

• Small tweaks to properties
• Removed ReConnected event - was duplicating calls with the Connected event
• Polling interval is now read and set correctly. No longer writable after instantiation.
• Wrap Login method for socket

WinNUT

• Remove unused UpdateMethod property and field
• Add support for Suspend system power mode change to try to prepare WinNUT for suspension (isn't always called before system suspends.)
• Reinforced Resume system power mode change to cleanup WinNUT's state if it was left connected while suspending previously
• WinNUT initiates the call to Login to the UPS now (support for accessing UPS without a login as intended by NUT)

Related

• 145

• 162

[kirsch33]

i am happy to see this PR--i previously have been using a fork of this repo I made for myself which the only change being the MaxRetry variable within UPS_Device.vb vastly increased. that is what has resolved the connection issues for me.

related to https://github.com/nutdotnet/WinNUT-Client/issues/65, i believe it makes sense for this PR to also address a configurable option for the MaxRetry interval.

considering this software is otherwise perfect for me besides the connection issue, it would be greatly appreciated and thank you for all your work on this!

[gbakeman]

Hi @kirsch33, thanks for your interest and sorry you had to fork just for that small change! 😄 To be honest, I wasn't planning on tackling #65 here since I'm helping another user who's experiencing a multitude of issues at the moment. Generally though, I think I'm leaning more towards indefinite/persistent connections instead of a set amount before giving up - let me know in #65 if you think it should be different.

[kirsch33]

@gbakeman that sounds good to me! and its no issue. this app is perfect otherwise, or else I wouldnt have went thru all that trouble lol so kudos to you and the other maintainers.