Websockets via Node.js/socket.io

Question

Hi,

I am trying to get a simple example for HTML5 websockets running on Azure. I am using node.js/express/socket.io and have created a worker role to run my application.

Running the application locally via node server.js or the Azure emulator yields the correct behaviour (using Chrome), in that I can see a WS handshake and the socket communication.

When deploying the same app to Azure it does not perform the WS handshake successfully and falls back to xhr-polling. 

It would be great if somebody could let me know if this is even supported on Azure at all. So far I have not been able to find a working Azure deployment which shows Websockets working (with node, not IIS8). If anybody could point me to a simple example configuration which gets me started that would be awesome!

-Alex

Answer 1

Hi,

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay.

Appreciate your patience.

 

Best Regards,

Ming Xu

---

Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 2

Yes it definitely does work in Worker Role. Try disabling xhr polling and forcing websockets using the following code:

  io.set('transports', [
    'websocket'
  ]);

---

This posting is provided "AS IS" with no warranties, and confers no rights

Answer 3

You can also try enabling RDP and remoting in to the box to see what is going on locally. Use the Enable-AzureRemoteDesktop powershell cmdlet following by Publish-AzureService to do that.

---

This posting is provided "AS IS" with no warranties, and confers no rights

Answer 4

Hi Glenn,

Thanks for your response.

Unfortunately forcing websockets alone does not appear to do the trick.

I have basically created another app by following this article: https://www.windowsazure.com/en-us/develop/nodejs/tutorials/app-using-socketio/ (I used a worker role for the node app).

By default socket.io transports default to websocket, htmlfile, xhr-polling, jsonp-polling according to https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO, so the websocket transport should be chosen by default (without even configuring it in the app). This is exactly what I did and when running in the local emulator it works just fine in Chrome (you can see it in Tools > Developer Tools > Network) but not when deploying to Azure.

Even configuring the transport explicitly does not do the trick (the app simply hangs given that no other fallbacks are allowed):

var io = sio.listen(app)  , nicknames = {};
io.set('transports', ['websocket']);
io.sockets.on('connection', function (socket) {...

I also enabled remote desktop for my worker role and see that my application files are located in f:\\approot. I am unclear where the logs go to, can you point me to the appropriate location/setup?

Finally, I would very much appreciate it if you can point me to a working deployment of the Node.js/socket.io example chat application where I can see it actually working.

By now I have spent a significant amount of time trying to get this trial application working. I consider this a task that should not take more than 10 minutes for evaluation purposes, especially given that it is almost trivial to setup on AWS. Searching the Web for related content appears also extremely sparse leaving me to think this is a feature that is supposed to work but nobody actually tried out by deploying the chat app and looking at the network transports.

If the node.js integration in Azure is currently not production ready I would appreciate knowing about this.

Thanks in advance for digging deeper here.

Regards,

-Alex

Answer 5

Thanks Alex

We're looking into this and will get back to you. I am seeing similar behavior when I deploy to Worker Role and am investigating. If there is an issue we will definitely fix it as supporting WebSockets is one of the key reasons we have Worker Role support....

---

This posting is provided "AS IS" with no warranties, and confers no rights

Answer 6

Alex

I've verified that WebSockets is working as I indicated in our private thread. I think it's possible you might have a networking / proxy issue that is preventing the upgrade. It is working for me both if I force transport to WebSocket or if I allow the default set of transports.

Thanks

Glenn

---

This posting is provided "AS IS" with no warranties, and confers no rights

Answer 7

After some digging, many Azure deployments and generally a lot of time spent it turns out that the internet provider blocked websocket connections on port 80 and 8080 (secured websockets worked though). I have just tested my app through my own network setup and provider and it appears to work fine from there. For me the takeout is that a solution like socket.io that can fallback to more conventional HTTP based connections is very valuable in that it helps to circumvent these sorts of issues.

Thanks to Glenn who helped me along the way by suggesting solutions, testing and eliminating other possible issues!