Protocol
- From
- Stas Degteff (2:5080/102.1)
- To
- Alex Kocharin
- Date
- 2006-03-29T21:41:06Z
- Area
- RU.UNIX.FTN
Привет, Alex!
Ответ на сообщение Alex Kocharin (2:5012/2.470) к All, написанное Вторник 28 Марта 2006 в 20:15:08:
AK> Ниже представлен более другой протокол, чем я использовал ранее. Скоро я
AK> попытаюсь его реализовать в своем мылере. Жду конструктивной критики. :)
AK> Понятно, что протокол, который я использовал, очень избыточен и не то,
AK> чтобы сложен, но данные обрабатываются довольно долго. Я придумал немного
AK> более другой сабж, который имхо лучше алгоритмизируется и в котором
AK> отсутствуют все проблемы с непечатаемыми символами и символами, которые не
AK> лезут в HTTP-запрос.
AK> В этом протоколе все данные передаются _одним_ блоком в base64encoded.
Это тоже избыточно. Давай начнём с концепции.
Можно передавать управляющую информацию в виде XML (парсеры есть готовые и в php, и в perl), а данные передавать в бинарном виде в ответ на запрос файла.
В целях безопасности клиент должен передавать пароль только после получения ответа от сервера. При этом реализовать CRAM - раз плюнуть.
Для передачи имени файла можно использовать заголовки HTTP и параметры CGI. Файл можно передавать шифрованным.
Сессия отслеживается за счёт передачи идентификатора, дополнительно после хендшейка идентификатор сессии каждый раз может хешироваться с помощью пароля на сессию. (Надо подумать, насколько сложно это реализовать.)
В результате сессия будет выглядеть приблизительно так (теги и параметры в XML заданы для примера, переводы строки сделаны для красоты, в XML все символы вне <> игнорируются):
-запрос 1
POST /IWnode HTTP/1.0
Content-type: text/xml
<SYSTEM ADDR="2:50/13@fidonet" ADDR="2:5012/2.470@fidonet" SYS="AK-Station"
ZYZ="Alex Kocharin" OPT="CRAM-MD5 ZCRYPT"><EOF>
-Ответ 1
Content-type: text/xml
<SESSIONID=12345ACDF>
<SYSTEM ADDR="2:50/2@fidonet" OPT="CRAM-MD5 ZCRYPT">
<CRAM-MD5 Challenge="34eiur0uferaj89tw34ut89aiafq0wjrwfjwfj4rj">
<EOF>
-запрос 2
POST /IWnode HTTP/1.0
Content-type: text/xml
<SESSION ID=12345ACDF>
<CRAM-MD5 Response="a787097676787f7088098786c08-98d989998efefa">
<EOF>
-Ответ 2
Content-type: text/xml
<SESSION ID=12345ACDF>
<OK secure>
<EOF>
-далее идут шифрованные данные, например по алгоритму из info-zip и указывается Content-type: application/octet-stream
клиент в запросе передаёт список имеющихся файлов для сервера,
сервер в ответе передаёт список имеющихся файлов для клиента и запрашивает первый файл.
клиент запрашивает файл и далее в том же запросе отдаёт первый файл
сервер в ответе подверждает приём, запрашивает следующий файл и отдаёт запрошенный файл клиенту.
Если все файлы из списка получены - делаем запрос нового списка и отдаём запрошенный ремотой файл.
Сессия завершается по обмену пустыми списками.
Надо также предусмотреть команды удаления файлов из дальней очереди, модификаторы докачки и т.п.
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