Quand une reconnexion du signalR se produit-elle?

J’ai commencé à travailler avec SignalR et j’essayais de déterminer quand une reconnexion de concentrateur se produit. Je n’ai trouvé aucune explication satisfaisante sur le web. Quelqu’un peut-il expliquer quand / pourquoi une reconnexion se produit?

Une reconnexion du concentrateur se produit lorsqu’un client se déconnecte puis récupère la connectivité peu après. Les valeurs de configuration de SignalR déterminent en grande partie les horodatages des exemples suivants, donc ne prenez pas les temps verbatim.

Voici plusieurs exemples et leurs résultats (format temporel m: ss) impliquant un comportement de reconnexion:

Lorsque je mentionne ce qui suit, je fais référence à la méthode du serveur côté serveur

  • OnConnected
  • OnDisconnected
  • OnReconnected

1)
0:00 – Le client se connecte au serveur, OnConnected est déclenché
0:10 – Le client perd la connexion en raison de problèmes de FAI (et réalise qu’il perd la connexion)
0:15 – Le client retrouve la connectivité
0:16 – L’événement OnReconnected est déclenché

2)
0:00 – Le client se connecte au serveur, OnConnected est déclenché
0:10 – Le client perd la connexion à cause du câble Ethernet (ne se rend pas compte qu’il est déconnecté)
0:15 – Le client retrouve la connectivité
Deux choses peuvent arriver ici
A: 0:16 – Rien ne se passe et le client continue sa connexion précédente
B: 0: ~ 45 – Le client réalise sa déconnexion *
B: 0:46 – Le client passe à l’état de reconnexion
B: 0:47 – Le client se reconnecte avec succès et l’événement OnReconnected est déclenché.

3)
0:00 – Le client se connecte au serveur, OnConnected est déclenché
0:10 – Le client perd la connexion à cause du câble Ethernet (ne se rend pas compte qu’il est déconnecté)
0: ~ 45 – Le client réalise sa déconnexion *
0:46 – Le client passe à l’état de reconnexion
1:15 – Le serveur détermine que le client est parti depuis trop longtemps, puis oublie de le faire, en mettant en queue une commande de “déconnexion” pour le client s’il se reconnecte légèrement plus tard. ***
1:15 – OnDisconnected est déclenché
1:16 – Le client retrouve la connectivité
1:17 – Le client effectue une reconnexion “douce” (ne déclenche pas OnReconnected)
1:18 – Le client récupère la commande “déconnexion”
1:19 – Le client appelle “stop” et effectue une déconnexion logicielle (ne déclenche pas OnDisconnected)

4)
0:00 – Le client se connecte au serveur, OnConnected est déclenché
0:10 – Le client perd la connexion à cause du câble Ethernet (ne se rend pas compte qu’il est déconnecté)
0: ~ 45 – Le client réalise sa déconnexion *
0:46 – Le client passe à l’état de reconnexion
1:15 – Le serveur détermine que le client est parti depuis trop longtemps, puis oublie de le faire, en mettant en queue une commande de “déconnexion” pour le client s’il se reconnecte légèrement plus tard. ***
1:15 – OnDisconnected est déclenché
1h30 – Le client cesse d’essayer de se reconnecter (il tente trop longtemps) **
1h30 – Le client passe à l’état déconnecté

* En raison du maintien du côté client, vérifiez: Utilisé pour déterminer si un client est hors ligne en raison d’un manque de survie. Non utilisé pour le transport de longue durée

** En raison du délai de déconnexion côté client: utilisé pour déterminer si un client se reconnecte depuis trop longtemps et il est probable que le serveur a oublié le client pendant le temps imparti.

*** En raison du délai de déconnexion du serveur: utilisé pour déterminer à quel moment un client doit être oublié. C’est une période qui commence à courir une fois qu’une connexion est étiquetée comme étant morte sur le serveur. En fin de compte, le serveur met en queue une commande de déconnexion pour le sujet du client qui indique au client (s’il se reconnecte) qu’il doit démarrer une nouvelle connexion. La commande disparaît du serveur lorsque le sujet est nettoyé.

J’espère que cela t’aides!