Здравствуйте, ZveN, Вы писали:

ZN>Привет!

<telepat mode on>
Система — биллинг. Задача — преобразовать байты в бабки. Для этого необходимо взять пакет из потока нетфлоу, определить кому принадлежит описываемый в пакете трафик и сколько этот трафик стоит. Потом можно снять с баланса пользователя стоимость этого трафика и записать этот трафик в статистику пользователя. Рабочие блоки из этого описания получаются следующие:
* приемник потока нетфлоу
* парсер пакетов
* идентификатор
* тарификатор
* баланс пользователя
Сервисные блоки можно предположить следующие:
* сплиттер — делит поток однородных данных на несколько подпотоков. Можно сразу выделить подтипы — интеллектуальные (деление потока по некоторому признаку) и простые (равномерное разделение потока).
* буфер — буферизирует поток. Можно обойтись и без них, но управление потоками данных будет уже сложнее. Подтипы — FIFO, LIFO, push/pull переходы и т.д.

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

Теперь к вопросу как параллелить. приемник -> буфер -> сплиттер -> ...
</telepat mode off>

Здравствуйте, 3BEP, Вы писали:

BEP>Здравствуйте, ZveN, Вы писали:

ZN>>Привет!

BEP><telepat mode on>
BEP> * буфер — буферизирует поток. Можно обойтись и без них, но управление потоками данных будет уже сложнее. Подтипы — FIFO, LIFO, push/pull переходы и т.д.
BEP></telepat mode off>

Буфер не нужен . Очередь входящих сообщений процесса-сплиттера прекрасно справится с буферизацией.

Здравствуйте, Gaperton, Вы писали:

G>Буфер не нужен . Очередь входящих сообщений процесса-сплиттера прекрасно справится с буферизацией.

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

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

Здравствуйте, Gaperton, Вы писали:

G>Вообще — есть один аспект, в котором проектирование для Эрланга сильно отличается от ОО проектирования — хотя в целом там все близко. Этот аспект — в Эрланге инкапсуляция функциональности и состояния не связана, как в ОО, а разделена. В ОО — у вас функциональность нарезана на классы вместе с состояние. В Эрланге — состояние инкапсулируется отдельно — при помощи процессов, а функциональность тоже отдельно — при помощи модулей.

G>В результате, для мало-мальского описания дизайна для Эрланга вам потребуется _две_ модели (в случае ОО в простых ситуациях хватает только одной — диаграммы классов, а здесь ни в каких не хватит одной). Первая — диаграмма функциональной связи модулей — кто про кого знает. Она — статическая, как диаграмма классов в ОО — только сильно проще, и нечего не говорит о стейте, только связность кода показывает. Вторая — диаграмма потока данных, которая показывает процессы и их взаимодействие. Это уже "динамическая" диаграмма, показывающая вам с одной стороны как завернут и инкапсулирован стейт, с другой — поток данных. При этом, один процесс Эрланга может в общем случае реализовывать группу сущностей из DFD — скажем, внутри него есть и storage, и несколько "процессов" из диаграммы.

А можно какойнибудь пример с картинками?

Здравствуйте, Critical Error, Вы писали:

CE>Здравствуйте, Gaperton, Вы писали:

G>>Вообще — есть один аспект, в котором проектирование для Эрланга сильно отличается от ОО проектирования — хотя в целом там все близко. Этот аспект — в Эрланге инкапсуляция функциональности и состояния не связана, как в ОО, а разделена. В ОО — у вас функциональность нарезана на классы вместе с состояние. В Эрланге — состояние инкапсулируется отдельно — при помощи процессов, а функциональность тоже отдельно — при помощи модулей.

G>>В результате, для мало-мальского описания дизайна для Эрланга вам потребуется _две_ модели (в случае ОО в простых ситуациях хватает только одной — диаграммы классов, а здесь ни в каких не хватит одной). Первая — диаграмма функциональной связи модулей — кто про кого знает. Она — статическая, как диаграмма классов в ОО — только сильно проще, и нечего не говорит о стейте, только связность кода показывает. Вторая — диаграмма потока данных, которая показывает процессы и их взаимодействие. Это уже "динамическая" диаграмма, показывающая вам с одной стороны как завернут и инкапсулирован стейт, с другой — поток данных. При этом, один процесс Эрланга может в общем случае реализовывать группу сущностей из DFD — скажем, внутри него есть и storage, и несколько "процессов" из диаграммы.

CE>А можно какойнибудь пример с картинками?

Нет, я свои только на бумаге рисовал. Но вообще — поищите по ключевым словам DFD (dataflow diagram), это очень простая диаграмма. Пример диаграммы связности модулей есть. Я не настаиваю на том, что его надо рисовать именно так — но, думаю, идея понятна. В данной задаче у меня нет процессов, поэтому нет и DFD.
http://gaperton.livejournal.com/7229.html