Создание сетевого протокола

atavin-ta · 13 фев 2009, 06:55

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

Naeel Maqsudov · 13 фев 2009, 09:44

К разработке любого нового протокола приступайте внимательно изучив спецификацию X.200 Международного союза электросвязи. "Эталонная модель взаимодействия открытых систем". Определите, насколько глубоко необходимо проработать каждый из 7 уровней эталонной модели для Вашего случая, и все ли они необходимы.

Определите, какова роль сервера? Только аутентификация+координация сессий(диалогов) (а данные передаются между клиентами напрямую) или и передача данных в том числе?

atavin-ta · 13 фев 2009, 10:00

Сервер может принимать и передавать данные и чат сообщения и управлять клиентами. Клиенты могут принимать и передавать данные и чат сообщения, но не могут управлять. Весь трафик идёт через сервер.

&quot писал(а):К разработке любого нового протокола приступайте внимательно изучив спецификацию X.200 Международного союза электросвязи. "Эталонная модель взаимодействия открытых систем".

Гед это взять?

Naeel Maqsudov · 14 фев 2009, 17:36

Как где взять? Разумеется на сайте Международного союза электросвязи.

http://www.itu.int/rec/T-REC-X.200-199407-I/en

Если Вы работаете в компании, которая зарегистрирована в ITU (там московских котнор, например, я нашел чуть меньше десятка), то Вы можете получить логин и пароль и скачать любую спецификацию.

Если нет, то надо порыться в инете. Наверняка где-то выложена. Кроме того по мотивам этой спецификации написано множество книг на русском языке. Точное название спецификации "X.200 : Information technology - Open Systems Interconnection - Basic Reference Model: The basic model". Также она известна под названием "OSI model" или "Эталонная модель взаимодействия открытых систем"

http://en.wikipedia.org/wiki/OSI_model

Naeel Maqsudov · 14 фев 2009, 21:16

OSI - это 7 уровней. Решите для Вашей задачи, какие из них Вам нужно реализовывать, а какие нет.
Првые 2 уровня OSI - это физический и сетевой. С физическим все ясно. Задача сетевого это адресация и маршрутизация. Думайте сами, годится ли для этих целей TCP/IP в чистом виде. (Неважно, что сам стек протоколов TCP тоже восходит к OSI)
Возможно, что вы захотите вместо IP адресов, уже поверх TCP использовать свою собственную адресацию. Например, для того чтобы отравитель мог указывать место назначения пакета (другого пользователя), а он шел транзитом через сервер или серверы (скорее всего серверов должно предусматриваться много, так как рано или поздно неизбежно возникнет вопрос о масштабировании и распределении нагрузки)
Т.е. возможно потребуется прикрутить к TCP дополнительные возможности по маршрутизации.

atavin-ta · 16 фев 2009, 04:23

&quot писал(а):Если Вы работаете в компании, которая зарегистрирована в ITU (там московских котнор, например, я нашел чуть меньше десятка), то Вы можете получить логин и пароль и скачать любую спецификацию.

Если бы в такой компании, то темы вообще бы не было. В том то и дело, что это самодеятельность.

&quot писал(а):Т.е. возможно потребуется прикрутить к TCP дополнительные возможности по маршрутизации.

TCP не меняется, всё вешается на него сверху. Прикладной пакет вкладывается в поле данных TCP или другого протокола того же уровня. Перенос с одного протокола на другой возможен, но только на сервере приложения. При этом информация извлекается из прикладных пакетов и заново в них упаковывается. Сервер приложения может быть только один. Сервер приложения ведёт таблицу соотвествия имен пользователей IP адресам соответсвующих клиентов в рамках их сетевых сеансов. Вся адресация только на основе имен пользователей. В списке имен пользователей постоянно присутсвует имя Server, не входящее ни в одну группу.

Naeel Maqsudov · 17 фев 2009, 10:34

Значит нужна своя адресация....
Больше того. Отправленный TCP-пакет может теоретически дойти до клиента по частям, или даже объединиться с соседним... Т.е. на самом деле нет гарантии, что если мы отправили 2 пакета по килобайту, то на другой стороне мы их получим в нужной последовательности как 2 пакета.
Теперь для каждого уровня OSI, начиная с сетевого изобретаем протокол. Каждый следующий расширяет возможности предыдущего.
2 уровень OSI - сетевой
Разрешаем 2 вида операций передачу пакета (TRANSMIT) и запрос повтора (RESENDQRY) Для каждой операции нужно от 1 до 4 разных примитивов. В данном случае нам нужны запрос и подтверждение для передачи, и, я думаю будет достаточно только запроса на повтор. Вот и первые пакеты:
TRANSMIT_RQ: [SRC][DST][SEQN][LEN][DATA]
TRANSMIT_RESP:[SRC][DST][LASTN]
RESENDQRY_RQ:[SRC][DST][N]
Для каждого поля нужно выбрать достаточную длину. Поле DATA должно быть переменной длины LEN байт
SEQN - это циклический счетчик, используемый приемником для контроля последовательности.
LASTN - это номер последнего полученного пакета
N - это номер начиная который надо переслать заново
Теперь надо думать, как получатель и приемник должны поступать в каких ситуациях. Какие таймауты должны быть между примитивами.

