Предположим, я создаю приложение модели клиент-сервер и разрабатываю свой протокол для взаимодействия клиента и сервера. Протокол приложения поверх TCP/IP. Вопрос в следующем: существуют ли какие-либо работы (книги, публикации), описывающие правила построения таких протоколов "по уму"?

Здравствуйте, <Аноним>, Вы писали:

А>Предположим, я создаю приложение модели клиент-сервер и разрабатываю свой протокол для взаимодействия клиента и сервера. Протокол приложения поверх TCP/IP. Вопрос в следующем: существуют ли какие-либо работы (книги, публикации), описывающие правила построения таких протоколов "по уму"?
О задаче раскажи.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, <Аноним>, Вы писали:

А>>Предположим, я создаю приложение модели клиент-сервер и разрабатываю свой протокол для взаимодействия клиента и сервера. Протокол приложения поверх TCP/IP. Вопрос в следующем: существуют ли какие-либо работы (книги, публикации), описывающие правила построения таких протоколов "по уму"?
WH>О задаче раскажи.

Небольшой Instant Messenger.

Здравствуйте, <Аноним>, Вы писали:

А>Небольшой Instant Messenger.
Гоняй XML.

Аноним 311 wrote:
> WH>О задаче раскажи.
> Небольшой Instant Messenger.
Бери какую-нибудь из реализаций XMPP (он же Jabber) и не занимайся фигней.

Здравствуйте, Cyberax, Вы писали:

C>Аноним 311 wrote:
>> WH>О задаче раскажи.
>> Небольшой Instant Messenger.
C>Бери какую-нибудь из реализаций XMPP (он же Jabber) и не занимайся фигней.

Я для примера сказал. Положим потом я буду писать другое приложение (базу данных, например). Есть по существу ответ?

Здравствуйте, WolfHound, Вы писали:

А>>Небольшой Instant Messenger.
WH>Гоняй XML.

какой интересный, а главное совершенно безсмысленный ответ

Здравствуйте, Аноним, Вы писали:

А>>>Предположим, я создаю приложение модели клиент-сервер и разрабатываю свой протокол для взаимодействия клиента и сервера. Протокол приложения поверх TCP/IP. Вопрос в следующем: существуют ли какие-либо работы (книги, публикации), описывающие правила построения таких протоколов "по уму"?
WH>>О задаче раскажи.

А>Небольшой Instant Messenger.

я бы на вашем месте не заморачивался бы с интерфейсом(пользовательским), а реализовал его как плагин например к миранде,
ну а реализацию сервера- если чем-то не устраивает множество имеющихся irc, icq, jabber и пр., то взял бы реализацию одного из них
и доимплементил необходимые фичи.

Здравствуйте, Sni4ok, Вы писали:

S>какой интересный, а главное совершенно безсмысленный ответ
Почему бессмысленный?

Здравствуйте, <Аноним>, Вы писали:

А>Я для примера сказал. Положим потом я буду писать другое приложение (базу данных, например). Есть по существу ответ?
Не существует протоколов в вакууме.
В каждом конкретном случае нужно смотреть по задаче.

Здравствуйте, WolfHound, Вы писали:

WH>Не существует протоколов в вакууме.
Существуют, только они сферические

You will always get what you always got
  If you always do  what you always did

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Sni4ok, Вы писали:

S>>какой интересный, а главное совершенно безсмысленный ответ
WH>Почему бессмысленный?

Потому что человек просит снабдить его литературой:

Вопрос в следующем: существуют ли какие-либо работы (книги, публикации), описывающие правила построения таких протоколов "по уму"?

А твой ответ похож на анекдот про генератор случайных чисел

You will always get what you always got
  If you always do  what you always did

Аноним 311 wrote:
>> > WH>О задаче раскажи.
>> > Небольшой Instant Messenger.
> C>Бери какую-нибудь из реализаций XMPP (он же Jabber) и не занимайся фигней.
> Я для примера сказал. Положим потом я буду писать другое приложение
> (базу данных, например). Есть по существу ответ?
По существу ответ будет, если будет вопрос по существу.

Пока его нет.

Здравствуйте, Аноним, Вы писали:

А>Предположим, я создаю приложение модели клиент-сервер и разрабатываю свой протокол для взаимодействия клиента и сервера. Протокол приложения поверх TCP/IP. Вопрос в следующем: существуют ли какие-либо работы (книги, публикации), описывающие правила построения таких протоколов "по уму"?

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

Есть книженция Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware. Сам не читал и по моему не совсем то что нужно, но оставляет впечатление чего то не очень глупого. Есть вроде некоторые рассуждения в классической книженции Стивенса "Сети TCP/IP, Том 3. Разработка приложений типа клиент/сервер для Linux/POSIX". Так в голову больше сходу ничего и не приходит...

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, <Аноним>, Вы писали:

А>>Небольшой Instant Messenger.
WH>Гоняй XML.
Если по Интернету то лучше со сжатием.

Здравствуйте, Aviator, Вы писали:

