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

[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 построен на таких пакетах, я просто упомянул где я их видел

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

[AlexandrY]

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

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

[XVR]

Данные не добавляются в начало/конец, вместо этого пересобираются списки описывающие пакет.

В sk_buff именно добавляются. Сами экземпляры sk_buff действительно собираются в списки, но это уже следующий уровень иерархии.

У пакетов может и середина на ходу подменяться, скажем при шифрации в тоннелях.

Может

Ну и где, в каких объектах вы будете хранить только заголовки или исходные незашифрованные фрагменты еще не назначенные пакетам?

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

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

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

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

Код

class Buffer {
public:

void* get_image(size_t &size); // Return accumulated so far image
void push_front(const void* image, size_t size); // Prepend data in buffer with 'image'
void push_back(const void* image, size_t size); // Append 'image' to data in buffer
};

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

Код

class StackItem {
StackItem* next;
public:
StackItem(StackItem* n=NULL) : next(n) {}

virtual void process(Buffer&) =0;
void call_next(Buffer& b) {next->process(b);}
};


class UDP : public StackItem {
public:
UDP(StackItem* n) : StackItem(n) {}

virtual void process(Buffer& b)
  {
   b.push_front( ... UDP header ...);
   b.push_back( ... CRC ... );
   call_next(b);
  }
};

class IP ...
class EthPkt ...

class EthernetMAC : public StackItem {
public:

virtual void process(Buffer& b)
  {
   EthernetSendBuffer(b.get_image()):
  }
};

void main()
{
  EthernetMAC e_mac;
  EthPkt e_pkt(&e_mac);
  IP ip(&e_pkt);
  UDP udp(&ip);

  Buffer b;
  b.push_back(...); // Data to send
  udp.process(b);
}

[AlexandrY]

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

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

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

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

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

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