На главную страницу сайта
· Наш магазин · Объявления · Рейтинг · Статьи · Частоты · Копилка · Аэродромы · Live!
· Файлы · Диапазоны · Сигналы · Музей · Mods · LPD-форум · Клуб · Радиостанции
На сайте: гостей - 46,
участников - 2 [ Iacov, Spirex]
 · Начало · Опросы · События · Статистика · Поиск · Регистрация · Правила · FAQ · Галерея ·
 Форум —› Программное обеспечение —› ASFT: автоматическая передача файлов через последовательный порт 
Трансиверы Yaesu в нашем магазине


Yaesu FT-817ND
руб.

Yaesu FT-857D
руб.

Yaesu FT-897D
руб.

Yaesu FT-450D
руб.

Yaesu FT-950
руб.
Автор Сообщение
dimss
Участник
Offline4.0
с сен 2004
Рига
Сообщений: 1236

Дата: 31 Мар 2023 12:49:42 #  

Вашему вниманию предлагается небольшой побочный продукт моей непрофессиональной деятельности - ASFT.

Данная программа предназначена для обмена файлами через последовательный порт двух или более компьютеров под Linux. Кому-то может пригодиться для обмена файлами через радиомодем. Большинство известных протоколов передачи файлов через последовательный порт или давно устарели, или узкоспециализированные. От многих из них ASFT отличается вот чем:

1. Современное шифрование chacha20-poly1305
2. Обмен ключами ECDH X25519
3. Автоматическая работа, подходит для M2M и тому подобного
4. Поддержка полудуплекса и многоточечной конфигурации - удобно для радиомодемов и RS-485.
5. Изначально под Linux, но при желании можно легко портировать на другие ОС. Ничего экзотического не применяется.
6. Годится для различных применений - в файл можно записать почти что угодно

Протокол передачи - строго запрос-ответ. Не чемпион по скорости, зато "вездеход". Может работать со сколь угодно низкой скоростью.

https://github.com/dimss1979/asft
LFSR
Участник
Offline0.0
с мар 2022
Киев
Сообщений: 153

Дата: 01 Апр 2023 06:35:34 #  

Данная программа предназначена для обмена файлами через последовательный порт двух или более компьютеров под Linux.
Очень своевременно! :)
Реклама
Google
abradox
Участник
Offline6.2
с окт 2013
Москва, Mоск. обл
Сообщений: 1634

Дата: 01 Апр 2023 11:15:50 #  

Очень своевременно! :)
Вполне себе пригодно, чтобы не городить "паровозы" из ppp/pppd + ftp/ftps/sftp/scp.
Тем более: Поддержка полудуплекса и многоточечной конфигурации
Так что свою нишу прога вполне может найти.
LFSR
Участник
Offline0.0
с мар 2022
Киев
Сообщений: 153

Дата: 02 Апр 2023 12:09:40 #  

Так что свою нишу прога вполне может найти.
Так и я ж про то. Я не ерничаю. Сейчас множество коллективов (вот у нас в Киеве, например) занимаются беспилотниками. Наверное слава(и финансовый успех) Байрактара покоя не дают. Вполне себе своевременный проект... под их нужды :) .
abradox
Участник
Offline6.2
с окт 2013
Москва, Mоск. обл
Сообщений: 1634

Дата: 02 Апр 2023 12:58:46 #  

LFSR
Я не ерничаю.
И я тоже не ёрничаю.
Сейчас множество коллективов (вот у нас в Киеве, например) занимаются беспилотниками.
Если желаете обсуждать это, то создайте соответствующую тему, если получится.
А в этой теме будет осбужаться программа уважаемого dimss.
dimss
Участник
Offline4.0
с сен 2004
Рига
Сообщений: 1236

Дата: 03 Апр 2023 15:14:13 · Поправил: dimss (03 Апр 2023 15:15:12) #  

чтобы не городить "паровозы" из ppp/pppd + ftp/ftps/sftp/scp.

PPP и IP дает возможность применять великое множество приложений, написанных для IP, но малопригоден на низких скоростях. Еще на позапрошлой работе экспериментировали, и оказалось, что нужно не менее 2400 bps для относительно нормальной работы. Кроме того, PPP требуется полный дуплекс. При полудуплексе ему совсем плохо.

