Open dmak opened 7 years ago
Давайте по-русски писать, и смотреть что "имеем с гуся" - главное мы имеем спецификацию протокола RFC 959 : FILE TRANSFER PROTOCOL (FTP) оговаривающую в п. 3.5 (стр.24) условия при которых происходит возобновление прерванной передачи данных:
3.5. ERROR RECOVERY AND RESTART
There is no provision for detecting bits lost or scrambled in data transfer; this level of error control is handled by the TCP. However, a restart procedure is provided to protect users from gross system failures (including failures of a host, an FTP-process, or the underlying network). The restart procedure is defined only for the block and compressed modes of data transfer. It requires the sender of data to insert a special marker code in the data stream with some marker information. The marker information has meaning only to the sender, but must consist of printable characters in the default or negotiated language of the control connection (ASCII or EBCDIC). The marker could represent a bit-count, a record-count, or any other information by which a system may identify a data checkpoint. The receiver of data, if it implements the restart procedure, would then mark the corresponding position of this marker in the receiving system, and return this information to the user. In the event of a system failure, the user can restart the data transfer by identifying the marker point with the FTP restart procedure. The following example illustrates the use of the restart procedure. The sender of the data inserts an appropriate marker block in the data stream at a convenient point. The receiving host marks the corresponding data point in its file system and conveys the last known sender and receiver marker information to the user, either directly or over the control connection in a 110 reply (depending on who is the sender). In the event of a system failure, the user or controller process restarts the server at the last server marker by sending a restart command with server's marker code as its argument. The restart command is transmitted over the control connection and is immediately followed by the command (such as RETR, STOR or LIST) which was being executed when the system failure occurred.
и если соединение с удалённым сервером не отвечает условиям спецификации протокола, по возобновления передачи данных не происходит, частично переданный файл удаляется и операция начинается с начала в полном соответствии со спецификацией протокола FTP.
По-русски – нет проблем. В дополнение к RFC 959 от 1985 года есть ещё RFC 3659:
5.2. Error Recovery and Restart
STREAM mode transfers with FILE STRUcture may be restarted even though no restart marker has been transferred in addition to the data itself. This is done by using the SIZE command, if needed, in combination with the RESTART (REST) command, and one of the standard file transfer commands.
Но у нас в любом случае RFC959 основа, и если условия спецификации не соблюдаются процедура передачи начнётся с нуля. Давайте исходить из этого общего предположения и проверять от него чтобы быть уверенными что мы не встретились с общей ситуацией. И если в случае когда протокол допускает возобновление передачи с конца последнего успешно переданного блока происходит передача с начала файла, будем смотреть где происходит сброс счётчика переданных байт.
Я думаю что это происходит в WinSCP, и для проверки глянул бы как она себя ведёт в такой ситуации? FileZilla продолжает передачу с учётом факта обрыва, по крайней мере под демоном я это вижу, а WinSCP я не пользуюсь потому наблюдений по ней у меня нет.
Согласно Wikipedia, команда MLSD
является частью RFC3659. Эту команду я вижу в логе NetBox, то есть, NetBox уже использует эту спецификацию.
Как я понимаю, единственный вариант продолжить закачку по протоколу RFC959 – это использовать команду LIST
(?) + APPE
(у вас есть с использованием этой команды?), в то время как по протоколу RFC3659 – это SIZE
+ REST
+ STOR
(все поддерживаются сервером). В моём случае сервер отвечает клиенту, что он поддерживает докачку в STREAM mode по протоколу RFC3659:
FEAT
211-Features:
SIZE
REST STREAM
MDTM
MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
...
То есть, я не вижу причины, почему докачка невозможна. Вы говорите, что соединение с удалённым сервером не отвечает условиям спецификации протокола – какие именно должны быть соблюдены условия?
Дополнительная информация: Use of FTP “append” command.
Я думаю что это происходит в WinSCP
WinSCP тоже ведёт себя неприлично. Когда соединение обрывается (я отключал WiFi), он перелогинивается, но почему-то при повторной отправке файла возникает control connection timeout:
> 2017-04-14 15:41:00.431 TYPE I
< 2017-04-14 15:41:00.431 200 Type set to I
> 2017-04-14 15:41:00.431 PORT 10,0,0,36,228,168
< 2017-04-14 15:41:00.431 200 PORT command successful
> 2017-04-14 15:41:00.431 REST 114066508
< 2017-04-14 15:41:00.441 350 Restarting at 114066508. Send STORE or RETRIEVE to initiate transfer
> 2017-04-14 15:41:00.441 STOR 033.psd
< 2017-04-14 15:41:00.451 150 Opening BINARY mode data connection for 033.psd
. 2017-04-14 15:41:15.343 Timeout detected. (control connection)
. 2017-04-14 15:41:15.343 Copying files to remote side failed.
. 2017-04-14 15:41:15.343 Connection was lost, asking what to do.
При использовании FileZilla проблемы с докачкой не было. Тем не менее, были замечены два бага:
REST 102958971
+ STOR 033.psd
– в логе сервера они видны).Ну, вики великий "авторитет" - любая статья печатаемая там не появится без "одобрямс" со стороны т.н. "опытных участников" среди которых нет ни одного научного работника либо инженера, зато присутствуют исключительно маркетологи и сотрудники отделов продаж от спонсоров проекта - это пару раз признавали его руководители.:) Не просто так там к примеру в статьях по ЦПУ Alpha AXP приведена совсем иная техническая информация чем та, что печаталась в DEC Technical Journal - в 1997 права на ЦП Alpha AXP купила Intel и сразу объявила о сворачивании проекта как "морально устаревшего и исчерпавшего потенциал развития" хотя при его анонсе был определён его жизненный цикл - 25 лет. Но после полного и вдобавок с грубыми ошибками копирования архитектуры Alpha AXP для своих i586+/Itanium Intel купила права и закрыла проект, а до того производила DEC Chip AXP 2106x и честно воровала чужие идеи.:)
Что до FTP - RFC-959 это база протокола которую обязаны реализовывать все, а RFC3659 это её расширение и её могут реализовывать уже не все, хотя она и относится к числу настоятельно рекомендуемых. У меня pure-ftpd демон реализует оба RFC, но принудительно заставляет клиента работать по RFC-3659.
То, что мы с вами видим в логе WinSCP говорит нам "Процедура докачки не реализована в WinSCP", а в FileZilla упоминаемая вами проблема FTPS/TLS от 2015-го года давно исправлена, а вывод в лог отправленных на сервер команд - для этого у FZ есть настройки и коли кому надо тот под себя настраивает вид лога.
Я понимаю, что не всему написанному на wikipedia нужно верить. Если у вас есть замечания к именно той статье, на которую я привёл ссылку, то давайте будем более конструктивны. Ваше замечание насчёт CPU Alpha AXP вы можете занести прямо на страничку Wikipedia, в крайнем случае есть закладка "Talks" где вряд ли кто-то будет вам закрывать рот – напишите об этом.
Клиент WinSCP посылает серверу команды из RFC-3659, соответственно он должен правильно его реализовывать. Но WinSCP хоты бы "пытается" начать докачку, в то время как NetBox сразу перезаписывает, без предупреждения.
FileZilla был скачен мною сегодня, версия 3.25.1. Я без особых претензий к этому клиенту, но эту ошибку эту я не придумал. Возможно, что-то настроил в нём не так – надо посмотреть повнимательнее. А консоль неконсистентна: вначале он пишет в консоль
Command: PWD
Command: TYPE I
Command: PASV
Command: MLSD
но после восстановления от сбоя команды, посылаемые на сервер, не попадают в консоль. Для кого-то это может показаться логичным, для меня – нет. Консоль = верхнее окошко в GUI, а не лог-файл на файловой системе. В любом случае, докачка в нём работает, если не форсировать FTPS/TLS.
Реализация протоколов восстановления соединения зависит от ответа сервера - какой режим он может реализовать, так что тут надо смотреть.
Реализация протоколов восстановления соединения зависит от ответа сервера
Я не уверен, что на сегодняшний день есть хоть один "серьёзный" FTP сервер, который не реализует RFC-3659. В конце-концов, ничто не мешает объявить, что NetBox работает только с FTP серверами, которые реализуют RFC-3659. По факту я не уверен, что кто-то тестировал NetBox на "чистом" RFC-959.
Я начал параллельную дискуссию насчёт проблемы в WinSCP на форуме. Пока не понятно, в чём именно дело, но для WinSCP есть workaround: использовать passive mode.
Ну, с ворграундом понятно - в пассивном режиме именно сервер выбирает набор портов соединения, а в активном наоборот - клиент. А это не все сервера разрешают из соображений безопасности. Насчёт реализации RFC-959 без RFC-3659 - роутер ZyXEL, NDMS 2.0.8C (LINUX), pure-ftpd :
Protocol - Server and protocol information Server information 21-Remote system UNIX Type: L8 21-Session protocol FTP 21-Compression: No
Protocol capabilities/information
35-Can change permissions: Yes 35-Can change owner/group: No 35-Can execute arbitrary command: Protocol commands only 35-Can create symlink/hardlink: No/No 35-Can lookup user groups: No 35-Can duplicate remote files: No 35-Can check available space: No 35-Can calculate file checksum No 35-Native text (ASCII) mode transfers: No
Additional protocol information
NetBox = The server supports these FTP additional features: EPRT IDLE MDTM SIZE MFMT REST STREAM MLST type;size;sizd;modify;UNIX.mode;UNIX.uid;UNIX.gid;unique; MLSD UTF8 ESTA PASV EPSV SPSV ESTP
для дома достаточно, т.к. девайс стоит исключительно в качестве сетевого принт-сервера для лазерника, а поелику на HDD есть свободное место, то там расположен вспомогательный FTP с локальной файло-помойкой. Скорость записи не ахти - USB 2.0 более 15 - 18 Мб/с не позволяет, но для "сегодня скинуть, завтра флешкой заберут" хватает.
Команды в Additional protocol information
– это то, что поддерживает сервер? Если да, то почти все эти команды выходят за рамки RFC-959. Иначе, возможно, в прошивку положили обрезанную версию pure-ftpd
, поскольку в стандартной версии он реализует массу RFC:
Pure-FTPd has one of the most complete implementation of the FTP protocol specifications. It includes the protocol basics, plus modern extensions like MLST/MLSD (extensible and mirror-safe directory listings). Pure-FTPd is the first daemon to implement ESTA and ESTP.
SEE ALSO RFC 959, RFC 2228, RFC 2389, RFC 2428 and RFC 4217.
SPSV
Так или иначе, мне кажется, можно последовать принципу 80/20, то есть, реализовав поддержку докачки по протоколу RFC-3659 покрыть 80% всех usecases.
Похоже да, прошивка имеет размер 8 Мб чтобы влезала в однокристалку на которой собран роутер. С идеей расширения согласен.
Для справки. Докачку в WinSCP в active mode уже с год как починили (в passive работала и раньше):
. 2018-09-04 23:04:26.969 Binary transfer mode selected.
. 2018-09-04 23:04:26.969 Starting upload of D:\backup.rar
> 2018-09-04 23:04:52.026 TYPE I
< 2018-09-04 23:04:52.031 200 Type set to I
> 2018-09-04 23:04:52.031 PORT 10,0,14,87,238,198
< 2018-09-04 23:04:52.033 200 PORT command successful
> 2018-09-04 23:04:52.033 REST 3897103249
< 2018-09-04 23:04:52.036 350 Restarting at 3897103249. Send STORE or RETRIEVE to initiate transfer
> 2018-09-04 23:04:52.036 STOR backup.rar
< 2018-09-04 23:04:52.043 150 Opening BINARY mode data connection for backup.rar
. 2018-09-04 23:04:52.044 Session ID reused
. 2018-09-04 23:04:52.045 Using TLSv1.2, cipher TLSv1/SSLv3: ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA, ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
. 2018-09-04 23:04:52.045 TLS connection established
. 2018-09-04 23:04:53.044 Increasing send buffer from 262144 to 1048576
...
А RFC-1738 чинить и не планируют - год назад им написал по поводу #255 и на днях ответили - IETF RFC are recommendations, but their strict adherence is not necessary. - IETF RFC это рекомендации, но их строгое соблюдение не обязательно. :)
Не совсем понимаю, как RFC-1738 связан с текущим issue про докачку по FTP. А у вас есть лог того, как выглядит докачка на каком-нибудь сервере? Мне любопытно, как это выглядит.
RFC-1738 Uniform Resource Locators (URL) - поломали, так что тут можно получить проблему установки соединения в процессе докачки.
Под рукой лога нет, но по памяти там будет запись о передаче данных с позиции ... бит .
Под рукой лога нет, но по памяти там будет запись о передаче данных с позиции ... бит.
Тем не менее, интересен весь лог, с самого начала (USER
, PASS
, FEAT
и т.д.)
Будет - дам, пока случая его получить не было. У меня давненько связь не рвалась.
У меня давненько связь не рвалась.
Это легко можно сэмулировать отключив во время upload на минутку WiFi в system tray, или вынув сетевой кабель из сокета в сетевой карте.
Только одна труднгость :) - железо стоит в стойке и к кабелям не подберёшся. Потому -будет момент - будет и лог,а специально играть нет времени.:(
When I choose "Resume" and connection is interrupted, NetBox re-establishes the connection automatically after some timeout (OK), but then automatically does "overwrite" of destination file (wrong). So each time the connection is reset/interrupted, the destination file is reset and upload begins from scratch. Expected that interrupted upload is resumed.
NetBox v2.2.0.427, also posted to forum.