Транспорт: различия между версиями
User (обсуждение | вклад) |
User (обсуждение | вклад) |
||
Строка 17: | Строка 17: | ||
В целях оптимизации, ''Событие'' помещается во внутреннюю FIFO очередь ''Транспорта'' только тогда, когда по нему приходит значение, отличное от предыдущего. Это позволяет существенно сократить объем пересылаемых данных, и избежать отправку повторных значений. | В целях оптимизации, ''Событие'' помещается во внутреннюю FIFO очередь ''Транспорта'' только тогда, когда по нему приходит значение, отличное от предыдущего. Это позволяет существенно сократить объем пересылаемых данных, и избежать отправку повторных значений. | ||
+ | |||
+ | Отдельная пересылка индивидуального ''События'' так же была бы крайне не эффективной. Объем "полезных" данных по ''Событию'' был бы меньше или сравним с накладными расходами самого протокола. | ||
= Протоколы = | = Протоколы = |
Версия 01:11, 24 ноября 2019
Архитектура Транспорта DPA
Транспорт DPA отвечает за пересылку данных по событиям драйверов от DPA сервера в DPA хост.
Так как частота опроса оборудования может составлять 100-500 миллисекунд, количество снапшотов на один драйвер может составлять 10-20 штук, и на один DPA сервер может приходиться до 100 драйверов, то суммарная частота и объем пересылаемых данных между DPA сервером и DPA хостом может быть существенной. Поэтому Транспорт DPA использует механизмы оптимизации трафика.
Минимальной единицей обмена является Событие, которое содержит данные одного Снапшота или одного Состояния драйвера.
Как правило, новое Событие формируется при каждой операции чтения Снапшота, то есть при получении данных от оборудования, либо при каждой операции вычисления Состояния, если Событие отвечает за отправку данных по Состоянию.
Перед отправкой, Событие попадает во внутреннюю FIFO очередь Транспорта. Из очереди событие будет отправлено получателю - DPA хосту.
По различным источникам данных частота обновления может быть совершенно разной. Например, Событие, отвечающее за данные Нагрузки на шпиндель, будет получать новые значения текущей нагрузки при каждом чтении с оборудования. То есть частота изменения этих данных может быть очень высокой.
С другой стороны, События, отвечающие, например, за данные по Режиму работы или Корректору скорости подачи, будут получать обновленные данные не так часто.
В целях оптимизации, Событие помещается во внутреннюю FIFO очередь Транспорта только тогда, когда по нему приходит значение, отличное от предыдущего. Это позволяет существенно сократить объем пересылаемых данных, и избежать отправку повторных значений.
Отдельная пересылка индивидуального События так же была бы крайне не эффективной. Объем "полезных" данных по Событию был бы меньше или сравним с накладными расходами самого протокола.