les inconvénients des websockets

Je voudrais savoir quel genre de limitations il y a à utiliser les websockets.

Websockets est tellement.. puissant. Je ne peux pas imaginer qu'il est sans les inconvénients.

Dire, quel est le nombre d'utilisateurs qui peuvent se connecter simultanément à un serveur (si je suis en train de créer un jeu et les utilisateurs se connectent au jeu à travers les WebSockets, ce qui va limiter le nombre d'utilisateurs en mesure de se connecter à tout moment?)

Aussi est-il vrai qu'à chaque connexion, la qualité des connexions (vitesse et des trucs comme ça) va diminuer?

  • le fil que vous avez lié est à propos de Gmail.. pas vraiment les websockets. J'ai édité ma question à se concentrer davantage sur la deuxième partie de la question dans l'affaire de toutes les confusions.
InformationsquelleAutor Pacerier | 2011-06-03
  1. 39

    Les avantages et les inconvénients de cours dépendent du cas d'utilisation spécifiques, mais je vais essayer de souligner certaines différences entre les WebSocket et HTTP.

    WebSocket est plus complexe que HTTP. Vous pouvez établir une connexion HTTP avec un client telnet, mais vous ne pourrez probablement pas faire la même chose avec WS. Même si vous avez ignoré la poignée de main (qui incluent l'utilisation de la fonction de hashage SHA1), vous serait alors pas en mesure de bien le masque et la trame de données à envoyer, et le serveur ferme la connexion.

    Comme Uwe dit, WebSocket connexions sont destinés à être plus persistants que les connexions HTTP. Si vous ne voulez recevoir une mise à jour toutes les 30 minutes, vous voulez aller avec HTTP. Si vous souhaitez recevoir des mises à jour à chaque seconde, un WebSocket pourrait être une meilleure option, car l'établissement d'une connexion HTTP et prend beaucoup de temps.

    D'établir une connexion HTTP, vous devez d'abord établir une connexion TCP (SYN, SYN/ACK, ACK), puis envoyer une requête GET avec un assez grand en-tête, puis enfin de recevoir la réponse du serveur (avec une autre grosse-tête).

    Avec un WebSocket il vous suffit de recevoir la réponse (pas de demande nécessaire), et il est livré avec une beaucoup plus petite en-tête: à partir de deux octets pour les petites images, jusqu'à 10 octets pour ridiculement grands cadres (dans la gamme gigabyte).

    Vous avez besoin de peser les deux coûts (en gardant une connexion ouverte vs d'établir une nouvelle connexion) pour décider entre les deux protocoles.

    Note: cette réponse est fondée sur le projet de protocole (draft-ietf-hybi-thewebsocketprotocol-09). WebSocket est en évolution rapide, de nombreuses implémentations sont toujours basés sur les anciennes versions, certains détails peuvent changer avant qu'il soit finalisé.

    • PS: pour un jeu en temps réel, vous voudrez probablement WS; quelque chose au tour par tour (comme aux échecs), HTTP interrogation pourrait être approprié.
    • heys thx pour l'aider. de quel délai pensez-vous est approprié pour les jeux d'échecs avec http interrogation?
    • Il peut dépendre de la façon dont rapide, le jeu est, peut-être aussi faible que 1 seconde pour le blitz, mais 5 ou même 10 secondes serait faisable en une plus lente du jeu. Le plus important est de donner à l'utilisateur une bonne expérience. Quelque chose que j'ai oublié de mentionner, c'est que vous avez besoin de savoir comment votre serveur gère les connexions (basé sur le thread ou des événements). Si elle crée un nouveau thread pour chaque connexion, vous serez à court de mémoire si le nombre d'utilisateurs connectés en même temps. Si il est basé sur l'événement, puis WS peut être très efficace.
    • j'aimerais comprendre le fil de la théorie, mais que voulez-vous dire par " event-driven mise en œuvre de WS?
    • Je veux dire en utilisant quelque chose comme l'appel système select() pour gérer plusieurs connexions dans un seul thread. Voir stackoverflow.com/questions/6206590/...
    InformationsquelleAutor suriv
  2. 1

    De ce que j'ai lu, cela semble être lié à HTTP Server Push j'ai lu qu'il est généralement recommandé de ne pas utiliser, car il crée un grand nombre de connexions sur le serveur.

    Si je dois choisir, je n'aurais probablement toujours développer un client mécanisme d'interrogation.

    • yep c'est définitivement un serveur push technolog. Cependant ne serait-il pas de soi pour le serveur ainsi, pour chaque client, de le frapper une fois toutes les 5 secondes.. (ou parfois même moins)
    • Si elle frappe toutes les 5 secondes, il n'a qu'à fournir une connexion au client toutes les 5 secondes et peut ensuite fermer/réutilisation de cette connexion. Quand on a une technologie push, ma compréhension est que les connexions toujours doit être présent.
    • Ok bon point. Cependant, au lieu de le faire toutes les 5 secondes, je le fais à chaque fois à son achèvement. En d'autres termes, se connecter.. fait, se connecter.. fait, se connecter.. fait, se connecter... Dans ce cas, quel serait votre avis (push ou pull?)
    • Je vais encore essayer de tirer en premier. Si vous n'êtes pas satisfait, alors essayez de les pousser.
    InformationsquelleAutor Uwe Keim