I need to have a background thread that does some work and sends data to the users connected to the service through SignalR.
I thought of hosting this thread inside IIS, and to spawn it when Application_Start is first hit, or in a separate worker process.
If I host it in IIS and create it at the start of the application
- The thread starts only when the app is first hit. I need it running as soon as I start the service.
- I do not have control over this thread via a desktop GUI, I can't stop or pause it in a simple way.
If I host it in a separate process, such as a Windows Service
- I don't have access to the SignalR service instance
- I don't want to connect to the SignalR service as a user to send data to other users. I wanr a different approach to this, one that doesn't imply the worker being a client to SignalR itself.
What is your opinnion on this ? Do you see any other solution ?
The way we have approached this is to create a separate endpoint on the web application that your Windows service can call.
Imagine the following URI exists in an ASP.NET MVC controller: http://[myserver]/api/TellUsers/[msg]. Inside of this method, you can get the connected hub clients and make the call.
[HttpPut]
public void TellUsers(string msg)
{
var connectionManager = AspNetHost.DependencyResolver.Resolve<IConnectionManager>();
var demoClients = connectionManager.GetClients<MyHubDerivedClass>();
demoClients.TellUsers(msg);
}
[Insert caveat about proper error checking here.]
Of course, you don't have to use MVC. Any publicly accessible URI would work. As for securing it, you can use any valid technique for securing ASP.NET endpoints.
I know the question is rather old but:
In truth i rather like the "client itself" example you have. This gives you control from many different points rather than just one. Example - multiple services can call over to control the service. I can't see any reason you can't have an admin user which is able to invoke "special" commands that others users can't.
That's a tried and tested design for many systems. I'd stick with it.
Related
I am looking for a way user can communicate between an ASP and Winform applications.
I am looking for something like soluto.com, I want to let the user send commands to other computers via Website. So let's say the user signed up for 10 computers, which is registered on the mvc app. User can select all the 10 computer and send a "Do this task" with a click of a button.
I am thinking something like, Winform will create a httplisten server. Everytime winform is open, it will send a "I am online" post to mvc, along with IP:Port. The server will send a request to that ip:port when required.
That approach seems very unsecure though, having an open port, configuring firewall and etc, seems like a overkill.
I was wondering if there way any other way of accomplishing this.
Thank you for the help.
P.S. Before you claim this is a stupid idea, Piriform is doing something like this also. Take a look at Agomo.com
Use SingalR with properly architected web and windows applications (e.g. MVP, MVC, etc.)
SignalR with window client (WPF)
Console App & SignalR
Create a WCF service within the WinForm application, specify endpoint(s) (and secure the endpoint appropriately), and connect to said endpoints from your ASP.NET application the same way you would also connect to a WCF service.
Why don't you just have the Winforms app use a standard HttpClient or WebRequest to periodically poll the service (maybe every 5 seconds or so) and ask if there if there are any tasks that need to be performed?
Unless you need realtime, low-latency, high performance communication then this is the easiest way to solve your problem with minimal to zero client side setup or security configuration.
The way I would do it is implement it like a stack in a data persistence layer. So each client could have rows in a table that are added when a task is queued. When the clients sends an HTTP GET request to the MVC server it will return the an array of tasks for that client and you could have it either delete them from the database right away or wait for the client to send a HTTP command later to indicate which tasks it completed.
You could represent tasks as a simple data object with a few properties, or just a string or int that you can lookup on the client in some way to invoke the appropriate code.
For reasonable security each client just needs to be given a unique key like a GUID or equivalent that it can later send to the server to validate its identity. This is also known as a cookie, secret, or API key.
I have a Windwos Application (Let's name it App) and a WebService Project (name it WS) and a SqlServer Database (DB), and the technologies are all from Microsoft and .net.
The roles are that whenever App needs to do an action, it calls WS and WS does the magic work with DB and then returns the result to App.
So far, so good, but I need something more than that. I need a third Application, let's call it a Robot, this Robot monster should have the ability to find all alive clients (App instances) and not kill, but call them on some specific times, then the App(s) will decide do an action on being called.
My information lacks here, and that is why I want you guys to help me find the best solution for this Server-Calls-Client-And-Client-Does-Something thing.
I have very short handed and pragmatic solution ideas:
Each client application invokes a method for instance YesIamAlive() of the webservice each x seconds/minutes. If the server gets this request it will be saved so you are be able so see which clients are alive. Each client which not sending an alive request for the last x seconds / minutes is not any longer alive. Another method which is also called on a routinely basis and it forces the client to do an action.
You could use SignalR for a websocket communication between your server and client. This example shows a chat server, which is not simular to your request but it shows the idea behind it:
http://braindrivendevelopment.com/2013/01/28/signalr-with-windows-azure-cloud-services/
I am quite sure that there are even more elegant solutions for your problem.
SignalR (GitHub) is an excellent framework for "pushing" to clients in near real-time. It works with both web and WinForms clients.
i have thoroughly searched the internet (most of the links sent me to stackoverflow ;)) to try to come up with a solution how to keep a WCF Service alive under IIS (7.5).
Many of the responses here were suggesting to write an application that will periodically send dummy requests to the WCF service in order to keep it alive.
My question is:
what if I create a thread in the WCF which will start when a service is first called (in a static constructor) that will periodically consume the WCF itself?
I mean for example in c#:
while (true)
{
WebClient client = new WebClient();
string returnString = client.DownloadString("http://...");
Thread.Sleep(1000 * 5);
}
assuming that "http://..." is an URI to a provided WebMethod which for example returns some integer.
Would that work?
Basically I need some kind of web service (not particulary a WCF but not a Windows Service) that is running on a server that performs some operations and updates something in a SQL Server database. So if the described approach will not work, what might be the best way to achieve this?
Go to your IIS -> Application Pool (or create new one) -> Advanced settings and set Regular Time Interval=0
See related thread here.
AppFabric allows you to create wcf services which can autostart and be long living - this might be worth checking out as a hosting option (it's just a plugin for IIS)
Auto Start
What you are doing is basically wrong from the outset.
The problem is this:
IIS is basically a stateless request broker for http requests (basic IIS) and a request broker for service requests (IIS w. AppFabric).
What you are asking for is how to turn the inherently stateless IIS into a stateful server, with eternal threads running.
That is not what IIS does, IIS handles requests and its AppDomain is subject to AT ALL TIMES be torn down (destorying all threads).
Which makes the most upvoted answer dangerous, as it teaches you how to affect the recycle process, without controlling the tear-downs (off app-domains and threads) that IIS itself will intermittenly perform.
The requester is "foreign" to the IIS itself.
The internal lifetime of the service though, is entirely managed by IIS (and the configuration of its applications) itself.
So if with "keep alive" you mean: to constantly request some service, then do as Andreas suggest further up (create a schedueled job).
If with "keep alive" you mean: to make sure the same instance of the class handles requests, then you need to look into WCF lifetimes.
If with "keep alive" you mean: to make the code you have created "stateful" and keep f.eks static variables alive and so on, well you are not accepting that IIS is basically a stateless pr. request broker with internal lifetime management.
I suggest you create a small program (console app) that calls the web service. The program should take as arguments the url of the web service. Then you create a windows scheduled task that runs the program. In this way you have a lot of flexibility as compared to the embedded approach you are querying about as the program is just another client to the web service.
Try to avoid using while loop. Maybe http://quartznet.sourceforge.net/ is something you are looking for. On WCF start create Task every 10 minutes which will cal WCF itself.
I am building a WCF service that will expose several operations, it will run in IIS because it needs HTTPS endpoints. Most of the operations will perform within seconds or less; however, one or two of these operations will take between 5-90 minutes.
The primary consumer of this service will be an ASP.NET MVC application; what is the correct way to do handle this?
Should I jackup the timeout and do some ajax calls? Should I add a table to my database, and have the long running operations update this database, and have the web interface poll this table every minute? I'm not sure what (if there is) the generally accepted best practice for this.
I wrote something similar for my senior project, basically a job scheduling framework.
I chose to go down the path of storing the "status" of the "job" in the database.
I wrote a manager windows service that implemented a WCF client (proxy)
I wrote a WCF Service that implemented my "worker host".
The manager service would read the queue from the database, and hand out work to all of my "worker hosts". The reason I had windows service perform this task as opposed to just having the UI talk directly to the worker host, was because it gave an extra level of control over the whole process.
I didn't like the idea of having "the network cable unplugged" from my worker host, and never getting a status update again from this specific job. So, the windows service gives me the ability to constantly monitor the progress of the WCF worker host, and if a connection error ever occurs (or something else unexpected), I can update the status to failed. Thus, no orphaned jobs.
Take a look at this
WCF Long Running Operations
There could be other options but they are nearly the same. You can also come up with some push notifications (I assume no data is returned) as one int the following link
WCF Push
I am currently developing a C# Windows Form Application that I intend to let it interact with a server. The server will receive posting from a mobile application that I have developed and whenever a posting is received, my Windows Form Application should be notified and give me a notification. In order to do this, I intend to use WCF duplex service for it.
E.g. My mobile application sends an posting over to my server. Once my server reads and receives the new posting, the service should send a message over to my winform app to alert me that a posting is received. And the UI of the winform app should update accordingly to what I want to updated. (e.g. adding new panels)
This is basically how I wish for it to work
They way this would work is
WCF Service in running on my server
Windows Form connects to my server's WCF service using Duplex Contract
Mobile app posts to a webpage
Once the webpage receives the posting, the asp.net will invoke the WCF service
WCF duplex service receives the posting and sends the information to the winform app
My winform Application aka WCF Client updates UI with this new message received
My question is, how does step 4 proceed to step 5? To be specific, how does the service sends the information over to the winform app upon receiving the posting.
To be even more specific, once the posting is received from the webpage, the service contract is invoked and the information is sent and received by the service, how does the service make use of the call back channel to send the information over to the winform app and update the UI accordingly?
The answer to this question depends on how your WCF service is hosted and how "big" the service will eventually be (in terms of number of simultaneous clients).
The simplest scenario is a self-hosted WCF service (meaning hosted in a Windows Service or as a desktop application--not in IIS). In this case, you can use InstancePerSession mode and make your service use sessions. In this case, you'll have a 1:1 correspondence between clients and instances of your service class. When a client connects, retrieve the callback reference and store it in a static list outside of the service class. When you need to send a message to one or more clients, simply iterate over (or find the desired client in) your list and call the appropriate function on the callback contract
If you need to host your service in IIS, then the situation is trickier because you have the possibility of multiple processes hosting your service, so your list can potentially get fragmented (or blown away in the event of an app pool recycle). In this case, you'll have to use something external to your service (MSMQ, perhaps) to notify other application pool processes that a message needs to be sent.
In terms of a duplex connection, you are really just able to communicate two way over that one connection, not with all connections of the service without doing some tricky thread stuff and shutting the door on any scalability (or using something outside the service to handle to pub/sub).
One solution though that may work a lot more along the lines of what you want to do would be SignalR. It allows a single client to make a request and then you can broadcast data from that request to other clients (or target it). Take a look at its info, its sole purpose is real time communication in .NET with multiple clients.
Also another note, is that you will want to use some sort of BackgroundWorker or something for your listening thread in WinForms so that the UI is not locked while the background operations are running.