Связь между сервером и клиентом для WinForms

Question

У меня есть более 50 компьютеров в стиле киоска, которые я хочу получать по запросу обновление состояния с одного компьютера, а не с интервалом. Эти компьютеры находятся в локальной сети относительно компьютера, запрашивающего состояние.

Я исследовал WCF, но, похоже, мне понадобится установить IIS, и я бы не стал устанавливать IIS на более чем 50 Windows XP - поэтому я думаю, что это исключает использование веб-службы, если только WinForm не может быть хостом для веб-службы?

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

Эти коробки работают под управлением .NET 3.5 SP1, поэтому у меня есть полная гибкость в версии .NET, но я бы хотел придерживаться C #.

Каков наилучший способ реализовать это? Должен ли я просто прикусить пулю и узнать больше о сокетах или у .NET есть лучший способ справиться с этим?

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

изменить 2: Я избегал традиционного сервера / клиента и использовал обратное, потому что хотел избежать слишком большой полосы пропускания и не знал, о каких издержках я говорил. Я также надеялся получить больше контроля над отдельными киосками. Посмотрев на это, я думаю, что у меня все еще может быть это с WCF и соединением по IP (который я не знал, что мог соединиться по IP, я думал, что мне нужно будет добавить 50 веб-сервисов или что-то в этом роде).

Answer 1

WCF необязательно размещать в IIS, его можно размещать в Winform, в виде консольного приложения или службы Windows. Вы можете заставить каждый компьютер размещать свою службу в пределах winform, и написать программу на своем собственном компьютере, чтобы вызывать службу каждого компьютера для получения информации о состоянии.

Еще один способ сделать это - разместить одну службу на своем компьютере и заставить 50+ компьютеров вызывать службу после обновления их статуса. Вы можете использовать базу данных для службы для сохранения данных о состоянии каждого узла в сети. Эта опция проще в обслуживании и масштабируема.

P.S. WCF призван заменить удаленное взаимодействие .net, альтернативы могут быть привязка net.tcp или net.pipe

Answer 2

Не используйте удаленное взаимодействие.

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

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

Используйте веб-сервисы.

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

Как другие говорили, что вам не нужен IIS, вы можете самостоятельно принимать гостей. См. ServiceHost класс для получения подробной информации о том, как это сделать.

Answer 3

Независимо от того, используете ли вы веб-службу или WCF на центральном сервере, вам нужно только установить и настроить IIS на сервере (а не на 50+ клиентах).

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

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

Настройка каждого клиента с его собственным веб-сервисом будет представлять собой инверсию традиционной (клиент-сервер) архитектуры клиент / сервер, и, как вы уже отметили, это будет нецелесообразно.

Answer 4

Если вы не планируете масштабировать это до нескольких тысяч клиентов, я не думаю, что производительность WCF будет даже незначительной проблемой. Вы можете легко размещать службы WCF из служб Windows или из приложений Winforms, и вы обнаружите, что что-то работать с WCF будет довольно просто, как только вы получите ключевые понятия.

С большим успехом я развернул примерно 100-150 клиентов.

В Интернете достаточно ресурсов для начала работы. Вот один из них, который поможет вам:

http://msdn.microsoft.com/en-us/library/aa480190.aspx

Answer 5

Я бы предложил использовать .NET Remoting. Это довольно просто реализовать и не требует ничего другого.

Answer 6

Как тот, кто реализовал нечто подобное с более чем 500+ клиентами и растет:

Очередь сообщений - путь.

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

Пара важных замечаний:

Разрешение процессу опрашивать клиентов, а не наоборот = Плохая идея .. он вообще не масштабируется, и вы скоро столкнетесь с проблемами, если процесс займет слишком много времени для завершения .. Не говоря уже о наличии для обработки всех ip-адресов (есть ли у вас доступ ко всем клиентам на требуемых портах? Что лучше, когда меняется ip и т. д.)

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

Относительно пропускной способности: в киоске обычно показываются изображения / видео и т. Д. Сообщения о статусе 1Kb или меньше не будут большими накладными расходами

Я НЕ МОГУ подчеркнуть, что нынешний дизайн, который вы представляете, будет иметь очень интенсивный цикл разработки И не будет масштабироваться или расширяться (поверьте мне, мы усвоили этот урок). Кроме того, создание хорошего клиент-серверного протокола для такого типа вещей - сложная работа, которая впоследствии будет совершенно бесполезна, если вы допустите ошибку проектирования (перенести протокол не так просто)

Мы создали наше решение поверх ActiveMQ (используя библиотеку NMS c #) и в настоящее время расширяем Simple Service Bus для нашей внутренней работы.

Мы используем WCF только для связи между нашим приложением winforms и централизованными службами

Answer 7

Если вам просто нужно обновить статус, вы можете использовать гораздо более простое решение, такое как простой обмен сообщениями между сервером и клиентом tcp или, как сказал orrsella, удаленное взаимодействие. WCF здесь немного лишний.

Одно замечание: если все ваши киоски 50+ подключены через Интернет, вам может понадобиться использовать VPN или иметь открытый порт на каждом киоске (что представляет угрозу безопасности), чтобы ваш сервер мог получать обновления статуса из каждого киоска .

У нас была похожая ситуация, но статус периодически отправляется на наш сервер, поэтому у нас есть только 1 порт для защиты / безопасности. Частота обновления настраивается так, чтобы приспособиться к более медленным клиентам.

Answer 8

Для меня лучше изучить сетевое взаимодействие ... или ручной способ сокетной коммуникации .. веб-службы работают медленнее, потому что они содержат метаданные ..

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