FTP-client OR ? Опции

[Allregia]

Привет всем.

Для решения одной задачи, нужно чтобы контроллер на LPC17xx мог брать файлы по сети с компа или NAS (в пределах локалки, хотя это вроде неважно).
Проще всего наверное по FTP, но если фтп-серверы для АРМов я встречал, то клиентов пока не нашел.

Не посоветует ли премудрый ALL где можно найти сорцы фтп-клиента, или может какое другое решение?

[scifi]

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

[Allregia]

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

А где про это можно почитать? Дело в том, что основная часть проекта - ввод/вывод аналоговых величин, их обработка, управление процессами - тут я хорошо разбираюсь и приличный опыт имеется. А вот в сетевых устройствах и протоколах я пока слабо разбираюсь, и в данном случае это побочная и небольшая часть проекта. С эзернетом на LPC17хх пока дальше примеров на демоборде не продвинулся Собственно, на 50% из-за эзернета и USB и был сделан переход с AVR на LPC в новой версии девайса..

[gladov]

Я бы еще порекомендовал в сторону TFTP посмотреть. Как бы ни был FTP прост, а TFTP еще проще Он специально затачивался под "простые" системы.

[politen]

http://ru.wikipedia.org/wiki/FTP
rfc внизу
дальше прямой путь в http://www.keil.com/support/man/docs/rlarm...m_tn_cfgtcp.htm

Сообщение отредактировал politen - Nov 13 2010, 21:16

[Allregia]

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

во 2-м случае у меня возникает другой вопрос- может у нас неверно поставлена задача, и решать ее надо не методом фтп-клиента а другим?

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

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

[gladov]

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

Вот тут Вы частично ответили на свой же вопрос Обычно, когда делаются устройства с возможностью дальнейшего развития в плане Ethernet и "установки их в другом городе", клиентские реализации уже не катят, т.к. Вы не знаете куда занесет устройство и, следовательно, оно само не знает куда ему коннектиться. А вот если оно - сервер, то уже не его забота знать где оно стоит. Опять же, возможно Вам захочется потом забирать логи с одного устройства двумя компами? Конечно, все зависит от конкретной задачи, но, как правило, все встроенные системы являются скорее серверами нежели клиентами, т.к. они предоставляют кому-то какие-то услуги, информацию, статистику и т.п.

[ArtemKAD]

клиентские реализации уже не катят, т.к. Вы не знаете куда занесет устройство и, следовательно, оно само не знает куда ему коннектиться.

Почему? Как раз если есть централизованный сервер для всех устройств, то устройство всегда знает куда ему коннектиться. А вот законнектиться к устройству которое находиться "где-то там" да еще и вероятно за проксёй - вот это задачка из гиморойных.

[AlexandrY]

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

Вообще-то FTP клиентов довольно много открытых есть.
А вы где искали? Может вы не отличили клиента от сервера?

[sasamy]

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

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

[Allregia]

Вообще-то FTP клиентов довольно много открытых есть.
А вы где искали? Может вы не отличили клиента от сервера?

Ну, читать я вроде еще умею
А искал как обычно - гугглом, не считая просмотра аппликух - LPC, Keil, etc.
Если знаете что-то конкетное - буду очень признателен за ссылку.

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

Я конечно чайник в TCP/IP, но не настолько....
Как тут уже сказали - все наоборот, это серверу надо провисывать портфорвардинг или виртуальные серверы на роутере, а клиенту - надо знать только IP сервера.
Возьмите как пример E-Mule - как клиенту ему все равно где он стоит, лишь бы его порты небыли полностью закрыты на роутере. Ну даже если обратку не получит, будет в LowID, поганенько. но работать будет.
А вот как серверу (управление им извне через веб-интерфейс) - пока ему роутинг не пропишешь, кина не будэ.

[sasamy]

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

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

Если Вы это планируете делать через Интернет в будущем - то логи и тем более конфиги по FTP - это офигенная дыра в безопасности.

[politen]

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

во 2-м случае у меня возникает другой вопрос- может у нас неверно поставлена задача, и решать ее надо не методом фтп-клиента а другим?

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

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

если сбор сведений не чаще одного раза в минуту (хотя никто не мешает сделать чаще), то как вариант, SNMP. сборка сведений тем же кактусом, в котором достаточно развиты средства для сбора и анализа статистики. единственно, что обычно на снмп запрос поступает ответ с текущим состоянием устройства. опять же вы не описали с какой периодичностью снимаются показания.

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

Сообщение отредактировал politen - Nov 14 2010, 13:09

[Allregia]

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

Предполагается два режима, в одном - раз в несколько часов, в другом - непрерывно.
После обсуждения у себя, остановились на FTP.
В локалке можно что-то другое (кстати, подскажите что, я знаю только NetBios, Samba), если оно проще в реализации чем фтп.

