Как лучше всего передать сигнал из приложения ASP.NET на одном компьютере в службу .NET Windows на другом компьютере?

Question

У меня есть веб-приложение ASP.NET, развернутое на одном компьютере, и служба Windows C #, которая развернута на другом компьютере. Каждый раз, когда пользователь делает новую публикацию через веб-приложение, я хочу немедленно отправить сигнал службе Windows, чтобы начать обработку этой информации.

Мне не нужно передавать какие-либо параметры - просто сигнал о том, что пора начинать обработку для нового куска данных, хранящихся в базе данных.

Было бы неплохо, если бы служба Windows получила сигнал обработки от веб-приложения в течение ~ 200 миллисекунд.

Первоначально я выбрал встраивание WCF в Windows Service и использование NetTcpBinding. Однако WCF оказался неудачным выбором:

1) Требуется множество нетривиальных мерзких кодировок / настроек.

2) Это ужасно медленно - в настоящее время для простого вызова требуется 20 секунд (!) Для вызова с одного компьютера на другой, в то время как пинг между этими компьютерами занимает менее 1 миллисекунды.

3) Команда WCF от Microsoft жалка на [отсутствие] ответов на жалобы разработчиков (Google http://www.google.com/search?q=wcf+client+slow и посмотрите сами).

Так что я ищу хорошую альтернативу.

В настоящее время мой выбор № 1 - System.Net.Sockets.Socket: http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.aspx

Пример в статье кажется простым и менее сложным, чем чудовище WCF.

Как вы думаете, это был бы хороший выбор, и если да - есть ли готы?

Есть ли лучший подход?

Операционные системы: Windows Server 2008 (производство), Windows 7 (разработка).

Я уже решил проблему с постановкой в ​​очередь нескольких запросов: если winservice получает несколько запросов на обработку, он просто обрабатывает данные, пока все новые данные не будут полностью обработаны.

Обновление 1: почему даунтинг?

Обновление 2: Это может быть нормально, чтобы иногда терять сигнал. Я все равно перерабатываю новые сообщения в winservice каждую минуту. Я просто хочу убедиться, что большинство сообщений обрабатываются практически сразу после того, как пользователь их сохранил.

Answer 1

Было бы лучше использовать MSMQ для постановки в очередь сообщений, которые будут обрабатываться вашей серверной службой.Протокол Tcp ненадежен, если вы планируете не терять ни одного сообщения / сигнала.

Answer 2

Рассматривали ли вы .NET Remoting ?Официально это устарело в пользу WCF, и когда дело доходит до корпоративных систем, вероятно, есть веская причина для такого устаревания.Тем не менее, мой текущий проект (.net 3.5) использует его без проблем.

Я разделяю ваше разочарование по поводу WCF: кажется, нет быстрого и простого способа запустить его в работу;количество конфигурации, необходимой для запуска даже простого веб-сервиса Hello World, обескураживает.Тем не менее, я подозреваю / надеюсь, что где-то в WCF есть путь наименьшего сопротивления, и у меня просто нет достаточного практического опыта, чтобы это знать.

Answer 3

Как насчет выполнения UDP-трансляции из вашего ASP-кода. UDP ненадежен по своей природе, но в локальной сети это вряд ли проблема. Код ASP не будет уверен, что сообщение доставлено и обработано, но я понимаю, что это не то, что вы хотите или нужно в любом случае. Наиболее важно, что широковещательная рассылка UDP очень дешевая, а отправка и получение могут быть выполнены очень быстро.

Answer 4

Я бы посмотрел на что-то вроде MassTransit или NServiceBus .

Особенно, если это то, что вы планируете делать в других местах или планируетемного делаюЯ считаю, что они оба могут проходить через MSMQ и должны предоставлять надежную служебную шину для передачи сообщений между разделами вашего приложения.