Protocol

From

Oleg Lobachev (2:2432/260.1)

To

Alex Kocharin

Date

2006-03-30T09:48:34Z

Area

RU.UNIX.FTN

* Replying to a msg in carbon.copy.

Say yes, Alex. At least say hello.

30 Mar 06 10:29, you wrote to me:

 AK>  * Forwarded from area 'ru.unix.ftn'
 AK>>> Да и всегда проще читать строки фиксированной длины, чем парсить.
 OL>> Строки фиксированной длины - зло. И 60-е годы прошлого века.

 AK> А в asciiz строках один байт лишний. ;)

(Пожимая плечами) asciid наше все. ;)

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

 AK> А у меня диалап и модем со сжатием. :))))

Не роляет.

 AK> Но в запросе клиента хоть как текст будет.

Сравни get filename и ту гору XML, что была выше по треду.

 AK>>> А что есть CRAM?
 OL>> Challenge-Response Authentication Mechanism.

 AK> А что такое Challenge-Response Authentication Mechanism? :)

to google?

Если коротко и на пальцах это вот что. "<" - запрос клиента, ">" - ответ
сервера.

< здрасте. Я знаю пороль p.

> на СЧ r.

< вот r**p.
Поскольку сервер тоже знает пороль p и знает какое случайно число r он этому
клиенту отдал, он тоже считает r**p и сравнивает с тем, что сказал клиент. Если
оно совпадает - клиент аутентифицировался. Чтобы при прослушке траффика нельзя
было из r и r**p вычислить p, фунцкия ** должна быть трудно обратимой. Например
возведением в степень большого числа r, меняющегося в каждой новой сессии.

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

 AK> А DoS - это то же, что DDoS?

Угу, только DDoS - распредленная.

 AK> И при чем здесь это?

Что будет, если клиент будет начинать сессии, но не завершать их?

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

 AK> 1) Много сессий.

См. ниже.

 AK> 2) Почему-то никто не рассматривает передачу данных _клиентом_.

Пфе. Хотя нет, не пфе. Это тоже нужно учитывать. Но обычно или запихивают
данные в запрос, если их мало, или разворачивают эту схему на 180 градусов и
радуются жизни.

 OL>> десятилетия. Поэтому для применений в real world, а не на очередной
 OL>> лабе по сетевому программированию, лучше взять уже имеющийся
 OL>> протоколл, с уже имеющейся реализацией на твоем_любимом_языке.

 AK> За основу моего варианта был взят binkp. Правда, оч-чень извращенный. :)

Бр-ррр.

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