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

[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]

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

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