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

[Misile_Inc]

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

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

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

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

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

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

Спасибо!

[XVR]

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

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

[AlexandrY]

В стеке каждый объект-протокол принимает экземпляр объекта-пакета, добавляет к нему свой пролог и эпилог и передает по стеку дальше

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

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

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

[XVR]

А разве стек TCP/IP линукса сделан на C++?

Нет, но и на С можно писать в ООП стиле.

Да, и какие вы свойства и методы припишите объекту пакета?

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

В стеке TCP нет понятия пакета внутри реализации.

Там есть нечто похожее - 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 объекты пакетов лишь запутают реализацию.

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

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

[TigerSHARC]

Нет, но и на С можно писать в ООП стиле.

Можно подробнее про программирование на С в ООП стиле? желательно с примером

[sasamy]

Можно подробнее про программирование на С в ООП стиле? желательно с примером

Предыдущую страницу слобо посмотреть ? пример
http://prex.sourceforge.net/src/S/252.html#L48

[TigerSHARC]

Предыдущую страницу слобо посмотреть ? пример
http://prex.sourceforge.net/src/S/252.html#L48

спасибо. Не могли бы вы немного объяснить в чём приемущества такого подхода(когда работаем с объектами на С)? пока не понятна сама суть. Просто все объекты кода описываются как структуры

[AlexandrY]

спасибо. Не могли бы вы немного объяснить в чём приемущества такого подхода(когда работаем с объектами на С)? пока не понятна сама суть. Просто все объекты кода описываются как структуры

Приведен избитый пример структуры базового драйвера. Написан он так не потому, что хотели изобразить в стиле ООП, а потому что иначе не написать драйвер который может динамически подключаться к прикладным уровням.
Например к файловой системе может быть подключен драйвер NAND Flash, а потом отключен и подключен драйвер SD карты.
Но это показуха, поскольку чуть меняется тип периферии скажем нужен драйвер мультиплексированного канала к внешнему вспомогательному контроллеру, как такая структура драйвера уже не подходит и нужно рядом сочинять другой.
Т.е. полное отсутствие полиморфизма.
Другая проблема в том, что самые интересные функции драйвера скрыты в функциях ioctl и devctl.
Там вообще творится беспредел. Что точно эти функции делают можно понять исключительно просканировав все их исходники сверху донизу.
Это противоположность принципу наследования.
В нормальном ООП подходе места таким функциям нет. Вместо этого должно было быть наследование абстрактных методов от базового драйвера и дополнение уникальными методами.
Вместо этого же имеем ioctl с десятками (если не сотнями) типов аргументов. Браузеры кода можно выкинуть, это самые скверные места в операционках.
И после этого любители линукса говорят, что что-то могут сделать за пять минут. Ну-ну!