Связь между сервером и клиентом для 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 даже будет проблемой. Вы можете легко размещать службы WCF из служб Windows или приложений Winforms, и вы обнаружите, что что-то, что работает с WCF, будет довольно простым, как только вы получите ключевые понятия.

Я с большим успехом применил что-то подобное около 100-150 клиентов.

Там множество ресурсов на сети, чтобы вы начали - вот один, чтобы вы собираетесь:

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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

сообщение является создание очередей путь.

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

Несколько важных замечаний:

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

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

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

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

Мы построили наше решение ontop из ActiveMQ (с использованием библиотеки NMS C#) и в настоящее время расширяют простую служебную шину для наших внутренних операций.

Мы используем только WCF для общения между нашими WinForms приложений и централизованного обслуживания (ов)