I've deployed my nodeJS server in windows azure.
My client fails while connecting to server and handle the following error :
WebSocket connection to 'wss://ooplrfrfranode.azurewebsites.net/socket.io/1/websocket/lHrd-DOydinODjbS7-tc' failed: Error during WebSocket handshake: Unexpected response code: 503.
Any Help please.
Thanks.
Windows Azure Web Sites has recently added support for the WebSocket protocol. Both .NET developers and node.js developers can now enable and use WebSockets in their applications.
There is a new option on a web site’s Configuration tab to enable WebSockets support for an application.
Source: http://azure.microsoft.com/blog/2013/11/14/introduction-to-websockets-on-windows-azure-web-sites/
For students struggling with socket.io on Azure
I've struggled for 2 days with this. I was using a student free tier for the service app and apparently that was part of the problem.
I made a B1 plan app service with my student credits. After uploading my node.js app it worked out of the box.
After that, I downscaled it to a free tier and it still works now(fingers crossed). This might help for students struggling with socket io on azure.
Related
I'm working on an asp.net core 2.2 MVC web application. We are using signal r core version 1.1.0 (added via the nuget package Microsoft.AspNetCore.SignalR). The client side application is an angularjs application referencing version 1.1.4 of the aspnet-signalr javascript library.
Our application is deployed on Azure and the hosting app service is scaled horizontally : there currently two instances of our web application up and running. I'm testing the behavior of my application by using Google chrome version 75.0.3770.100 on a windows 10 machine.
The app service is configured so that the web sockets are enabled and the ARR affinity is disabled. I'm experiencing a strange behavior, basically if I test my application and I perform several browser hard refresh (ctrl + F5) it happens randomly that the client side application is unable to connect to the notification hub. The following errors are reported in the google chrome console:
WebSocket connection to 'wss://myapp.azurewebsites.net/notificationsHub?id=3Fmlw2yC5qm3vi0qny50Qg' failed: Error during WebSocket handshake: Unexpected response code: 404
Error: Failed to start the transport 'WebSockets': null
GET https://myapp.azurewebsites.net/notificationsHub?id=nEYPEDw5f0AkLz5otCAOyA 404
Error: Failed to start the transport 'ServerSentEvents': Error: Error occurred
GET https://myapp.azurewebsites.net/notificationsHub?id=2G9VVr5mcx7QT2wbSfwDLA&_=1561652513485 404
Error: Failed to start the transport 'LongPolling': Error
Error: Failed to start the connection: Error: Unable to initialize any of the available transports.
If I change the app service configuration so that both the web sockets and the ARR affinity are enabled everything works like a charm. My suspicious is that when the app service is horizontally scaled then the ARR affinity is required regardless of the transport protocol (in my case, both the server side application and the client browser are able to support the web socket protocol).
Based on my understanding, the official microsoft documentation states that when using web sockets as a communication protocol the client ARR affinity is not required, even if the hosting app service is horizontally scaled to multiple instances. At this point I'm not sure about my understanding of the signalr core documentation.
Am i missing something ? Did I misunderstood the official documentation ?
EDIT 3 JULY 2019
For the ones interested to this subject (scaling out a web application using signal-r core), you can refer to this github issue for all the details.
The short answer is that the new signal-r core is actually stateful and requires sticky sessions when the application is scaled out to multiple servers.
If you are on Azure only, you can avoid the usage of sticky sessions and have several other benefits by using the Azure signalr service.
If you don't want to use this azure service the only option to avoid sticky sessions is configuring signal r core so that the client-server protocol negotiation is avoided and the communication is done by using web sockets only (refer to the linked github issue for all the details). Notice that doing so you will lose the ability of downgrading to other protocols when web sockets aren't supported, which is one of the core features of signal-r core.
If you want to affinity disable, then I think the component you're missing is the hosted SignalR service. It's the proxy service that will maintain session info for you as your app service scales out. Follow these steps to add SignalR service as a service dependency to your project.
We are trying to host the BOT on the Enterprise server IIS server which is an internet server visible to Microsoft and other outside public domains.
So, after hosting the BOT on the enterprise cloud server we would get an endpoint ex: https://myenterpriseserver.com/api/messages.
Can I use the above endpoint to register the bot in the microsoft's dev.botframework.com?
Please help, as we are planning for a large scale implementation of the BOT.
Thanks,
Mahesh
As long as the server has a SSL Certificate it should work assuming you deploy the bot correctly. Test it out first by using the Bot Emulator to see if you can send a receive messages from a computer in your system's network. Next try registering the bot on Microsoft's Bot Framework and seeing whether Microsoft's Bot Connector service can connect to the bot successfully.
Your system/intranet may block outside messages from Microsoft in which case you will have to change some settings, etc. with your firewall. This GitHub Issue follows an issue with white-listing Microsoft's Bot Connector service.
I am hosting a WebSockets (SignalR) application on a Azure VM and I am experiencing the following 400 (Bad Request) error when connecting remotely.
WebSocket connection to 'ws://xxx.cloudapp.net/signalr/connect?transport=webSockets&
clientProtocol=1.5&connectionToken=JMLk3b...&connectionData=%5B%7B%22name%22%3A%22
dashboard%22%7D%5D&tid=10' failed: Error during WebSocket handshake:
Unexpected response code: 400
This does not happen when accessing the app locally within the VM.
My suspicion is that this is a proxy problem as highlighted in these various articles.
However, I can't seem to find any articles indicating whether one can actually host WebSockets apps on Azure VMs (I know they recently enabled WS on Azure Websites, but it seems as if the VMs don't have this feature yet).
Any help would be appreciated. Thanks!
The problem ended up being proxy servers (such as Squid) used client side at various ISPs and not proxy servers on the Azure side.
I am attempting to connect to a Socket.IO server hosted in the extension folder of my Azure Mobile service using the startup script, although I am unable to do so, and receive the error:
"WebSocket connection to 'ws://mymobileservice.azure-mobile.net/extensions/socket.io/?EIO=2&transport=websocket' failed: Error during WebSocket handshake: Unexpected response code: 503"
I am using port 80 with a path of 'extensions/socket.io'
I've also used port 443 with a secure connection, and that has yielded the same error.
Am I on the right track?
Any help is greatly appreciated.
You figured this out, but here's a definitive answer.
The best way to host a socket.io server is to host it on Azure Websites directly (Azure > New > Website) instead of Azure Mobile Services. Once you publish your socket IO server to the website, don't forget to go to the "Configure" tab and enable "Websockets" for the server.
There is an amazing tutorial on deploying the socket.io chat app to azure websites here:
https://azure.microsoft.com/en-us/documentation/articles/web-sites-nodejs-chat-app-socketio/
I am using Node.js + Socket.io in my application.
Say, my chat application (php) is hosted on server A and node.js is hosted on AWS.
Each client accesses chat application and in the background it registers the client with the node.js application hosted on AWS.
The problem is when I use a proxy server from hidemyass.com and configure my firefox to access the application.
The application is loading but it unable to connect to node server hosted on AWS and I get a 403 Forbidden error.
Is this a problem with AWS security configuration or a node.js settings ? I am unable to figure this at all.
I have tried my best to search for reasons why this would happen, but didn't get any clue. Can it be an AWS configuration issues or Is it to do with Nodejs server settings. Any guess or help is highly appreciated.
Thanks you very much.