В RFC0959 упоминается следующая процедура отмены передачи:
1) Telnet IP сигнал
2) Telnet Synch сигнал
3) ABOR команда
Цеплялся двумя телнетами к виндовому FTP-серверу (по Control и по Data).
Какой-либо реакции на вложенные команды получить не удалось.
Похоже, что сервер просто игнорирует команды во время передачи данных (считывает, но не исполняет).
Насколько правильно такое поведение?
Насколько критично будет для клиентов, если я заложу в свой сервер аналогичное поведение?
Клиенты предполагаются обычные Total Commander, FAR, проводник.
З.Ы. Total Commander'овский клиент посылает Synch и ABOR, потом просто разрывает соединение данных
(по таймауту что-ли, не дождавшись разрыва со стороны сервера?).
R.O. Prokopiev wrote: > > Реализую простенький FTP-сервер. > > В RFC0959 упоминается следующая процедура отмены передачи: > 1) Telnet IP сигнал > 2) Telnet Synch сигнал > 3) ABOR команда > > Цеплялся двумя телнетами к виндовому FTP-серверу (по Control и по Data). > Какой-либо реакции на вложенные команды получить не удалось. > Похоже, что сервер просто игнорирует команды во время передачи данных > (считывает, но не исполняет).
А ты передаешь Synch как TCP urgent data? Если нет, стоит попробовать.
> Насколько правильно такое поведение? > Насколько критично будет для клиентов, если я заложу в свой сервер > аналогичное поведение? > Клиенты предполагаются обычные Total Commander, FAR, проводник.
Я бы сделал, как в RFC.
> З.Ы. Total Commander'овский клиент посылает Synch и ABOR, потом просто > разрывает соединение данных > (по таймауту что-ли, не дождавшись разрыва со стороны сервера?).
Я думаю, он посылает Synch и ABOR из вежливости по отношению к тем
серверам, которые эту последовательность поддерживают. Клиенту, если он
не хочет сохранить управляющее соединение, от этого аборта легче не
становится.
R.O. Prokopiev wrote: > > Здравствуйте, Pzz, Вы писали: > > Pzz>А ты передаешь Synch как TCP urgent data? Если нет, стоит попробовать. > > Что за urgent data? > поподробнее пож.
См. инструкцию на send() на предмет флага MSG_OOB.
Здравствуйте, Pzz, Вы писали:
>>>А ты передаешь Synch как TCP urgent data? Если нет, стоит попробовать. >> Что за urgent data? >См. инструкцию на send() на предмет флага MSG_OOB.
Где-то описано, что Synch должен передаваться по OOB?
Попробовать, оно конечно можно, только смысла особого нет.
На тех сокетах, на которых будет работать мой FTP-сервер OOB нет и не будет.
Интересно, а как работают с вложенными командами другие FTP-серверы?
линуксовые например?..
R.O. Prokopiev wrote: > >>>>А ты передаешь Synch как TCP urgent data? Если нет, стоит попробовать. >>> Что за urgent data? >>См. инструкцию на send() на предмет флага MSG_OOB. > Где-то описано, что Synch должен передаваться по OOB?
RFC 854. "TELNET PROTOCOL SPECIFICATION"
THE TELNET "SYNCH" SIGNAL, страницы 8-10:
. . . . .
To counter this problem, the TELNET "Synch" mechanism is
introduced. A Synch signal consists of a TCP Urgent notification,
coupled with the TELNET command DATA MARK. The Urgent
notification, which is not subject to the flow control pertaining
to the TELNET connection, is used to invoke special handling of
the data stream by the process which receives it. In this mode,
the data stream is immediately scanned for "interesting" signals
as defined below, discarding intervening data. The TELNET command
DATA MARK (DM) is the synchronizing mark in the data stream which
indicates that any special signal has already occurred and the
recipient can return to normal processing of the data stream.
> Попробовать, оно конечно можно, только смысла особого нет. > На тех сокетах, на которых будет работать мой FTP-сервер OOB нет и не будет.
Интересно, что это за соцкеты такие?
Я писал как-то FTP сервер на сокетах, которые не позволяли принимать OOB
(т.е., принимать-то они принимали, но наверх отдавали как обычные
данные). Это было PC/TCP.
Мое решение было — команды обрабатываются даже во время передачи файла.
Побочным эффектом была возможность запустить несколько файловых передач
одновременно с одного управляющего содинения
> Интересно, а как работают с вложенными командами другие FTP-серверы? > линуксовые например?..
Ну, во всяком случае, на break они, как правило, реагируют.
Здравствуйте, Pzz, Вы писали:
Pzz>R.O. Prokopiev wrote: >> >>>>>А ты передаешь Synch как TCP urgent data? Если нет, стоит попробовать. >>>> Что за urgent data? >>>См. инструкцию на send() на предмет флага MSG_OOB. >> Где-то описано, что Synch должен передаваться по OOB?
>RFC 854. "TELNET PROTOCOL SPECIFICATION" > [...]
200 OK
>> На тех сокетах, на которых будет работать мой FTP-сервер OOB нет и не будет. >Интересно, что это за соцкеты такие?
Такие вот сокеты, местного розлива. Для одной железки.
>Мое решение было — команды обрабатываются даже во время передачи файла. >Побочным эффектом была возможность запустить несколько файловых передач >одновременно с одного управляющего содинения
Ну это уж черезчур
В спецификации, имхо, такого не предусмортено.
Клиенту не понятно будет, какой ответ соответствует какому потоку данных.
Достаточно поддержки вложенных комманд ABOR, STAT, QUIT:
Certain commands (such as ABOR, STAT, QUIT) may be sent over the
control connection while a data transfer is in progress. Some
Сервер мой будет простым: TYPE I, MODE S, STRU F.
Файлы небольшие — докачки не будет ( REST тоже не буду реализовывать )
Так что наверно и без вложенных команд можно обойтись...
R.O. Prokopiev wrote:
>>> На тех сокетах, на которых будет работать мой FTP-сервер OOB нет и не > будет. >>Интересно, что это за соцкеты такие? > Такие вот сокеты, местного розлива. Для одной железки.
Ну, к самодельным соцкетам OOB приладить не трудно.
В TCP нет настоящего OOB в смысле возможности передать некоторое
количество данных в обход потока. Передать можно только указатель на
местоположение OOB в общем потоке. Подразумевается при этом, что
принимающая сторона, узнав, что ей впереди светит OOB, может быстренько
прочитать поток до этого места. Что собственно Телнет и делает в
Synch-режиме — пропускает все, кроме команд, пока не дочитает до OOB.
>>Мое решение было — команды обрабатываются даже во время передачи файла. >>Побочным эффектом была возможность запустить несколько файловых передач >>одновременно с одного управляющего содинения > Ну это уж черезчур > В спецификации, имхо, такого не предусмортено. > Клиенту не понятно будет, какой ответ соответствует какому потоку данных.
А нефига посылать вложенные команды, если не можеть разгрести результаты
— т.е., это уже не моя проблема
> Достаточно поддержки вложенных комманд ABOR, STAT, QUIT: > Certain commands (such as ABOR, STAT, QUIT) may be sent over the > control connection while a data transfer is in progress. Some
А что делать с остальными командами, если такая все же придет?
Сейчас бы я, наверное, возвращал на них какую-нибудь ошибку. Но в
молодости выбираешь решение, которое кажется наиболее кульным
> Сервер мой будет простым: TYPE I, MODE S, STRU F. > Файлы небольшие — докачки не будет ( REST тоже не буду реализовывать ) > Так что наверно и без вложенных команд можно обойтись...
Тебе в любом случае придется поиспытывать его с разными клиентами.
Я ожидаю больше всего сложностей в том, чтобы "помочь" клиентам
правильно показывать содержимое директории. RFC по FTP не описывает, в
каком виде отдается список файлов. Те клиенты, которые пытаются
показывать всякую дополнительную информацию про файлы (т.е., практически
все клиенты, кроме command line), используют разные эвристики, чтобы
догадаться, как все же эту информацию с сервера извлечь.
Твой сервер будет нестандартным, поэтому клиентам будет тяжеловато с ним
работать — придется подгонять сервер в совершенно неожиданных местах...