[AlexandrY]

Ну, читать я вроде еще умею
А искал как обычно - гугглом, не считая просмотра аппликух - LPC, Keil, etc.
Если знаете что-то конкетное - буду очень признателен за ссылку.

FTP клиенты есть в: eCOS, MQX, RTEMS, VxWorks, Nucleus и т.д.

Рекомендовал бы MQX и перейти на семейство Kinetis ARM Cortex-M4

[sasamy]

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

Попробуйте это "обычно" в сети Интернет - с Интернетом шутки плохи На Linux я например легко имею шифрованную приватную сеть и тут уже безразлично - какая сторона выступает в роли клиента а какая в роли сервера для разных протоколов, но в любом случае устройства всегда являются клиентами - все они коннектятся к серверу VPN. Сами устройства могут быть и в Гондурасе И ни один хакер-какер не подсунет мне левые настройки, как например в центре Москвы порнушку крутили на рекламных щитах.

[AlexandrY]

Попробуйте это "обычно" в сети Интернет - с Интернетом шутки плохи На Linux я например легко имею шифрованную приватную сеть и тут уже безразлично - какая сторона выступает в роли клиента а какая в роли сервера для разных протоколов, но в любом случае устройства всегда являются клиентами - все они коннектятся к серверу VPN. Сами устройства могут быть и в Гондурасе И ни один хакер-какер не подсунет мне левые настройки, как например в центре Москвы порнушку крутили на рекламных щитах.

Шифрованная приватная сеть далеко не лучший вариант для дальней связи.
Во всех перечисленных выше осях есть надстройка SSL. Это более чем адекватное решение.
Но в данном контексте тот кто организовал канал связи первым может не являться клиентом с точки зрения приложения.

Я думаю разработчика решения мало интересует голый TCP канал хоть и защищенный.
Гораздо интересней автоматизированное проектирование удаленного взаимодействия приложений.
Для этого специально создан Windows Communication Foundation. И в нем нет понятия серверов и клиентов, а есть только сервисы и потребители.
Если сервисы считать отдаленным аналогом серверов, то они в приложении центра сбора информации как раз будут находится на удаленных устройствах.

[sasamy]

Шифрованная приватная сеть далеко не лучший вариант для дальней связи.

Озвучте "наилучший" вариант - это же для Вас не проблема

Во всех перечисленных выше осях есть надстройка SSL. Это более чем адекватное решение.

На базе SSL как раз построено шифрование того о чем я говорил

Я думаю разработчика решения мало интересует голый TCP канал хоть и защищенный.

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

Гораздо интересней автоматизированное проектирование удаленного взаимодействия приложений.

Гораздо интересней вообще не задумываться о защищенности данных - этим занимается стороннее ПО и разработчика мало интересует как все организовано - Linux это реализует в полной мере.

Для этого специально создан Windows Communication Foundation. И в нем нет понятия серверов и клиентов, а есть только сервисы и потребители.
Если сервисы считать отдаленным аналогом серверов, то они в приложении центра сбора информации как раз будут находится на удаленных устройствах.

Все это будет стоить денег - в Linux это ничего не стоит.

[Allregia]

Товарищи, вспомните про бритвочку Оккама
Я просил дать ссылочку на исходники примера фтп-клиента, и мне тут только:

Windows Communication Foundation.

не хватает для полного счастья!

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

P.S. Никаких линухов в этом устройстве нет и в ближайшие годы не будет. Эксплуатирующиеся сегодня две версии устройства вообще работают одна на PIC16F876 а вторая на ATMega329.

[sasamy]

P.S. Никаких линухов в этом устройстве нет и в ближайшие годы не будет.

Как и расширяемости системы - тоесть через месяц когда заказчику нужно будет что-то чуть более чем круто дрыгнуть GPIO или скачать файл по FTP (а это уже сегодня для Вас целая проблема) ответ будет один - не в этой жизни.

И подозреваю тут тостого троля

Эксплуатирующиеся сегодня две версии устройства вообще работают одна на PIC16F876 а вторая на ATMega329.

Какое отношение эти замухрышки имеют к ветке ARM ?

Сообщение отредактировал sasamy - Nov 14 2010, 22:10

[andrewlekar]

Рекомендую автору взглянуть в сторону использования на устройстве голого TCP клиента, либо HTTP клиента.

[Allregia]

Какое отношение эти замухрышки имеют к ветке ARM ?

Это не "замухрыжки", а отличные контроллеры, которые прекрасно решают определенный круг задач.
Не нужно быть таким снобом, я не собрираюсь ставить Пентиум, где достаточно Z80 , или менять в серийно выпускаемых нами сенсорах, 6-ногий PIC10F222 на ARM9.
А отношение простое - новая версия делается на LPC17xx, поэтому я тут и спрашиваю.

