Socket.io côté client sans serveur node.js

À utiliser socket.io sur le côté client, généralement, nous commençons une node.js serveur et comme ça:

<script src="/socket.io/socket.io.js"></script>

ou avec port spécifique:

<script src="http://localhost:3700/socket.io/socket.io.js"></script>

Question est la suivante:

est-il nécessaire d'utiliser node.js serveur de servir socket.io.js ?

...ou est-il possible d'

faire une copie locale de socket.io.js au lieu de passe au serveur à chaque fois que nous avons besoin de support.io?

comme, nous allons à l'affichage de la source et copie tout ce que nous avons obtenu à partir de la source de la balise script,

coller et enregistrer en tant que socket.io-local.js de sorte que la prochaine fois que nous utilisons:

<script src="socket.io-local.js"></script>

ça marche ?

Mises à jour

Merci pour tous les grands réponse,

Je vous pose cette question parce que, dans le cas qui m'occupe, je n'ai pas vraiment accès au serveur:

Je suis en train d'écrire le côté client pour se connecter à d'autres développeurs de Prise de Sever qui est écrit en Java.

Donc je vais devoir penser à une façon de contourner le fait que je n'ai pas de serveur, il existe pour moi.

de ce que j'ai pu en tester,
de cette façon semble fonctionner mais je ne sais vraiment pas ce qui se passe derrière la scène.

source d'informationauteur Lin Ti-Wen

  1. 24

    Manifestement, vous pouvez hôte la prise.io de la bibliothèque du client n'importe où et de le tirer dans une page. Toutefois, il sera presque certainement pas de travail avec votre serveur basé sur Java.

    De comprendre pourquoi, vous devez comprendre ce que socket.io est vraiment en train de faire en coulisses; la bibliothèque client est seulement une petite partie.

    Socket.io effectivement définit et met en œuvre de son propre protocole en temps réel de la communication entre un navigateur et un serveur. Il le fasse d'une manière qui prend en charge plusieurs transports: si—par exemple—un navigateur de l'utilisateur ou par procuration ne prend pas en charge Les WebSocketsil peut revenir à le temps d'interrogation.

    Ce que le socket.io client n'est:

    1. Fait une XHR GET demande de /socket.io/1. Le serveur répond avec un ID de session, configuré délais d'attente, et pris en charge les transports.
    2. Le client choisit le meilleur moyen de transport que le navigateur de l'utilisateur prend en charge. Dans les navigateurs modernes, il va utiliser les WebSockets.
    3. Si les WebSockets sont pris en charge, il crée un nouveau WebSocket pour initier une connexion WebSocket (HTTP GET avec Upgrade: websocket en-tête) pour une URL spéciale – /socket.io/1/websocket/<session id>.
    4. Si les WebSockets ne sont pas pris en charge par le navigateur ou ne parviennent pas à se connecter (il y a beaucoup d'intermédiaires dans la nature comme les procurations, les filtres, les dispositifs de sécurité des réseaux, et ainsi de suite ce qui ne supportent pas les WebSocket demandes), de la bibliothèque revient à XHR le long du scrutin, et fait une demande XHR pour /socket.io/1/xhr-polling/<sesion id>. Le serveur n'a pas répondu à la demande jusqu'à ce qu'un nouveau message est disponible ou un délai d'attente est atteint, à quel point le client répète la demande XHR.

    Socket.io composant serveur gère l'autre extrémité de ce désordre. Il s'occupe de toutes les Url sous /socket.io/la configuration des sessions, l'analyse de WebSocket mises à niveau, en fait de l'envoi de messages, et un tas d'autres livres.

    Sans tous les services fournis par le support.io serveur, le client de la bibliothèque est assez inutile. Elle va juste faire une demande XHR à une URL qui n'existe pas sur votre serveur.

    Ma conjecture est que votre serveur basé sur Java juste implémente les WebSockets protocole. Vous pouvez vous connecter directement à l'aide de le navigateur fournis par l'Api WebSocket.

    Il est possible que votre serveur ne mettre en œuvre la prise.io protocole – il y a un peu abandonné les projets Java, mais c'est peu probable. Parler avec le développeur de votre serveur pour savoir exactement comment il a mis en place un serveur socket."

  2. 4

    Autonome de construction de la socket.io-client est exposé automatiquement par le support.io server comme /socket.io/socket.io.js. Sinon, vous pouvez servir le fichier socket.io-client.js trouvé à la racine de ce référentiel.

    https://github.com/LearnBoost/socket.io-client

    J'ai un module appelé fusil de chasse-client qui en fait des roulés de socket.io. Je devais le faire un script client personnalisé ainsi que la prise de courant.io script client, mais je ne voulais pas que tous les utilisateurs de mon module pour inclure de multiples références de script sur leurs pages.

    J'ai trouvé que, lorsqu'il est installé, vous pouvez servir le client généré le script de support.io par de la lecture du fichier /node_modules/socket.io/node_modules/socket.io-client/dist/socket.io.js. Donc mon module ajoute un écouteur pour sa propre URL et quand elle sert mon script client personnalisé il sert également dans le socket.io script client. Alto! Une seule référence de script pour les utilisateurs de mon module 🙂

  3. 1

    Bien que cela soit techniquement possible, je ne vois pas pourquoi vous auriez besoin de le faire. Si vous êtes inquiet au sujet de la réduction des données qui transitent sur le fil, ce changement ne sera pas effectivement bien au-delà des quelques caractères enregistrés dans le plus court src tag. Il suffit de changer l'emplacement du fichier JS sur le serveur ne sera pas réellement d'améliorer les performances - le JS doit être envoyé.

    Bonne mise en cache (qui Socket.IO a) retournera une "304 not Modified" (et non ré-envoyer le fichier JS à chaque fois que vous chargez une page).