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

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

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

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

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

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

Спасибо!

Ну например, (сугубо мое мнение) критерий красивости-правильности:
1. оно работает. надежно и на всем множестве оговоренных сочетаний железо-операционка-программа
2. Программист "со стороны" может рассказать, что и как сделано (понял зависимость между модулями программы) и согласен внести изменения в код (для небольшие косметические изменения) после одного часа ознакомления с исходными текстами.

А будете Вы делать цикл через for(), do() или while() - это неважно.

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

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

Все же, мне кажется, коня не такого уж и сферического я нарисовал: задача достаточно типовая- сплошь и рядом имеем связи между устройствами через несколько протоколов из модели OSI. Канальный уровень обеспечивает доставку сообщений и контроль целостности, уровень прикладной занимается решением самой задачи взаимодействия.
Дело лишь в том, что раньше платформы, с которыми я имел дело, не имели сред разработки с поддержкой ООП.

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

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

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

(Приблизительно так сделан стек TCP/IP в Linux'е, если я правильно помню)

А разве стек TCP/IP линукса сделан на C++?
Да, и какие вы свойства и методы припишите объекту пакета?
Метод послать самого себя? Или свойство дошел или не дошел? И зачем это нужно будет уровням, которые за этим вообще не следят?

В стеке TCP нет понятия пакета внутри реализации. Там есть несколько видов очередей.
Элементами тех очередей в свою очередь являются списки. А вот те списки уже описывают элементы пакета.
Т.е. пакеты могут никогда не представляться одной непрерывной областью памяти.
На физическом уровне пакеты посылаются DMA по связным спискам.
Но хуже того, каждый уровень может оставить в очереди копию фрагмента пакета для последующего быстрого переповтора. Один фрагмент может быть потом приписан нескольким пакетам.
Т.е. если создавать объекты пакетов, то возникнут неявные связи между этими пакетами, что вообще все ООП коту под хвост пошлет.
Вообщем для стека вроде TCP объекты пакетов лишь запутают реализацию.

Нет, но и на С можно писать в ООП стиле.
Получить доступ к содержимому. Добавить данные в начало. Добавить данные в конец.
Можно взять готовый контейнер - std::deque<char>. Он вполне соотвествует пакету (хотя и несколько избыточен из за своей универсальности)

Там есть нечто похожее - struct sk_buff с указателями
* @head: Head of buffer
* @data: Data head pointer
* @tail: Tail pointer
* @end: End pointer
data-tail - содержит собственно тело пакета
head-data - место для заголовков, которые могут добавить уровни протокола
и tail-end - место для добавления суфиксов опять же от обработчиков уровней протокола

Есть, и немало
Пакеты - слишком общее слово. Они бывают самые разные. Те, что в sk_buff - то же пакеты, я имел в виду именно их

Я не утверждал, что весь стек TCP построен на таких пакетах, я просто упомянул где я их видел

А вот подойдет ли этот метод ТС - это вопрос к нему. И он сильно зависит от собственно протоколов, которые ему надо реализовывать (это я тоже писал)

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

В sk_buff именно добавляются. Сами экземпляры sk_buff действительно собираются в списки, но это уже следующий уровень иерархии.
Может
Так, еще раз:
Мое предложение касается ТОЛЬКО случаев, когда каждый уровень протокола только добавляет свои заголовки и хвосты к данным, полученным из предыдущего уровня. Это сильно ограничивает применимость такого подхода, но все же имеет право на жизнь (может у ТС как раз такой стек протоколов).

Пример - UDP через Ethernet (без поддержки фрагментирования).

Объект, описывающий буфер, содержит память на 1 максимальный Ethernet пакет (около 1.5К). Сначала в него пишут пользовательские данные. Потом уровень UDP пишет заголовок UDP и CRC (не помню, в начале оно или в конце). Потом IP добавляет свой заголовок, потом Ethernet добавляет Ethernet заголовок и Frame CRC. Все, что получилось, отправляется в контролер.

Класс буфера будет иметь такой интерфейс:


Описание стека будет выглядеть так:

Что то вы запутались.
Говорите, что заголовки добавляет уровень протокола, а на самом деле метод реализуете в объекте пакета.
Получается объект пакета реализует весь протокол, тогда зачем уровни OSI?
Сразу пишите Packet.Send и придете к логическому концу.

Здесь вообще проявляется ошибочность мнения, что на C можно писать в стиле ООП.
Если бы писали на С-и, то действительно мелочь, кто добавляет заголовки, объект пакета или объект уровня. Перенес процедуру из одного модуля в другой и забыл.

В ООП же если вы пригрузили объект пакета несвойственной функциональностью, то вам придется впоследствии очень много переписывать.
Т.е. в реальном ООП ошибка модели объектов дорого стоит.
А в C-и она не стоит ничего, ибо это все умозрительные построения. За что я и люблю С-и

Да
Нет. В объекте пакета реализованна функциональность по добавлению произвольных данных, а собственно данные поставляет объект из стека протоколов
Пакет ничего о протоколах не знает
И метода Send у пакета нет.
Можно, и пишут
Я же написал пример интерфейсов. Где там 'несвойственной функциональность' у объекта пакета?

Это да

Угу, там где в С++ приходится переписывать реализации классов, в С приходится писать программу заново, т.к. после исправлений в стиле 'умозрительные построения' часто концов не может найти сам автор

а как же модели драйверов, VFS и пр, или например
http://en.wikipedia.org/wiki/GLib

Сообщение отредактировал sasamy - Jul 26 2012, 09:54

Ну да, за многоточиями в ваших аргументах можно спрятать любой смысл.
Но что-то много многоточий. Это говорит от том, что объект-пакет изначально задумывался вами как протокольно зависимый, а... ?

Но изменение в пакетах некоторых атрибутов в теле тоже широко распространено. Например номер пакета при ретрансмитах или изменение приоритета для продвижения в очереди на передачу. Почему нет метода push_middle ?

Потом, понятие пакета появляется только на некотором низком уровне протоколов. А так вообще пользователь работает с потоком или, например, со списками пар [имя]=[значение]. Навязывание пакета как изначальной единицы обмена сильно ограничивает функциональные возможности протокола.
Пакетизация реализоваться должна по необходимости где-то на внутренних уровнях. А до того данные должны идти единой очередью.
Опять же имеет значение синхронный или асинхронный способ взаимодейстивя со стеком предусматривается.