Обсуждение HDLC #10
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Можно ли в рамках курсовой работы остановится на том, что мы выдадим готовый массив с фреймом для отправки, и просто будем посылать его снова, если не будет ответа?
Получается, чтобы создать соединение, мне нужно сделать функцию, которая будет отдавать этот буфер, но я пока плохо понимаю, как мне придет ответ. Как его разобрать я понимаю
Что значит остановиться?
Чтобы создать соединение нужно
И мы снова приходим к тому, что я уже говорил не раз: есть API вашего модуля. Где оно? Какие имеет функции? Где алгоритмы в конце концов? Где диаграммы, раз не можем сделать алгоритмы?
Метод send
Методы connect
Метод connect_recive
Метод recive
Как я в принципе понимаю логику работы своего протокола. Жду комментариев
Не понимаю одной логики, я делаю просто 4 метода, которые дают и принимают фреймы под видом обычных функций, или что конкретно еще нужно добавить. Прошу направить меня или дать ссылки на примеры для изучения
Чтобы понять, нужно было сделать диаграмму последовательности.

В вашем случае сущноси будут Главная программа (человечек, Вы), UART, какой-то блок создающий и потребляющий информацию из подключения, экземпляр подключения (ваш модуль). И таких диаграмм надо сделать несколько: рассмотретсь случаи когда все пакеты доходят с первого раза, когда какие-то пропадают, когда без очереди приходят. Давайте 2 диаграммы для начала.
Вроде как переделал под все требования первую схему, когда все дошло, и соединение установлено.
https://drive.google.com/file/d/1zTlphz4DXeDvR3_lOIHZ-LBTHXp-UOUR/view?usp=drive_link
Буду посылать ссылкой на гугл диск, чтобы было удобнее отслеживать актуальную версию
Не уверен, что правильно переделал, жду комментариев
Последовательная диаграмма соединения:
https://drive.google.com/file/d/1zTlphz4DXeDvR3_lOIHZ-LBTHXp-UOUR/view?usp=drive_link
Спасибо! По вашему примеру переделаю, а также сделаю диграммы для других сценариев. Завтра до 13 постараюсь управиться
Диаграмма connect, когда все успешно
https://drive.google.com/file/d/1zTlphz4DXeDvR3_lOIHZ-LBTHXp-UOUR/view?usp=drive_link
Диаграмма not_connect, когда пакет не дошел сразу
https://drive.google.com/file/d/1JqhlFN7W-glqe-T7DDJOaTSGi0Tv0-IF/view?usp=sharing
Нужно ли делать отдельную диаграмму, когда не дошел пакет?
Диаграмма send, когда все успешно
https://drive.google.com/file/d/1mYgZ_ZPXZuS-zRomPgyMpuswglhmQB4f/view?usp=sharing
Диаграмма send_err, когда пришел не тот пакет в ответ
https://drive.google.com/file/d/10tvV3DAOhxO4ssRB3UVaw87HMS5lbzS1/view?usp=sharing
Нужно ли делать отдельную диаграмму, когда не дошел пакет?
Диаграммы уже лучше отображают действительность и идею. Нужно понимать, что каждая стрелочка вправо - это вызов функции, а стрелочка влево - возврат из функции.
Теперь на месте "создай соединение со 2 стороной" Нужно написать
connect()
При том явно напрашивается то, что connect() не возвращает нам байты для отправки.
connect()
только изменяет состояние объекта соединения.Наводящий вопрос: как понять, что пришла пора повторно отправлять пакет? Не важно пакет соединенния и информационный пакет.
Ответ: должна быть функция, которую надо вызывать часто. В качестве параметра этой функции должно быть значение: сколько времени прошло с последнего вызова этой функции. Таки образом для каждого отправленного пакета можно будет установить таймер. При каждом вызове функции вычитать из таймеров значени параметра функции.
И всё равно не эта функция должна возвращать данные для отправки. Должна быть функция, которая делает одно: даёт данные, которые надо будет отправить по UART или любому другому интерфейсу.
На данный момент переделал только connect. Завтра с утра займусь остальными, до этого закрывал учебу, посылаю ещё раз, чтобы не искать.
https://drive.google.com/file/d/1zTlphz4DXeDvR3_lOIHZ-LBTHXp-UOUR/view?usp=drive_link
Отлично! Вы этой диаграммой описали один индеальный случай. Но при этом всё верно!
Диаграмма connect, когда все успешно
https://drive.google.com/file/d/1zTlphz4DXeDvR3_lOIHZ-LBTHXp-UOUR/view?usp=drive_link
Диаграмма not_connect, когда пакет не дошел сразу
https://drive.google.com/file/d/1JqhlFN7W-glqe-T7DDJOaTSGi0Tv0-IF/view?usp=sharing
Диаграмма send, когда все успешно
https://drive.google.com/file/d/1mYgZ_ZPXZuS-zRomPgyMpuswglhmQB4f/view?usp=sharing
Очень нужны ваши комментарии, правильно ли я понимаю логику отправки информационных фреймов. Также немного поправил connect и сделал, когда пакет не дошел с первого раза, попутно все расписав с комментариями
не вы говорите модулю, что надо отправить повторно пакет. Вы как раз разрабатываете модуль, который делает это за вас. Вы лишь должны вызывать функцию, которая ведёт учёт таймаутов. А параметр этой функции - дельта времени с последнего вызова этой функции. Человеческим языком: если вы вызываете эту функцию каждую миллисекунду, то параметр всегда будет равен 1.
Нужно понимать, что UART принимает байты, а не пакеты. Вы не знаете, получили вы пакет или нет. Это делает ваш модуль. Ваш модуль декодирует фреймы (ждёт FD, деэкранирует).
Не будет у вас публичной функции check_frame. У вас будет функция hdlc_got_raw_data() или как-то так. и уже в неё отдаёте полученные байты.
Также нужно соблюдать нотацию. Посмотрите примеры.
Диаграмма connect, когда все успешно
https://drive.google.com/file/d/1zTlphz4DXeDvR3_lOIHZ-LBTHXp-UOUR/view?usp=drive_link
Диаграмма not_connect, когда пакет не дошел сразу
https://drive.google.com/file/d/1JqhlFN7W-glqe-T7DDJOaTSGi0Tv0-IF/view?usp=sharing
Диаграмма send, когда все успешно
https://drive.google.com/file/d/1mYgZ_ZPXZuS-zRomPgyMpuswglhmQB4f/view?usp=sharing
Диаграмма send_err, когда пришел не тот пакет в ответ
https://drive.google.com/file/d/10tvV3DAOhxO4ssRB3UVaw87HMS5lbzS1/view?usp=sharing
Не уверен все ли правильно, но хотелось бы поговорить о реализации функций, чтобы закрыть все недочеты в диаграммах
Не нарушать нотацию. Иначе не понятно, как прочитать
ранее мы говорили:
Чтобы что-то отправлять, вы должны сначала спросить свой модуль, есть ли что отправлять. А вот ваш модуль будет отправлять пакет заново, когда наступит таймаут. На диаграммах до сих пор отсутствует что-либо связанное с уведомлением вашего модуля о прошедшем времени.
Диаграмма connect, когда все успешно
https://drive.google.com/file/d/1zTlphz4DXeDvR3_lOIHZ-LBTHXp-UOUR/view?usp=drive_link
Диаграмма not_connect, когда пакет не дошел сразу
https://drive.google.com/file/d/1JqhlFN7W-glqe-T7DDJOaTSGi0Tv0-IF/view?usp=sharing
Диаграмма send, когда все успешно
https://drive.google.com/file/d/1mYgZ_ZPXZuS-zRomPgyMpuswglhmQB4f/view?usp=sharing
Диаграмма send_err, когда пришел не тот пакет в ответ
https://drive.google.com/file/d/10tvV3DAOhxO4ssRB3UVaw87HMS5lbzS1/view?usp=sharing
Нотации все поправлены. Вопрос, можно ли сделать обработчик ошибок в си, наподобие го, где можно в условиях сравнивать, вернулась та ли ошибка?
Жду ваших комментариев
Коммиты должны содержать описание, которое отражает суть изменений

А дальше? А пакет, который мы отправили? Когда его в следующий раз отправим?
Если мне нужно будет уменьшить или увеличить количество пакетов?
прямо напрашивается структура (
struct ...
) и объявление переменной-массива, где размер массива -COUNT_BUFFERS
Вот эта структура фрейма что делает в main и вообще вне вашего модуля. Ваш модуль предоставляет только структуру соединения и функции работы с этим соединением.
Структура фрейма была убрана
800f48bc11