Protocol

From: Oleg Lobachev (2:2432/260.1)
To: Alex Kocharin
Date: 2006-03-29T22:40:48Z
Area: RU.UNIX.FTN

Say yes, Alex. At least say hello.

30 Mar 06 00:46, you wrote to Stas Degteff:

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

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

(Задумчиво) yacc? ;)

Другое дело, что 1) это действительно ориентация на ээ... структуру
представления данных, а не на язык. Парсеров XML - дофига, на всем от сей до
тикля. 2) Если можно обойтись без XML, лучше без него обойтись. Кроме того, это
ж типа обертка для мейлера, да? Щаз вспомним, что траффик вроде бы платный и
будем придавливать XML gzip'ом на лету. Бр-рррр.

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

Строки фиксированной длины - зло. И 60-е годы прошлого века.

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

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

А об объеме ты подумал? ;))

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

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

Challenge-Response Authentication Mechanism.

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

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

(Мрачно) Чтоб никто не догадался.

AK> Мне кажется, что лучше, если сервер видит один запрос как полноценную
AK> сессию, а клиент в одной сессии дает столько запросов, сколько _ему_
AK> надо. Так отпадают все проблемы с таймаутами, обрывами, etc. И bsy'шки
AK> залипать не будут. :)

Если я тебя правильно понял - welcome to the DoS.

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

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

Если ты уж _так_ упрощаешь, что у тебя сессия выглядит как "запрос - на файл",
то для следующего файла разумнее посылать еще один запрос - то бишь начать еще
одну сессию вида "запрос - на файл".

SD>> Сессия завершается по обмену пустыми списками.

AK> Вот он, лишний запрос...

Ты еще от CRAM'а лишние запросы начни отрывать. ;)

Тут или так:

начало_сессии: запрос - отзыв
аутентификация: CRAM (черным ящиком серия запросов и отзывов)
передача файла: запрос - кусок файла - подвтерждение - подтверждение
подтверждения (хм, Остапа несло)
передача следующего файла: см. выше, и так до опупения.
конец_сессии: запрос - отзыв

Что, хоть и несколько overloated, но логично, когда файлов у тебя много, и ты
их запрашиваешь одним кусоком.

Или так:
начало_сесси: запрос - файл. конец_сессии.

Подтверждениями пусть tcp занимается, за один раз передается один файл. Хех, да
посмотри на само http. Вот это - вторая схема. Какой-то pop3 - первая.

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

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

Нефига себе детали... А потом удивляемся почему оно реализовано через задницу.

Вообщем, еще раз: разработка хорошего, надежного, быстрого протоколла, с
попытками уменьшить время отзыва, возможность DoS и прочие вещи - это очень
хитрая штука. Реализация уже готового хорошего протоколла - тоже весьма хитрая
штука. Поиск граблей во всем этом растягивается на десятилетия. Поэтому для
применений в real world, а не на очередной лабе по сетевому программированию,
лучше взять уже имеющийся протоколл, с уже имеющейся реализацией на
твоем_любимом_языке. Прикручивание оно на server side, доточка нужной
функциональности, раздача клиентам и объяснение на какую кнопку Ok надо жать
оставляется читателю в качестве упражнения. ;)

Greetingz Oleg

---
* Origin: Thou hast seen nothing yet. -- Miguel de Cervantes (2:2432/260.1)
SEEN-BY: 46/50 50/12 400/567 814 450/1024 452/25 154 461/1313 2432/260 4614/20
SEEN-BY: 4615/21 4635/1024 4642/4 5000/5000 5001/100 5002/63 5003/58 5010/2 53
SEEN-BY: 5011/13 5012/30 46 5015/28 221 5019/31 5020/545 715 760 1641 1982
SEEN-BY: 5020/2238 2871 4441 5021/29 44 5025/3 5027/12 5028/61 5029/60
SEEN-BY: 5030/115 830 901 1080 1400 5035/38 5036/10 5041/4 5042/12 21 5049/19
SEEN-BY: 5049/164 5053/16 5054/1 8 9 37 45 50 63 67 89 5059/9 5062/10 5063/3
SEEN-BY: 5064/7 5070/156 5071/22 5072/333 5077/70 5078/20 5080/111 147 239
SEEN-BY: 5080/1003 5085/13 87 5093/4 33 55 5095/20 5096/18 5097/31 64 303
SEEN-BY: 6000/0 1 12 6001/10 6028/1 6055/2 6083/12
PATH: 2432/260 5080/1003 5020/545 5054/1 37