I2P Dev Meeting - May 18, 2004

14:07 <jrandom> 0) привет 14:07 <jrandom> 1) статус тестовой сети 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) обновления дорожной карты 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) привет 14:07 * jrandom машет 14:08 <Nightblade> привет 14:08 * jteitel машет в ответ 14:08 <jar> привет 14:08 <duck> прив 14:08 <Masterboy> :P 14:08 <jrandom> еженедельные статусные заметки выложены на http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> сорри, если я сегодня немного не в форме, график сна ещё больше сбит, чем обычно 14:09 <jrandom> в любом случае, переходим к 1) статус тестовой сети 14:10 <duck> диверсификация ведь автоматически произойдёт при более крупной сети, не так ли? 14:10 <jrandom> да, и/или при менее смещённых порогах выбора пиров 14:11 <jrandom> например, если бы порог скорости был по медиане, а не по среднему, мы получали бы вдвое меньше быстрых пиров, чем надёжных 14:11 <jrandom> в отличие от текущей ситуации, где скорости сильно смещены 14:12 <Masterboy> ну, сеть зажила — это не так уж плохо 14:12 <jrandom> ага, хотя это заняло дольше, чем должно, и выявило способы, как можно улучшить 14:13 <jteitel> сеть действительно восстановилась? Я до сих пор не могу надёжно подключиться к i2p irc 14:13 <jrandom> профили пиров недостаточно быстро «старели» и неэффективно продвигали новых кандидатов 14:14 <jrandom> это также запустило цепочку вторичных событий — перегрузку routers, которые не могли выдержать нагрузку (из‑за недостаточного профилирования), что привело к исчерпанию памяти у некоторых перегруженных routers и их выключению 14:15 <human> айеее айеее айее! 14:15 <jrandom> это был процесс, jteitel — некоторые из наблюдаемых проблем связаны со сбоями netDb 14:15 <jrandom> привет, human 14:15 <jteitel> О, ок 14:16 <_cervantes_> не мог бы проблемный router переложить tunnels на другого пира? 14:16 <ugha_node> Вау, пожизненная скорость: 8.87KBps отправлено, 8.35KBps получено. 14:16 <Nightblade> jteitel: я подключился только что после нескольких попыток... всё ещё жду, когда пройдёт мой /join 14:16 * BrianR осматривается. 14:16 <jrandom> нет — router может просто сбросить tunnel (если изначально не должен был его принимать) 14:16 <ugha_node> (И я перезапустил свой router полчаса назад) 14:16 <BrianR> чёрт. Я опоздал. 14:17 <BrianR> jrandom: (спасибо, что поставил myi2p ближе к концу повестки) 14:17 <jrandom> ugha> да, вам всем пришлось подхватить нагрузку за те три быстрых 14:17 <jrandom> хех :) 14:18 <duck> атака была недурной 14:18 <ugha_node> jrandom: Очевидно. 14:18 <_cervantes_> так не лучше ли быть жёстче и отклонять tunnels при более низком пороге 14:19 <jrandom> да, cervantes — сейчас routers никогда не отклоняют tunnel, если только не могут достичь следующего перехода 14:19 <jrandom> нам нужно добавить какую‑то форму троттлинга, возможно, на основе размера jobQueue/средней задержки и т. п. 14:20 <jrandom> кроме того, нужно удостовериться, что мы не пытаемся строить слишком много tunnels одновременно, как это произошло, когда большая их часть упала 14:20 <_cervantes_> или просто позволить пользователю задать порог, исходя из железа/пропускной способности, которые у него/неё есть 14:20 <jrandom> (из‑за ухода в офлайн быстрых и надёжных пиров) 14:20 <_cervantes_> по крайней мере на этом этапе 14:20 <jrandom> о, хорошая мысль — позволить людям явно задавать максимум участвующих tunnels. 14:21 <jrandom> внесём это в следующую ревизию. хорошее замечание. 14:21 <ugha_node> Звучит прямо как нечеткая логика. 14:21 <jrandom> нам нужно справляться с перегрузкой, и простая постановка сообщений в очередь в памяти точно не работает 14:21 <duck> (привет, fvw) 14:21 <_cervantes_> было бы неплохо иметь какую‑то агрегированную статистику по производительности tunnel... какой нагрузке они соответствуют на эталонном процессоре(ах) 14:22 <_cervantes_> кстати, я выключил свой сервер... на него валилось куча tunnels, а я ещё не собрал jbigi ;-) 14:22 <jrandom> см. http://localhost:7655/routerStats.html#Tunnels 14:23 <jrandom> ах! да, jbigi — это то, что мы хотим поощрять у всех 14:23 <BrianR> Есть мысли насчёт бюджетирования пропускной способности для tunnels? 14:24 <jrandom> сейчас запланировано на 3.0 (с общим ограничением пропускной способности для router целиком в 0.4.1) 14:24 <jrandom> но ввести ограничения пропускной способности для каждого tunnel раньше тоже не повредит 14:25 <fvw> Разумно ли тратить на это силы так рано, если куда проще и точнее сделать это в ядре тех ОС, на которых работают большинство нынешних пользователей/тестировщиков? 14:25 <_cervantes_> мне бы хотелось видеть настройки глубины для каждого tunnel (возможно, это уже можно) 14:25 <_cervantes_> например, я уже знаю, что могу доверять своему серверу... так что не хочу проходить _x_ переходов, чтобы добраться до него 14:25 <jrandom> fvw> хорошее замечание, особенно учитывая, что сейчас мы не съедаем слишком много полосы 14:26 <jrandom> хм, cervantes — да, каждый клиент может задавать длину своих tunnels, но не уверен, что это именно то, что ты хочешь 14:26 <_cervantes_> неа 14:26 <jrandom> cervantes — думаю, тебе нужен QoS (качество обслуживания), где можно укоротить соединение для конкретного пира 14:26 <_cervantes_> например... 14:26 <_cervantes_> ага 14:27 <jrandom> (что было намечено на i2p 4.0, но это больше чем через год == бесконечность) 14:27 <_cervantes_> в этом случае ещё и выбирать глубину для каждого i2p-хоста 14:27 <BrianR> fvw: Да, но i2p нужно хотя бы примерно знать, сколько пропускной способности доступно потенциальным участникам tunnel, чтобы принимать грамотные решения при построении tunnel... 14:27 <_cervantes_> а, ок 14:27 <_cervantes_> :) 14:27 <jrandom> но это хорошая идея и технически реализуемая, патчи приветствуются :) 14:28 <_cervantes_> патч уже в письме... вместе с чеком на 5000 слитков e-gold 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR: возможно, можно пойти наполовину — отслеживать, в скольких tunnels он участвует, а также сколько полосы эти tunnels потребляют, и использовать это как часть решения — принимать или отклонять запрос на создание tunnel? 14:28 <jrandom> хех 14:30 <jrandom> ок, есть ли что‑то ещё по статусу тестовой сети? 14:30 <Masterboy> а как насчёт моего парадокса? 14:30 <Masterboy> :) 14:30 <jrandom> мой план — выпустить 0.3.1.3 с обновлениями к четвергу или пятнице 14:31 <jrandom> Masterboy: у меня не было времени просмотреть твои логи, но мы это решим 14:31 <_cervantes_> пятница 2005? 14:31 <_cervantes_> круто 14:31 <Masterboy> ок 14:31 <jrandom> ок, переходим к 2) SAM 14:31 <Masterboy> теперь мы знаем, у кого устаревший router.. 14:32 * jrandom передаёт микрофон нашему бесстрашному разработчику SAM.pm 14:33 <jrandom> (это ты, BrianR :) 14:33 <BrianR> секунду.. :) 14:33 * duck аплодирует 14:33 <jrandom> между тем, тут ли dm или firerabbit? 14:33 -!- Irssi: #i2p: Всего 26 ников [0 ops, 0 halfops, 0 voices, 26 normal] 14:33 * jrandom проверяет /names, нет. ну ладно 14:33 <jrandom> (ну, обновлений SAM lib для .net/C# нет) 14:34 <duck> а .py штуки ещё актуальны? 14:34 <duck> или их сделали устаревшими улучшения SAM 14:34 <jrandom> не уверен 14:34 <BrianR> Ок. Я вернулся. 14:34 <Nightblade> Моя библиотека на C, кажется, работает... хотя я ещё не написал приложение, чтобы её использовать 14:34 <jrandom> круто, nightblade! 14:35 <Nightblade> Кто‑нибудь здесь писал на GTK+/C под Windows? 14:35 <human> duck: клиентской lib нужен небольшой апдейт для поддержки версионирования 14:35 <_cervantes_> "hello world"? 14:35 <human> duck: остальное должно работать без проблем 14:35 * jrandom предлагает datagram вроде tftp как идеальный тест для SAM :) 14:35 <Nightblade> ну, вообще что угодно... GTK хорошо работает под windows.....? 14:35 <jrandom> (или даже SAM streaming вместо datagram или raw) 14:36 <jrandom> круто, BrianR — как идут дела с .pm и samcat? 14:36 <BrianR> Net::SAM в CVS в основном нерабочий. 14:36 <BrianR> Надеюсь выправить все баги и запустить datagram и raw до конца недели. 14:37 <BrianR> Чуть больше работы потребуется, чтобы придать потокам приятную объектно‑ориентированную «отделку». 14:37 <Nightblade> ага, я не заморачивался с datagram или raw... только stream 14:37 <Nightblade> но это всё, что мне и нужно anyway 14:37 <fvw> human: Рассматривал wxWindows? Она довольно полезна для такого рода вещей (не думаю, что есть целевой GTK для windows) 14:37 <jrandom> класс, BrianR 14:38 <BrianR> Жена зовёт на ужин. Могу и не успеть вернуться к обсуждению myi2p. Я выложил модель угроз и всякое, тупой файловый сервер и т. п., на узле 208 14:38 <human> fvw: порт GTK под windows существует (GIMP тоже работает на windows) 14:38 <jrandom> круто, nightblade, лучше сначала реализовать то, что нужно 14:38 <human> fvw: s/client/port/ 14:38 <jrandom> хех, ок, BrianR, спасибо 14:38 <fvw> human: Я имею в виду целевой gtk под windows для wxWindows (которую я и предлагал использовать) 14:38 * fvw машет BrianR. Приятного аппетита. 14:38 <human> fvw: ах... ну, про vxWidgets (новое имя vxWindows :-) не знаю 14:39 <human> fvw: но про GTK+ говорил Nightblade, не я :-) 14:40 <fvw> Упс, глаза косые, не обращай внимания. 14:40 <Nightblade> Я не так хорошо знаком с C++, как с C 14:40 <Nightblade> насколько я знаю, GTK — единственная кроссплатформенная GUI‑библиотека на C 14:40 <Nightblade> не то чтобы я особенно любил GTK 14:40 <fvw> не принципиально, к wxWindows легко подступиться из C. 14:40 <Nightblade> хм 14:40 <Nightblade> ну, может, и на неё гляну 14:40 <Nightblade> я знаю C++, но не писал на нём больших программ 14:41 * fvw тоже не кодер на C++, но как‑то без проблем сделал на нём довольно большой просмотрщик транзакций для транспортной компании. 14:42 <Nightblade> уверен, у wxwindows более зрелый порт под windows 14:42 <Nightblade> чем у gtk 14:42 <fvw> вполне вероятно, да. 14:43 <Nightblade> (ладно, продолжайте встречу) хе‑хе 14:43 <jrandom> :) 14:43 <jrandom> ок, прыгаем к 3) обновлениям дорожной карты 14:44 * jrandom нерадиво обновлял http://www.i2p.net/roadmap в последний месяц 14:44 <jrandom> но теперь всё актуально 14:44 <jrandom> к сожалению, очевидно, что 0.4 на следующей неделе не выйдет 14:44 <duck> (а 1.1, 2.0, 3.0 тоже актуальны?) 14:45 <jrandom> так точно 14:45 * Masterboy прочитал, понравилось — не спешим, пожара нет.. 14:46 <duck> кому‑то бы обновить и wikipedia/infoanarchy :) 14:46 <jrandom> о, мне, наверное, стоит убрать из 0.4 «SAM bridge and client libraries implemented and tested» 14:46 <jrandom> хех, да, поэтому я !thwapped iA какое‑то время назад, когда они просто скопировали страницу из вики 14:46 <jrandom> (им нужно просто ссылаться на /roadmap, а не дублировать содержимое) 14:47 <Masterboy> SAM закончен? 14:47 <jrandom> он функционален, да, хотя работа над дополнительными клиентскими библиотеками продолжается 14:47 <jrandom> s/are/is/ 14:48 <jrandom> ок, если по дорожной карте больше нет вопросов/замечаний, переходим к 4) MyI2P 14:50 <jrandom> хотя я сам перестал работать над myi2p, мы открыли это как баунти — http://www.i2p.net/node/view/216 14:50 <jrandom> частично это значит, что нам нужно правильно сформулировать требования, и шли споры о том, какими они должны быть 14:51 <Masterboy> пытался заманить туда друга, он сказал: слишком много работы, слишком мало денег ;P ну, он капиталист ;) 14:51 <Masterboy> ну, я предложил это закодить.. 14:52 <jrandom> кодинг там всегда приветствуется :) 14:53 <jrandom> но текущий нерешённый архитектурный вопрос — как поступать с людьми, которые не могут держать свой i2p router/myi2p‑нод постоянно включёнными 14:53 <Nightblade> нужен просто какой‑нибудь доверенный i2p ISP 14:53 <jrandom> есть два предложения: либо использовать хостинговых провайдеров, либо отделить систему, чтобы использовать распределённое хранилище 14:54 <_cervantes_> второе — идеальное долгосрочное решение 14:54 <_cervantes_> *latter 14:54 <duck> (и это будет ещё одно баунти) 14:55 <_cervantes_> или сервис webcache/proxy... 14:55 <jrandom> верно — если пойдём по пути хостингового провайдера (или локально запускаемой ноды), когда появится DHT (распределённая хеш-таблица)/и т. п., мы сможем переносить всё больше контента в DHT 14:55 <jrandom> _cervantes_: это по сути распределённое хранилище — недоверенные кэши данных 14:57 <deer> * Masterboy интересуется, где bogobot 14:57 <jrandom> сложная часть — получить нужный функционал управления доступом: с недоверенными кэшами данных/распределённым хранилищем ACL (списки управления доступом) по сути — шифрование 14:57 <jrandom> но «побочный канал» к этой дискуссии — три пункта, поднятые анонимом @ http://www.i2p.net/node/view/215#comment-105 14:57 <_cervantes_> и подписанный контент 14:58 <jrandom> верно, в обоих вариантах нужен подписанный контент 15:00 <_cervantes_> вот где модель hypercubus уместна... но это вовсе не «быстрое» решение 15:00 <jrandom> из обсуждений в irc прошлой ночью: мы сфокусировались на «модели угроз livejournal» — какие атаки волнуют пользователей LJ, а какие нет 15:01 <wilde> прежде всего — сначала запустить базовый MyI2P 15:02 <jrandom> верно, и чтобы реализовать базовый myi2p, нам нужно понять архитектуру развёртывания 15:03 <jrandom> с моделью угроз lj, для пользователей, которые не могут запускать свои ноды, думаю, нам не нужно идти путём недоверенных кэшей данных 15:03 <jrandom> и почему кто‑то будет использовать myi2p, если им нужна лишь модель угроз lj? потому что он анонимный 15:04 <jrandom> мы можем бесконечно гнаться за идеализированной системой, но есть закон убывающей отдачи 15:04 -!- Irssi: #i2p: Всего 24 ника [0 ops, 0 halfops, 0 voices, 24 normal] 15:05 <jrandom> поэтому я склоняюсь к тому, чтобы оставить баунти в текущем виде — альтернативы можно добавить позже, после выхода базовой системы 15:05 -!- duck_ теперь известен как duck 15:06 <jrandom> в общем, думаю, у меня всё по 4) MyI2P, если только у кого‑то нет чего‑то ещё, что хочется поднять 15:06 <jrandom> если нет — переходим к 5) ??? 15:07 <_cervantes_> хм, тебе нужен большой молоток председателя :) 15:07 <jrandom> я забыл упомянуть в заметках встречи новый eepsite у morph.i2p, а у nickster.i2p теперь доступен публичный fproxy! 15:08 <jrandom> (и у sungo.i2p вебкамера уже запущена :) 15:08 <_cervantes_> хех... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> у кого‑нибудь ещё что‑то есть, что хочется поднять? 15:10 <jrandom> если нет, то это выводит нас на отметку в 70 минут 15:10 <deer> <Masterboy> нет 15:10 * jrandom сворачивает 15:10 * jrandom *baf* закрывает встречу