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. И в нем нет понятия серверов и клиентов, а есть только сервисы и потребители.
Если сервисы считать отдаленным аналогом серверов, то они в приложении центра сбора информации как раз будут находится на удаленных устройствах.