Поддержание подключения к FTP-контролю

Question

Некоторое время назад я задал вопрос, касающийся поддержания контрольного соединения в сеансе FTP во время большой передачи.Хотя я и добился успеха после того, как реализовал решение для вопроса, который я уже задал , похоже, что проблема заключается в ISP, то есть из-за того, что мои контрольные соединения умирают во время больших передач.

Интересно, что старая клиентская программа FTP «Leap-FTP» решает эту проблему, просто отправляя команды «NOOP» на сервер по управляющему соединению во время загрузки.В то время как другие популярные клиенты умирают во время переносов (Filezilla, мой скрипт на Python FTP), LeapFTP хорошо работает из-за этого обходного пути.

Я провел некоторое исследование потоков и очереди, но у меня возникли проблемы с созданием кодачтобы это произошло.

Решение кажется достаточно простым (по крайней мере, в моей голове): инициируйте загрузку, пока запускается эта функция загрузки, отправляйте команду NOOP каждые n секунд.Прекратите посылать команду NOOP после завершения функции загрузки.

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

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

Спасибо!

Answer 1

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

Answer 2

Чтобы обрабатывать несколько сокетов одновременно в одной программе, вы можете использовать функцию select вместо потоков.Это либо проще, либо сложнее, в зависимости от вашего опыта программирования.

Я считаю, что потоки обычно просты, но когда что-то идет не так, отладка, это настоящая боль, когда пишется код для мультиплексирования сокетов с использованием selectявляется более сложным, но менее трудным для отладки, чем потоки.

Основы использования select состоят в том, что вы настраиваете свои сокеты и вызываете функцию select.Он скажет вам, какие сокеты готовы для чтения или записи.Тогда вы проверяете время.Если с момента вашего последнего NOOP прошло X секунд, отправьте его на контрольный разъем.Если сокет передачи готов для чтения или записи, обработайте его.Если контрольный разъем готов к чтению, прочитайте его и проверьте, нет ли ответа NOOP, сообщений об ошибках, закрыт ли канал управления и т. Д.

Answer 3

Так как в данном случае вам все равно (сильно, во всяком случае) о производительности, вероятно, проще всего использовать отдельный поток для него, который находится в цикле, просто спит в течение N секунд, проверяет, отменен ли он, и если не посылает NOP и снова спит.