нужно будет что-то чуть более чем круто дрыгнуть GPIO или скачать файл по FTP (а это уже сегодня для Вас целая проблема)

Да, основная задача конкретного устройства - это именно "круто дрыгать GPIO" на основании полученных с других GPIO и АЦП данных, плюс юзер-интерфейс (несколько кнопок и ЖКИ, что в общем-то тоже "ногодрыганье").
"Скачать файл по ФТР" - это примерно 5-10% задачи устройства, и да - для меня это проблема, поскольку я с этим совершенно не знаком.
Зато я отлично знаком с "ногодрыганьем", и самое главное - алгоритмам и расчетам, включая обработку сигналов, чем многие, кто прекрасно знает ТСР далеко не всегда могут похвастаться
И это, если бы были мысли использовать "поделки финских студэнтов"(с)?, то мы взяли бы какую-нибудь microPC и не городили бы свои контроллеры.

Рекомендую автору взглянуть в сторону использования на устройстве голого TCP клиента, либо HTTP клиента.

Это как раз то, о чем я и спрашиваю тут уже вторую страницу - где можно посмотреть на пример ?
А я его уже адаптирую под конкретные цели.

[politen]

Попробуйте это "обычно" в сети Интернет - с Интернетом шутки плохи На Linux я например легко имею шифрованную приватную сеть и тут уже безразлично - какая сторона выступает в роли клиента а какая в роли сервера для разных протоколов, но в любом случае устройства всегда являются клиентами - все они коннектятся к серверу VPN. Сами устройства могут быть и в Гондурасе И ни один хакер-какер не подсунет мне левые настройки, как например в центре Москвы порнушку крутили на рекламных щитах.

не мешайте все в кучу. щиты взломали не потому, что система была сделана на МК/АРМ. там был "социальный инжиниринг"+все построено на винде, где создание защищенной системы требует кропотливой настройки. сервера, работающие под распространенными ОС, предоставляют много возможностей, в т.ч. и для взлома. Реализации под конкретные процессоры (не столь распространенные как процессоры PC), обычно предполагают выполнение базовых функций и тем более, подмена настроек редко когда возможна. К задачам удаленного управления/мониторинга всегда нужно подходить учитывая в т.ч. инфраструктуру, в которой устройство будет работать. Большую часть даже возможности "атак" достаточно просто отразить правильной настройкой этой самой инфраструктуры

[Allregia]

Всем спасибо, оказалось все очень просто - пример нашелся в каталоге IAR (я Кейлом пользуюсь, а ИАР когда-то ставил "поиграться").

[gladov]

На Linux я например легко имею шифрованную приватную сеть и тут уже безразлично - какая сторона выступает в роли клиента а какая в роли сервера для разных протоколов, но в любом случае устройства всегда являются клиентами - все они коннектятся к серверу VPN. Сами устройства могут быть и в Гондурасе И ни один хакер-какер не подсунет мне левые настройки, как например в центре Москвы порнушку крутили на рекламных щитах.

Гм.. А Вы думаете, что на экранах, установленных в центре Москвы не было VPN??? Неужели Вы считаете что все вокруг (кроме некоторых особо грамотных) такие, что даже не думают о защите информации в центре Москвы? Вообще, по статистике более 70% современных сетевых взломов делаются за счет утечки информации от сотрудников, но никак не чисто техническими средствами.

[AlexandrY]

Озвучте "наилучший" вариант - это же для Вас не проблема

На базе SSL как раз построено шифрование того о чем я говорил

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

Гораздо интересней вообще не задумываться о защищенности данных - этим занимается стороннее ПО и разработчика мало интересует как все организовано - Linux это реализует в полной мере.

Все это будет стоить денег - в Linux это ничего не стоит.

VPN-ы это надстройка над IP, а SSL над TCP и это большая разница. VPN-ы по сути замещают TCP и хуже работают, в частности PPTP очень скверно работает на большие расстояния и в беспроводных сетях. Уж лучше лепить тогда доморощенный протокол поверх UDP.
А также количество реальных VPN соединений на одном сервере ограниченно где-то в районе тысячи. Дальше большие проблемы с производительностью идут. Т.е. плохая масштабируемость.
Вообщем я в свое время отказался от VPN.

Насчет удобства Линукса в качестве сервера TCP подключений не буду спорить, он очень удобен.
Но повторяю, Windows 7 с тем же успехом держит 10 тыс. и больше TCP подключений на моем лэптопе и не надрывается.

