Здравствуйте, netch80, Вы писали:

N>Если использовать libusb и взять пример грамотной инициализации, то всё в разы проще.
N>Полугода там нет. Зная конкретные запросы к UPS и ответы на них — пару дней без безумной спешки.

Не зная протокола ? Я так не могу.

Здравствуйте, netch80, Вы писали:


O>>Это Вы еще до USB не дошли, наверное.

N>А что USB? С точки зрения прикладного программиста в нём самое кривое — отсутствие механизма подачи внимания от внешнего устройства.

Он сильно переусложнен, имхо. Если работать напрямую, а не через обертки. После того же serial, который я нежно люблю за простоту, USB — ад и геморрой.

AS>>А в чем проблема?
Q>А в том, что по-хорошему негоже клиенту сервером прикидываться
Какие нить аргументы против этой фичи кроме "негоже" есть?
А вот аргумент за: возможность трансфера файлов между двумя FTP серверами, инициированного клиентом, который через себя данные не пропускает при этом

Здравствуйте, ononim, Вы писали:

AS>>>А в чем проблема?
Q>>А в том, что по-хорошему негоже клиенту сервером прикидываться
O>Какие нить аргументы против этой фичи кроме "негоже" есть?
NAT и firewall.

O>А вот аргумент за: возможность трансфера файлов между двумя FTP серверами, инициированного клиентом, который через себя данные не пропускает при этом
Это без проблем делается без обратного подключения к клиенту.

AS>>>>А в чем проблема?
Q>>>А в том, что по-хорошему негоже клиенту сервером прикидываться
O>>Какие нить аргументы против этой фичи кроме "негоже" есть?
Q>NAT и firewall.
Тогда их еще не было. Они сами со себе являются хаками, основанными на "обычных" сценариях пользования TCP/IP

O>>А вот аргумент за: возможность трансфера файлов между двумя FTP серверами, инициированного клиентом, который через себя данные не пропускает при этом
Q>Это без проблем делается без обратного подключения к клиенту.
Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю.

Здравствуйте, ononim, Вы писали:

O>Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю.

... и по причине лёгкого абуза запрещена по умолчанию везде, кроме особо закрытых сетей.

Здравствуйте, netch80, Вы писали:

N>Что именно не нравится?
Так написали же. Проблемы с кодировками; наличие двух каналов связи, один из которых изначально устанавливался от сервера к клиенту; пассивный режим, требующий дополнительных портов и сокетов.

N>Отдельным каналом для данных? SCTP не было.
Отдельный канал не нужен при обычном TCP (и даже UDP).

N>Авторизация? Не было ни причины ни идей придумывать что-то сложнее.
N>ARPAnet тогдашних времён был нацелен на полное доверие и выживание при любой возможности, и решения были соответствующие.
N>Например, в SMTP-серверах до середины 90-х не было защиты от релеинга чужих писем. Потому что не было спама.
Защиту никто не критикует, это как раз понятно, что теперешних проблем с секьюрити тогда никто не предполагал.

Здравствуйте, ononim, Вы писали:

O>>>Какие нить аргументы против этой фичи кроме "негоже" есть?
Q>>NAT и firewall.
O>Тогда их еще не было. Они сами со себе являются хаками, основанными на "обычных" сценариях пользования TCP/IP
Ну если про NAT это еще можно сказать, то firewall -- извините, это не хак. Arpanet разрабатывалась как военная сеть и предположить тот факт, что не на всех машинах будут доступны все порты, можно было.

Q>>Это без проблем делается без обратного подключения к клиенту.
O>Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю.
Хотел написать, что вся эта красота отключена на 999 серверах из 1000, но меня опередили.

Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21?

O>>Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю.
N> ... и по причине лёгкого абуза запрещена по умолчанию везде, кроме особо закрытых сетей.
Ну мона запрещать не все подряд, а делать списки IPшников куда мона конектиться и/или разрешать оную фичу тока для доверенных юзеров, а не анонимусов.

Q>>>NAT и firewall.
O>>Тогда их еще не было. Они сами со себе являются хаками, основанными на "обычных" сценариях пользования TCP/IP
Q>Ну если про NAT это еще можно сказать, то firewall -- извините, это не хак. Arpanet разрабатывалась как военная сеть и предположить тот факт, что не на всех машинах будут доступны все порты, можно было.
"Недоступность портов" это ваще идиотская фишка файрволлов я считаю. Как и файрволлы сами по себе. IDS еще куда ни шло.
ЗЫ Я работаю в конторе у которой бизнес основан на файрволлах, так что знаю что говорю

O>>Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю.
Q>Хотел написать, что вся эта красота отключена на 999 серверах из 1000, но меня опередили.
Ну если рассматривать анонимнусные сервера и логины — то само собой

Q>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21?
Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует.
Философская причина: новая команда FTP — новая сущность, зачем? Мне всегда эстетически нравились архитектуры в которых базовым набором команд делаются все необходимые операции как конструктором, и не нравились где каждая команда — суть пользовательская операция.

Здравствуйте, okman, Вы писали:

O>Не зная протокола ? Я так не могу.

Все UPS'ы, что мне встречались, работали как communication device, т.е. обычный виртуальный COM-port.

