Решение для очереди сообщений для подключенных к Интернету распределенных клиентов C # - PullRequest
Новая
       25

Решение для очереди сообщений для подключенных к Интернету распределенных клиентов C #

4 голосов
/ 28 октября 2011

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

Вкратце, у нас есть распределенная архитектура: различные события на стороне сервера генерируют рабочие элементы, которые извлекаются нашими развернутыми клиентами. Эти клиенты подключаются к серверу, получают работу и обрабатывают ее, а затем возвращаются к «ожиданию выполнения работы».

Несколько важных сведений об этих клиентах:

  1. Сегодня у нас есть несколько сотен клиентских установок, и мы должны быть готовы к росту до десятков тысяч в следующие 18 месяцев.
  2. Клиенты никогда не отправляют задачи на сервер - они «только для извлечения».
  3. Полезная нагрузка для клиентов составляет <= 1 КБ каждый. </li>
  4. Нам не нужна расширенная аутентификация и шифрование трафика (хотя это и неплохой бонус)
  5. Наши клиенты работают в различных операционных системах MS,> = WinXP-SP1. Некоторые из них являются частью активных каталогов Windows или доменов Windows или специальных рабочих групп.
  6. В основном клиенты бездействуют. Мы хотим эффективно «ждать работы», а затем как можно быстрее реагировать на работу (т.е. мы хотим, чтобы клиенты получали рабочий элемент как можно скорее после его постановки в очередь)
  7. Иногда наши клиенты на некоторое время исчезают из Интернета: их машины отключаются на день или на ночь и т. Д. Мы хотим, чтобы рабочие элементы приходили, когда они снова подключаются к сети. Другими словами, нам нужна надежность сообщений.
  8. Мы контролируем весь клиентский и серверный код, но не клиентские среды (хотя наши установщики устанавливают необходимое программное обеспечение, например .NET 3.5, если его там еще нет)

Итак, учитывая вышесказанное - MSMQ будет работать "естественно" для нас? Я не нашел четкого ответа на вопрос, как (или если) MSMQ обрабатывает клиентов, прослушивающих сообщения, когда их нет в доменном / активном каталоге и когда они подключаются через Интернет. Пока что мои чтения по MSMQ кажутся довольно "ориентированными на предприятия" - не будет ли наше требование не для предприятия проблемой MSMQ?

Какие еще решения вы использовали в прошлом в подобных установках?

И, конечно, какие еще вопросы я должен задавать? ; -)

Спасибо!

Ответы [ 2 ]

3 голосов
/ 28 октября 2011

RabbitMQ звучит как решение для вас.

RabbitMQ

Библиотека RabbitMQ .NET / WCF

2 голосов
/ 28 октября 2011

Если вы смотрите на центральный сервер в Интернете с очередями, в которых содержатся сообщения, ожидающие, пока удаленные клиенты их прочитают, то MSMQ вам не подходит (как бы мне не хотелось это говорить). MSMQ не может получать сообщения через Интернет с использованием HTTP. Вам придется открыть порт 135 и использовать протокол RPC, и это не обязательно хорошая идея в Интернете.

Приветствие Джон Брейквелл

...