Предложенная топология сети для этого небольшого приложения передачи данных / команд? - PullRequest
5 голосов
/ 20 августа 2011

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

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

Сведения о системе:

  • Сбор необработанных данных происходит на одном компьютере с Linux.Простая обработка данных, сохранение на диск и передача в сеть занимают около 25% мощности ЦП и небольшой объем памяти.В сеть поступает менее 0,5 Мб / с данных.Весь код для генерации данных находится на c ++.

  • Другая машина Linux запускает несколько процессов визуализации / обработки / графического интерфейса.GUI управляет как машиной сбора данных, так и процессами на самом компьютере vis / processing / GUI.Этот код в основном на языке C ++, с несколькими небольшими утилитами на Python.

  • Мы будем писать другие приложения, которые захотят прослушивать необработанные данные, обработанные данные и всекоманды передаются;эти приложения также захотят выполнять команды - мы не можем предвидеть, сколько таких модулей мы хотим написать, но мы ожидаем, что 3 или 4 процесса с большими объемами данных преобразуют все 32 входных потока в один выход;а также 3 или 4 одноразовых небольших приложения, таких как «регистратор команд».Требование модульности означает, что мы хотим, чтобы старые генераторы данных и издатели команд не зависели от количества слушателей.Мы также хотим, чтобы команды были подтверждены их получателями.

  • Эти две машины соединены коммутатором, а пакеты (и данные, и команды, и подтверждения) отправляются в UDP.

Пять возможностей, о которых мы думаем:

  1. Потоки данных, команды и подтверждения зависят от номера порта.Генератор данных отправляет независимые потоки данных в виде пакетов UDP на разные номера портов, связанные независимыми процессами визуализатора на компьютере визуализации.Каждый процесс также связывает порт прослушивания для входящих команд и другой порт для входящих подтверждений исходящих команд.Эта опция кажется хорошей, потому что ядро ​​выполняет работу по передаче / фильтрации пакетов;но плохо, потому что трудно понять, как процессы обращаются друг к другу перед лицом непредсказуемых добавленных модулей;это также может привести к взрыву связанных портов.enter image description here

  2. Потоки данных нацелены на соответствующие визуализаторы по номеру порта, и каждый процесс связывает порт для прослушивания команд.Но все издатели команд отправляют свои команды процессу пересылки пакетов, который знает порты ввода команд всех процессов и перенаправляет каждую команду всем им.Подтверждения также отправляются на этот универсальный командный порт и пересылаются всем процессам.Мы упаковываем информацию о предполагаемой цели каждой команды и каждого подтверждения в пакеты command / ack, поэтому самим процессам приходится просеивать все команды / acks, чтобы найти те, которые относятся к ним.enter image description here

  3. Процесс пересылки пакетов также является целью всех пакетов данных.Все пакеты данных и все командные пакеты передаются, возможно, 40 различным процессам.Это, очевидно, значительно увеличивает трафик в подсети;это также убирает взрыв связанных портов.enter image description here

  4. На компьютере могут работать два распределителя пакетов - один передает команды / подтверждения на все порты.Другие транслируют данные только на те порты, которые могут потребовать данные.

  5. Наши 32 процесса визуализации могут быть объединены в 1 процесс, который собирает данные для 32 сигналов, что значительно сокращает дополнительный трафик этой опции.3 причины.

Если вы экспериментировали с передачей данных между несколькими процессами на небольшом количестве машин и у вас есть некоторый опыт или практические рекомендации относительно того, какие стратегии являются надежными, яБуду очень признателен за совет!(просьбы о разъяснении на фото приветствуются)

1 Ответ

2 голосов
/ 20 августа 2011

У меня недостаточно представителей, чтобы переместить этот вопрос на programmers.stackexhange.com, поэтому я отвечу на него здесь.

Сначала я добавлю вам немало технологий, каждая из которых вам нужна.взгляните на.

  • Hadoop Каркас, уменьшающий карту.Возможность собирать большие суммы данных и обрабатывать их по распределенным узлам.

  • Kafka Система обмена сообщениями с чрезвычайно высокой производительностью.Я бы посоветовал смотреть на это как на шину сообщений.

  • ZooKeeper Распределенная система, которая позволит вам «разобраться» во всех аспектах вашей распределенной системы.,Это система координации, которая распространяется

  • Pub / Sub Messaging

  • ∅mq Другойбиблиотека сокетов, позволяющая обмениваться сообщениями в пабах / суб-сообщениях и другие механизмы передачи сообщений N-to-N.

Теперь, когда я разработал несколько технологий, я объясню, что буду делать.

Создайте систему, которая позволяет создавать N разъемов.Эти соединители могут обрабатывать данные / команды N на диаграмме, где N - это конкретный сигнал.Это означает, что если у вас было 32 сигнала, вы можете настроить свою систему с 32 разъемами для «подключения».Эти разъемы могут поддерживать двустороннюю связь.Следовательно, ваша проблема получения / команды.Один соединитель будет публиковать свои данные на что-то, например, Кафку, по теме, относящейся к этому сигналу.

Использовать систему публикации / подписки.По сути, происходит то, что коннекторы публикуют свои результаты в указанной теме.Эта тема - то, что вы выбираете.Затем процессоры, пользовательский интерфейс, бизнес-логика и т. Д., Слушают определенную тему.Все они произвольны, и вы можете настроить их так, как хотите.

 ============         =============      =====     ============       =============
 = Signal 1=  < --- > = Connector = < -- = K = --> = "signal 1" --->  = Processor =
 ============         =============      = a =     ============       =============
                                         = f =
 ============         =============      = k =     ============       =============
 = Signal 2=  < --- > = Connector = < -- = a = --> = "signal 2" --->  = Processor =
 ============         =============      =   =     ============   |   =============
                                         =   =                    |
 ============         =============      =   =     ============   |  
 = Signal 3=  < --- > = Connector = < -- =   = --> = "signal 3" --- 
 ============         =============      =====     ============       

В этом примере первый соединитель «публикует» свои результаты в теме «сигнал 1», в которой первый процессор прослушивает эту тему.Любые данные, отправленные в эту тему, отправляются на первый процессор.Второй процессор прослушивает данные «сигнала 2» и «сигнала 3».Это представляет собой что-то вроде пользовательского интерфейса, получающего различные сигналы одновременно.

Следует иметь в виду, что это может происходить по любым темам, которые вы выберете.«Процессор» может прослушать все темы, если вы считаете это важным.

...