Но уровень приложения это иное. Если с TCP все ясно и вылизывалось годами, то гибкое взаимодействие на прикладном уровне гораздо сложней.
Вот скажем тут мысль использовать FTP была.
Но беда в том что найти надежный фриварный сервер FTP есть проблема.
Либо эти ФТП не поддерживают SSL, либо не имеют пассивных соединений, либо плохо поддерживают коннект, либо убивают файлы при одновременном доступе писателей и читателей и т.д.
Т.е. решение с FTP это скажем так лучший способ поиметь проблемы. И разруливать все ситуации надо будет разработчику дивайсов.

В противоположность этому Windows Communication Foundation создан уже с учетом опыта взаимодействия дивайсов с центрами сбора информации и учитывает все административные нюансы таких взаимодействий. Причем работа с WCF не обязательно требует установки Windows CE на дивайсы. А вот работа с Линуксом на базе каких-нить фреймворков распределенного взаимодействия (хотя таких не знаю) потребует и на дивайсах Линукса.

[sasamy]

"поделки финских студэнтов"(с)

Да будет Вам известно - подавляющее большинство открытий делается людьми в молодом возрасте (естественно Linux это никакое не открытие). С тех пор как Торвальдс предложил бесплатный клон Unix прошло уже почти 20 лет и его кода там не более 2%. Можете называть Linux как угодно но только Ваши изделия по значимости в современном мире даже близко не лежат с Linux - так что делайте выводы о ценности своих завлений о поделках.

Гм.. А Вы думаете, что на экранах, установленных в центре Москвы не было VPN??? Неужели Вы считаете что все вокруг (кроме некоторых особо грамотных) такие, что даже не думают о защите информации в центре Москвы?

Это у Вас привычка говорить за других ? Ничего я не думал - это был пример несанкционированного доступа из реальной жизни, а то тут особо грамотные предлагают сервисами светить в Интернет потому что сами так обычно делают

[sasamy]

Причем работа с WCF не обязательно требует установки Windows CE на дивайсы. А вот работа с Линуксом на базе каких-нить фреймворков распределенного взаимодействия (хотя таких не знаю) потребует и на дивайсах Линукса.

WCF потребует привязки к определенной лицензируемой технологии за использование которой придется платить всегда. Собственно идея WCF ничего нового не несет - майкрософт в очередной раз доказывает что ничего нового они изобрести не могут в принципе - взгляните на Plan 9 и в каком году она появилась.

С опозданием но все же

VPN-ы это надстройка над IP, а SSL над TCP и это большая разница. VPN-ы по сути замещают TCP и хуже работают, в частности PPTP очень скверно работает на большие расстояния и в беспроводных сетях. Уж лучше лепить тогда доморощенный протокол поверх UDP.
А также количество реальных VPN соединений на одном сервере ограниченно где-то в районе тысячи. Дальше большие проблемы с производительностью идут. Т.е. плохая масштабируемость.

У Вас какое-то очень специфичное и узкое понятие VPN OpenVPN которым я воспользовался не привязан к TCP - более того рекомендуется (что я и сделал) использовать в качестве транспортного протокола UDP. Никаих "лучших доморощенных протоколов" Вы никогда не сделаете - перестаньте уже витать в облаках, пора спускаться на землю

Сообщение отредактировал sasamy - Nov 15 2010, 12:45

[gladov]

На Linux я например легко имею шифрованную приватную сеть и тут уже безразлично - какая сторона выступает в роли клиента а какая в роли сервера для разных протоколов, но в любом случае устройства всегда являются клиентами - все они коннектятся к серверу VPN. Сами устройства могут быть и в Гондурасе И ни один хакер-какер не подсунет мне левые настройки, как например в центре Москвы порнушку крутили на рекламных щитах.

Это у Вас привычка говорить за других ? Ничего я не думал - это был пример несанкционированного доступа из реальной жизни, а то тут особо грамотные предлагают сервисами светить в Интернет потому что сами так обычно делают

"И ни один хакер-какер не подсунет мне левые настройки, как например в центре Москвы порнушку крутили на рекламных щитах" - я просто написал, что у админов экранов тоже был VPN, SSL и т.п. И это им не помогло. Поэтому я бы не был столь категоричен в высказываниях, что вместо открытого протокола можно накрутить VPN и "нам не страшен серый волк". А открытые протоколы безусловно в инет выпускать нельзя, это даже не обсуждается.

[sasamy]

"И ни один хакер-какер не подсунет мне левые настройки, как например в центре Москвы порнушку крутили на рекламных щитах" - я просто написал, что у админов экранов тоже был VPN, SSL и т.п. И это им не помогло. Поэтому я бы не был столь категоричен в высказываниях, что вместо открытого протокола можно накрутить VPN и "нам не страшен серый волк". А открытые протоколы безусловно в инет выпускать нельзя, это даже не обсуждается.

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