Предположим есть желание сделать аналогичную вещь.Как правильно и что всетаки почитать?
Задача такая:есть N клиентов и сервер. Клиенты вполне могут быть за файрволлами/натами(известно только что исходящие tcp-коннекты они делать могут)
каждый клиент может передавать видеопоток(скажем так), принимать команды от других клиентов, передавать голос,обеспечивать возможность чата. Также возможна ситуация когда надо с одно клиента рассылать видео на несколько других(и обеспечивать им возможность общатся голосом,в фулл дуплексе),могут файлами обмениватся.
Команды и видеопоток по возможности должны идти в реальном времени.Голос желательно бы тоже не задерживать.

Клиенты все на ADSL,максимум 512Kbit/s upload(download как минимум столько же)
планируется следующая схема-клиенты коннектятся к серверу, весь трафик идет через сервер(если надо-он размножает видеопоток,осуществляет микширование голосовых потоков).
Несколько TCP-сессий от одного клиента не очень желательно поднимать.
Саму реализацию думаю делать примерно так:
struct
{
int32 magic;//идентификатор пакета
int32 packet_type;//тип пакета:1-это фрагмент видеопотока,2-сообщение чата,etc
int32 len;//длина пакета
char * data;
}
очевидная проблема — голосовые пакеты должны идти с примерно одинаковой частотой, при том что битрейт видеопотока заранее не известен и он может прыгать, плюс передача файлов(с поддержкой докачки разумеется)....

Как наиболее правильно это все мультиплексировать?
Как я понимаю нужен некий планировщик, позволяющий по крайней мере на клиенте гарантировать что один поток данных не забьет другой.Как его наиболее правильно реализовать?Где можно примеры посмотреть?Идеи некоторые есть но как это делается наиболее правильно?

Поднимать несколько tcp-сессий (что в принципе возможно) и ставить QoS-метки как я понимаю большого смысла не имеет(их все равно будут игнорировать)?

p.s.подразумевается что на клиентских машинах торренты с ослами выключены (самим клиентом) в момент когда мы работаем.

A>Здравствуйте, Аноним, Вы писали:

А>>Предположим, я создаю приложение модели клиент-сервер и разрабатываю свой протокол для взаимодействия клиента и сервера. Протокол приложения поверх TCP/IP. Вопрос в следующем: существуют ли какие-либо работы (книги, публикации), описывающие правила построения таких протоколов "по уму"?

A>Ну хочется человеку поизобретать велосипед, а вы сразу набросились . На самом в данном вопросе велосипедостроение очень помогает осознать как всё работает и отбивает всяукое желание делать в дальнейшем всё самому.

A>Есть книженция Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware. Сам не читал и по моему не совсем то что нужно, но оставляет впечатление чего то не очень глупого. Есть вроде некоторые рассуждения в классической книженции Стивенса "Сети TCP/IP, Том 3. Разработка приложений типа клиент/сервер для Linux/POSIX". Так в голову больше сходу ничего и не приходит...

Здравствуй, dmitriy_k,

Вопросы ты очень правильные задаешь.
Я вот сам себе примерно представляю, в каком порядке протокол проектировать, но литературы никакой, увы, посоветовать не могу.
Так что если что-то найдешь — пиши сюда ссылки обязательно.
Посоветовать могу только порыться среди готовых протоколов на ietf.org.
Во-первых, народ решал уже очень большое количество задач. Так что есть шанс банально найти готовый RFC с подходящими свойствами. А реализовать существующий протокол гораздо лучше, чем придумать свой.
Во-вторых, можно почерпнуть идей для своего протокола.

Ну, а теперь, собственно, соображения:
1. Прежде всего нужно понять, какие будут потоки данных, и какие к ним предьявляются требования.
Например, что важнее — гарантия доставки или гарантия синхронности.
Для текста, как правило, важнее первое (отсюда вытекает выбор TCP как основы).

Для видео/аудио как правило важнее гарантия синхронности, потому может иметь смысл построить протокол на UDP и сделать так, чтобы он был малочувствителен к потере пакетов.

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

Топологию подключений нужно рассматривать достаточно аккуратно. Она зависит, в первую очередь, от соотношения ширины доступного канала и необходимой ширины полосы.
Я вот недавно читал про неких кренделей, которые хотят смешать youtube c p2p: сервер раздает видеоконтент, но клиенты умеют его кэшировать и раздавать друг другу. Так что если вы с товарищем смотрите одну трансляцию, то сервер будет отдавать вам в среднем один поток, а уже он будет делиться между вами не напрягая внешнюю сеть. И все это прозрачно, как стекло. Таким образом, парни хотят решить проблему доставки высококачественного контента по узкополосным сетям.

Здравствуйте, dmitriy_k, Вы писали:

