реклама на сайте
подробности

 
 
2 страниц V  < 1 2  
Reply to this topicStart new topic
> "Слоеный" протокол, На Си++
kolobok0
сообщение Jul 26 2012, 12:08
Сообщение #16


практикующий тех. волшебник
*****

Группа: Участник
Сообщений: 1 190
Регистрация: 9-09-05
Пользователь №: 8 417



Цитата(AlexandrY @ Jul 24 2012, 20:59) *
...Делать из пакета объект довольно оригинально. ...


это Ваше виденье задачи... наверное оно идеально.... для вас...

для тех кто идеально не читал - повторюсь...

исходя из задачи.
пока лично я НЕ вижу задачи самой. Вижу абстрактные рассуждения о правильности использование плазменной пушки при выборах в губернаторы. Если всё и без неё прокатит - то нафига её тщить? А если есть прямая выгода - то да надо юзать...

а теоретические изыски - это я пас... я больше практик...

Сообщение отредактировал kolobok0 - Jul 26 2012, 12:12
Go to the top of the page
 
+Quote Post
XVR
сообщение Jul 26 2012, 12:22
Сообщение #17


Гуру
******

Группа: Свой
Сообщений: 3 123
Регистрация: 7-04-07
Из: Химки
Пользователь №: 26 847



Цитата(AlexandrY @ Jul 26 2012, 15:05) *
Ну да, за многоточиями в ваших аргументах можно спрятать любой смысл.
Но что-то много многоточий.
Заметьте, что все многоточия собранны в обработчиках уровней протокола, а не в самом объекте пакета (class Buffer)
Цитата
Это говорит от том, что объект-пакет изначально задумывался вами как протокольно зависимый, а... ?
Неа, в объекте-пакете (Buffer) не одной точки нету, не то что многоточий rolleyes.gif

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

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

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


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

Go to the top of the page
 
+Quote Post
Misile_Inc
сообщение Jul 27 2012, 09:27
Сообщение #18


Частый гость
**

Группа: Участник
Сообщений: 174
Регистрация: 30-08-11
Из: Санкт-Петербург
Пользователь №: 66 926



Спасибо, господа sm.gif Вашу дискуссию чрезвычайно приятно было наблюдать.
Я сделал из нее некоторые выводы и буду на основе этих выводов решать задачу.
Уточню, что действительно "каждый уровень протокола только добавляет свои заголовки и хвосты к данным".
Еще раз спасибо!
Go to the top of the page
 
+Quote Post
TigerSHARC
сообщение Jul 29 2012, 15:31
Сообщение #19


Знающий
****

Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195



Цитата(XVR @ Jul 25 2012, 12:45) *
Нет, но и на С можно писать в ООП стиле.


Можно подробнее про программирование на С в ООП стиле? желательно с примером
Go to the top of the page
 
+Quote Post
sasamy
сообщение Jul 29 2012, 16:23
Сообщение #20


Знающий
****

Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858



Цитата(TigerSHARC @ Jul 29 2012, 19:31) *
Можно подробнее про программирование на С в ООП стиле? желательно с примером


Предыдущую страницу слобо посмотреть ? пример
http://prex.sourceforge.net/src/S/252.html#L48
Go to the top of the page
 
+Quote Post
TigerSHARC
сообщение Jul 29 2012, 19:12
Сообщение #21


Знающий
****

Группа: Свой
Сообщений: 688
Регистрация: 4-09-09
Пользователь №: 52 195



Цитата(sasamy @ Jul 29 2012, 20:23) *
Предыдущую страницу слобо посмотреть ? пример
http://prex.sourceforge.net/src/S/252.html#L48

спасибо. Не могли бы вы немного объяснить в чём приемущества такого подхода(когда работаем с объектами на С)? пока не понятна сама суть. Просто все объекты кода описываются как структуры
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Jul 29 2012, 20:15
Сообщение #22


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(TigerSHARC @ Jul 29 2012, 22:12) *
спасибо. Не могли бы вы немного объяснить в чём приемущества такого подхода(когда работаем с объектами на С)? пока не понятна сама суть. Просто все объекты кода описываются как структуры


Приведен избитый пример структуры базового драйвера. Написан он так не потому, что хотели изобразить в стиле ООП, а потому что иначе не написать драйвер который может динамически подключаться к прикладным уровням.
Например к файловой системе может быть подключен драйвер NAND Flash, а потом отключен и подключен драйвер SD карты.
Но это показуха, поскольку чуть меняется тип периферии скажем нужен драйвер мультиплексированного канала к внешнему вспомогательному контроллеру, как такая структура драйвера уже не подходит и нужно рядом сочинять другой.
Т.е. полное отсутствие полиморфизма.
Другая проблема в том, что самые интересные функции драйвера скрыты в функциях ioctl и devctl.
Там вообще творится беспредел. Что точно эти функции делают можно понять исключительно просканировав все их исходники сверху донизу.
Это противоположность принципу наследования.
В нормальном ООП подходе места таким функциям нет. Вместо этого должно было быть наследование абстрактных методов от базового драйвера и дополнение уникальными методами.
Вместо этого же имеем ioctl с десятками (если не сотнями) типов аргументов. Браузеры кода можно выкинуть, это самые скверные места в операционках.
И после этого любители линукса говорят, что что-то могут сделать за пять минут. Ну-ну!
Go to the top of the page
 
+Quote Post
sasamy
сообщение Jul 29 2012, 22:17
Сообщение #23


Знающий
****

Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858



Цитата(AlexandrY @ Jul 30 2012, 00:15) *
В нормальном ООП подходе места таким функциям нет. Вместо этого должно было быть наследование абстрактных методов от базового драйвера и дополнение уникальными методами.


И на каждый такой уникальный метод создавать новый системный вызов ? ггг - типичный такой индусский подход sm.gif как все же прекрасно что не все болеют ООП головного мозга.

Сообщение отредактировал sasamy - Jul 29 2012, 22:51
Go to the top of the page
 
+Quote Post
Misile_Inc
сообщение Aug 2 2012, 14:59
Сообщение #24


Частый гость
**

Группа: Участник
Сообщений: 174
Регистрация: 30-08-11
Из: Санкт-Петербург
Пользователь №: 66 926



Может есть какая - нибудь книга, где бы автор рассматривал подходы к программированию протоколов?
А то каждый раз что-нибудь свое изобретаю.
Go to the top of the page
 
+Quote Post

2 страниц V  < 1 2
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 11th July 2025 - 09:14
Рейтинг@Mail.ru


Страница сгенерированна за 0.0146 секунд с 7
ELECTRONIX ©2004-2016