FTP-client OR ? Опции

[Allregia]

Привет всем.

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

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

[Allregia]

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

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

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

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

[politen]

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

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

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

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

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

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

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

[sasamy]

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

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

[AlexandrY]

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

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

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

[sasamy]

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

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

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

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

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

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

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

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

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

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

[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 на дивайсы. А вот работа с Линуксом на базе каких-нить фреймворков распределенного взаимодействия (хотя таких не знаю) потребует и на дивайсах Линукса.