Client-side socket.io without a node.js server

Question

To use socket.io on the client side, usually we start a node.js server and go like this:

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

or with specific port:

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

Question is:

is it necessary to use node.js server to serve socket.io.js ?

...or is it possible to

make a local copy of socket.io.js instead of goes to server every single time we need socket.io?

---

like, we go to view source and copy everything we got from the source of script tag,

paste and save it as socket.io-local.js so that next time we use:

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

will that work ?

---

Updates

Thanks for everyone's great response,

I'm asking this because in the case I'm involved, I don't actually have access to the server:

I am writing the client-side to connect to other developer's Socket Sever which is written in Java.

Therefore I'll have to think a way to work around the fact that I don't have a server there for me.

from what I've been testing, this way seems to work but I really don't know what's happening behind the scene.

Answer 1

You obviously can host the socket.io client library anywhere and pull it in to a page. However, it will almost certainly not work with your Java-based server.

To understand why, you need to understand what socket.io is really doing behind the scenes; the client library is only a small part of it.

Socket.io actually defines and implements its own protocol for realtime communication between a browser and a server. It does so in a way that supports multiple transports: if—for example—a user's browser or proxy doesn't support WebSockets, it can fall back to long polling.

What the socket.io client actually does is:

1. Makes a XHR GET request for /socket.io/1. The server responds with a session ID, configured timeouts, and supported transports.
2. The client chooses the best transport that the user browser supports. In modern browsers, it will use WebSockets.
3. If WebSockets are supported, it creates a new WebSocket to initiate a WebSocket connection (HTTP GET with Upgrade: websocket header) to a special URL – /socket.io/1/websocket/<session id>.
4. If WebSockets aren't supported by the browser or fail to connect (there are lots of intermediaries in the wild like proxies, filters, network security devices, and so forth that don't support WebSocket requests), the library falls back to XHR long polling, and makes a XHR request to /socket.io/1/xhr-polling/<sesion id>. The server does not respond to the request until a new message is available or a timeout is reached, at which point the client repeats the XHR request.

Socket.io's server component handles the other end of that mess. It handles all the URLs under /socket.io/, setting up sessions, parsing WebSocket upgrades, actually sending messages, and a bunch of other bookkeeping.

Without all of the services provided by the socket.io server, the client library is pretty useless. It will just make a XHR request to a URL that doesn't exist on your server.

My guess is that your Java-based server just implements the WebSockets protocol. You can connect directly to it using the browser-provided WebSocket APIs.

It is possible that your server does implement the socket.io protocol – there are a few abandoned Java projects to do that – but that's unlikely. Talk with the developer of your server to find out exactly how he's implemented a "socket server."