Closed k5123 closed 6 years ago
Thanks, will definitely take a look at this, planning to do an overhaul at some point anyway, being my first ever made library / "more serious" c# library. Its definitely not what it should be.
So, it should not have the race conditions it had before, but currently probably not the ultimate correct way to do it, but it now just waits for responses from the server, and as long these responses do not contain error messages, it continues on with the next command, also waits before a successful connection is made with the TCP server before continuing, including a timeout in case it somehow can't connect. + Some more changes, which you can read on the release page ^^.
Connect procedure assumes a fixed timing (Thread.Sleep(500)?!) for connection to a server and does not check whether sending the next command is actually sensible or not. This ignores (for example) the variable time it'll take a server to do reverse IP lookups etc, throwing the entire rest of the connection sequence off balance.
Effect: Usually the expected join of a channel at the end of the sequence isn't even happening, because the server wouldn't yet accept that command. Fix: Use state machine to observe actual connection status before continuing with next command.