search

Zemetrans / CProtocol

0 stars 0 forks source link

Описание протокола #3

Open Zemetrans opened 8 years ago

Zemetrans commented 8 years ago

Добрый вечер!

Выложу пока текстовую версию описания протокола (диаграмму последовательности нарисую позже, надо разобраться как там условия делать). Пока есть два небольших вопроса: 1) У меня в описании есть "Фрейм обрыва связи". Правильно я понимаю, что Error Frame генирируются самой шиной? Если да, тогда, наверное, не стоит делать делать отдельный кадр ошибки для AJ, проще отфильтровывать обычный Error Frame.

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

Описание

Фреймы: 1) Фрейм начала передачи серии Состоит из двух байтов. Первый байт →код начала передачи серии + контрольная сумма (crc 4) серии, второй байт — количество фреймов серии 2) Информационный фрейм Первый байт — порядковый номер фрейма, остальные байты — полезная нагрузка. 3) Фрейм перезапуска серии Первый байт → код перезапуска серии 4) Фрейм обрыва связи Error frame. Первый байт — AJ_MAJIC 5) Фрейм принудительного завершения (?) Первый байт — код принудительного завершения

Протокол установления связи: 1) Клиент отправляет в сеть кадр с полями ID = ID клиента, Дополнительное поле ID = 0x3fff, в первом байте данных указывает AJ_MAJIC = 0x0B. 2) Сервер при получении кадра, указанного в пункте 1, отправляет в сеть кадр в котором ID = ID сервера, Дополнительное поле ID = ID клиента, в двух байтах данных находится ID текущей сессии клиента. 3) Клиент при получении кадра указанного в п.2 сохраняет ID текущей сессии. Далее каждое дополнительное поле ID клиента будет содержать ID текущей сессии.

Передача: 1)Клиент → Сервер

Клиент 1) Клиент отправляет серверу фрейм начала передачи серии. 2) Клиент посылает серверу серию 3) Если во время отправки серии клиент получил фрейм перезапуска серии, то клиент прерывает передачу серии и вновь отправляет серверу фрейм начала передачи серии (возвращается на п1) 4) Если во время отправки серии клиент получил фрейм принудительного завершения, то передача данных прекращается. 5) Если во время отправки серии клиент получил фрейм начала передача серии, то клиент переходит в режим передачи Сервер → Клиент, текущий процесс передачи серии прекращается. 6)Если все информационные фреймы успешно переданы, клиент прекращает передачу. Если после завершения передачи информационных кадров клиент получается кадр перезапуска серии, то этот кадр отбрасывается.

Сервер 1) Сервер слушает канал передачи данных. 2) Если сервер получает от клиента кадр начала передачи серии, то сервер выделяет место под информацию (информационная загрузка фреймов + счётчики) и инициализирует дескриптор приёма серии. 3) При получении информационного кадра счётчик кадров, соответствующего дескриптора уменьшается на единицу. 4) Если очерёдность получения кадров нарушена, то сервер отсылает клиенту фрейм перезапуска серии и заново принимает серию. (возвращение на п3) 6) Если счётчик количества кадров становится равным нулю, то сервер проверяет контрольную сумму серии. Если контрольно сумма не совпадает, то получение серии считается неуспешным, иначе серия считается успешно полученной. 7) Если сервер получает из сети фрейм обрыва связи, то получение всех активных серий считается неуспешным. 8) Если сервер получает от клиента фрейм принудительного завершения, то получение серии считается неуспешным, поток прекращает свою работу. 9) Если сервер получает от сервера фрейм начала передачи серии, а кадры предыдущей серии получены не полностью, то предыдущая серия прерывается. Начинается приём новой серии (возвращение на п. 2) 10) Если счётчик количества кадров серии не стал равным нулю или не пришло ни одного кадра за timeout времени, то связь считается разорванной, получение серии неуспешным.

2) Сервер → Клиент

Сервер 1) Сервер инициализирует дескриптор передачи серии. 2) Сервер отправляет клиенту фрейм начала передачи серии. 3) Сервер посылает клиенту серию. 4) Если во время отправки серии сервер получил фрейм перезапуска серии, то клиент прерывает передачу серии и вновь отправляет клиенту фрейм начала передачи серии (возвращается на п2) 5) Если во время отправки серии сервер получил фрейм принудительного завершения, то передача данных прекращается. 6) Если во время отправки серии сервер получил фрейм начала передача серии, то сервер переходит в режим передачи Клиент → Сервер, текущий процесс передачи серии прекращается. 7)Если все информационные фреймы успешно переданы,сервер прекращает передачу. Если после завершения передачи информационных кадров сервер получается кадр перезапуска серии, то этот кадр отбрасывается.

