Is it possible that repeated OnConnected will call before previous OnDisconnected?

Question

Imagine some spherical horse in a vacuum: I lost control of my client application, maybe some error has happened. And I tried to re-enter to the hub immediately. Is it possible, that OnConnected starts faster then OnDisconnected and I turn up twice on the server?

Edited:

Sorry, I didn't say than I meant SignalR library. I think if my application won't call stop() the server will wait about 30 seconds by default. And I can connect to the server again before OnDisconnected is called. Isn't it?

Answer 1

A client can connect a second time while the first connection is open (it will have a separate connection id though).

If the client doesn't manage to notify the server that it's closing the connection, the server will wait for a certain amount of time before removing the connection (DisconnectTimeout). So in that case, if you restart the connection immediately, it will be a new logical connection to the server with a new connection id.

SignalR will also try to reconnect to the existing connection when it is lost, in which case it would retain its connection id once reconnected. I would recommend reading the entire article about SignalR connection lifetime events.

Answer 2

You'll have to take it from the client's side, also note that if you're using TCP the following would take place:

TCP ensures that your packets will arrive in the order they were sent. And so let's imagine that at the same moment the "horse" hit the space and the connection broke, your server is sending the next packet that would check the connection (if you implemented your server good enough that is).

Here, there's two things that may happen:

1. The client has already recovered and can respond in time. Meaning the interval in time when the connection had problems was small enough that the next packet from the server hasn't arrived yet. And so responding to your question, there's no disconnection in the first place.
2. The next packet from the server arrived but the client is not responding (the connection is severed). The server would instantly take note of this, raising the OnDisconnected event. If the client recovers virtually at the same time the server takes note, then it would initiate another connection (OnConnected).

So there's no chance that the client would turn twice. If any, the disconnection interval will be small enough for the server not to notice the problem in the first place.

Again, another protocol may behave differently. But TCP is will designed to guarantee a well established connection and communication between a server and clients.

It's worth mentioning that many of the communication frameworks (if not all) use TCP implicitly by default.