Some time ago i Wrote a service with a timer that make an action every n minutes. All was right. But now, I want to write a service that waits for a signal, message or something from a gui application for doing his job.
I want me process to sleep pacefull (not in a infinite loop sniffing something) until my winforms application tell him "Hey, do things and give me a ring when the work is done"
could someone give me staring point?
Thanks.
You can use Windows Communication Foundation to allow your client to communicate with your service, send it requests, and register to receive progress events from existing running jobs.
You need to use interprocess communication (IPC). For C#, this usually means either .NET remoting -- on older versions of .NET -- or Windows Communication Foundation (WCF) -- on newer versions of .NET.
Essentially, the client application connects to an interface implemented by the service, and can then call methods on it, as if it was in the same process.
If this is too complicated, you could use a named event object, which the service waits on, and the client sets.
Starting point:
Self-hosting WCF service
Any of the IPC mechanisms qualify to get this done. If your needs a simple, just message passing, consider either a named pipe (NamedPipeServerStream) or a socket. If they are elaborate, consider Remoting over an IPC channel or WCF.
Personally, I like named pipes for this. Just make sure the pipe name is prefixed by "Global\" so it is visible from the interactive desktop session. Encrypt the messages if security is a concern. Spin up a background thread in your service that makes a blocking call on the pipe stream to implement the message handling.
If the windows service is on the same machine, you could stop and start the service? or call a webservice that stops/starts a service on a another machine?
If you did have a service that polls (or "sniffs") for something to do , this could be a very small and basic call to a database to check for something that will trigger the actual work?
Related
I want to deploy an Windows services in parallel for redundancy and load balancing purposes.
How can i be sure that when the client sends a request to both of these services, that only 1 of them process the actual call?
Example:
When the client or other services sends a message to start a manufacturing process, both of these services will recieve that request. I want to make sure that only one of those services processes this request, so that manufacturing process do not get started twice!
Do they need to able to talk to themself?
Is there a possibility to sync those services?
Which is the most elegant/robust way of handling this problem?
Look into using a mutex to allow both services to only pick up a message once.
Mutex Description C#
Although, you'll need to make sure this can work in the way you want. this can help schedule between application processes and boundaries, but if this is deploy to two different machines, or Cloud services, the Mutex isn't going to work.
for that you'll need to figure out another of communicating across the applications, usually using a database or a MSMQ to create a message queue that you can pop messages off as you need them from each service.
The safest way, and also the best practice, for your example, would be to retrieve (not to peek) messages from a queue leveraging MSMQ. This gives you a clear explanation of the use case: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/msmq/ms706253(v=vs.85)
~Pino
I'm working on a project including WCF server and remoting clients.Now the necessary functional part of the software need to push message from server to specified client.
I know that Socket can achieve this, but I want to use WCF Only. So I find document on WCF duplex service.Here is my idea:
I start a new thread which communicate with duplex service only once
and then wait for the callback from the server.(Keep the thread
alive and let the proxy opened for waiting the callback )
At the server side,I save all the clients' callbackInstance in a List,and once I want to invoke callback on the specified client,I will take the callbackInstance out from the List and invoke the callback method.
Question
Is my idea feasible?
If question one is yes,how to detect whether the client is still alive(Prevent from invoking the callback on a client-proxy which is closed. )
Is this something we can replace Socket in WCF Service?
Thanks a lot.
Everything is feasible ... It's all a question of what you know, what's involved, and how much time/money you have.
I haven't worked much with duplex WCF because I had to use one way in webservices, but another approach is using a framework like XSockets . It's version 4 is in beta ATM, but the developers are quite approachable and active, so if you have any issues, they'll be happy to work.
It'll give you real time communication in both direction with one to one or one to many, and might fit your use case ...
I've tried a few different ways to do this, but I keep coming up short.
In short, here's what I need to do:
Create a WCF service that acts as a router between client (desktop pc) run diagnostic tools and "widgets" (that also run desktop windows and are have internet connectivety). Since these "widgets" are typically behind some sort of firewall, we've decided to use an IIS hosted WCF service over a tcp connection (port 800, i believe) for callbacks.
Notifications of what the widget is doing need to be sent, asyncronously up through the router to any "connection" clients.
Clients need to be able to syncronously call into the widgets to get diagnostic data or command them to perform a task.
Right now I have a windows service running on the widget that monitors it's status and provided a link to the internal programs to get data.
I also have a light weight diagnostic application running on desktops.
I have created a single callback interface for both status-push and data-pulls that both the widget monitoring program and desktop program implement.
My first attempt was to have the router service keep a list of registered devices and clients and pass messages between them.
Ie: Desktop calls server.getwidgetcolor("widgetid"); and the service calls _widgetlist["widgetId"].getcolor() and returns it.
Similarly the widget monitoring program calls server.notifywidgetcolorchange("widgetid") and the service calls, on all registered client _widgetlist["widgetid"].clients.Notifiycolorchange()
The problem I am running into is that if a wigdet is calling up to the server at the same time the client is calling down to that widget, both calls timeout.
I initially had the server setup as a singleton, and have played with changing the concurancy mode to multiple or re-entrant, but those didn't seem to work.
Conceptually, i'd like to have the service be per-call and persist somehow, that device and client call backs so that when a call comes in, the server wakes up, depersists the call back, sends the message, then goes back to sleep.
With all that said:
Is that ^^ possible (to persist call-back data so that a per-call server can call back on clients)? If not, could I make the service per session (for clients/widgets) but pass the data between service sessions through some other means? Shared memory? File?
Is the over all design possible/recommended? I've looked into the WCF routing library, but that doesn't seem to do what I want, unless I'm reading it wrong?
Are there other technologies I should be using that can do this more easily?
Thanks,
-Bill
I am working on one Asp.Net application and need to send mails periodically based on some event. First I thought of creating a thread in global.asax and start thread in application_start. But that becomes a bit of problem when application pool crashes or something. So I implemented a windows service and started thread in that and log any errors in windows event log. This works fine. But I need to know whether I am implementing it correctly or is there a better way of doing it?
I think you are moving (or moved already) to the right direction.
We have similar architectures as well, in some cases we used MSMQ to queue outgoing notifications from the ASP.NET application then the Windows Service, usually called Messaging Manager, can grab asynchronously the incoming messages and send the emails or alerts out.
this proves to be effective and robust, if anything crashes after the message has been queued, nothing will be lost because the windows service will always process the messages in the queue, so you can have ASP.NET recycling or the machine with the windows service being rebooted, nothing is lost ever. And in fact in normal production mode, messages are sent out instantly, the decoupling or loose of sync is mostly hidden when everything is working smooth and servers are not overloaded or suffering anything.
In a later project we are now implementing something similar using TIBCO technologies, EMS for the queues and Business Works for queue subscribers.
Using a Windows Service for this kind of tasks is the preferred way instead of doing it in the ASP.NET application. You may also take a look at Quartz.NET which could simply your code for scheduling the task execution and dealing with threads. But if you don't want to write Windows Services probably the simplest would be to have a console application that will do the job of sending emails and then simply use the Windows Task Scheduler to run it at regular intervals.
Another option is a message-based approach. You could have a Windows Service/Console Application reading messages of a message queue (like msmq) and send email when a message is recieved. You can then have your ASP.NET application publish messages to this queue.
Minibuss is a lightweight client for msmq which is very easy to work with. Another options is NServiceBus.
The requirement:
My [windows/web] service in C# 3.5 periodically has something to say about its state. It could be a progress status, log entry, error or warning, or signal of data availability.
Client applications are on the same network, and they would like to learn about some of these messages.
Clients start and stop randomly, largely outside of my control.
Clients are written in C#, C++ and even Delphi.
Database connection that can support storing my service's messages may not be available.
I would like my service to publish its messages (text-based protocol) for subscribers to be able to see and react to. I don't want to bother with how many clients are connected, or are there clients at all.
I was looking into named pipes, regular TCP/IP, semaphores, but I cannot seem to find anything that fits the bill.
Currently I'm forced to store a file on the network that is being currently updated, but it's not clean, and requires clients to have access to a network share.
Looks like you need to use WCF for this.
WCF can handle named pipes, TCP/IP and it can do windows and Web services.
You can have a look here:
http://msdn.microsoft.com/en-us/library/ms731082.aspx
Hope this helps!
Check out the OWIN project and the Kayak implementation.
It will allow you to run your own in-process web server.