Проектирование сетевых протоколов

Если не копипаст, то отличная статья!

Прошу прощения, «AT-команды», ATZ — это уже команда (сброс модема, кажется).

Очень интересная справка (всё же не совсем статья). Всё разжевал «для нубов», это несомненный плюс.
Будет супер если ты будешь писать мини-цикл статей про различные типы проектирования. Хотя бы про данные.
Хотелось бы всё же почитать про проектирование протоколов на доступном языке. Было бы куда отсылать интересующихся и не очень наученных по данной теме.

Весьма интересная статья.
Автору посоветую рассмотреть серию протоколов Modbus, весьма популярный в АСУиТП набор протоколов, хорошо задокументированный. Правда есть у него один «бзик», порожденный его массовостью. Почти каждая контора, которая выпускает на рынок желехку поддерживающую этот протокол, говорит что Modbus то стандартный, но вот мы чуток его под себя приспособили.
Наиболее частые приспособления — введение новых типов команд (как правило вместе с новыми типами данных), ну такие изменения еще как-то предусмотрены в документации на протокол, но иногда новаторы изменяют значения зарезервированных команд; изменение правил упаковки данных (тот самый порядок следования байт); изменение привязки типов к диапазонам адресов — ну тут вольница, в принципе, я уже даже не обращаю на такие вещи внимания.

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

Перенес пост в блог «разработка»

Очень понравилось, хорошо написано. Хочется узнать о шифровании\ дешифровании данных и защите протоколов. Автору большое спасибо!

ну надо как минимум помянуть названия N+1 реализаций RPC, так и не захвативших мир =)
а в плане тэговых структур модный нынче гугловый protobuf и различные сериализаторы объектов встроенные в языки.

Я как-то писал протокол обмена данными для системы распределенных вычислений. Протокол должен был обеспечивать связь клинета(вычислителя) и центра вычислений(координатор действий и сборщик результатов).
У меня протокол был в виде классов с примерно таким интерфейсом
class proto_command {
...
virtual void * pack() const = 0;
};

class proto_hello: public proto_command {
struct {
const char[5] = "Hello";
} cmd_struct;

char * pack();
char * unpack();

};


Все было сложнее, но суть, думаю, понятна — каждая команда в отдельном классе.
Вот, собственно, функции упаковки и распаковки спасали от всяких переворачиваний. Как пакуем, так и распаковываем.

p.s. Не писал на плюсах уже много лет, так что если синтаксически что-то не так — извиняйте =)

> Это означает, что размер любой структуры всегда будет кратен 4 (если размер структуры был 14, то в конец
> допишутся 2 ничего не значащих байта и размер станет равен 16).

Дополню: не обязательно в конец. Если внутри структуры идут, например, байтовые данные, они тоже выравниваются. Идея в том, что каждое поле структуры должно быть варавнено на 2/4 и т. д. байта.

Однозначный плюс этому обзору, всё понятно и доходчиво разложено по полочкам. Автору спасибо, была бы возможность в карму бы добавил плюс. Жду с нетерпением новых статей.

ээ, могу ошибаться, но имхо, одним из первых важных моментов в описании сетевого протокола будет хотя бы упоминание свойств и возможностей нижележащего протокола, таких как есть ли гарантированная доставка, коррекция ошибок и т. д. простой пример — реализация того, что описывает автор на основе удэпэ и тисипи будет существенно отличаться.

Не понял, «Вопрос-ответ» не может использовать в качестве упаковки дынных структыры или теги? Зачем смешиваете логику работы и представление данных? Разе в HTTP 1.1. Get+XML это не «вопрос-ответ» с тегами? Это тоже самое что говрить, что обощи бывают трёх видом — красные, круглые и вкусные.
Короче говоря трудности с терминологий и какая-то мешанина.

Тогад уж пишите, что по логике обмена протоклы бывают:
1) «ЗАпрос-ответ» (я не «ВОпрос-ответ»), кода одна из сторон обмена (ведомая/slave) может передавать данные только по запросу второй (ведущей/мастер/host). Это самый простой с точки зрения реализации тип обмена, но недостаком имеет длительное время реакции при большой кол-во аобнентов в сети (пока всех опросишь).
2) асинхроные, когда обе стороны равноправны и могут начать обмен в любой момент времени. Достоинством имеет минимальное время реакции, но необходимо решать вопросы синхронизации состояний у абонентов и коллизий при некоторых физический протоколах.
3) ВременнЫе окна (Time frames). Фактический смешаный типа, когда одна из сторон управляет обменом и может предоставлять право обмена другим абонентам и/или группам. Очень популярный тип, широко применяется при радиобмене — от GSM до WiFi. Позволяет сохранить приемлемое время реакции и не потерять возможность управления сетью. Но всё равно нужно решать проблеммы коллизий для некоторых физических уровней.

