Запуск графического отображения на нескольких системах с сохранением синхронизации

Question

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

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

Все это закодировано на C # .Net.

Клиентский дисплей представляет собой приложение Windows Forms.Сервер принимает TCP-соединения, а затем обслуживает их циклическим образом, сохраняя основные часы того, что происходит.Клиенты посылают сигнал, который гласит: "Я достиг точки синхронизации 32" (или 19, или 5, или что угодно еще) и ожидает подтверждения от сервера, а затем движется дальше.Или сервер может сказать "Нет, вам нужно начать с точки синхронизации 15".

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

Затем Спецификация изменилась.

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

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

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

Имейте в виду, что также существуют ограничения по времени и скорости.Я мог бы поместить танцевальную программу в сетевую базу данных, но мне пришлось бы довольно быстро вводить инструкции, и было бы много читателей, использующих довольно сложный протокол (DBI, SqlClient и т.д.), Чтобы получить небольшой фрагмент текста.Это кажется чересчур сложным.И я все еще нужно что-то, чтобы все они отображались синхронно.

Предложения?Мнения?Безумные предположения?Примеры кода?

PS:Ответы могут не быть помечены как "правильные" (поскольку это не "правильный" ответ), но + 1 голос за хорошие предложения точно.

Answer 1

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

Архитектура, на которой мы, наконец, остановились после изрядного количества тестов, предполагала наличие одной "главной" машины.В вашем случае это означало бы наличие одного из ваших 20 клиентов, который выступает в качестве ведущего, и подключение его к серверу через TCP.

Затем сервер отправил бы всю серию команд для этой серии на эту одну машину.

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

Ключевым моментом для бесперебойной работы, однако, является наличие интеллектуальных средств связи между главным сервером и "главной" машиной - вы хотите сохранить пропускную способность как можно ниже.В случае, подобном вашему, я бы, вероятно, создал один двоичный двоичный объект, содержащий текущий набор команд для 20 машин в его наименьшей форме.(Может быть, что-то вроде 20 байт или 40 байт, если вам это нужно, и т.д.).Затем "главная" машина побеспокоилась бы о том, чтобы передать это другим 19 машинам и самой себе.

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

"Главный" сервер - самый сложный.В нашей реализации у нас фактически был тот же клиентский код, что и в остальных 19 (как отдельный процесс), и один процесс "перевода", который взял большой двоичный объект, разбил его на 20 частей и передал их.Она была довольно проста в написании и работала очень хорошо.