FTP по RS-485, Реально ли? Опции

[skripach]

Может не совсем Ethernet но всё же...
Задача передавать файлы, удалять файлы, просматривать директории на SD-карте которая вставлена в "железку".
Связь с "железкой" осуществляется по существующим каналам (PC->RS-232->RS-485->"железка").
Вопрос реально ли сделать подобие FTP сервера но по RS-485.
Очень хотелось бы для PC ничего не создавать, а пользоваться стандартным FTP-клиентом.

[SysRq]

А если ошибка в канале битовая... Начнутся перезапросы, перепосылки пакетов...

Это loopback. Я сам себе сервер, сам себе клиент. По полудуплексному каналу я предлагаю гонять только протокол верхнего уровня.

Без проблем, но его придется написать...

Обработку TFTP (или HTTP) запросов в железе. На ПК софта полно.

[zltigo]

Обработку TFTP (или HTTP) запросов в железе. На ПК софта полно.

Вы опять о чем-то, чего не понимаете,говорить пытаетесь

(HDLC, к сведению, является несущей PPP)

Нет, они идеологически похожи по формированию фреймов, но один в другом не нуждаются. Тем более, что как уже поминал, HDLC это биториентированный протокол и в нем байториентированный UART не нуждается.

[AlexandrY]

Слаб я в идеологии... Это враги из Freescale называют физический уровнь PPP как HDLC.
Да и другие как сговорились все этот уровень HDLC называют.

А так согласен HDLC это битовый протокол.
У нас одна уважаемая фирма даже собственный придумала формат тоннеля IP поверх FrameRelay с битовым HDLC и через свои спутниковые каналы качает с огромной скоростью.

Нет, они идеологически похожи по формированию фреймов, но один в другом не нуждаются. Тем более, что как уже поминал, HDLC это биториентированный протокол и в нем байториентированный UART не нуждается.

[zltigo]

Да и другие как сговорились все этот уровень HDLC называют.

Для битовых потоков это так и есть - классика жанра. Тот-же X.25 лежит в таком случае поверх HDLC+LAPB(вот эту сладкую парочку
уровня Data Link и могут называть как придется)->MLP->X.25

спецификации AX.25 ?

Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex.
Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно . Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.

[AlexandrY]

Боюсь мужику все равно придется поверх X.25 лепить PPP.
А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов?

Ну а X.25, как и многое другое, писал собственноручно.
Скажу одно, что после уровня LAP* заниматься разрешением коллизий уже изрядно поздно . Одиночные битые фреймы они хоть и на самом верху на IP уровне отсеиваться и переповторяться могут, но не массовые потери.

[SM]

Боюсь мужику все равно придется поверх X.25 лепить PPP.

Что-то это масло масляное - TCP/IP over AX.25 over PPP

А то кто будет проводить назначение сетевых адресов, DNS-ов, шлюзов?

Дык это уже всякие там DHCP/BOOTP и тому подобное, это выше, чем TCP/IP, да и фиксированно прописать можно, и без DNS вообще (это тут только с жиру беситься - доменные имена вводить в 485-ой сети). А какие-то фиксированные адреса в RS-485 сети наверное уже и так есть... Которые видимо в AX.25 вид "позывной+SSID" придется переделать.

Про AX.25 не занимался, не знаю. Ну а X.25, как и многое другое, писал собственноручно - чего там нет, так это разруливания halfduplex.

Блин, сорри, досадная опечатка вышла, букву пропустил... В этом сообщении http://electronix.ru/forum/index.php?showt...st&p=698806 - все три раза должно быть AX.25

[AlexandrY]

Маразм крепчал...
DHCP используют вообще-то только при наличии уровня LLC-MAC. Хотя можно в принципе наверно предложить коллеге эмулировать LLC и МАС поверх RS485.

...Дык это уже всякие там DHCP/BOOTP и тому подобное, это выше, чем TCP/IP, да и фиксированно прописать можно, и без DNS вообще...

[SM]

при наличии уровня LLC-MAC.

Что за новости? Это где еще такое в RFC-2131 написано? UDP+броадкасты есть - значит и DHCP реализуем, и совершенно все равно, что там ниже, MAC или не MAC.
Да и реализуется он (DHCP) "одной левой", если уж человек на FTP позарился. Хотя в контексте - фиксированные айпишники всем, и вперед.

Короче - если TCP/IP over AX.25 встроен в ядро ОС на PC, то и какой-то протокол преобразования IP-адресов в AX.25 адреса (по аналогии с изернетовским ARP) тоже там есть. Дело за малым - поднять AX.25 и TCP/IP over AX.25 в девайсе.

[zltigo]

AX.25.

Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти. Нужно коллизии разруливать на байтово-фреймовом уровне пока навстречу идет фрейм свое буферизировать и не передавать. А при конфликте встречных фреймовых маркеров должно быть понятие уступающего слейва. И уж потом, если разрулили не 100% коллизий качественно, например, по причине упрощения разруливателя, то это тогда битое на IP вывалится и подчистится.

[SM]

Да успокойтесь Вы с AX.25 - ну он уже по любому работает с ГОТОВЫМИ фреймами и если будет тупо ими кидатся, то просто может и ни один не дойти.

