Встреча разработчиков I2P — 29 ноября 2005

15:25 <jrandom> 0) привет 15:25 <jrandom> 1) Состояние сети и 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) привет 15:25 * jrandom машет 15:25 <jrandom> еженедельные заметки о статусе выложены @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar передаёт jrandom "baf" 15:26 <c3rvantes> ещё нет! 15:26 * jrandom размахивается 15:26 <jrandom> э-э... 15:26 <jrandom> давайте сперва пройдёмся по первым пунктам повестки :) 1) Состояние сети и 0.6.1.6 15:27 <jrandom> многое было обновлено в последних нескольких релизах, но сеть по-прежнему выглядит достаточно стабильной. 15:28 <jrandom> на нескольких router'ах мы видели серьёзные всплески участия router'ов, хотя это довольно безвредно 15:28 <+legion> круто, согласен, состояние сети улучшается. И да, почему бы не выкинуть tcp в 0.6.1.7 15:28 <jrandom> (э-э, то есть всплески в tunnel participation) 15:29 <@cervantes> ты не шутишь 15:29 <jrandom> не уверен, legion. Возможно, есть пользователи, у которых доступен только tcp, но, насколько помню, таких был всего один, ну максимум два 15:29 <+legion> ну, я заметил, что с 0.6.1.5 router иногда самопроизвольно перезапускался. 15:29 <+Complication> У меня колебания в разумных пределах, от 100 до 250 участвующих tunnel'ов 15:29 <jrandom> Не вижу серьёзных причин оставлять его, а вот причины убрать есть 15:30 <jrandom> круто, Complication 15:30 <jrandom> (эти цифры довольно средние, согласно stats.i2p/, но помните: подобные числа могут навредить анонимности, поэтому их не стоит публиковать, особенно не на записываемых встречах ;) 15:30 <+Complication> Мой старый Celeron всё ещё сам перезапускается примерно каждые 10 часов 15:30 <+Complication> В остальном подключён лучше, чем когда-либо 15:30 <Pseudonym> каковы причины отказаться от этого? 15:31 <+Complication> TCP дорог по ресурсам 15:31 <@cervantes> мой router в полном раздрае 15:31 <+Complication> В плане количества потоков на соединение 15:31 <@cervantes> Complication: умножь на 10 — и получишь текущий диапазон моего router'а ;-) 15:31 <+legion> У меня колеблется в пределах 200–400 участвующих tunnel'ов, так что кажется, всё лучше, чем когда-либо. 15:32 <+Complication> cervantes: ай-ай 15:32 <+Complication> Я видел странный сбой, когда было 2000 участвующих tunnel'ов, но это было летом 15:32 <jrandom> Pseudonym: производительность (CPU/память, лучшее планирование благодаря нашим требованиям к полунадёжной доставке), сопровождаемость, более эффективное занесение в чёрный список 15:32 <+Complication> Единовременный всплеск, который больше не повторялся 15:32 <+legion> да, в некоторых прошлых версиях такие всплески случались 15:32 <jrandom> Complication: у нас были всплески > 2000 tunnel'ов с этой последней ревизией 15:33 <jrandom> но, надеюсь, 0.6.1.7 это исправит 15:33 <+legion> Ну, это хорошие причины убрать tcp :) 15:33 <jrandom> но, повторюсь, всплески в tunnel participation — это нормально, так как большинство из этих tunnel'ов не используется 15:34 <@cervantes> Pseudonym: похоже, в сети осталось всего один-два router'а, которые всё ещё используют tcp 15:34 <jrandom> возможно, стоит убрать tcp и в этой ревизии, так как в ней нет других крупных изменений. Так мы сможем довольно ясно увидеть, как это повлияет на всё 15:34 <jrandom> (и при необходимости можем включить обратно) 15:35 <Pseudonym> если его используют всего два router'а, не думаю, что это как-то существенно повлияет 15:35 <Pseudonym> (разве что router'ов в сети станет на два меньше) 15:35 <@cervantes> 2 недовольных клиента 15:35 <jrandom> ну, транспорт всплывает в некоторых странных ситуациях — это одна из причин, почему я хочу его отключить :) 15:35 <+Complication> Надеюсь, они не воспримут это слишком лично 15:36 <+Complication> Очень мерзко со стороны некоторых ISP фильтровать UDP. 15:36 <+Complication> Мерзко и совершенно бессмысленно. 15:36 <jrandom> (например, когда router «умирает», люди помечают свой транспорт SSU как неработающий и из‑за этого откатываются на транспорт tcp) 15:36 * Pseudonym обожает своего ISP. никаких ограничений 15:37 <+Complication> Значит, без TCP можно будет увидеть, как UDP справляется в одиночку? 15:37 <+Complication> «без дополнительных колёс» :P 15:37 <+legion> хм, и как нам обходить такие мерзкие фильтры без tcp? 15:38 <jrandom> именно, Complication :) 15:38 <jrandom> legion: никак 15:38 <jrandom> (restricted routes (маршруты с ограничениями)) 15:38 <+Complication> Ну разве нет ряда полезных приложений помимо файлообменников, которые тоже используют UDP‑пакеты крупнее, чем у DNS? 15:39 <+legion> :( не звучит хорошо 15:39 <+Complication> По размеру, сопоставимые с минимальным размером пакета, который использует I2P? 15:39 <jrandom> э, legion, это не проблема 15:39 <jrandom> Complication: потоковые протоколы 15:39 <+Complication> Нельзя напрямую заблокировать UDP, не покалечив при этом DNS. 15:39 <+Complication> Можно ограничивать размер пакетов. 15:40 <+legion> ок, прозвучало так, будто может быть 15:40 <+Complication> VoIP? 15:40 <jrandom> это было бы проблемой, если бы это было широко распространено — если бы интернет‑сообщество в целом запретило udp 15:40 <+Complication> Хм, VoIP использует большие или маленькие пакеты? 15:40 <jrandom> но если это лишь несколько ISP, мы можем относиться к ним как к restricted routes 15:40 <+Complication> Или ты имел в виду скорее... видео‑стриминг? 15:40 <+legion> Думаю, там смесь и тех и других 15:41 <jrandom> и то и другое, Complication: RTSP работает поверх UDP, а real работает поверх RTSP, насколько помню 15:41 <+Complication> s/p/s 15:42 <+legion> Тогда к следующему пункту? 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> Я всё ещё не уверен, что мы уберём tcp в 0.6.1.7, но, вероятно, да. 15:43 <jrandom> ага, у кого‑нибудь есть ещё что-то по пункту 1)? если нет, давайте перейдём к 2) Syndie 15:43 <+Complication> То есть есть как минимум 227 приложений (некоторые, возможно, устаревшие или для LAN), которые используют UDP 15:44 <jrandom> да ну, это же интарвеб. всё, что нужно — проксированный доступ по HTTP 15:44 <jrandom> По пункту 2) мне особо добавить нечего сверх того, что в письме (и что на Syndie) 15:44 <+legion> Я убеждён, да, выбрасывать. :) 15:44 <jrandom> есть ли что‑нибудь по Syndie, что хотите обсудить? 15:45 <+legion> Мне тоже нечего сказать по пункту 2). 15:45 * Complication читает "how Syndie works" 15:46 <+Complication> Один небольшой эффект в UI постоянно меня удивляет. :D 15:46 <+Complication> Когда я раскрываю тред сообщений, меня каждый раз удивляет, что активное сообщение перемещается и становится верхним в списке. :P 15:47 <+Complication> Но это, вероятно, можно смело игнорировать. Я просто очень придирчив и человек привычки. :P 15:47 <@cervantes> модель трединга как раз обсуждается подробно 15:47 <@cervantes> ;-) 15:47 <+Complication> Привыкну. :) 15:48 <+Complication> cervantes: в Syndie? Нужно найти этот тред. :) 15:48 <@cervantes> Мне это тоже не нравится — но это вполне может измениться 15:48 <jrandom> да, это немного странно, полагаю 15:48 <+legion> ага 15:48 <@cervantes> "subject: syndie threading" 15:49 <+Complication> Кроме того, если раскрытое сообщение было бы самым нижним, ему всё равно пришлось бы переместиться. 15:49 <+Complication> Иначе оно там застряло бы. 15:50 <jrandom> ну, навигация внизу показывает по 10 тредов за раз, а не 10 сообщений. так что она могла бы раскрывать нижний тред 15:50 * cervantes сейчас тестирует несколько разных вариантов UI‑стилей трединга 15:51 <jrandom> круто 15:51 <jrandom> да, в идеале мы сможем переключать их через CSS, а если нет — на серверной стороне 15:52 <@cervantes> точнее, "threading navigation styles" 15:53 <@cervantes> хм, мои тесты по умолчанию используют чистые HTML c вложенными неупорядоченными списками 15:53 <@cervantes> сверху можно навешивать столько CSS и JavaScript, сколько нужно или хочется 15:53 <jrandom> есть какая‑то ETA, когда мы сможем увидеть макеты? 15:53 <@cervantes> (однако это лишь proof of concept, а не реальная реализация UI) 15:54 <@cervantes> Большую часть кода я пишу во время встреч I2P ;-) 15:54 <jrandom> хех 15:54 <@cervantes> возможно, первый макет будет готов сегодня вечером 15:54 * jrandom планирует ежедневные встречи 15:54 <jrandom> круто 15:54 <@cervantes> чёрт :) 15:55 <jrandom> ок, у кого‑нибудь есть что‑то ещё по 2) Syndie? 15:55 <jrandom> если нет, перейдём к 3) I2P Rufus 0.0.4 15:56 <jrandom> Мне особо добавить нечего сверх того, что в письме — Rawn/defnax, вы тут? 15:56 <+legion> ну, насколько хорош 0.0.4? Какие проблемы остались, если остались? 15:57 * jrandom без понятия 15:58 <+legion> Может, кто‑то из пользователей ответит. Кажется хорошим и стабильным? 15:58 <jrandom> ок, похоже, Rawn и defnax сейчас не здесь. если у кого есть вопросы/комментарии/опасения по поводу I2P Rufus, заходите на форум и пишите 15:58 <+legion> чёрт, видимо, придётся. 15:59 <+legion> переходим к 4)? 15:59 <jrandom> ага, похоже на то. ок, 4) ??? 15:59 <+Complication> К сожалению, я не пробовал I2P Rufus. 16:00 <jrandom> кто‑нибудь хочет поднять ещё какие‑то темы? 16:00 <jrandom> (давайте, надо растянуть, чтобы cervantes успел ещё поработать!) 16:00 <+legion> да, что там интересного намечается? 16:00 <+bar> где можно почитать подробнее про "restricted routes"? 16:00 <+bar> (я *искал*) 16:01 <+legion> Может, даже обсудим i2phex? 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes наводит курсор мыши на кнопку закрытия 16:01 <jrandom> э, #future.restricted 16:02 <jrandom> плюс страницы how_* и todo 16:02 <jrandom> (в сети) 16:02 <+Complication> Хех, похоже, I2P пропустил один build :D 16:02 <+Complication> :D 16:02 <+bar> спасибо 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion: немного хаков в netDb, улучшения производительности, restricted routes, улучшения streaming, улучшения eepproxy, улучшения tunnel'ов и т. д. много всего, но пока ничего не готово 16:03 <+legion> хм, странно 16:03 <jrandom> что‑нибудь по i2phex, legion? 16:03 <jrandom> Complication: да, так и задумано. Я забыл увеличить для BUILD = 2 16:03 <+Complication> (не то чтобы это на что‑то влияло, просто интересно, видел ли я раньше такой редкий случай :) 16:04 <+legion> класс, звучит отлично, спасибо! 16:04 <jrandom> о, кстати... было бы круто, если бы кто‑нибудь занялся обновлением нашего веб‑сайта 16:05 * jrandom не хочет об этом думать, но это рано или поздно нужно сделать 16:05 <+legion> да, есть 16:05 <+legion> стоит ли сейчас обновить i2phex до последнего кода phex из CVS? 16:06 <+Complication> Не уверен, я давно не слышал Redzara 16:06 <jrandom> насколько помню, redzara ждал обновлений phex от gregorz'а 16:06 <jrandom> (чтобы мы могли получить довольно чистое обновление/расширение) 16:08 <+legion> хм, тогда зачем i2phex? 16:08 <+Complication> На всякий случай? 16:08 <jrandom> хмм? 16:08 <jrandom> i2phex — это расширение к phex 16:08 <+legion> Похоже, они хотели, чтобы был просто phex с расширением под i2p 16:09 <jrandom> расширение, то есть изменение очень небольшого числа частей 16:09 <jrandom> er, s/bits/components/. чтобы мы могли легко обновлять код, когда разработчики phex что‑то поправят 16:10 <+legion> если так, то мне не должно быть сложно обновить его до последнего кода из CVS, хотя я понимаю, что на деле будет 16:10 <jrandom> последнее, что я слышал на форуме: план такой — I2Phex и Phex будут отдельными приложениями, но будут разделять большую часть кода 16:10 <jrandom> ага, legion, это было бы здорово, но, насколько я знаю, Gregor ещё не закончил изменения в Phex 16:11 <jrandom> (этого как раз и ждал redzara) 16:11 <+legion> а, понятно 16:11 <jrandom> так что альтернатива — либо помочь Gregor'у, либо продолжать модифицировать текущую кодовую базу I2Phex 16:12 <+legion> ну тогда если я не буду ждать и просто обновлю i2phex новым кодом, redzara не будет смысла продолжать 16:12 <jrandom> ну, не совсем. 16:12 <jrandom> обновить I2Phex до текущего кода Phex — это было бы здорово, да 16:13 <jrandom> но как только разработчики Phex обновят свой код, мы снова выйдем из синхронизации 16:13 <+legion> ок, вероятно, займусь этим сегодня вечером или в течение пары дней. 16:13 <jrandom> круто 16:13 <+legion> Отлично. 16:14 <+legion> На самом деле я не пытаюсь держать i2phex синхронным с кодом phex, просто похоже, что в CVS есть фиксы, которые i2phex точно пригодятся. 16:15 <+legion> Также я хочу выкинуть из i2phex любой код и функции phex, которые не нужны. 16:15 <jrandom> круто 16:16 <+legion> Что касается новых функций и исправления того, что ещё не работает, например очередей на выгрузку... Я уже смотрел, как заставить работать webcache'ы, но ещё много предстоит сделать. 16:17 <jrandom> именно. да, у phex раньше была рабочая поддержка gwebcache, но sirup её отключил, так как поначалу это было не нужно 16:17 <+legion> Я планирую со временем добавить jeti в i2phex. 16:17 <jrandom> здорово 16:18 * jrandom никогда не использовал jeti, и я надеюсь, что это останется опциональным компонентом, но поддержать больше возможностей — это круто 16:18 <+legion> Да, это может быть опционально, пользователи смогут скачать jeti2phex ;) 16:19 <jrandom> принято 16:19 <+legion> С i2phex ещё можно много чего сделать, хотя и сейчас он работает отлично. 16:20 <+legion> Пока что держать клиент подключённым и работающим 24/7 возможно и легко. 16:21 <jrandom> да, у меня с ним были хорошие успехи... «делаю резервные копии моих лицензированных записей» 16:21 <+legion> хех :) 16:22 <jrandom> ок, у кого‑нибудь ещё есть что‑то для встречи? 16:23 * cervantes подкатывает китайский гонг 16:23 <+legion> Кажется, я что‑то забываю... хм 16:24 <+legion> А, да, есть идеи, как уменьшить объём памяти, который потребляют i2p и i2phex? 16:25 <+Complication> Ну, транспорт TCP немного съедает 16:25 <jrandom> можно запустить оба в одном jvm 16:25 <+Complication> Если его убрать, немного освободится 16:26 <@cervantes> вынь пару планок памяти из машины 16:26 <cat-a-puss> у кого‑нибудь есть опыт с javolution, поможет ли это? http://javolution.org/ 16:26 <jrandom> (clients.config в каталоге установки i2p задаёт основной класс и аргументы для запуска клиентов) 16:26 <+legion> Так если мы запустим оба в одном jvm и уберём tcp, сможем опустить до менее чем 50 МБ? 16:27 <jrandom> без понятия, legion. зависит и от того, что ты имеешь в виду под 50MB. RSS/VSS/etc 16:27 <jrandom> Я бы не рекомендовал запускать оба в одном JVM, если только вы не держите оба запущенными постоянно, так как остановка одного убьёт и другой 16:27 <@cervantes> legion: ограничение пропускной способности и лимит на участников тоже может помочь 16:27 <jrandom> ага, как сказал cervantes 16:28 <cat-a-puss> мне кажется, если мы точно знаем, сколько объектов определённого типа нам, скорее всего, понадобится, это поможет предотвратить чрезмерное выделение памяти jvm 16:28 <+Complication> Верно, она делает разные типы выделений, в которых я так и не разобрался 16:28 <jrandom> ага, кое‑что из этого мы делаем, cat-a-puss (см. net.i2p.util.ByteCache) 16:29 <+Complication> (но, как я сказал, Java для меня очень новая вещь) 16:29 <jrandom> Я поглядывал на javolution раньше, но, похоже, он сильно продвинулся. Я взгляну ещё раз 16:30 <cat-a-puss> jrandom: я знаю, у нас на работе некоторые его используют и довольны, хотя им не важны вопросы выделения памяти 16:31 <jrandom> ну, это действительно не сэкономит памяти, но поможет снизить нагрузку на GC 16:31 <+legion> Лично меня распределение памяти не особо волнует, но многих — да. 16:31 <jrandom> о, и у него ещё лицензия BSD 16:31 <cat-a-puss> точно 16:31 <jrandom> legion: выделение памяти влияет на производительность 16:32 <+legion> э, ой, тогда потребление памяти 16:33 <+legion> Многие очень довольны utorrent из‑за его очень маленького потребления памяти. 16:33 <jrandom> ах, ну да. мы можем это поднастроить со временем, но так как i2p работает в рамках дефолтных размеров jvm, я не особо переживаю (у нас много пространства для твиков) 16:34 <jrandom> ок, у кого‑нибудь есть ещё что‑то для встречи? 16:35 <+legion> не, у меня всё... 16:37 * jrandom размахивается 16:37 * jrandom *baf* закрывает встречу