Другой вариант - старинные протоколы вроде xmodem, kermit, UUCP. Они все ещё живы и входят в состав большинства дистрибутивов Linux. Для работы без вмешательства пользователя и в режиме полудуплекса подходит только UUCP. Но в нем нет шифрования.

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

занимаются беспилотниками... своевременный проект... под их нужды

Им нужна работа в реальном времени. Полная противоположность тому, что у меня получилось.
abradox
Участник
Offline6.2
с окт 2013
Москва, Mоск. обл
Сообщений: 1634

Дата: 03 Апр 2023 22:20:58 #  

dimss
Но предполагаемая скорость передачи данных в моем случае - от десятков до сотен бит в секунду.
Да, есть задачи, где это может найти применение.
dimss
Участник
Offline4.0
с сен 2004
Рига
Сообщений: 1236

Дата: 07 Апр 2023 11:09:58 #  

Заменил алгоритм фрейминга с HDLC на COBS. Теперь при размере блока по умолчанию 200 байт максимальный размера фрейма всего 222 байта, включая маркеры начала и конца пакета.
Zmej
Участник
Offline3.1
с дек 2005
...
Сообщений: 10588

Дата: 08 Апр 2023 15:51:38 #  

Теперь при размере блока по умолчанию 200 байт максимальный размера фрейма всего 222 байта,

Почти изобрели повторно ax.25 :)

Больше интересно, какие сом-портовые модемы использовать планируете, китайские rf-модули прямого преобразования вроде ism, lora всяких?
dimss
Участник
Offline4.0
с сен 2004
Рига
Сообщений: 1236

Дата: 11 Апр 2023 12:07:43 #  

Почти изобрели повторно ax.25 :)

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

То, что я "изобрел" - это скорее сильно упрощенный вариант UUCP с шифрованием.

Больше интересно, какие сом-портовые модемы использовать планируете, китайские rf-модули прямого преобразования вроде ism, lora всяких?

Всё началось именно с дешевых модулей LoRa. Но решение получилось весьма универсальным, так что каждый может применять то, что ему больше подходит. Прямо сейчас на столе несколько устройств с RS-485... Также рассматривается возможность разработки своего программного модема.
Zmej
Участник
Offline3.1
с дек 2005
...
Сообщений: 10588

Дата: 12 Апр 2023 08:17:28 · Поправил: Zmej (12 Апр 2023 08:19:54) #  

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

По идее шифрование и не нужно было туда помещать, так как АХ - это протокол второго уровня (по классической сетевой модели osi).
Шифрование - по сути, уже удел протоколов следующих уровней.

К своему стыду, не знаю устройство uucp.
Лишь помню, что так называли какую-то примитивную электронную почту под дос в 90е.
У меня даже были ее программы тогда, но что там и как, к кому соединяться и чем - понятия не имел и не было у кого узнать.
dimss
Участник
Offline4.0
с сен 2004
Рига
Сообщений: 1236

Дата: 12 Апр 2023 18:22:55 #  

По идее шифрование и не нужно было туда помещать, так как АХ - это протокол второго уровня (по классической сетевой модели osi).
Шифрование - по сути, уже удел протоколов следующих уровней.


Таковым было понимание где-то до конца 90-х годов. Но практика показала, что необходимо внедрять шифрование и на более низких уровнях. Например, Wi-Fi прошел болезненный путь от полностью открытой сети до WPA3. Причем в новом диапазоне 6 ГГц вообще не допускается использование Wi-Fi с уровнем безопасности ниже WPA3.

И даже в проводных сетях внедряется шифрование. Например, DSL стандарта G.hn предусматривает обмен ключами по алгоритму X.1035 - немного устаревшему (там не эллиптические кривые), но все еще стойкому.

Я пошел дальше, и вообще выкинул адресацию и контрольную сумму из формата кадра. Если мы получили пакет и не можем расшифровать, то он - не для нас :) На низких скоростях нагрузка на процессор пренебрежимо мала. Если хочется энергосбережения дополнительного, то можно снова ввести поле "адрес" в формате - чисто как способ оптимизации. Контрольную сумму верну, когда буду делать режим репитера. Репитер не имеет ключа шифрования по определению, но ему надо как-то фильтровать битые пакеты.

