Protocol

From

Stas Degteff (2:5080/102.1)

To

Alex Kocharin

Date

2006-03-30T22:37:04Z

Area

RU.UNIX.FTN

   Привет, Alex!

    Ответ на сообщение Alex Kocharin (2:5012/2.470) к Stas Degteff, написанное Четверг 30 Марта 2006 в 00:46:28:


SD>>  Давай начнём с концепции.
SD>> Можно передавать управляющую информацию в виде XML (парсеры есть
SD>> готовые и в php, и в perl),

AK> Не стоит ориентироваться на какой-либо язык. А так, при использовании
AK> других языков, придется огребать проблемы с парсингом...

XML - стандартен и библиотеки для работы с XML уже разработаны для всех популярных языков программирования. php и perl я привёл потому что расчёт на работу на хостинге, а для хостингов типичными являются эти языки.

AK> Да и всегда проще читать строки фиксированной длины, чем парсить.

Хм. Откуда фиксированная длина (например) у названия станции? Сразу накладываешь ограничения.

SD>>  а данные передавать в бинарном виде в
SD>> ответ на запрос файла.

AK> Кстати, хотелось бы избежать бинарного вида вообще. Хотя бы ради
AK> единообразия. В твоем предложении сервер отдает файлы в бинарном виде, а
AK> клиент - в текстовом. (бинари в пост-данные вроде не лезут)

Файл клиент вполне может отдавать в двоичном виде - при условии, что прокси-сервер (если работа идёт через него) пропустит такой запрос.


SD>> В целях безопасности клиент должен передавать пароль только после
SD>> получения ответа от сервера. При этом реализовать CRAM - раз плюнуть.

AK> А что есть CRAM?

Challenge - response authentication method. Аутентификация с использованием вопроса и ответа. Сервер задаёт вопрос (случайную последовательность), клиент на основе вопроса и пароля генерирует ответ и передаёт его серверу. Сервер у генерирует свой вариант ответа и сравнивает с полученным. Совпали - ОК. Не совпали - отлуп.

SD>> Для передачи имени файла можно использовать заголовки HTTP и параметры
SD>> CGI. Файл можно передавать шифрованным.

AK> А зачем шифровать файл?

Чтобы из PKT не вытащили снифером пароль.

SD>> Сессия отслеживается за счёт передачи идентификатора, дополнительно
SD>> после хендшейка идентификатор сессии каждый раз может хешироваться с
SD>> помощью пароля на сессию. (Надо подумать, насколько сложно это
SD>> реализовать.)

AK> Я думал об идентификаторе сессии, но в конце концов отказался от него. Для
AK> экономии времени и траффика, хотелось бы иметь наименьшее число запросов. А
AK> так могут потребоваться лишние запросы для координации и закрытия сессии.

Один запрос - инициация, один - закрытие.

AK> Советую не забывать, что здесь запросы получает апач, обработка каждого
AK> запроса им займет некоторое время. Так что, в отличии от того же binkp,
AK> необходимо избежать лишних "пустых" запросов.

Лишних запросов избежать невозможно: серверу требуется подтверждение приёма файла клиентом, без этого удалять файл нельзя.

....

SD>> клиент в запросе передаёт список имеющихся файлов для сервера,
SD>> сервер в ответе передаёт список имеющихся файлов для клиента и
SD>> запрашивает первый файл.

AK> Хотелось бы предоставить возможность запроса нескольких файлов.

Кто мешает клиенту сделать несколько параллельных запросов? Тут-то идентификатор сессии и пригодится.

...

SD>> Надо также предусмотреть команды удаления файлов из дальней очереди,
SD>> модификаторы докачки и т.п.

AK> Ну это уже детали...

Очень важные детали. В хорошо спроектированном протоколе _нет_ мелочей.

Stas Degteff
... Golded+,Binkd,Husky developer.Jabber:stas.grumbler@plotinka.ru,ICQ:24628713
--- GoldED+/W32-MINGW 1.1.5-b20060326 (WinNT 5.0.2195-SP4 AMD_K7_M4)
 * Origin: Grumbler mail station, Ekaterinburg. (2:5080/102.1)
SEEN-BY: 46/50 47/77 50/12 203 400/814 450/186 1024 451/30 454/9 465/285
SEEN-BY: 469/418 712/256 4646/15 5000/5000 5001/5001 5002/50 79 5003/57
SEEN-BY: 5010/53 5011/13 5012/23 46 5015/28 221 5019/31 5020/154 175 400 545
SEEN-BY: 5020/639 715 758 830 937 1523 1604 1982 2020 2142 2238 2871 4441
SEEN-BY: 5021/29 5022/128 5025/3 750 5026/45 5027/12 5030/49 115 436 556 966
SEEN-BY: 5030/1063 1900 5031/47 70 5035/38 5040/47 5042/13 5043/3 5049/50
SEEN-BY: 5053/16 5054/1 8 9 37 45 63 67 89 5059/9 37 5061/120 5062/1 10 5063/3
SEEN-BY: 5064/7 5067/2 5070/1222 5077/70 5080/41 68 72 80 102 135 172 180 185
SEEN-BY: 5080/196 223 229 801 1003 5083/21 5085/13 5090/108 113 5095/20
SEEN-BY: 5096/18 5099/11 6000/0 1 12 6001/10 6090/1

PATH: 5080/102 68 80 5020/4441 545 5054/1 37