"Слоеный" протокол, На Си++ Опции

[Misile_Inc]

Здравствуйте! Есть протокол из трех уровней:

1. Физический (physical) - RS-232;
2. Канальный (data link);
7. Прикладной (application);

Уровни 2 и 7 имеют свои механизмы контроля ошибок (CRC, контрольная сумма), механизмы адресации и подтверждений.

Если с физическим уровнем все ясно, то остальные 2 уровня заставили меня задуматься.

Как вы считаете, как наиболее "Красиво" и "Правильно" организовать "Заворачивание" данных сначала в один протокол (Уровень 7), затем другой (Уровень 2) на языке C++ ?

Если не затруднит- с примерами / pattern.

Спасибо!

[Misile_Inc]

Ruslan1, я старался поставить вопрос несколько глубже: С++ в отличие от С поддерживает объектно-ориентированный стиль программирования. Возможно, в рамках идеологии ООП будет правильнее определить объекты, с помощью которых (над которыми) выполняются все операции.
Например, объект самого пакета для каждого уровня программирования.
А for(), do() или while() - это из области процедурного программирования. По идее, такие детали должны скрываться от пользователя в методах класса.

[kolobok0]

...в рамках идеологии ООП будет правильнее определить объекты, с помощью которых (над которыми) выполняются все операции...

прелесть ООП так-же состоит в том, что сущности(а после них и объекты) определяются исходя из задачи. Если Вам требуется поднять TCP/IP протокол - это одно решение. Если MODBUS - это второе..если что нить аля своё - третье... всё зависит от задачи. конкретной. а решать сферического коня в вакууме можно конечно же. Но внося или сразу оговаривая грани, за которые ходить табу. тем самым вырисовывая чего хочется, или чего можется в зависимости от опыта, виденья, ресурсов и т.д...

[AlexandrY]

прелесть ООП так-же состоит в том, что сущности(а после них и объекты) определяются исходя из задачи. Если Вам требуется поднять TCP/IP протокол - это одно решение. Если MODBUS - это второе..если что нить аля своё - третье... всё зависит от задачи. конкретной. а решать сферического коня в вакууме можно конечно же. Но внося или сразу оговаривая грани, за которые ходить табу. тем самым вырисовывая чего хочется, или чего можется в зависимости от опыта, виденья, ресурсов и т.д...

Делать из пакета объект довольно оригинально.
Но если подумать не очень умно.
Протоколам и так достаточно работы по формированию полей пакета, выделению памяти, контроля целостностии т.д.
А тут еще понадобится дополнительная работа по поддержанию актуальных переменных со свойствами пакета, членов класса.
Сразу встает проблема синхронизации,т.е. безконфликтные запись объектом уровня и чтение приложением при проходе пакетов через уровни OSI.
Если же у пакетов не будет свойств, то зачем из них делать объекты?

Думаю для RS232 достаточно сделать объект порта и объект подключения.
В объект подключения передавать объект фабрики пакетов.