What’s the best way to pass a signal from ASP.NET app on one machine to .NET Windows Service on another machine?

Question

I have a ASP.NET web application deployed on one machine and C# windows service that is deployed on another machine. Every time when user makes new posting through web app, I want to send immediate signal to windows service to start processing that information.

I don't really need to pass any parameters - just a signal that it's time to kick off processing for new chunk of data stored in the database.

It would be nice if windows service received processing signal from web app within ~200 milliseconds.

My initial choice was to embed WCF into Windows Service and use NetTcpBinding. However WCF turned out to be an unfortunate choice:

1) It requires lots of non-trivial ugly coding / configuring.

2) It's terribly slow – currently in order to make a simple call it takes 20 seconds (!) to call from one machine to another while ping between these machines takes less than 1 millisecond.

3) Microsofts' WCF team is pathetic in their [lack of] replies to developers' complaints (Google http://www.google.com/search?q=wcf+client+slow and see yourself).

So I'm looking for a good alternative.

Currently my choice #1 is System.Net.Sockets.Socket: http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.aspx

The example in the article seems to be straightforward and less complex than WCF monstrosity.

What do you think, would it be a good choice and if so – are there any gothas?

Is there a better approach?

Operating systems: Windows Server 2008 (production), Windows 7 (development).

I already solved problem with queue-ing multiple requests: if winservice receives multiple processing requests, it simply processes data until all new data is fully processed.

Update 1: why the downvoting?

Update 2: It could be ok to loose signal occasionally. I reprocess new postings in winservice every minute anyway. I just want to make sure that most postings are processed almost immediately after user saved them.

Answer 1

It would be better to use MSMQ to queue up messages that would be processed by your back end service. Tcp is not reliable when you do plan on not loosing any message/signal.

Answer 2

Have you considered .NET Remoting ? Officially it's been deprecated in favor of WCF, and when it comes to enterprise systems, there's probably good reason for that deprecation. Nevertheless, my current project (.net 3.5) uses it with no problems.

I share your frustration with WCF: there seems to be no quick and easy way to get it up and running; the amount of configuration necessary to launch even a simple Hello World webservice is disheartening. However, I suspect/hope that there IS a path-of-least-resistance in WCF somewhere, and that I just don't have enough hands-on experience to know it yet.

Answer 3

How about doing a UDP broadcast from your ASP code. UDP is inherently unreliable, but on a LAN that is hardly a problem. The ASP code will not be sure that the message is delivered and acted upon, but I gather that is not what you want or need anyway. Most importantly, an UDP broadcast is very low-cost and sending and receiving can be done very fast.

Answer 4

I would take a look at something like MassTransit or NServiceBus .

Especially if this is something you're planning on doing in more places or planning on doing a lot. I believe they can both go through MSMQ and should provide a solid service bus for transmitting messages between sections of your application.