ClientManager or Transports should have feedback for initial connection failures #684
TactiFail
started this conversation in
Feature Request
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Problem
Currently, calling something like this to connect to a server:
provides no built-in way of determining if the connection failed.
The
OnClientConnectionState
event'sClientConnectionStateArgs
struct does not distinguish between a genuine disconnect from the server (you disconnected manually, or were kicked), and an initial connection failure (e.g. due to the server being down). If you try to connect to a server which is not running (or you put in the wrong IP or port or something), and you log each of theOnClientConnectionState
calls, you will get something like:versus a successful connection and later disconnection:
So you would need to track the state changes and make a determination of whether the
Stopping
state is legitimate or the result of a failed initial connection. Essentially, a latch needs to be introduced to check whether a givenStopping
state followed aConnected
state (legitimate disconnect) or aConnecting
state (failed initial connection).Example:
While my above solution works, it requires at minimum some modifications (albeit trivial) to a managing class by adding and tracking the
_lastConnectionState
field.Barring that, you would need to poll the connection and see if it is successful before continuing. I haven't tried this yet but it seems inefficient.
Proposal
As discussed in #357 (comment), the
Transport.StartConnection()
can't reallyreturn
a boolean of any real use since each connection will have a necessary time delay before that feedback can be given.For that reason, I am proposing an additional event such as
ClientManager.OnClientConnectionFailed
or similar which can be raised when the initial connection fails. If possible, it should have failure information such as whether the remote IP address was reachable, whether the port was open or closed, etc. Any failures beyond this initial connection check would best be handled in the variousAuthenticator
classes or elsewhere.As an alternative, the
Transport.StartConnection()
call could be made async, but that would be a potentially breaking change for little to no discernible benefit since people would then need to await the call for it to be of any use.As another alternative, it could throw a new Exception, maybe a
ClientConnectionFailedException
or something. Probably less "breaking" than async but still something that would require people to wrap it in a try/catch. And having something throw an exception a few seconds after it is called feels weird.Beta Was this translation helpful? Give feedback.
All reactions