Опрашивать или не опрашивать (в контексте веб-сервисов)

Question

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

Answer 1

Частично зависит от того, сколько у вас пользователей.

Скажем, у вас есть 1 000 000 пользователей, у вас будут проблемы с поддержанием такого количества сеансов.

Но если ваша система может отвечать на 1000 запросов опроса в секунду, то каждый клиент может опрашивать каждые 1000 секунд.

Answer 2

Я бы использовал механизм, основанный на событиях, вместо опроса. В WCF вы можете легко это сделать, следуя платформе Publish-Subscribe, которую Джувал Лоуи предоставляет на своем веб-сайте, IDesign.net .

Answer 3

Я думаю, что Шираз прибил это, но я хотел сказать еще две вещи.

1. У меня были проблемы с дуплексом контракты. Вы должны иметь все ваши утки подряд в отношении канал обратного вызова ... вы должны проверьте, чтобы убедиться, что он открыт, и т.д. Материал IDesign.net будет минимальное количество сантехнического кода вам придется включить.

2. Если это имеет смысл для вашего решения (это уместно только в определенных ситуации), привязка MSMQ позволяет клиент для отправки данных в сервис асинхронным образом (например, дуплекс), но услуга не "опрос" для сообщения ... он получает уведомление, когда один входит в очередь через несколько под-укрытие сантехники.

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

О чем подумать.