UniSet
2.8.0
|
- \ref pgUNetUDP_Common - \ref pgUNetUDP_Conf - \ref pgUNetUDP_Reserv - \ref pgUNetUDP_SendFactor - \ref pgUNetUDP_Stat
Обмен построен на основе протокола UDP. Основная идея заключается в том, что каждый узел на порту равном своему ID посылает в сеть UDP-пакеты содержащие данные считанные из локальной SM. Формат данных - это набор пар [id,value]. Другие узлы принимают их. Помимо этого данный процесс запускает "получателей" по одному на каждый (другой) узел и ловит пакеты от них, сохраняя данные в SM. При этом "получатели" работают на одном(!) потоке с использованием событий libev (см. UNetReceiver). или каждый на своём потоке. Это определяется параметром unet_update_strategy.
По умолчанию при считывании используется unet_broadcast_ip (указанный в секции <nodes>) и id узла - в качестве порта. Но можно переопределять эти параметры, при помощи указания unet_port и/или unet_broadcast_ip, для конкретного узла (<item>).
unet_update_strategy - задаёт стратегию обновления данных в SM. Поддерживается два варианта:
В текущей реализации поддерживается возможность обмена по двум подсетям (Ethernet-каналам). Она основана на том, что, для каждого узла помимо основного "читателя", создаётся дополнительный "читатель"(поток) слушающий другой ip-адрес и порт. А так же, для локального узла создаётся дополнительный "писатель"(поток), который посылает данные в (указанную) вторую подсеть. Для того, чтобы задействовать второй канал, достаточно объявить в настройках переменные unet_broadcast_ip2. А также в случае необходимости для конкретного узла можно указать unet_broadcast_ip2 и unet_port2.
Переключение между "каналами" происходит по следующей логике:
При старте включается только первый канал. Второй канал работает в режиме "пассивного" чтения. Т.е. все пакеты принимаются, но данные в SharedMemory не сохраняются. Если во время работы пропадает связь по первому каналу, идёт переключение на второй канал. Первый канал переводиться в "пассивный" режим, а второй канал, переводится в "нормальный"(активный) режим. Далее работа ведётся по второму каналу, независимо от того, что связь на первом канале может восстановиться. Это сделано для защиты от постоянных перескакиваний с канала на канал. Работа на втором канале будет вестись, пока не пропадёт связь на нём. Тогда будет попытка переключиться обратно на первый канал и так "по кругу".
В свою очередь "писатели"(если они не отключены) всегда посылают данные в оба канала.
В текущей реализации поддерживается механизм, позволяющий регулировать частоту посылки данных для каждого датчика. Суть механизма заключается в том, что для каждого датчика можно задать свойство
Для возможности мониторинга работы имеются счётчики, которые можно привязать к датчикам, задав их для соответствующего узла в секции '<nodes>' конфигурационного файла.