Пример диалога с потерей пакета №2
TRANSMIT_RQ[1]->
<-TRANSMIT_RESP[1]
TRANSMIT_RQ[2]->
TRANSMIT_RQ[3]->
<-TRANSMIT_RESP[3]
<-RESENDQRY_RQ[2]
TRANSMIT_RQ[2]->
<-TRANSMIT_RESP[2]

Отправитель должен иметь буфер передачи. Пекет лежит в буфере до таймаута или до прихода TRANSMIT_RESP

Это все в общих чертах. Думайте. Будет много частностей.

Следующий уровень - уровень транзакций.
Теперь смотрим, что такое DATA.
Думаем, нужны ли нам параллельно идущие транзакции между одним SRC и одним DST....

atavin-ta · 18 фев 2009, 09:46

Как обычно делается взаимоидентфикация клиента и сервера? Нужен ли получателю буфер приёма? Надо ли разделять буфера по информационным потокам? Где брать инфу по транзакциям?

Naeel Maqsudov · 18 фев 2009, 13:25

Буфер приема и буфер передачи нужен по любому.
Если передача\прием многопоточные, то каждому потоку свой буфер.
Даже если однопоточные, то все равно нужно прием и передачу осуществлять в отдельных нитях, так как само приложение может быть занято чем угодно, а принять очередной пакетик надо сразу же как только он пришел.
По транзакциям... не знаю, надо ли где-то брать инфу... сами решите какие возможности транзакций Вам нужны.
Может они вообще не требуются, а может будет достаточно только операций начела и завершения транзакции (чтобы отследить целостность большого количества данных), ну и индикации о завершении транзакции по инициативе оппонента, или по сбою протокола (т.е. по таймауту)

[DATA] на этом уровне тогда может выглядеть как

DLGSTART_REQ:[DLGID][TOUT][DATA2] - начало диалога №DLGID
DLGCONT_REQ:[DLGID][DATA2] - продолжение диалога
DLGEND_REQ:[DLGID][DATA2] - передача последней порции (возможно пустой)
DLGSTART_RESP:[DLGID] - подтверждение начала (хэндшейк)
DLGCANCEL_RESP:[DLGID] - отклонение диалога
DLGEND_RESP:[DLGID] - подтверждение завершения
DLGCANCEL_IND:[DLGID] - индикация о завершении диалога по таймауту неактивноcти ([TOUT] был определен в начале диалога)

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

Можно также от возможностей трензакций отказаться, и просто устанавливать отдеольное соединение для каждого диалога. Но тогда на предыдущем уровне у соединения должен быть уникальный идентификатор.

atavin-ta · 18 фев 2009, 13:38

&quot писал(а):По транзакциям... не знаю, надо ли где-то брать инфу... сами решите какие возможности транзакций Вам нужны.

Я хочу прочитать для того, чтобы не маяться велосипедами.

&quot писал(а):Если передача\прием многопоточные, то каждому потоку свой буфер.

Я имел ввиду не совсем потоки исполнения. Предположим два юзверя отправили файлы одному. Должен ли клиент создать два буфера приёма. А если один экземпляр прилады принимает два файла с одного адреса? Тот же вопрос относится и к буферам передачи. И должен ли сервак множить буфера при одновременном транзите разных файлов? Имеет ли смысл дробить на куски чат-сообщения? Надо ли в таких случаях явно выделять потоки исполнения, или можно ограничиться разделением времени с учётом того, что два пакета сетевого уровня всё равно не могут быть приняты или отправлены одновремено? Как разделить инофрмацию, которая не должна смешиваться, например куски двух файлов, возможно с совпадающими именами? И напоминая об идентификации. Протокол не ялвляется стандартным и работает под номером порта, который может быть использован другим разработчиком. Нужна защита от соединения с чужой прогой, использующей совпадающий номер порта. Как это обычно делается? Один велосипед на тему идентификиции у меня уже есть, но может быть есть готовые решения? Да и не знаю я, насколько плох или хорош мой вариант идентификации. Я отправляю с сервера пакет длиной 257 байт. Клиент ждёт, потом сравнивает. Если первый пакет с сервака не совпадает с эталонным, клиент сам отключается. Причём, время ожидания не ограничено, а сервак клиента не идентифицирует.