При копировании папки с файлами NB рвёт соединение после передачи каждого файла

[z0hm]

В активном режиме при копировании папки с файлами NB рвёт соединение после передачи каждого файла, такое же поведение и у ТС.
http://forum.ru-board.com/topic.cgi?forum=5&topic=31718&start=7800#9

В пассивном режиме закачка идёт нормально.

[VictorVG]

@z0hm

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

Включите в настройках проблемного соединения поддержку активности на вкладке Соединение и увеличте его таймаут до 90 - 130 секунд. Обычно это помогает.

[z0hm]

В данном случае не помогает. Увеличение таймаута приводит лишь к большему времени зависания недвижущегося диалога копирования. Т.е. в результате в логе видим всё то же:
. 2015-10-17 00:00:51.390 Timeout detected.
. 2015-10-17 00:00:51.390 Got reply 1004 to the command 4
. 2015-10-17 00:00:51.390 Connection was lost, asking what to do.
. 2015-10-17 00:00:51.390 Asking user:
. 2015-10-17 00:00:51.390 Lost connection. ("Timeout detected.","")

Например в активном режиме таймаут стоит 15с, копируем папку с текстовыми файлами, на каждый уходит порядка 5с, после первого же скопированного файла NB "втыкается", чего-то ждёт оставшееся время, а потом выдаёт диалог о потере соединения. И меня грызут сомнения, что дело именно в кривизне сервера - в NB ранее уже были проблемы с таймаутами, может это из той же оперы? Поэтому и зарепортил.

[VictorVG]

Нет, тут явно серверная проблема с активным режимом. На работу приволокли прибор со встроенным QNX,с самописным qmyftpd сконфигурированым под активный режим. С моей стороны Tru64 UNIX и клиентом сидит mc а проблемы похожие. Только демон рвёт связь каждые 45 секунд или получив 16 Кб даннных. С трудом выяснили что ограничения вызванны банальным переполнением памяти в однокристалке. Разработчики использовали для управления прибором MCS-51, а у той адресное пространство как-то ограничено до 64К, ну ребятки и порезали всё что могли.:)

Включите в настройках проблемного соединения поддержку активности на вкладке Соединение и увеличте его таймаут до 90 - 130 секунд.

Поддержку активности (удержание соединения путём посылки клиентом SYNC/NOP в паузах между передачами данных) почему не выключили? Без этого смысла в увеличении таймаута нет.

[z0hm]

Поддержку активности (удержание соединения путём посылки клиентом SYNC/NOP в паузах между передачами данных) почему не выключили? Без этого смысла в увеличении таймаута нет.

Я полагал, что удержание должно вступать в работу перед наступлением таймаута, скажем секунд за 5-10 до таймаута выдаётся первая dummy команда - это у NB или у меня с логикой что-то не так?

[VictorVG]

Сам пор себе механизм удержания соединения не включается, а таймаут это период ожидания ответа от удалённого хоста и ставить его короче 90 секунд не стоит т.к. на время ответа влияет сквозная задержка сети и загрузка сервера. А первая составляющая в зависимости от канала и числа сегментов в текущем маршруте как раз равна 10 - 30 секунд и выше. Я и 50 - 70 секунд встречал даже на быстрых Frame Relay T-1/T-3 каналах (1,544/45 Мбит/с). Тут всё зависит от нагрузки промежуточных узлов и их количества на конкретном маршруте. Чем их больше тем больше задержка сети, и таймаут нужен в том числе и для её учёта чтобы не разорвать соединение раньше времени.

Механизм удержания включается клиентом по условию "Данных для передачи на сервер у меня нет но и оператор не сказал bay (завершение FTP сеанса), а время ожидания моего ответа сервером кончается и он может разорвать соединение которое рвать ещё нельзя" вне зависимости от наличия таймаута, но частично он его учитывает при оценке состояния сеанса. По большому счёту это сообщение серверу состояния "канал ещё нужен, но клиент в данный момент не готов им воспользоваться поскольку ждёт данные от локальной системы".

Правда и сервер может быть неверно настроен и потому рвать соединение ранее чем надо. Если к нему есть достут это стоит посмотреть и выставить ему таймаут ожидания ответа от клиента 130 - 150 секунд чтобы он не рвал соединение раньше времени. Иные сервера по умолчанию после завершения передачи ждут 0,5 - 0,8 сек и рвут связь. Я видел такие грамотные настройки, да и оправдания местных ребят обычно похожи как под копирку - "А сервер в локалке и там больше ждать не надо, зато я всё могу с консоли видеть! А то кидают мусор а мне после разбирай!".:)