Как сервер WCF сообщает клиенту WCF об изменениях? (Лучшее решение затем простой опрос, например, Комета или долгий опрос)

Мне кажется, что вы уже знаете ответ: используйте длинный опрос. :) Итак, я думаю, единственное, что осталось объяснить, это как вы могли бы добиться этого с помощью WCF и наиболее эффективным способом.

Основы:

1. Во-первых, решите, как долго вы хотите проводить каждый "длинный опрос" " быть. В качестве аргумента я выберу таймаут 5 минут.
2. В привязке на стороне клиента измените sendTimeout = "00:05:00" .
3. Как и при использовании XmlHttpRequest (XHR) для длительного опроса, когда действительно истечет время ожидания, вы получите необходимо обнаружить это и повторно отправить следующий запрос на опрос. Это довольно просто в WCF, потому что существует конкретное исключение TimeoutException , которое вы можете перехватить, чтобы легко обнаружить, что это проблема или какое-то другое исключение.
4. В зависимости от того, как вы ' При размещении службы WCF вам необходимо настроить себя так, чтобы обработка продолжалась до 5 минут. С чистой точки зрения WCF вам нужно убедиться, что вы установили receiveTimeout = "00:05:00" . Однако, если вы размещаете внутри ASP.NET, вам также необходимо настроить среду выполнения ASP.NET на более длительный тайм-аут, который выполняется с помощью ( примечание: измерения этого атрибута в секундах).

Эффективность в клиенте

Если вы просто настроили свой клиент для синхронного вызова службы, и клиент блокируется на 5 минут, ожидая ответа. , это не очень эффективное использование системных ресурсов. Вы можете поместить эти вызовы в фоновые потоки, но это ' s по-прежнему будет поглощать ресурс потока, пока вызов не завершен. Самый эффективный способ справиться с этим - использовать асинхронные операции.

Если вы создаете свои сервисные контракты вручную, я бы посоветовал проверить этот раздел в MSDN на OperationContractAttribute.AsyncPattern , чтобы узнать, как добавить BeginXXX / EndXXX пара асинхронных методов для каждого из ваших вызовов. Однако, если вы используете svcutil для генерации ваших контрактов на операции, все, что вам нужно сделать, чтобы сгенерировать асинхронные методы, - это передать параметр / async в командной строке. Для получения более подробной информации по этой теме ознакомьтесь с темой «Синхронные и асинхронные» на MSDN .

Теперь, когда вы определили свои асинхронные операции, шаблон очень похож на работу с XHR. Вы вызываете метод BeginXXX , которому передаете делегат AsyncCallback . Метод BeginXXX вернет вам IAsyncResult , который вы можете либо удерживать, если хотите иметь возможность дождаться операции (в более сложных сценариях), либо игнорировать, а затем Инфраструктура WCF будет асинхронно отправлять запрос на сервер и ждать ответа за кулисами. При получении ответа или возникает исключительная ситуация, будет вызван обратный вызов, который вы передали в метод BeginXXX . Внутри этого метода обратного вызова вам необходимо вызвать соответствующий метод EndXXX , передав переданный вам IAsyncResult . Во время вызова метода EndXXX вам необходимо задействовать обработку исключений, чтобы иметь дело с любой логической ошибкой, которая могла произойти при вызове метода, но и здесь вы теперь сможете поймать TimeoutException , о котором мы говорили ранее. Предполагая, что вы получили хороший ответ, данные будут возвращены вызовом EndXXX , и вы можете реагировать на эти данные любым разумным способом.

ПРИМЕЧАНИЕ: Одна вещь, о которой следует помнить об этом шаблоне - характер нарезания резьбы. Асинхронные обратные вызовы от WCF будут получены в потоке из пула управляемых потоков . Если вы планируете обновить пользовательский интерфейс с помощью такой технологии, как WPF или WinForms, вам необходимо убедиться, что вы маршалируете вызовы обратно в поток пользовательского интерфейса, используя методы Invoke или BeginInvoke .

Эффективность на сервере

Если мы собираемся беспокоиться об эффективности в клиенте, мы должны быть вдвойне так, когда речь идет о сервере. Очевидно, что такой подход предъявляет больше требований к серверу, потому что соединение должно оставаться открытым и ожидающим, пока не появится причина для отправки уведомления клиенту. Проблема здесь в том, что вы хотите связать среду выполнения WCF только с обработкой тех клиентов, которым фактически отправляется событие. Все остальное должно просто спать, ожидая наступления события. К счастью, тот же шаблон async, который мы только что использовали на стороне клиента, работает и на стороне сервера. Однако теперь есть большая разница: теперь вы должны вернуть IAsyncResult (и, следовательно, WaitHandle ) из метода BeginXXX , который среда выполнения WCF затем будет ждать сигнала перед вызовом метода EndXXX .

Вы не найдете много документации внутри MSDN, кроме ссылок, которые я уже предоставил ранее, и, к сожалению, их примеры по написанию async-сервиса менее чем полезны. Тем не менее, Венлун Донг некоторое время назад написал статью о масштабировании служб WCF с помощью асинхронной модели , которую я настоятельно рекомендую вам проверить.

Честно говоря, я могу ' Я даю слишком много советов о том, как лучше всего реализовать асинхронную модель на стороне сервера для вас, потому что это полностью зависит от того, из какого источника данных будут исходить ваши события в первую очередь. Файловый ввод-вывод? Очередь сообщений? База данных? Некоторое другое проприетарное программное обеспечение с собственной службой обмена сообщениями, над которым вы пытаетесь прикрыть фасад? Я не знаю, но все они должны предлагать собственные асинхронные модели, на которых вы можете использовать свой собственный сервис, чтобы сделать его максимально эффективным.

Обновленное предписание

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