Cross process signalling - best way of doing it?

[Clive Smith]

Hi Folks,

I am developing an application consisting of a webservice and a Win32
service both written in C#.

When the webservice is called it writes a number of records away to a SQL
server database. These records require further processing by the Win32
service as soon as they appear in the database. The database in SQL 2000.

The easiest way for the Win32 service to check if it needs to do anything is
to actively poll the database every few seconds looking for any new records
written away by the webservice but I am not a great fan of any form of
active polling and would rather the Win32 service was notified of the need
to go look in the database for the new records.

The key drivers for any solution are reliability and simplicity and with
that in mind I have identified a number of potential solutions:-

1. Notify the Win32 service by via a named pipe. Downside is that there is
no managed implementation in .NET until v3 of the framework.

2. Notify the Win32 service via a remoted object

3. Notify the Win32 service via a memory mapped file. The downside is
similar to named pipes i.e. no managed implementation yet available in .NET

4. Notify the Win32 service via a custom command.

5. Notify the Win32 service via a local TCP/IP connection

Notifications to the Win32 service may come in bursts of up to 10 at a time
and although I think that custom commands would be the most simple way of
achieving what I want I am not 100% sure whether this method would be
suitable given that the WIn32 service may need to service up to 10 custom
commands in a short period of time. I am not sure if custom commands are
queued if the Win32 service is busy or if they are lost.

Any comments or pointers regarding a suitable solution would be welcomed.

Thanks,

- Clive

 

[Eugene Mayevski]

Hello!
You wrote on Sat, 31 Mar 2007 19:16:23 +0100:

CS> Any comments or pointers regarding a suitable solution would be
CS> welcomed.

You can take a look at MsgConnect (http://www.eldos.com/msgconnect). It lets
you use Windows-like messaging via memory-mapped file or sockets in a
uniform way. You will get a queue of messages there. MsgConnect was built
with service-UI communication as one of the main uses.

With best regards,
Eugene Mayevski
http://www.SecureBlackbox.com - the comprehensive component suite for
network security

 

[Clive Smith]

Thanks for the info it is definately worth looking at. I would like to avoid
third party libraries if possible but it does not completedly rule it out.
It looks to be fairly cheap too!

Thanks,

- Clive

 

[Willy Denoyette [MVP]]

Hi Folks,

I am developing an application consisting of a webservice and a Win32 service both written
in C#.

When the webservice is called it writes a number of records away to a SQL server database.
These records require further processing by the Win32 service as soon as they appear in
the database. The database in SQL 2000.

The easiest way for the Win32 service to check if it needs to do anything is to actively
poll the database every few seconds looking for any new records written away by the
webservice but I am not a great fan of any form of active polling and would rather the
Win32 service was notified of the need to go look in the database for the new records.

The key drivers for any solution are reliability and simplicity and with that in mind I
have identified a number of potential solutions:-

1. Notify the Win32 service by via a named pipe. Downside is that there is no managed
implementation in .NET until v3 of the framework.

Named pipes are used by the remoting infrastructure when using the "IpcServerChannel " in
V2, no need to wait for the down-level named pipe support in V3.
For more detailed info take a look at the System.Runtime.Remoting.Channels.Ipc namespace.

Another option is to used triggers at the SQL DB side, no need to have a separate Windows
service for further processing.


Willy.