Protocol
- From
- Stas Degteff (2:5080/102.1)
- To
- Oleg Lobachev
- Date
- 2006-03-30T22:50:48Z
- Area
- RU.UNIX.FTN
Привет, Oleg!
Ответ на сообщение Oleg Lobachev (2:2432/260.1) к Alex Kocharin, написанное Среда 29 Марта 2006 в 22:40:48:
OL> Тут или так:
OL> начало_сессии: запрос - отзыв
OL> аутентификация: CRAM (черным ящиком серия запросов и отзывов)
Эти два объединяются, реально уложимся в два запроса.
OL> передача файла: запрос - кусок файла - подвтерждение - подтверждение
OL> подтверждения (хм, Остапа несло)
Подтверждение получения подтверждения - это запрос следующего файла (или пустой запрос).
OL> передача следующего файла: см. выше, и так до опупения.
OL> конец_сессии: запрос - отзыв
OL> Что, хоть и несколько overloated, но логично, когда файлов у тебя много, и
OL> ты их запрашиваешь одним кусоком.
OL> Или так:
OL> начало_сесси: запрос - файл. конец_сессии.
OL> Подтверждениями пусть tcp занимается, за один раз передается один файл.
Подтверждение приёма нужно передать во втором запросе.
OL> Хех, да посмотри на само http. Вот это - вторая схема. Какой-то pop3 -
OL> первая.
Я думал над тем, чтобы аутентификацию проводить средствами HTTP (оптимально digest-auth), тогда только подтверждение о приёме файла потребует дополнительной пары запрос-ответ:
- запрос к серверу, ответ 407 и challenge в заголове HTTP;
- запрос к серверу с параметрами аутентификации в заголовке; сервер отдаёт запрос скрипту, скрипт обрабатывает и даёт ответ (в ответе - либо список файлов, либо файл, либо все файлы подряд)
- запрос к серверу, ответ 407 и challenge в заголове HTTP;
- запрос к серверу с параметрами аутентификации в заголовке и с данными о принятых файлах; сервер отдаёт запрос скрипту, скрипт отвечает об удалении файлов.
Но это сразу ограничивает сферу применения: вебсервер должен поддерживать такую аутентификацию.
И ещё один недостаток односторонней аутентификации: лже-сервер с лёгкостью сможет провести реальную сессию с клиентом... Если аутентификацию проводить в программе, есть возможность реализации двухсторонней CRAM аутентификации.
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