struct header
{
int type;
int size;
...
}
Проектирование сетевых протоколов
Сабж скорее для общалки, но тут больше шансов на ответ компетентных людей.
Интересуют любые ресурсы - книжки, статьи и сайты в интернете, которые могли бы помочь в разработке собственного протокола прикладного уровня. Суть в том, что не уверен, что такие существуют. Близко к теме нашел только http://habrahabr.ru/blogs/development/42940/
Если с текстовыми протоколами более-менее понятно, с бинарными возникает ряд вопросов. А фиксированные структуры лучше, или переменной длины? А как оно коррелирует с размером фрейма/пакета? А какие подвохи могут быть при передаче между 32 и 64 битными системами? Как вообще все это лучше организовать. А как лучше прикрутить сжатие/шифрование? и т.д. и т.п.
На самом деле, самому оно конечно можно все это продумать, но, боюсь получится тормознутое г-но, поэтому, хотелось бы сначала посмотреть, как оно нормально делается.
З.Ы. посмотреть исходники чего-нибудь конечно вариант, но, это скоре, на крайний случай. Ньюансов можно и не заметить.
Интересуют любые ресурсы - книжки, статьи и сайты в интернете, которые могли бы помочь в разработке собственного протокола прикладного уровня. Суть в том, что не уверен, что такие существуют. Близко к теме нашел только http://habrahabr.ru/blogs/development/42940/
Если с текстовыми протоколами более-менее понятно, с бинарными возникает ряд вопросов. А фиксированные структуры лучше, или переменной длины? А как оно коррелирует с размером фрейма/пакета? А какие подвохи могут быть при передаче между 32 и 64 битными системами? Как вообще все это лучше организовать. А как лучше прикрутить сжатие/шифрование? и т.д. и т.п.
На самом деле, самому оно конечно можно все это продумать, но, боюсь получится тормознутое г-но, поэтому, хотелось бы сначала посмотреть, как оно нормально делается.
З.Ы. посмотреть исходники чего-нибудь конечно вариант, но, это скоре, на крайний случай. Ньюансов можно и не заметить.
Цитата: ~ArchimeD~
А фиксированные структуры лучше, или переменной длины?
От задачи зависит. Обычно делают начальное слово, что было понятно с чего пакет начинается, потом сам пакет, потом его контрольная сумма, потом некое конечное слово.
Цитата: ~ArchimeD~
А какие подвохи могут быть при передаче между 32 и 64 битными системами?
От разрядности системы зависит только внутренняя архитектура приложения, что идет в сеть на зависит от системы.
Цитата: ~ArchimeD~
А как лучше прикрутить сжатие/шифрование?
OpenSSL на шифрование
gzip на сжатие
Цитата: oxotnik333
От задачи зависит. Обычно делают начальное слово, что было понятно с чего пакет начинается, потом сам пакет, потом его контрольная сумма, потом некое конечное слово.
Понятно что от задач. Но, какие-нибудь примеры или ЦУ не помешали бы. Я могу придумать отправлять сначала заголовок пакета, содержащий тип, размер и т.д., а затем - само тело. Но, например, в случас с UDP это не вариант. Да и вообще извращение.
Цитата: oxotnik333
От разрядности системы зависит только внутренняя архитектура приложения, что идет в сеть на зависит от системы.
Да ну? А я напишу
Код:
и буду отсылать/получать, вот оно уже будет зависеть :) На самом деле, этот момент впринципе самостоятельно предусматриваемый, есть long, и т.д., но вдруг есть тонкости?
Цитата: oxotnik333
OpenSSL на шифрование
gzip на сжатие
gzip на сжатие
Спасибо кэп. Я бы сделал 2 заголовка - один чисто размер шифрованого/сжатого сообщения + какой-нибудь тип кодирования. Второй, содержащий информацию о данных, прятал бы внутрь. Только вот как оно по человечески делается - не знаю.
Я вроде писвл ведь - что все это самостоятельно вполне реализуемо, и вопрос не "как?" а "как лучше?". Поэтому и возникло желание почитать какие-нибудь примеры/указания
Лень цитировать, по пунктам:
UDP и шифрование это вещи как бэ мало совместимые
Как измениться структура, которая выплевывется в сокет от разрядности?
Касаемо сжатия и шифрования: сначала пакет сжимаем, а потом через SSL сокет кидаем его. Какие проблемы то?
ЗЫ: и все таки что за задача то стоит? а то получается придумываем новый формат типа недавно обсуждаемого ZML, вкупе с Поповым.
UDP и шифрование это вещи как бэ мало совместимые
Как измениться структура, которая выплевывется в сокет от разрядности?
Касаемо сжатия и шифрования: сначала пакет сжимаем, а потом через SSL сокет кидаем его. Какие проблемы то?
ЗЫ: и все таки что за задача то стоит? а то получается придумываем новый формат типа недавно обсуждаемого ZML, вкупе с Поповым.
В общем, проехали. Никаких проблем нету и разговариваем не по делу.
Если будут какие-нибудь ссылки, вроде приведенной мной в первом посте, прошу поделиться.
Вообще, задача - сделать демона и remoteGUI для него. Пока, это все только изучение матчасти до того, как приступить непосредственно к нажиманию на кнопачки, т.е. никакого кода еще нету, есть только задумка. Поэтому, особых затыков пока не вижу, конкретных проблем нету. + Хотелось бы рассмотреть вопрос абстрактно, не вдаваясь в подробности, для типовых ситуаций, так сказать на будущее.
Если будут какие-нибудь ссылки, вроде приведенной мной в первом посте, прошу поделиться.
Вообще, задача - сделать демона и remoteGUI для него. Пока, это все только изучение матчасти до того, как приступить непосредственно к нажиманию на кнопачки, т.е. никакого кода еще нету, есть только задумка. Поэтому, особых затыков пока не вижу, конкретных проблем нету. + Хотелось бы рассмотреть вопрос абстрактно, не вдаваясь в подробности, для типовых ситуаций, так сказать на будущее.
От себя добавлю, что по идее прикладной протокол абстрагируется от нижележащих. Когда я писал реализацию SMPP, мне было всё равно, сколько байт в ethernet-фрейме. Прикладные пакеты можно передавать хоть как, главное - чтобы на выходе был тот же прикладной пакет. Другое дело, что его можно оптимизировать под конкретные задачи и даже оборудование, но в общем виде эта задача не решается. :)
Пример по SMPP, довольно познавательно: раз, два и три. Протокол привожу для примера, поскольку сам работал с ним. Так вот, там типы данных выбраны независимо от платформы исходя из минимальной достаточности.
Если развить мысль, то прикрутить шифрование проще всего было бы на уровне SSL и тогда можно было бы ничего не знать о том, как это работает. Можно было бы шифровать именно пакет с данными, но тогда реализация протокола шифрования будет полностью на твоей совести. Со сжатием ещё проще: прогоняешь пакет через gzip и пихаешь в сокет. На том конце преобразование обратное. Если планируется использовать UDP, на прикладном уровне придётся реализовать механизм обеспечения надёжности передачи. Например, если передавать потоковый звук, он не должен прерываться из-за потери одного пакета.
Пример по SMPP, довольно познавательно: раз, два и три. Протокол привожу для примера, поскольку сам работал с ним. Так вот, там типы данных выбраны независимо от платформы исходя из минимальной достаточности.
Если развить мысль, то прикрутить шифрование проще всего было бы на уровне SSL и тогда можно было бы ничего не знать о том, как это работает. Можно было бы шифровать именно пакет с данными, но тогда реализация протокола шифрования будет полностью на твоей совести. Со сжатием ещё проще: прогоняешь пакет через gzip и пихаешь в сокет. На том конце преобразование обратное. Если планируется использовать UDP, на прикладном уровне придётся реализовать механизм обеспечения надёжности передачи. Например, если передавать потоковый звук, он не должен прерываться из-за потери одного пакета.
Цитата: ~ArchimeD~
Вообще, задача - сделать демона и remoteGUI для него.
А чего выдумывать то протокол свой... чем HTTP не подходит?
Цитата: hardcase
А чего выдумывать то протокол свой... чем HTTP не подходит?
да в принципе подходит. только вот почему многие предпочитают выдергивать из поста отдельную фразу и отвечать только на нее? Сказал же,
Цитата:
Пока, это все только изучение матчасти до того, как приступить непосредственно к нажиманию на кнопачки, т.е. никакого кода еще нету, есть только задумка. Поэтому, особых затыков пока не вижу, конкретных проблем нету. + Хотелось бы рассмотреть вопрос абстрактно, не вдаваясь в подробности, для типовых ситуаций, так сказать на будущее.
Пока рассматриваю вопрос с разных сторон + на будущее, а поскольку обмен данными предполагается частый, хочется сократить траффик.
2Sanila_san:
спасибо большое, как раз то, что хотелось увидеть тут:)
спасибо большое, как раз то, что хотелось увидеть тут:)
[QUOTE="~ArchimeD~"]спасибо большое, как раз то, что хотелось увидеть тут[/QUOTE]Ну, просто тема больная, поэтому поделился именно этим. Документы не самые простые, протокол не самый популярный, но объясняется всё довольно подробно.
Итак, читаю книгу "Unix. Разработка сетевых приложений". Читаю там собственно то, о чем и спрашивал:
Проблемы, которые могут возникнуть при передаче двоичных чисел:
Проблемы, которые могут возникнуть при передаче двоичных чисел:
Цитата:
- Различные реализации хранят двоичные числа в разных форматах. Наиболее характерный пример - прямой и обратный порядок байтов.
- Различные реализации могут хранить один и тот же тип языка С по разному. Например, большинство 32-разрядных систем Unix используют 32 бита для типа long, но 64-разрядные системы обычно используют 64 бита для того же типа данных.
Предлагаемые пути решения:
- Передавать все численных значения как текстовые строки
- Явно определять формат поддерживаемых типов данных (число битов и порядок байтов). RPC используют именно эту технологию. В RFC 1832 описывается стандарт представления внешних данных (XDR), используемый пакетом Sun RPC