I2P Dev Meeting - December 28, 2004

13:06 <@jrandom> 0) привет 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) привет 13:06 * jrandom машет рукой 13:06 <+postman> *машет* 13:06 <ant> <jnymo> привет 13:06 <@jrandom> краткие заметки о статусе выложены по адресу @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 13:07 <@jrandom> переходим к 1) 0.4.2.5 13:07 <@jrandom> как уже упоминалось, в целом всё работает 13:08 <+postman> ага, весьма впечатляет 13:08 <+postman> на моих системах больше вовсе нет тайм-аутов lease 13:08 <@jrandom> многие видели то же, что и ты, jnymo: 0 участвующих tunnels, в значительной степени из‑за повышенной эффективности и выбора пиров (где мы теперь знаем, что можно «подпитываться» с машины postman'а ;) 13:08 <ant> <jnymo> у меня тоже 13:08 <@jrandom> круто 13:08 <ant> <jnymo> и eepsites шустрые 13:09 <+postman> :) 13:09 <ant> <jnymo> спасибо, postman :) 13:09 <+postman> общая пропускная способность 29kb / 30.1kb/s 13:09 <frosk> кажется, что всем уделяют меньше любви, но на деле эту любовь просто используют эффективнее 13:10 <ant> <jnymo> вау 13:10 <@jrandom> круто, postman 13:10 <mule2> не думаю, что это идеал. лучше чтобы через все узлы шёл какой‑то трафик 13:10 <ant> <jnymo> я бы пережил это, если бы люди просто любили меня :( 13:10 <+postman> ага 13:10 <mule2> в качестве маскирующего трафика 13:10 <@jrandom> mule2: дело в том, что наша нагрузка сейчас намного меньше пропускной способности сети 13:11 <@jrandom> не думаю, что мы надолго сможем удерживать ёмкость больше нагрузки 13:11 <ant> <jnymo> mule2, postman также действует как mix (смешивающий узел).. так что трудно сказать, куда твои пакеты идут после входа 13:11 <@jrandom> так что меня не особо беспокоит, что мы не гоняем данные через более медленных пиров 13:12 <mule2> возможно, менее идеальная оптимизация была бы лучше для анонимности 13:12 <@jrandom> с другой стороны, это стимулирует больше людей (реализовать и) использовать i2pcontent, чтобы они могли делать зеркала и получать маскирующий трафик ;) 13:12 <jdot__> это проблема безопасности, что один router обрабатывает почти все tunnels? 13:13 <@jrandom> mule2: сначала доведём всё до максимально возможного уровня, а потом уже сможем обсуждать, как сознательно сделать хуже 13:13 <@jrandom> jdot__: у нас нет одного router'а, который обрабатывает весь трафик, но мы видим, что группы routers на очень быстрых каналах (colo и т. п.) берут на себя больше, чем пользователи dialup/dsl/cable 13:14 <@jrandom> к тому же меньше отказов tunnels означает, что мы меньше переразмещаем и исследуем 13:14 <mule2> возможно, можно было бы распределять трафик, пока мы далеки от лимитов routers 13:14 <@jrandom> верно, вероятностный отказ на уровне tunnel уже есть в router и может включаться, исходя из ограничений пропускной способности router 13:15 <ant> <jnymo> да, но такая высокая пропускная способность у узла postman'а усложняет его анализ.. так что может быть безопаснее посылать через него, чем чтобы все узлы гнали по одному КБ/с.. 13:15 <@jrandom> (но если postman не установит никаких лимитов, мы не сможем отбрасывать, исходя из их процента ;) 13:15 <ant> <jnymo> группировки более быстрых узлов создают что-то вроде каскадной структуры mix, да? 13:15 <@jrandom> ага, можно и так смотреть 13:15 <lektriK> могу я закрыть окно Start I2P? 13:15 * postman очень извиняется, что НЕ ограничивает свою пропускную способность 13:16 <@jrandom> lektriK: к сожалению, не совсем, если только вы не запускаете i2p как службу (См. http://localhost:7657/configservice.jsp) 13:16 <@jrandom> хех, postman, не переживай, мы отойдём от твоего router, если/когда достигнем его предела по ёмкости 13:17 <lektriK> Ок, там написано service started 13:17 <lektriK> теперь могу закрыть? 13:17 <@jrandom> lektriK: нет/да — вы можете выключить свой router, а затем запустить его снова через start->run->"net start i2p" 13:18 <mule2> в текущем виде несколько очень больших routers могли бы обработать все tunnels, убрав весь маскирующий трафик с остальных routers. но давайте продолжим это после встречи. 13:18 <mule2> не хочется жаловаться на то, что сеть работает слишком хорошо :) 13:18 <@jrandom> хехе 13:20 <@jrandom> в 0.5 будет ещё немного исследования, хотя слишком широкое распространение связано с проблемами анонимности. подробности ещё предстоит проработать для 0.5 (и в документе, первый черновик которого может быть готов на следующей неделе) 13:21 <@jrandom> в общем, у кого‑нибудь ещё есть что обсудить по 0.4.2.5? 13:21 <@jrandom> или кратко перейдём к 2) 0.5? 13:21 <+postman> двигаемся 13:21 <ant> <jnymo> очень стабильно... двигаемся 13:21 <@jrandom> считайте, что мы перешли 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> ага. всё ещё в процессе. больше информации, когда будет готово. 13:22 <ant> <Quadn-werk> Сэр Артур Ч. Кларк жив :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> .5 — это захватывающе 13:22 <@jrandom> ок, это всё, что могу сказать по теме — есть вопросы / что обсудить? 13:23 <@jrandom> да, определённо идёт важная переработка, основанная на том, что мы узнали за последние 16 месяцев 13:23 <@jrandom> (чёрт, или уже 18) 13:23 <+postman> jrandom: то есть 0.5 в основном будет использовать новую систему управления tunnel? 13:23 <ant> <Quadn-werk> арг, надеюсь, я не прервал встречу :/ 13:23 <+postman> вау 13:23 <ant> <Quadn-werk> сорри, хех 13:23 <ant> <jnymo> хех. у меня было предложение 13:24 <@jrandom> да, postman, новое управление, pooling и построение 13:24 <+postman> quadn: посмотри, что ты натворил — твой паст вызвал netsplit :) 13:24 <@jrandom> ах ты гад! 13:24 <ant> <Quadn-werk> ! 13:24 <@jrandom> как дела, jnymo? 13:24 <+postman> jrandom: каждый tunnel по‑прежнему будет отдельным локальным destination? 13:25 <@jrandom> чего-чего? 13:25 <@jrandom> в 0.5 не будет никаких изменений в i2ptunnel 13:25 <+postman> jrandom: ок 13:25 <@jrandom> (по крайней мере, я не планирую) 13:26 <mule> postman проводит intersection-атаку? 13:26 <ant> <jnymo> для тех, у кого вообще /нет/ использования полосы.. как насчёт позволить routers строить tunnels с ними внутри.. типа ABCABCA 13:26 <+postman> mule: нет, это была вина quadn :) 13:26 <ant> <jnymo> и это был бы фиктивный tunnel 13:27 <@jrandom> jnymo: рекламировать router со словами «эй, у меня избыток полосы, используйте меня» — опасная игра 13:27 <+postman> jrandom: какие проблемы тогда решает редизайн (в двух словах) 13:27 <ant> <jnymo> не уверен, что я это имел в виду, jrandom 13:27 <@jrandom> но похоже, что у нас будет два набора tunnels — обычные и exploratory (исследовательские), где вторые строятся из случайно выбранных пиров без отказов 13:28 <ant> <jnymo> jrandom: я имел в виду создать фиктивный tunnel и поставить себя в середину этого tunnel, чтобы просто имитировать некоторый трафик 13:29 <@jrandom> postman: делает намного сложнее коррелировать пиров внутри tunnel, позволяет клиентам эффективно выбирать длину своего исходящего tunnel и предоставляет опции, необходимые для противодействия атаке предшественника (с разными компромиссами) 13:29 <@jrandom> (о, и улучшение производительности за счёт избавления от множества вызовов modPow) 13:29 <+postman> ок, спасибо 13:29 <ant> <jnymo> postman: и идентификаторы tunnel на каждом переходе — это важно 13:30 <+postman> modpow? 13:30 <@jrandom> ах, jnymo. да, есть большой потенциал для генерации различного мусорного трафика 13:30 <ant> <jnymo> таким образом никакие два несоседних узла не смогут знать, что они в одном и том же tunnel, postman 13:30 <@jrandom> postman: модульное возведение в степень, высокая загрузка CPU и расточительность по памяти 13:31 <ant> <jnymo> jrandom: ок, круто 13:31 <+postman> ок 13:31 <scintilla> jrandom, насчёт предоставления клиентам возможности выбирать длину tunnel: будет ли что‑то, чтобы не дать людям выкрутить её до 99 (или сколько угодно)? 13:31 <ant> <jnymo> мощности CPU 13:32 <@jrandom> при необходимости мы можем добавить hashcash, но чрезмерно длинные tunnels всё равно в итоге будут падать 13:32 <scintilla> хорошее замечание 13:32 <@jrandom> мы даже можем добавить небольшой трюк — требовать, чтобы через tunnel в течение 60с после создания прошло валидное tunnel message, чтобы он считался «валидным» 13:33 <@jrandom> (так что если tunnel длиной 20 переходов, им будет слишком долго строить все эти переходы) 13:33 <scintilla> отличная идея — это не даст подобной нелепости задерживаться надолго 13:33 <@jrandom> но это всё против хакеров. обычные пользователи просто будут использовать доступный интерфейс 13:34 <ant> <jnymo> верно, вы ведь где‑то поставите верхний предел, да? 13:34 <ant> <jnymo> мы сможем ставить больше текущего максимума 2, верно? 13:34 <@jrandom> да, как выпадающий список # hops на /configclients.jsp или /i2ptunnel/edit.jsp 13:35 <@jrandom> о, я думал, максимум сейчас 3? ок, но да, больше 2 будет доступно 13:35 <ant> <jnymo> 3 tunnels, 2 hops 13:35 <@jrandom> а, ок 13:35 <@jrandom> да, 0.5 добавит несколько важных настроек, например, рандомизировать ли эти длины и насколько рандомизировать и т. д. 13:36 <frosk> максимум действительно 3 13:36 <ant> <jnymo> хмм 13:37 <@jrandom> ах, это 3 на /configclients 2 на i2ptunnel 13:37 <frosk> 0.5 всё ещё в графике на январь? 13:37 <ant> <jnymo> ах 13:37 <@jrandom> да frosk 13:37 <frosk> здорово 13:37 <@jrandom> я не буду больше тянуть со streaming lib, обещаю ;) 13:37 <frosk> звучит как куча работы :) 13:38 <@jrandom> на самом деле не так уж плохо, сложнее всего правильно подобрать алгоритмы 13:38 <@jrandom> (мелочи-шмелочи ;) 13:39 <+postman> frosk: и всё уже на бумаге 13:39 <+postman> :) 13:39 <ant> <jnymo> хех 13:39 <frosk> верно :) 13:39 <@jrandom> в основном да ;) 13:39 <@jrandom> ок, есть ещё что‑нибудь по 2) 0.5? 13:39 <ant> <jnymo> ни‑чего 13:39 <frosk> ничегошеньки 13:40 <@jrandom> ок, переходим к старому доброму 3) ??? 13:40 <@jrandom> привет 13:40 <@jrandom> кто‑нибудь ещё хочет что‑нибудь поднять? 13:41 <ant> <jnymo> postman: на i2pmail.org нет smtp/pop3 inproxies, так? 13:41 <cat-a-puss> я всё ещё вижу странные задержки на стороне клиента... 13:41 <+postman> хмм, нет 13:41 <frosk> вот тут я бы вручил поздравительную бутылку вина за отличный год разработки ;) 13:41 <+postman> jnymo: POP3 доступен только для пользователей i2p 13:41 <@jrandom> cat-a-puss: ах, я пропустил те сообщения, когда ты был ранее 13:41 <+postman> jnymo: есть SMTP inproxy как MX для домена i2pmail.org 13:42 <@jrandom> frosk: ура 13:42 <ant> <jnymo> ага-ага.. это круто.. 13:42 <cat-a-puss> например, у меня могут быть два локальных Destination, и когда один пытается подключиться к другому, есть задержка, и это не упирается в CPU 13:42 <mule> cat-a-puss: ты ещё и бонусный чек вручишь? 13:42 * postman дарит хороший виски 13:42 <@jrandom> cat-a-puss: правильно, ты видел задержку .5-1.0s, верно? 13:42 <cat-a-puss> mule: что? 13:42 <cat-a-puss> jrandom: да 13:43 <@jrandom> cat-a-puss: это совершенно нормально, часть механизма отложенного SYN 13:43 <mule> сорри, комментарий был от frosk 13:43 <ant> * jnymo достаёт то паршивое вино из коробки 13:43 <mule> frosk: ты ещё и бонусный чек вручишь? 13:43 <@jrandom> (он немного ждёт, прежде чем отправить SYN и соответствующий ACK, на случай если будет больше данных для объединения) 13:43 <scintilla> кстати, скоро я должен получить книгу со спецификацией алгоритма Fortuna... тем временем я экспериментировал со сбором энтропии в Java, не убивая машину 13:44 <@jrandom> круто 13:44 <ant> <jnymo> ммм, кто‑то хотел провести какие‑то атаки на i2p 13:44 <ant> <jnymo> кто это был? 13:44 <@jrandom> connelly 13:44 <cat-a-puss> есть способ предотвратить это, или мне просто стараться избегать краткоживущих подключений, где возможно? 13:45 <ant> <jnymo> что‑нибудь слышно об этом, jr? 13:45 <@jrandom> cat-a-puss: да, есть некоторые опции, которые можно передать при создании I2PSocketManager, сейчас найду их 13:46 <@jrandom> jnymo: это долгосрочная intersection-атака, так что через какое‑то время у него будут данные, помогающие определить, на каких routers находятся конкретные eepsites. уверен, он напишет нам краткое резюме, когда соберёт данные 13:46 <ant> <jnymo> scintalla: что за алгоритм Fortuna? 13:46 <ant> <jnymo> jrandom: окей 13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> это криптографически стойкий генератор псевдослучайных чисел... то, что абсолютно необходимо для надёжного шифрования 13:48 <jdot__> кто‑нибудь уже добровольно вызвался для этой атаки? 13:48 <@jrandom> cat-a-puss: тогда обязательно вызывай flush() после write() в I2PSocket 13:48 <@jrandom> jdot__: да, у него 7 добровольно участвующих сайтов 13:48 <cat-a-puss> jrandom: ок 13:49 <ant> <jnymo> насчёт великой дискуссии об именовании.. 13:49 <ant> * jnymo хихикает 13:49 <@jrandom> oh and i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> или даже =100 13:49 * jrandom кидает грязью в jnymo 13:50 <ant> <jnymo> я вообще работаю с x500, и моя работа позволяет мне иметь бесплатные winSevers 13:50 <ant> <jnymo> так что, возможно, я просто подниму центральный DNS для тестирования через месяц‑другой 13:51 <@jrandom> хех, централизованный сервер имён на .mil был бы чертовски забавен 13:51 <ant> <jnymo> хотя вколхозить адреса i2p в winserver может быть нетривиально.. не знаю 13:51 <ant> <jnymo> хех.. dnsalias — это то, что надо 13:52 <@jrandom> nano проделал очень классную работу, интегрировав dnsjava с i2p 13:52 <ant> <jnymo> о-о-о 13:53 <@jrandom> загляните на nano.i2p за подробностями 13:53 <ant> <jnymo> и никто не собирался мне сказать.. ах, спасибо 13:53 <@jrandom> но, как говорилось в прошлый раз, людям стоит выкладывать свои мысли и идеи об именовании в вики 13:54 <@jrandom> ок, есть ещё что‑нибудь для обсуждения на встрече? 13:55 <ant> <jnymo> неа 13:57 <@jrandom> ок, в таком случае 13:57 * jrandom размахивается 13:57 * jrandom *бам* закрывает встречу