Далее протоклы подразделяются по типу синхронизации потока данных:
1) Полностью асинхронные протоклы. Целиком зависят от надёжности нижележащего уровня. При искажении данных нсами воосстановить синхронизацию не могут. Соответсвенно могут работать поверх TCP/IP, но не на обычном последовательном порту.
2) Протоколы с временнОй синхронизацией. Синхронизируются по паузам между пакетами, либо возлагают процедуру синхронизации на протоколы более низких уровней.
3) Самосинхронизирующиеся протоколы. Как правило начало каждой посылки (пакета/кадра/фрейма) обозначается специальным маркером, который не может встречаться в данных, что реализуется, обычно, при помощи т. н. байт-стафинга или бит-стафинга. В простейшем случае маркером может служить символ перевода строки. В случае ошибки в потоке данных, будет потерян один блок данных, а со следующего блока синхронизация будет восстановлена. Самая популярная группа протоколов. (Большинство промышленных протоколв).

Протоколы могут иметь контроль целостности данный и/или коррекцию ошибок или не иметь.

1) Если протокол обладается контролем целостности (обычно при помощи контрольной суммы дла каждого блока данных), то принимающая сторона может определить факт искажения данных. (IP, UDP, TCP)
2) Если протокол обладает возможностью коррекции ошибок, то ошибки и искажения данных в некоторых пределах могут быть скорректированы принимающией стороной на основании избыточной информации передавайемой совместно с данными. (Форматы записи компкат и жёстких дисков, некоторые промышленные протоколы).
3) В противном случае, протокл полнотсью полагется на нижележащий уровень и в случае искажения данных, принимающая стороная об этом не узнает (например — HTTP).

Кроме того протоколы подразделяются по типу реакции на искажение данных:
1) Протоколы без повторов передачи. Полностью полагаются на нижелижещие уровни. В случае повреждения данных, передающая стороная не узнает, что данные не приняты.
2) Требующие подтверждения протоколы. Каждая порция данных требует подтверждения от принимающией стороны. В качестве развития, подтверждаться может не один пакет, а группа (как в TCP/IP). Если подтверждение не принято или получаен сигнал, о том, что данные приняты не верно, то передача может быть пвторена повторяется (а могут быть, как в UDP, просто отброшены неправильные данные).
3) Различные смешаные варианты. Например, данные могут повторяться с некоторым интервалом, в надежде, что одна из копий будет принята правильно.

Ещё можено делить протоклы по типу установления связи:
1) Перед началом сеанса связи происходит «рукопоажатие» (handshake) во время которого стороны договариваются о способе обмена данными и о возможности начала сеанса данных. Например — USB, IP, TCP.
2) «рукопожатие» не происходит — каждая сторона сразу готова принимать и передавать данные. Например UDP и множество промышленных протоколов.

Ваше деление по типу представления даных крайне не корректно. «структуры» обязательно имеют некий маркер позволяющий определить что это за структура и что за данные в ней. Для «теговых» протоколов таким маркером является теги. Вот и всё различие. Каким образом «вопрос-ответ» может быть типом представлния данных не понятно.

все плохо, хабр уже не тот, галактико вопасносте

1. Фактически нет разницы между тем, что вы называете «Вопрос-ответ» и «структуры». И то, и другое — обмен бинарными данными, просто формат может предполагать переменную длину структуры или фиксированную.

2. «Следовательно нам необходимо позаботиться об одинаковом значении этого параметра на сервере и клиенте.» Это жуткий совет, который скорее всего печальным последствиям. Нельзя ставить себя в зависимость от среды программирования. Если вы передаете бинарные данные, строго описывайте их в протоколе, а в программе соответствующие структуры обьявляйте с __attribute__((__packed__)) (это для gcc, естессно)

3. Как уже было сказано выше, про стадию рукопожатия — это лишнее. Путается красное с кислым. Есть понятие сценария взаимодействия, т. е. кто, как и когда посылает команды; в каком порядке; что происходит, если одна из сторон не отвечает и т. д. И еще отдельно есть понятие формата передачи данных: бинарные структуры, xml-блоки или нечто среднее; использование шифрования; повышение помехоустойчивости; архивирование. В общем, темы хотя и сильно взаимосвязаны, то стоило бы их отличать.

4. Что такое «теги+структуры» я не понял, чесно говоря. Сразу несколько ассоциаций появилось. Интересно было бы на пример реализации посмотреть, тогда, видимо, стало бы яснее.

По приведённым описаниям разница между «Вопрос-ответ» и «Структуры» только в том, что один символьный, а другой — бинарный. В принципе, AT-команды модема вполне подпадают под описание структуры

смещение и длина некоторых полей могут также задаваться в структуре, но в основном используются изначально заданные смещения

Фразы «легко обрабатываются» и «не очень высокая скорость обработки» мне кажутся взаимоисключающими. Видимо, первая фраза подразумевает наличие готовых парсеров. Это стоит переформулировать более явно.

Ниочем

См. также savingtheinternetwithhate.com/design.html

Секция «Protocol Overview (opinions for all)»

«Классика» любых проектов предполагает наличие ЗАДАЧИ (ее не увидел), которая диктует ТРЕБОВАНИЯ (их тоже не видно), ограничения, допущения, условия, требуемые ресурсы. Вывод напрашивается: о чем же публикация.
Задача решена или нет? Как узнать? Если решена, то с каким качеством?
Вопросы можно продолжать…