Здравствуйте, quwy, Вы писали:

Q>NAT и firewall.

Грамотно настроенный NAT-сервер пропускает как активный, так и пассивный FTP.

Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>Я знаю, я знаю!!

AS>идеальный протокол вместо ftp — это WebDAV over https
ситуация. есть программа бэкапа, которая грузится с флешки. она поддерживает ftp. WebDAV -- увы и ах
ситуация N2: есть программа восстановления диска, которая тоже грузится с флешки и тоже как ни странно поддерживает только ftp, то ни разу не WebDAV
ситуация N3: есть хостер, который дает мне доступ по ftp для заливки файлов (практически все дают), кто дает по WebDAV? ну кто-то может и дает...

Здравствуйте, мыщъх, Вы писали:

AS>>идеальный протокол вместо ftp — это WebDAV over https
М>ситуация. есть программа бэкапа, которая грузится с флешки. она поддерживает ftp. WebDAV -- увы и ах
Меняем программу.

М>ситуация N2: есть программа восстановления диска, которая тоже грузится с флешки и тоже как ни странно поддерживает только ftp, то ни разу не WebDAV
Меняем программу.

М>ситуация N3: есть хостер, который дает мне доступ по ftp для заливки файлов (практически все дают), кто дает по WebDAV? ну кто-то может и дает...
Меняем хостера.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, мыщъх, Вы писали:

AS>>>идеальный протокол вместо ftp — это WebDAV over https
М>>ситуация. есть программа бэкапа, которая грузится с флешки. она поддерживает ftp. WebDAV -- увы и ах
C>Меняем программу.
какая программа бэкапа, которая грузится в флехи, поддерживает WebDAV? можно ли обменять без доплаты, т.к. программу я уже купил.

М>>ситуация N2: есть программа восстановления диска, которая тоже грузится с флешки и тоже как ни странно поддерживает только ftp, то ни разу не WebDAV
C>Меняем программу.
на что меняем, простите? программ для восстановления дисков можно пересчитать по пальцам одной руки.

М>>ситуация N3: есть хостер, который дает мне доступ по ftp для заливки файлов (практически все дают), кто дает по WebDAV? ну кто-то может и дает...
C>Меняем хостера.
во имя чего? чтобы пользоваться идеальным протоколом WebDAV, который идеален как персидская принцесса, вот только нормальный народ говорит на английском, испанском и паре тройке других языков.

Здравствуйте, ДимДимыч, Вы писали:

O>>Не зная протокола ? Я так не могу.
ДД>Все UPS'ы, что мне встречались, работали как communication device, т.е. обычный виртуальный COM-port.

Тебе, наверно, только хорошие встречались, или одной фирмы.
На рынке дешёвых — куча таких, которые только через HID, причём конкретные сообщения нигде не документированы.

BTW, Victron'ы (они же GE) до сих пор принципиально не держат USB. Или RS-232, или SNMP коробочка.

Здравствуйте, okman, Вы писали:

N>>Если использовать libusb и взять пример грамотной инициализации, то всё в разы проще.
N>>Полугода там нет. Зная конкретные запросы к UPS и ответы на них — пару дней без безумной спешки.
O>Не зная протокола ? Я так не могу.

Действия послать порцию октетов и получить ответ достаточно просты, чтобы не лезть в детали протокола.

Здравствуйте, Eugeny__, Вы писали:

O>>>Это Вы еще до USB не дошли, наверное.
N>>А что USB? С точки зрения прикладного программиста в нём самое кривое — отсутствие механизма подачи внимания от внешнего устройства.
E__>Он сильно переусложнен, имхо. Если работать напрямую, а не через обертки. После того же serial, который я нежно люблю за простоту, USB — ад и геморрой.

Мнэээ... RS-232, конечно, кажется простым, но только до тех пор, пока на него не наворотишь свой слой пакетизации, детекта устройства и так далее. После этого он становится не проще USB, а может, и сложнее.

Здравствуйте, netch80, Вы писали:

O>>Не зная протокола ? Я так не могу.

N>Действия послать порцию октетов и получить ответ достаточно просты, чтобы не лезть в детали протокола.

Идея была в том, чтобы осилить протокол USB, решая одну из базовых задач.
Честно признаюсь — мне это не удалось. Перечитал Агурова и pdf-ки с usb.org почти все,
наверное, а в голове по-прежнему каша. Как все эти descriptors и reports связаны, и
как эта вся кухня работает — не понял. Поэтому после USB такие протоколы, как FTP, кажутся
элементарщиной. А пользоваться либами, не постигнув сути происходящего, мне неинтересно.
Лучше я помучаюсь еще какое-то время, "созрею", а потом возьму, да и осилю.

Здравствуйте, ДимДимыч, Вы писали:

O>>Не зная протокола ? Я так не могу.

ДД>Все UPS'ы, что мне встречались, работали как communication device, т.е. обычный виртуальный COM-port.

Ну так речь же не о том, сложно или не сложно использовать протокол практически, как с
помощью библиотек, а о сложности самого протокола. Не могу сказать, что USB в этом
плане простой. И такие вещи, как virtual com, появились, видимо, тоже неспроста,
потому что программировать COM существенно проще.