К своему стыду, не знаю устройство uucp... что там и как, к кому соединяться и чем - понятия не имел

Там суть была простая - компьютеры звонили по модему друг другу по договоренности администраторов, и передавали файлы. В силу этого сеть была весьма хаотична. Единой адресации в привычном нам ныне понимании не было. Протокол передачи данных имеется нескольких видов - в зависимости от типа используемого канала. Инструментарий для UUCP по сей день входит в состав большинства дистрибутивов Linux.

А когда-то на первой работе у меня был доступ к серверу с работающим UUCP. Но я им ни разу не пользовался. Зачем? Ведь уже был Интернет. Так мне тогда казалось...

Так что ASFT - это скорее упрощенная замена UUCP, но с современной криптографией.
Zmej
Участник
Offline3.1
с дек 2005
...
Сообщений: 10588

Дата: 13 Апр 2023 11:59:53 #  

На пальцах можете пояснить, как оно у вас там "плюет" пакеты, по одному 222-байтовому и ждет ответную квитанцию или какой-то группой пакетов, например штук 8, а потом подтверждает все или запрашивает потерянные, есть ли "докачка при обрыве связи"?


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

Откуда те дос программы мне попали - уже не помню, но эту ууцп почту в то время активно использовали кажется электросети у нас, адреса были что-то вроде user@<область>.energy.gov.ua и эти письма ходили и в обычный интернет. По всей видимости они звонили по областям друг другу модемами и где-то был гейт в обычный e-mail?
dimss
Участник
Offline4.0
с сен 2004
Рига
Сообщений: 1236

Дата: 13 Апр 2023 12:36:39 #  

"плюет" пакеты, по одному 222-байтовому и ждет ответную квитанцию или какой-то группой пакетов

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

Например, Wi-Fi - тоже в основе полудуплекс. Но там имитируется дуплекс путем использования больших буферов и сложного алгоритма доступа станций к "воздуху".

докачка при обрыве связи

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

Вообще "обрыв связи" в прежние времена был обычно связан с тем, что просто сбрасывался звонок со стороны оперятора связи, и при этом сбрасывались соединения TCP. При отсутствии коммутации каналов длительное отсутствие связи может быть только при авариях каких-то. Соответственно и функция "докачки" не очень востребована.
Zmej
Участник
Offline3.1
с дек 2005
...
Сообщений: 10588

Дата: 13 Апр 2023 14:48:46 #  

Докачку можно реализовать, если это кому-то нужно.

Это базовая функция любой нормальной низко-скоростной системы передачи файлов, начиная еще с bbs и фидо.
Где часто можно качать-качать и не долить какие-то последние килобайты, а потом начинать сначала что ли, теряя кучу времени?!

В радио канале тоже могут быть обрывы - например помеха, а попытки проверочных пакетов обычно не бесконечные, "ретрейн" кончится рано или поздно, по таймеру и/или по числу попыток.

Строго по одному.

При "тупом" модеме и ограниченном буфере только так. И когда прием-передача электронное, тоже не критично.
Хотя в AX.25 еще черт знает когда это ограничение красиво обходилось, когда можно было передавать несколько пакетов "за один выстрел", а приемный писал получаемые и отмечал какие есть, каких нет, потом подтверждал и запрашивал только недостающие - экономия во времени на мало скоростном канале как раз приличная выходила. Ведь меньше "клацанья" туда-сюда (на прием-передачу), подтверждений каждого блока, быстрей всё улетает, если принимается без помех.
dimss
Участник
Offline4.0
с сен 2004
Рига
Сообщений: 1236

Дата: 13 Апр 2023 15:56:21 #  

Это базовая функция любой нормальной низко-скоростной системы передачи файлов, начиная еще с bbs и фидо.

Хорошо, принято к сведению!
Реклама
Google
 

Создавать сообщения могут только зарегистрированные участники форума.
Войти в форум :: » Логин » Пароль
Начало
Средства связи, рации. Купить радиостанции Motorola, Yaesu, Vertex, приемники, антенны.
Время загрузки страницы (сек.): 0.024; miniBB ®