I have a 3-tier application:
1. web servers: publicly available, serves web pages and hosts logic
2. app servers: accessible only from web servers, running long running processes processes
3. database servers: accessible only from web and app servers
I would like to use signalR to update users about progress of long-running processes. These processes are kicked off by users through web servers ( user->web server-> app server). However, since the processes will be running on app serves, these app servers need to send update back to the browsers.
How should this be implemented so that SignalR can be used to push updates from app servers to browers, where browsers do not communicate directly to app servers?
Related
I am in a stage of using SignalR in my project and i don't understand when to use Self hosted option and when we should not use. As a example if I am willing to host my web application in server farm,
There will be separate hosting servers
Separate SignalR hubs in each IIS server
If we want to broadcast message into each client, how this is working in SignalR
The idea with SignalR running in multiple instances is that clients connected on instance A cannot get messages from clients connected to instance B.
(SignalR scaleout documentation)
However, when you scale out, clients can get routed to different
servers. A client that is connected to one server will not receive
messages sent from another server.
The solution to this is using a backplane - everytime a server recieves a message, it forwards it to all other servers. You can do this using Azure Service Bus, Redis or SQL.
The way I see, you use the self host option when you either don't want the full IIS running (because you have some lightweight operations that don't require all IIS heaviness) or you don't want a web server at all (for example you want to add real-time functionality to an already existing let's say forms application, or in any other process).
Be sure to read the documentation for self-hosting SignalR and decide whether you actually need to self host SignalR.
If you are developing a web application under IIS, I don't see any reason why you would want to self-host SignalR.
Hope this helps. Best of luck!
My team is in the middle of deciding the architecture of our backend system:
Webserver A is an ASP.NET MVC application with ASP.NET Web API component, hosted in Azure Website.
Windows Service B is a self-hosted OWIN server that will periodically push notifications to clients who subscribes to the notification, hosted in Azure VM.
Windows Service C is a client that subscribes to notification from B, hosted in Azure VM.
Since we are more-or-less entrenched in .NET stack, we implemented B as SignalR server with C being the SignalR client. This part seems to work well.
Now comes a point where we also want A to subscribe to B, but I realize that it means an ASP.NET Web Server is going to act as SignalR CLIENT, instead of the typical scenario where it acts as SignalR server.
I presume we can initialize the SignalR connection in Global.asax and make the process ever-running to avoid AppDomain recycle. However, I feel a bit iffy when a Web Server is made to do something other than serving web requests. This solution also make the web server not stateless since it needs to maintain the web socket connection alive.
Is there something fundamentally wrong with making an ASP.NET application a SignalR client? Is there any possible gotcha with this setup?
In Azure you cannot tell that your AppDomain will not recycle. Because of many reasons, it can restart itself to heal and then you will end up making a new connection to the SingleR server. Is that OK for you?
Also SingleR is mostly used in the Web Functionality improvement where polling and refresh on web clients is made simple. But as your requirement seems to be all a back end stuff, I would suggest you to go with any other event driven pattern. Check Azure Service Bus topic/subscription model to have different components listen to various events and act accordingly.
I am in a situation.
We have a Windows Server 2012 on which a play application is running. This play application is listen to port 80(using built-in HTTP server). Any request sent to my server say, http://abc.testserver.com is picked up by play.
We have one more web application which is developed using php and html. This is hosted on the same server on port 81 using IIS.
So any request http://abc.testserver.com:81 will launch my php web app. But we are not comfortable to expose the port no (i.e. 81) to the users.
Is there any way we can have both the applications running on the same server without displaying the port number to the user? (say use different domain names)
Please help us with possible approach if there is any.
Thanks
I need to make an application where a mobile web app can connect to a local web service in a LAN. For example, several locations are running this web service on their own local server. When someone with the mobile app comes into the location they can open it up and it will somehow be able to connect to that local webservice through WiFi. The mobile app won't know the IP of that webservice ahead of time. Any thought on how to go about this? This will be a .NET webservice and HTML5 app but I don't think that matters.
As mentioned in the comments you will probably have to make it configurable by the user as the will ultimately need the address of the server.
There is however another approach that you can take. Develop a small multicast/udp service that broadcasts the web service address every 10-30 seconds. In your android application register a broadcast receiver that responds to the network connectivity status and runs in the background.
This service on the Android service will pick up the address from the UDP broadcasts and then configure the application.
I have a web application and on that application i update a sql database ...what i want is that when i update the database from the web application a notification will be sent to any one openening my application or a pop up appears to them on their desktop informing them that the database is updated to check all this will be in an intranet.
I'm using ASP.Net and I'm the admin for all the PCs in the network and the server.
Does anyone knows how i can do this ?
Build a desktop application that polls the database regularly or better write a HTTP/REST service where desktop application poll frequently.
What you need is a WCF duplex service your website and your windows clients connect to. With such a service you can use callback methods to inform your windows clients through the service. But be aware that this is normally an intranet and not an internet scenario because such an wcf binding has problems with internet infrastructure (Proxies, Firewalls, ...)