самый главный подводный камень это сама МСВС;)
с точки зрения разработки там самый главный косяк — это хитрая очистка памяти при вызове например delete или free(). При этом все что вы освободили будет перезаписано нулями. Так что не советую удалять большие куски памяти, лучше их попытаться переиспользовать.
Еще не маловажный косяк МСВС — это софт, который там стоит (во всяком случае, в той версии где работал я было так). Для разработки (вернее чтобы что-нибудь поправить, полностью под ней сидеть невозможно) лучше всего редактор в mc :), так как все остальное крайне старо (например KDevelop2).
Поддержка протокола на двух концах — не так и сложно. У нас было заведено, что мы проектируем протокол, железячники его внедряют, слегка правят под себя и уже мы его реализуем так как надо.
Нет. По опыту работы на оборонку (а именно из этого опыта написана статья) могу сказать что те комплексы которые мы разрабатывали (при мне один успешно сдали и второй начали) успешно вписывались в разработанные нами протоколы (понятно дело с подпиливанием, но крайне минимальным).
Видимо я не точно описал что я понимаю под «Вопрос-ответом». Я не имел в виду что оно должно вот так выглядеть. Я имел в виду что это некий упрощенный сильно ограниченный язык (как я писал выше похоже на упрощенный SQL). TCP относится к структурным (если вы внимательно читали, то видели заметку про возможные параметры переменной длины).
Также я вначале статьи указал что это чисто мое деление на типы, оно такое как его вижу я, поучавствовав в разработке сетевых и распределенных приложений.
1. Не совсем согласен. Все-таки те же AT-команды проще обрабатывать текстовым анализатором, нежели рассматривать их с точки зрения бинарных данных. По сути АТ-команды (не только они, но и аналогичные им протоколы) похожи на упрощенный SQL.
2. Я бы скорее посоветовал использовать резерв-поля на местах упаковки. Это дает возможность писать кросс-платформенно без кучи дефайнов под все компиляторы.
3. Я бы не стал категорично это утверждать. Можно смотреть с разных сторон.
4. Конкретный пример реализации привести не могу в силу некоторых причин, могу только сказать общую идею.
Предположим есть у нас сервер, обрабатывающий изображения. Он может принимать кучу разных изображений, с кучей разных параметров. Например для сжатого жпегом ему еще нужна степень сжатия, для индексного изображения нужна палитра, для географически-привязанных изображений нужна геоинформация (придумать можно много всего). Соответственно всяких разных комбинаций бесчисленное множество. Это можно описать как некий главный тег (который будет в себе содержать все параметры, которые общие для всех случаев), в его области данных будут лежать дочерние теги, такие как изображение (опять же если это индексное изображение, то у него будет дочерний тег — палитра), геопривязка, EXIF и так далее.
Оно все конечно и так бывает. Но при разработке каких-то сложных комплексов обычно сначала проектируют (с учетом всего что можно будет добавить), а только потом уже делают протокол. И опять же железяку (я имею в виду некий кастомный аппарат, который также входит в этот комплекс, например видео-камеру) очень тяжело понимать/отдавать универсальные протоколы.
тоже вариант, но ИМХО отдельная фаза протокола не так страшно (ведь она выполняется один раз за весь сеанс связи, а он может состоять из команд так 500).
Да, это один из способов реализации. Честно говоря мне удобнее пользоваться методами внутри одного класса (это позволяет в любой момент заменить разбор на любой другой просто заменой файла с классом), а обращение к разборщику реализовывать через базовый класс.
Это не всегда хорошо. Оно очень удобно, я не спорю. Но когда нам нужна скорость и возможность реализации протокола на железе… тогда все эти универсальные протоколы идут практически сразу лесом.
Подобные руководства никогда не писал, поэтому такие ошибки есть;) Постараюсь ответить в обсуждении поста на подобные непонимания.
Рукопожатие нам нужно, чтобы понять а туда ли мы вообще будем слать данные и жив ли сервер. То есть это элементарная проверка на валидность и адекватность получателя.
с точки зрения разработки там самый главный косяк — это хитрая очистка памяти при вызове например delete или free(). При этом все что вы освободили будет перезаписано нулями. Так что не советую удалять большие куски памяти, лучше их попытаться переиспользовать.
Еще не маловажный косяк МСВС — это софт, который там стоит (во всяком случае, в той версии где работал я было так). Для разработки (вернее чтобы что-нибудь поправить, полностью под ней сидеть невозможно) лучше всего редактор в mc :), так как все остальное крайне старо (например KDevelop2).
Поддержка протокола на двух концах — не так и сложно. У нас было заведено, что мы проектируем протокол, железячники его внедряют, слегка правят под себя и уже мы его реализуем так как надо.
Также я вначале статьи указал что это чисто мое деление на типы, оно такое как его вижу я, поучавствовав в разработке сетевых и распределенных приложений.
1. Не совсем согласен. Все-таки те же AT-команды проще обрабатывать текстовым анализатором, нежели рассматривать их с точки зрения бинарных данных. По сути АТ-команды (не только они, но и аналогичные им протоколы) похожи на упрощенный SQL.
2. Я бы скорее посоветовал использовать резерв-поля на местах упаковки. Это дает возможность писать кросс-платформенно без кучи дефайнов под все компиляторы.
3. Я бы не стал категорично это утверждать. Можно смотреть с разных сторон.
4. Конкретный пример реализации привести не могу в силу некоторых причин, могу только сказать общую идею.
Предположим есть у нас сервер, обрабатывающий изображения. Он может принимать кучу разных изображений, с кучей разных параметров. Например для сжатого жпегом ему еще нужна степень сжатия, для индексного изображения нужна палитра, для географически-привязанных изображений нужна геоинформация (придумать можно много всего). Соответственно всяких разных комбинаций бесчисленное множество. Это можно описать как некий главный тег (который будет в себе содержать все параметры, которые общие для всех случаев), в его области данных будут лежать дочерние теги, такие как изображение (опять же если это индексное изображение, то у него будет дочерний тег — палитра), геопривязка, EXIF и так далее.
Рукопожатие нам нужно, чтобы понять а туда ли мы вообще будем слать данные и жив ли сервер. То есть это элементарная проверка на валидность и адекватность получателя.