Да не успокоюсь. Решение какое-никакое, а готовое, и соответствующее поставленной задаче - без какого либо самописного софта на PC. Пользуются им многие, то что Вы их не знаете, этого не отменяет. Про то, что на PC win никто не говорил (или, если я пропустил, извиняюсь). Да и для win полно готовых решений для "TCP/IP через AX.25", только они не встроены в систему, а требуют установки. Что касается "тупо кидается" - он не "тупо кидается", а с рандомной задержкой, т.е. "тупо как Ethernet". Вообще в пакетном радио другого способа разрешения коллизий, кроме как в AX.25, просто нет, и все пакеты доходят, несмотря на Ваши сомнения. Тут уж "может не дойти, может дойти" - непрофессионально, давайте или не гадать вообще, или измеренные (или рассчитанные) результаты "сколько может не дойти при каком уровне коллизий", и почему. Я руководствуюсь лишь практическими результатами пользователей, которые используют AX.25 по назначению, а именно поверх полудуплексного радиоканала, где коллизий и помех куда больше, чем в RS-485 кабеле.

[zltigo]

Я руководствуюсь лишь практическими результатами пользователей, которые используют AX.25 по назначению, а именно поверх полудуплексного радиоканала, где коллизий и помех куда больше, чем в RS-485 кабеле.

Теперь просьба подумать не отличаются-ли у радиолюбителей протоколы верхнего уровня от желаемого Автором FTP/TCP. C определенностью полагаю, что там протоколы/процедуры верхнего уровня сами по себе ПОЛУДУПЛЕКСНЫЕ и AX.25 в этом случае занимается разрешением потерь, равно, как и редких случайных коллизий канале, которые НИКАК не отличает от потерь вообще. Они действительно могут быть разрешены - выше я говорил, что и в "драйвере" для простоты можно и не гарантировать разрешения всех коллизий - верхний уровень сможет расхлебать последствия редких коллизий.
В FTP/TCP halfduplex не пахнет и коллизии будут ГАРАНТИРОВАННЫЕ и неразрешимые. Чего-нибудь будет пролезать разве только чудом и изредка.

P.S.
Посмотрел какую-то радиолюбительскую статью. В общем, по крайней мере в ней, буквы AX.25 вольно трактуются более, чем широко и к ним заодно валится в одну кучу Data Link уровень на котором действительно ожидаемо поминается контроль за занятостью канала передачи. Посмотрел исходники Линукса - то, что там написано не ведает, точнее не делает НИКАКИХ различий между simplex и duplex каналами. switch() везде присутствует, но они строго везде запаралелены. Пример:

Код

void ax25_kick(ax25_cb *ax25)
{
.....
        switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {
        case AX25_PROTO_STD_SIMPLEX:
        case AX25_PROTO_STD_DUPLEX:
            ax25_send_iframe(ax25, skbn, (last) ? AX25_POLLON : AX25_POLLOFF);
            break;

В конце концов все передается железному уровню одинаково - dev_queue_xmit(skb) и нехай там некий dev разбирается, как передать.

[SM]

Теперь просьба подумать не отличаются-ли у радиолюбителей протоколы верхнего уровня от желаемого Автором FTP/TCP.

не отличаются. Так как протокол верхнего уровня и есть TCP/IP. И я об этом уже писал - "TCP/IP over AX.25" - реализация этого в готовом виде имеется и для windows.

[zltigo]

....не отличаются. Так как протокол верхнего уровня и есть TCP/IP

Если следовать банальной логике, то обертывать TCP/IP в AX.25 незачем, ибо делают одно и то-же.
Единственная причина изложена здесь:
http://www.a27.ru/information/bulleten/199...paketnoe-radio/

AX.25 рассматривается как фактически стандартный протокол для использования в любительской радиосвязи и даже признается многими странами как легальный вид работы. Однако есть и другие стандарты. Любителями некоторых регионов используется TCP/IP. Часто используются специальные протоколы пакетного радио встраиваются внутрь пакетного формата AX.25. Это делается для обеспечения соответствия правилам, требующим, чтобы пакетные радиопередачи были в форме AX.25. Однако детали такого встраивания могут отличаться в различных странах.

Так-что TCP/IP через AX.25 это только один из частных случаев. Насколько я могу понимать родное использование AX.25 радиолюбителями это
посылка текстовых сообщений - чат, в стиле вопрос - ответ.

[SM]

Если следовать банальной логике, то обертывать TCP/IP в AX.25 незачем, ибо делают одно и то-же.

А то самое, о чем тут? Разруливание коллизий полудуплекса [радиоканала]...

А как это готовое называется и где можно взять.

Да так и называется - "TCP/IP over AX.25", или "TCP/IP через AX.25". В линуксе оно встроено в ядро. А для виндовс надо что-то там искать, качать и ставить. Одно из них то-ли FlexNet, то-ли NetFlex. Я сам этим никогда не пользовался, ибо не радиолюбитель. Просто знаю о существовании и о некоторых свойствах, да и то без 100%-ной гарантии.