Клиент 1) Клиент слушает канал передачи данных. 2) Если клиент получает от сервера кадр начала передачи серии, то клиент проводит инициализацию счётчика количества кадров серии, выделяет место под информационную загрузку. 3) При получении информационного кадра счётчик кадров уменьшается на единицу. 4) Если очерёдность получения кадров нарушена, то клиент отсылает серверу фрейм перезапуска серии и заново принимает серию. (возвращение на п3) 6) Если счётчик количества кадров становится равным нулю, то сервер проверяет контрольную сумму серии. Если контрольно сумма не совпадает, то получение серии считается неуспешным, иначе серия считается успешно полученной. 7) Если клиент получает из сети фрейм обрыва связи, то получение серии считается неуспешным. 8) Если клиент получает от сервера фрейм принудительного завершения, то получение серии считается неуспешным, поток прекращает свою работу. 9) Если клиент получает от сервера фрейм начала передачи серии, а кадры предыдущей серии получены не полностью, то предыдущая серия прерывается. Начинается приём новой серии (возвращение на п. 2) 10) Если счётчик количества кадров серии не стал равным нулю или не пришло ни одного кадра за timeout времени, то связь считается разорванной, получение серии неуспешным.

fulcrum7 commented 8 years ago

Сервер: 2) а если сервер не успел подготовиться? 4) опиши ситуацию приёма пакетов в другом порядке

fulcrum7 commented 8 years ago

Magic_aj - почему бы не 8 байт?

fulcrum7 commented 8 years ago

ID сессии - 18 бит, какие из 2 байт?

fulcrum7 commented 8 years ago

Открытый вопрос, мы хотим поддерживать передачу и приём одновременно? Как мы отличаем фермы управления от данных? 1 байт- описание типа фрейма? Сколько бит

fulcrum7 commented 8 years ago

Что там с потоками? Жень, в фине нет их наверное, а в роутере? Это надо биглуп делать с состояниями?

jenisov commented 8 years ago

да, потоки нельзя использовать.

обработку ошибок CAN тоже.

22 марта 2016 г., 0:13 пользователь fulcrum7 notifications@github.com написал:

Что там с потоками? Жень, в фине нет их наверное, а в роутере? Это надо биглуп делать с состояниями?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Zemetrans/CProtocol/issues/3#issuecomment-199489656

jenisov commented 8 years ago

набросал таблицу определений и протокол установки сессии

http://chopapp.com/#lye79fyf

jenisov commented 8 years ago

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

jenisov commented 8 years ago

потом может быть добавим фрейм завершения сессии, но это улучшение только

jenisov commented 8 years ago

предлагаю описать наш протокол в той же схеме, что и в http://chopapp.com/#lye79fyf

например:

client sends AJCAN chunk
==========================

client-n sends chunk start packet:
       ID:
           <CID>
       EID:
           <SessionID>
       DATA:
           <AJCAN_MAGIC>:4bytes
           <num packets in the chunk>:4bits
           <CRC of all bits in chunk>:12bits
           <chunk data size in bytes>:1byte
           <chunk data[0]>

client-n sends chunk data:
       ID:
           <CID>
       EID:
           <SessionID>
       DATA:
           <chunk packet number>:4bits
           <chunkdata[n..n+6]>:7bytes
Zemetrans commented 8 years ago 
2) а если сервер не успел подготовиться?

Я немного не понял, надо ли вводить ожидание подтверждения готовности к приёму или нет?

jenisov commented 8 years ago

нет, не будем усложнять

сервер обязан быть всегда готовым от сбоев должны защитить повторы попыток (получения сессии или ARDP пакетов)

30 марта 2016 г., 21:22 пользователь Zemetrans notifications@github.com написал:

2) а если сервер не успел подготовиться?

Я немного не понял, надо ли вводить ожидание подтверждения готовности к приёму или нет?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Zemetrans/CProtocol/issues/3#issuecomment-203565990

Zemetrans commented 8 years ago

http://chopapp.com/#tvqv0uln Как-то так схема должна выглядеть?