2010-11-03 14 views
2

j'ai observé le comportement suivant dans Firefox 4 et Chrome 7:Websocket onclose/onerror événements ne se déclenche pas si le serveur tombe en panne

Si le serveur exécutant le plantage du démon WebSocket, redémarrages, perd la connectivité réseau, etc alors le ' Les événements onclose 'ou' onerror 'ne sont pas déclenchés côté client. Je m'attendrais à ce que l'un de ces événements soit déclenché lorsque la connexion est rompue pour une raison quelconque.

Si toutefois le démon est d'abord fermé correctement, l'événement 'onclose' est déclenché (comme prévu).

Pourquoi les clients perçoivent-ils la connexion websocket comme ouverte lorsque le démon n'est pas correctement arrêté?

Je veux compter sur le comportement attendu pour informer l'utilisateur que le serveur est devenu indisponible ou que la connexion Internet du client a subi une interruption.

Répondre

5

TCP is like that. Le brouillon standard WebSockets le plus récent (v76) possède un mécanisme clean shutdown message. Mais sans cela (ou s'il n'a pas de chance d'être envoyé) vous comptez sur un nettoyage de socket TCP normal qui prend plusieurs minutes (ou heures).

Je suggère d'ajouter une sorte de gestionnaire de signal/piège de sortie au serveur de sorte que lorsque le serveur est tué/arrêt, un message d'arrêt propre est envoyé à tous les clients connectés.

Vous pouvez également ajouter un mécanisme de pulsation (ala TCP keep alive) à votre application pour détecter si l'autre côté s'en va.

+0

Merci. Ajouter une pulsation à mon application est probablement la solution la plus simple. –