tags:

views:

300

answers:

2

I have a created a C# windows service (Serv.exe) which is responsible for performing various tasks at the request of a running application (A.exe), some of these can take long periods of time and I need a way to know the status of my requested operation (running on the service) from the calling application (A.exe).

Currently the way I have started to implement this is by using the ControlService(handle, command, status) to send a custom command to the Service to perform the task being requested, I am also using QueryServiceStatus(handle, status) to get the status of the service from the SCM - so the basic plumbing is there and working.

Now the problem I have is, after sending my ControlService Command (which works fine) the calling application (A.exe) keeps running and, at a certain point, it needs to know if the task it requested of the service is finished or not - therefore I am looking for a way to Query the Service to report a custom status, not the standard running, stopped, pending, paused state of the actual service but the status of the request I made using the ControlService() request.

Is this at all possible? Any help or hints would be immensily appreciated.

Thanks,

+1  A: 

In the past, when I've had to handle more complex communication, I usually switch from QueryServiceStatus to having the service actually provide a means of communication via IPC.

Sockets and Pipes both work very well for this. The client and service can have pretty much an unlimited freedom in terms of what is communicated this way.

Reed Copsey
Ganesh R.
Shaitan00
I actually really like Pipes (my preferred approach), especially if you're using C#. Named and anonymous pipes work very, very well, and have fairly low overhead. They're especially easy if your client app is running on the same machine as the service. Another advantage of this approach, too, is that it's easy extensible. You can always add more messages as time goes on. Pipes can be bi-directional, so the server can directly notify the client (without a query being required), etc.
Reed Copsey
both the service (written in C# .NET2) and the calling application (C++ 6) are on the same machine (local) at all times. I know Pipes were only introduced in .NET3.5 so I assume I would just load all the required functions (P/Invoke stuff).Well - if this the better then the ControlService() I'll start that way... thanks for all the helpful feedback ...
Shaitan00
Check out this CodeProject artcile for an example of using Pipes from C# 2.0 (it requires P/Invoke, but is still not too tough): http://www.codeproject.com/KB/dotnet/NamedPipeOverlapped.aspx
Reed Copsey
Shaitan00
MAILSLOTS use datagrams, so they have no reliability contracts. You're not guaranteed that the receiver will receive the "message". See: http://msdn.microsoft.com/en-us/library/aa365576%28VS.85%29.aspx
Reed Copsey
A: 

What's worked very well for me is to set up an external queue, such as MSMQ or a database table. These are easy to code, support bidirectional traffic between app and service, allow for multiple apps talking to one service even over the network, and allow you to shut down the app and start it later with the messages intact. Plus, it's easier to debug because you can examine the traffic, particularly if you're using a database and marking the messages as read instead of deleting them. SQLite via the System.Data.Sqlite wrapper is perfect for this when you don't want to use a heavyweight database or don't want to worry about whether MSMQ is installed or running.

Another alternative is to put your logic inside of a WCF service and communicate to it via HTTP or TCP.

ebpower
I assume MSMQ requires me to install something (MSMQ), not allowed any more 3rd party tools. But we do have SQL 2005 installed already - that is an idea I had not considered using for such small communication.WCF supported in .Net 2.0?And you mean to have the calling application (C++ 6) communication using TCP (sockets) to the service (WCF)? Isn't that overkill for a once-in-a-while (23minute) request from the calling application? And wouldn't that require ports to be opened, etc...? I need to reduce the impact and cannot get IT involved.
Shaitan00
A couple of comments - Using MSMQ from VC++ 6 will not be trivial. WCF is .NET 3.0+.
Reed Copsey
Well, then if you can't install anything, and are restricted to VC++ 6 and .Net 2.0, then a small SQL Server 2005 table that holds messages from the service would be an easy and reliable way to go. It's also a great way to capture status messages and errors from the service.
ebpower