5

Part of this problem might be that there's too much discussion on the client side for me to see wood for the trees.

Anyway, here's what I want to do. I need a platform independent server-side implementation of WebSockets. I'd like it to run in NodeJS.

Now, 99% of what I've found on this topic talks about socket.io. But so far as I can tell, that is not WebSockets, it's a special "extra" protocol in its own right. I need something that works "by the (not-yet) standard". There's a good reason for that, and it's non-negotiable, trust me on that.

So, I tried WebSocket, but that requires (or appears to require both python and, worse, Visual Studio) to run on Windows. I need something that is platform independent and doesn't need special things like this.

I also tried node-websocket-server, but I can't get that to work at all. The example on the main page fails for me. It seems to accept a connection, but the client doesn't see it, neither side gets to send anything, and the client immediately sees the connection as closed. Indeed, all I ever get is a "connection" callback, and then it seems to die. Running in debug mode didn't tell me anything useful, except for some internal error about some object or other not having a flush() method. I half-suspect this is a defunct project?

So, I'm out of ideas. Is it possible to persuade socket.io to work purely by the (non)spec for WebSockets? Is there a way to get node-websocket-server to behave that I've failed to find. Is there a way round the Visual Studio dependency in websocket, or is there some other NodeJS based tool that meets all my requirements?

Oh, one other thing, I'd like the tool to coexist peacefully with "connect" as I'm using that for my regular document serving.

halfer
  • 19,824
  • 17
  • 99
  • 186
Toby Eggitt
  • 1,806
  • 19
  • 24

2 Answers2

5

I had the exact same problem that you're facing at the moment when I tried to use Socket.IO on a different platform without a direct port of the client (and without the motivation to port it myself).

I ended up moving my code to use ws which is a standards based websocket implementation for node without the added sugar from socket.io.

It works extremely well in my case over several different platforms but you would need to rework most of the connection/reconnection code etc.

Website : link

GitHub : link

NPM : npm install ws

cillierscharl
  • 7,043
  • 3
  • 29
  • 47
1

Socket.io uses WS under the covers so you may hit the same installation issue on Windows. You may find that it complains that you need to install Visual Studio 2010 for the ws component to work.

However, you can configure the version of Visual Studio used by node-gyp that runs the C++ compiler via an environment variable.

Examples:

  • set GYP_MSVS_VERSION=2012 for Visual Studio 2012
  • set GYP_MSVS_VERSION=2013e (the 'e' stands for 'express edition')

For the full list see - https://github.com/joyent/node/blob/v0.10.29/tools/gyp/pylib/gyp/MSVSVersion.py#L209-294

This is a painful for Windows users of NodeJS as it assumes you have a copy of Visual Studio installed which many non-dev end users will never have. So I'm lobbying Joyent to the encourage them to include web sockets as part of CORE node and also to ship a GNU gcc compiler as part of NodeJS install so we can permanently fix this problem and not have to force Windows node users to tweak their environment or download anything else.

Feel free to add your vote at:

NOTE: The Joyent team have indicated that socket.io will fall back to using a slower implementation when compiling ws fails. In other words your code will still run - just not as fast. This is not clear for end users performing an install of any app that depends on socket.io or ws as it display red error text during the install process leading users to assume that the install failed, when in fact it will work albeit slowly.

Tony O'Hagan
  • 21,638
  • 3
  • 67
  • 78