I am currently using signalR on Azure Websites with a single instance to push data to clients. No problems.
We're splitting our project into separate web/worker and wcf roles so we can scale them independently.
The site will work like this.
Scenario A
User submits some data to web role and it gets put in a service bus queue ready for worker A, sends a message to worker A that a new item has been added in case it's idle (to save polling). When worker A has processed it, sends a message back to web roles which pushes out to particular clients.
scenario B
receive data in wcf role and it gets put in a different service bus queue ready for worker B, wcf role sends message to worker B that a new item has been added in case it's idle. When worker B has processed it, sends a message to web roles and pushes it out to particular clients.
illustrated badly below:
I am going to enable signalR service bus backplane for the web roles to users. What i'm not sure about is how to get my roles communicating between each other.
I'll need:
web role => worker A
worker A => web role
wcf role => worker B
worker B => web role
Am I creating hubs on web, worker A and worker B all with service bus topics? And then connecting somehow with the signalr .net clients? How do I make sure it goes to all instances of the web role without exposing it publicly?
For some reason it seems simple for hundreds of clients to connect via JavaScript to my web role hub but try and connect some internal ones and I can't quite figure it out.
If anyones interested... What I ended up doing is this:
I created hubs on both the Web and Wcf role. The web role has a connection that allows javascript proxies at /signalr and the web and wcf role had one that didn't at /signalr-internal.
I used the Azure Service Bus as a backplane and let it handle both the web and wcf hubs automatically with no extra tinkering.
In the signalR authentication I probed to see where the connection was coming from (i.e an internal endpoint or the external ssl endpoing and denied / allowed access to particular hubs based on this. This allowed me to use the .net signalr clients on my workers that automatically connect / reconnect etc.
This ended up working nicely with no issues as of yet and it was simple to implement. I'll update if I run into any problems.
EDIT #1:
DO NOT USE THIS METHOD! Everything works splendidly until you actually deploy it into a live environment and then you get a host of issues that made me want to tear my hair out.
What I actually ended up doing (which work perfectly in live) was to use service bus Topics and create subscriptions to them for the listeners. This creates TCP connections and allows your communication to stay 100% internally without any crazy transport or boundary problems.
EDIT #2:
Since this post, Event Hubs were release and we switched over and never looked back. see last comment
Peter, realistically to get this approach to work you would need to switch to Web Roles or IIS hosted on an IaaS VM.
Currently Websites don't support Azure Virtual Networks which is the only way to enable private network inter-connectivity between instances on Azure.
You can add VMs, Web and Worker Roles to a Virual Network which should provide you with the access you're looking for without needing to expose everything via public endpoints.
Related
There is very limited information on azure signalR service. I need to clarify a question so any help would be highly appreciated.
how azure signalR service actually scale out ? I mean, as far I have worked on it. it seems that you have to include a primary key of azure signalR service to your hub. you can host you hub anywhere. So how hub scales out.?
SignalR Service manages all the client connections, as well as certain state information such as group membership. Your ASP.NET Core application establishes a connection to the SignalR Service instance.
When the application wants to send a message to connected clients, it uses this connection to instruct the service to do so. The service can also invoke hub methods via this connection.
You can read more about the service protocol.
When a client initiates a connection, it calls a negotiate endpoint on your ASP.NET Core application, which redirects the client to connect to the SignalR Service instance instead.
Because the ASP.NET Core application only needs to execute hub logic and most of the heavy lifting is done by SignalR Service, your application does not typically have to scale out to handle more SignalR connections. You can scale it based on the needs of the web traffic (serving web API and MVC requests, for example), and you can scale the service based on the needs of your SignalR traffic.
This is the documentation that I found and followed to have a signalr hub that worked across multiple App Service instances but behaving as a single hub.
You need to create a "backplane" in Azure using Storage queues and topics.
Details here: https://learn.microsoft.com/en-us/aspnet/signalr/overview/performance/scaleout-with-windows-azure-service-bus
#anthonychu is this still needed / applicable??
I'm looking into migrating an application to Service Fabric running on Azure. It's a realtime chat-style application using SignalR. I'd like to have an instance of a service running, self-hosting a SignalR hub (via OWIN) for each "affinity group" in which users are communicating. This is so I can avoid having to scale out SignalR with a backplane. I'd like to be able to spin these services up and down as groups of users enter and leave my application. I would expect I could host tens of these services per VM with a typical load of hundreds of users per group.
My idea is that I'd have a service locator that clients connect to initially to discover which service (port) is hosting their group. I would also have a service that spun up an instance of the chat service when the first request for that group came in.
How would I architect this in Service Fabric on Azure so that a) each of the services/actors is accessible with a SignalR client from the internet? and b) I'm only running as many services as necessary to serve m active groups out of n total groups? The demand for this app is very transient and spiky, so I'm hoping to take advantage of the fact that services are simply processes and can be provisioned in a matter of seconds vs. my current scenario where I have to spin up entire cloud services and wait tens of minutes to handle spikes (at which point it's too late)
You would do a few things:
Have a "service manager service" that intercepted initial join requests and created new Service Fabric services on the fly if they didn't already exist OR if they did already exist resolve the service's current location and then return that address to the client
Alternatively they could just pass back the internal service name (if you're ok exposing that information) and the client could do the resolution and then connection. To some degree this will depend on how much info you want to expose to the client, whether you can or want to modify it to "know about" Service Fabric, etc.
The client would then connect to the actual backing service directly
You would have to come up with some sort of mechanism for the actual chat services to know that there is nobody left and to either delete themselves or to go back through the manager.
You probably would be best off modeling the chat service as a Reliable Service rather than an actor as the Reliable Services stack allows more flexibility around communication protocols/stacks.
We are designing a system that is web based but also uses NServiceBus and Azure Service Bus to communicate. We have an on premiss server running IIS for the application and also several cloud services running web roles for communicating with external parties (those parties call on a RESTful interface in the cloud and the message is put on the bus or vice versa).
Both the cloud solutions and the on premiss server need to subscribe and publish messages. The publishing does not seem an issue but what happens to those subscriptions if IIS shuts down the processes, do they get woken again when a message arrives or is the service bus really pull based subscription so requiring an active listener.
I have seen questions on here about hosting publishers but nothing about the safety of subscribers.
Extra Info:
Quite by chance we noticed that sometimes in our development environment the applications would need to be started a couple of times before the messages would start arriving. However it occurred to me that if there were actually messages already in the queue when the application started then they would be processed and otherwise not. So the restart just means that it sees older messages and processes them then once running it gets on just fine. However another colleague noted that nsb related startup log files were only being generated after he visited the website hosted in the same web application for the first time. I have just had a similar problem, messages were in the queue but the breakpoint on the handler was not being hit. When I hit a webapi method on the same iis application instance suddenly messages were being processed. So my conclusion from this is that no, it is not safe to host a subscriber under iis or in this case even a web role.
I am answering my own question based on my experience rather than any deep knowledge of NServiceBus or Azure Service Bus.
It seems that it is not safe to rely on the service bus listener to be active under IIS or a web role. Both can shut down the process and, as the bus listener relies on polling the service rather than messages being pushed to the listener from the service, so no further messages will be received until the process starts again.
The good news is that the process will be restarted when the associated web site or web service is hit. so if you absolutely know that you will receive more traffic on the site than on the bus then you might take the risk that the bus listener will remain active. However for our project we are in the process of splitting the listener into a separate windows service.
Hi I am implementing a TCPIP listener in Azure WorkerRole. The WorkerRole listens for incoming TCP data and stores it in Azure Table Storage.
Everything is working fine when i do this in Run() of WorkerRole.
But when implement the same thing in a Run() of WebRole, i get a message "WebIIS has exited" and debug mode exits in dev environment.
Why is this?
Can some one explain where the WebRole difers from WorkerRole? Can we implement a TCPIP listener which continuously listens in a WebRole?
Thanks
Anil
Just think that WebRole works like a Web Application. by receiving a request then it returns a reponse while Worker Role works like a Windows Service. Although both can hand TPC messages they difers in the way they hand it. Web Role only will be available while process the request. Worker Role will be available constantly. If you want a Web Role to be continuosly listening a TCP channel the most probably is that Worker Role will fit your requierements better.
Regards,
My answer on a similar question: https://stackoverflow.com/a/2610895/94559
In short, web roles are for IIS, and worker roles are for everything else. In this case, I think you want a worker role.
What is an Azure Cloud Service Role?
In Azure, a Cloud Service Role is a collection of managed, load-balanced, Platform-as-a-Service virtual machines that work together to perform common tasks. Cloud Service Roles are managed by Azure fabric controller and provide the ultimate combination of scalability, control, and customization
What is a Web Role?
Web Role is a Cloud Service role in Azure that is configured and customized to run web applications developed on programming languages / technologies that are supported by Internet Information Services (IIS), such as ASP.NET, PHP, Windows Communication Foundation and Fast CGI.
What is a Worker Role?
Worker Role is any role in Azure that runs applications and services level tasks, which generally do not require IIS. In Worker Roles, IIS is not installed by default. They are mainly used to perform supporting background processes along with Web Roles and do tasks such as automatically compressing uploaded images, run scripts when something changes in database, get new messages from queue and process and more.
I’m designing a backend that allows users to establish a TCP socket with it and send/receive stuff along this socket (using a pseudo-protocol I’ve made up) in real-time.
It has to be scalable – i.e. architected on a cloud host. Currently I’m evaluating Windows Azure.
To achieve scalability the application will run on several Web Role Instances. Meaning the users’ TCP sockets will be split across several instances (via a load balancer).
This backend is an event-driven application – when a user sends something to it the message should be passed on to all other connected users.
This means there must be a reliable way to send messages from one Web Role Instance to all other Web Role Instances. As far as I understand, this is what inter-role communication refers to.
Using Service Bus, is it possible for all Web Role Instances to subscribe to a Topic and publish messages to it? Thus implementing the event-driven requirements of my distributed application?
(If not then I’ve misunderstood what this article is about: http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/)
I wanted to find this out before delving too deep into learning C#, .NET and Windows Azure development.
Thank you for your help.
Yes, using the service bus, all the web roles could send messages to a single topic and each role could have unique individual subscriptions to that topic, such that they all receive the messages sent.
Clemens Vaster has implemented an extension to SignalR using the service bus. It is possible that SignalR + the Service Bus may meet the needs of your project, including the TCP socket implementation.
http://vasters.com/clemensv/2012/02/13/SignalR+Powered+By+Service+Bus.aspx