_>Предположим есть желание сделать аналогичную вещь.Как правильно и что всетаки почитать?
_>Задача такая:есть N клиентов и сервер. Клиенты вполне могут быть за файрволлами/натами(известно только что исходящие tcp-коннекты они делать могут)
_>каждый клиент может передавать видеопоток(скажем так), принимать команды от других клиентов, передавать голос,обеспечивать возможность чата. Также возможна ситуация когда надо с одно клиента рассылать видео на несколько других(и обеспечивать им возможность общатся голосом,в фулл дуплексе),могут файлами обмениватся.
_>Команды и видеопоток по возможности должны идти в реальном времени.Голос желательно бы тоже не задерживать.

Если коснуться мира VoIP-коммуникаций, то там подобные задачи решаются следующим путем: контент и управляющие сигналы разносятся по разных протоколам вообще. Например, SIP — протокол для управления коннекциями (сигналинг), RTP — протокол для перегонки аудио/видео контента (медиа). В результате имеем две разных очереди сообщений, поэтому сигналам SIP не требуется дожидаться, пока будут обработаны поступившие до того RTP-датаграммы (ибо возможно, что они уже не нужны и могут быть отканселены).

Так что, либо пользуйтесь уже готовыми протоколами, либо на этой же идее создавайте свои. Оба потока (сигналинг и медиа) снабжаются timestamp-метками, на их основании синхронизируем прием/воспроизведение.

Здравствуйте, Sinclair, Вы писали:

S>Вопросы ты очень правильные задаешь.
S>Я вот сам себе примерно представляю, в каком порядке протокол проектировать, но литературы никакой, увы, посоветовать не могу.
S>Так что если что-то найдешь — пиши сюда ссылки обязательно.
S>Посоветовать могу только порыться среди готовых протоколов на ietf.org.
S>Во-первых, народ решал уже очень большое количество задач. Так что есть шанс банально найти готовый RFC с подходящими свойствами. А реализовать существующий протокол гораздо лучше, чем придумать свой.
S>Во-вторых, можно почерпнуть идей для своего протокола.
Пока что думаю либо свой писать поверх TCP, подвешивая свою синхронизацию и чередование фреймов
(недостаток-перепосылки TCP, которые в части случаев-аудиовидео данные-просто вредны)
либо-использовать чтото поверх TCP для всех служебных целей(и передачи файлов)
и RTP (http://www.cs.columbia.edu/~hgs/rtp/faq.html,RFC3550) для аудиовидео.
(опенсоурс реализаций RTP много).

Недостаток RTP — это UDP-протокол, соответственно теоретически имеем проблему с Symmetric NAT как минимум. Насколько она практически всплывает это вопрос отдельный(ответ хочется узнать -, учитывая что в моей задаче — в любом случае передача идет через сервер(у которого паблик IP,такой минимальный Session Border Controller).Хотя теоретически как я понимаю ничего не мешает запустить RTP поверх TCP (кроме того факта что получим минусы TCP)
Также — RTCP-траффик (не обязательно нужный) будет полосу кушать.

Плюсы RTP-малтикастинг (не работающий реально в интернет -)), отсутствие перепосылок, встроенная синхронизация(то что иначе потребуется реализовывать), из-за того что нету slow-start'а TCP можно сразу передавать на нужной скорости и в случае дропа-будет именно дроп а не ненужная(вероятно уже) перепосылка+падение скорости из-за slow-start. Какие еще плюсы интересно у него есть?

И насколько в реале критична проблема с файрволлами при использовании RTP(и того что на нем основано-SIP тотже как я понимаю RTP юзает)?

Здравствуйте, <Аноним>, Вы писали:


А>Если коснуться мира VoIP-коммуникаций, то там подобные задачи решаются следующим путем: контент и управляющие сигналы разносятся по разных протоколам вообще. Например, SIP — протокол для управления коннекциями (сигналинг), RTP — протокол для перегонки аудио/видео контента (медиа). В результате имеем две разных очереди сообщений, поэтому сигналам SIP не требуется дожидаться, пока будут обработаны поступившие до того RTP-датаграммы (ибо возможно, что они уже не нужны и могут быть отканселены).

А>Так что, либо пользуйтесь уже готовыми протоколами, либо на этой же идее создавайте свои. Оба потока (сигналинг и медиа) снабжаются timestamp-метками, на их основании синхронизируем прием/воспроизведение.
Как решается следующая задача:
если мы одновременно и файлы хотим передавать и аудиовидеопоток, и хотим чтобы передача файлов использовала полосу по остаточному принципу.В случае если делать свое поверх TCP то можно просто не посылать фреймы от файлов пока есть что передавать из аудиовидео-фреймов. В случае использования RTP — приоритет ему дать не получится. Что можно сделать кроме замера общей полосы пропускания до сервера(как?) и искуственного торможения скорости передачи файлов?Как я понимаю на системные функции по установки QoS мне расчитывать нечего?

Насколько реальны проблемы RTP с NAT?(предположим что одна из сторон у нас всегда на public IP,без NAT,а другая-вполне может быть даже за Symmetric NAT)
Используют ли RTP поверх TCP(а не UDP) вообще?

p.s.Реализацию RTP на базе ACE никто подсказать не может?