Встреча разработчиков I2P - 25 апреля 2005 г.

16:12 <jrandom> 0) привет 16:12 <jrandom> 1) Состояние сети и 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) привет 16:13 * jrandom машет 16:13 <@cervantes> прив 16:13 <jrandom> еженедельные заметки о статусе выложены @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> пока вы это пролистываете, перейдём к 1) Состояние сети 16:14 <jrandom> итак, как большинство из вас видели, у нас вышел новый релиз, и пока результаты довольно позитивные 16:15 <@cervantes> (ура!) 16:15 <jrandom> ещё не там, где нам нужно, но он в целом решает основные проблемы, которые мы наблюдали 16:15 <jrandom> ага, приятно снова иметь сносные скорости построения tunnels даже для tunnels на 2+ переходов :) 16:16 * jrandom имеет 50%+ успешности на другом router с tunnels на 1 переход 16:17 <jrandom> думаю, последние изменения в 0.6.1.17 тоже помогут в будущем избегать такого коллапса из‑за перегрузки 16:17 <jrandom> но заметный для пользователя эффект в том, что мы время от времени будем видеть истечение lease (временных записей), однако вместо того чтобы это самоусугублялось, система будет делать backoff 16:17 * cervantes запускает azureus 16:18 <+Complication> Сегодня утром я зафиксировал успешность клиентских tunnels (длина 2 +/- 1) около 35% 16:18 <+Complication> Сейчас ниже, так как я пробовал кое‑что менять, и последнее изменение вышло не слишком удачным :D 16:18 <@cervantes> jrandom: отлично выследил — на минутку мы уже начали быть похожи на freenet :) 16:19 <jrandom> *кхм* ;) 16:20 <+fox> <inkeystring> jrandom: не мог бы ты вкратце описать механизм backoff (уменьшения активности при перегрузке)? я сейчас работаю над чем‑то похожим для freenet 0.7 16:21 <jrandom> inkeystring: у нас уже был механизм backoff на транспортном слое, чтобы сокращать передачи к пиру при перегрузке транспортного слоя, но этого оказалось недостаточно 16:21 <@cervantes> *кхм* я сказал freenet, я имел в виду tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: новое изменение — прокинуть это на более высокий уровень, чтобы мы прекращали попытки строить tunnels, когда наш коммуникационный слой насыщен 16:22 <jrandom> (вместо того чтобы посылать ещё больше попыток построения tunnels) 16:22 <+fox> <inkeystring> спасибо — транспортный слой делает backoff только при потере пакетов, или у получателя есть какой‑то способ управлять потоком? 16:23 * jrandom мне кажется, мы пару раз обсуждали с toad влияние перегрузки против (vs) маршрутизации (в irc и в моём старом flog), хотя не припомню какой‑то однозначно положительной для сети развязки :/ 16:23 <jrandom> получатель может посылать NACK, и у нас есть хуки для ECN, но в них не было необходимости 16:23 <+fox> <inkeystring> да, спор снова всплыл на freenet-dev :-) по‑прежнему никакой серебряной пули 16:24 <+fox> <inkeystring> круто, спасибо за информацию 16:24 <+Complication> Они теперь тоже используют UDP, не так ли? 16:24 <jrandom> сейчас у сильно перегруженных пиров проблемы не с ограничением скорости на уровне каждого пира, а с широтой общения с пирами 16:24 <+Complication> (как транспортный протокол) 16:24 <+fox> <inkeystring> breadth = количество пиров? 16:24 <jrandom> да 16:25 <jrandom> с ростом успешности построения tunnels пирам больше не нужно общаться со сотнями пиров только чтобы построить tunnel 16:25 <jrandom> так что им хватает всего 20–30 пиров 16:25 <jrandom> (имеется в виду непосредственно подключённых пиров) 16:26 <+fox> <inkeystring> думаю, это хорошие новости для NAT hole punching, keepalive‑ов и т. п.? 16:26 <jrandom> с другой стороны, при 2–300 активных соединениях SSU канал в 6KBps будет испытывать трудности 16:26 <jrandom> ага 16:26 <+fox> <inkeystring> Complication: да 16:27 <+fox> <inkeystring> (в альфе 0.7) 16:27 <+Complication> Ага, значит, у них, вероятно, похожие проблемы 16:27 <+Complication> Надеюсь, кто‑нибудь найдёт волшебную пулю :D 16:27 <jrandom> Хотя и в другом виде. Транспортный слой — относительно простая задача 16:27 <+fox> <inkeystring> думаю, они могли переиспользовать часть кода SSU... или по крайней мере обсуждали это 16:27 <jrandom> (он изучается уже 30+ лет) 16:28 <jrandom> но балансировка нагрузки в i2p (и freenet) работает на более высоком уровне, чем связи точка‑точка, и имеет другие требования 16:28 <+fox> <inkeystring> да, сложность именно во взаимодействии с маршрутизацией 16:29 <jrandom> ага, хотя в i2p в этом плане проще (нам не нужно находить конкретных пиров с нужными данными, достаточно любого с ресурсами для участия в наших tunnels) 16:30 <+fox> <inkeystring> так что потерь эффективности нет, если обойти перегруженного пира... 16:30 <+fox> <inkeystring> в то время как в freenet обход перегруженного пира может увеличить длину пути 16:30 <+fox> <inkeystring> в любом случае, сорри за оффтоп 16:31 <jrandom> не проблема, хотя объяснять, почему изменения в 0.6.1.17 влияют на наш коллапс из‑за перегрузки, было уместно :) 16:31 <jrandom> ок, у кого‑нибудь ещё что‑то по 1) Состояние сети? 16:32 <+Complication> Ну, как уже упоминалось, при запуске чистой .17 я наблюдал заметную периодичность в пропускной способности и числе активных пиров 16:32 <+Complication> И, похоже, у ещё нескольких людей это тоже наблюдается, хотя я не представляю, насколько это распространено 16:33 <+Complication> Я размышлял о первопричинах, в основном с точки зрения ограничений на tunnels, но решения пока нет 16:33 <+Complication> Мне удалось сделать свои графики более ровными, но ценой некоторого общего ухудшения 16:33 <+Complication> Пробовал такие изменения, как: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (это было, чтобы он не полностью воздерживался от попыток построения собственных tunnels) 16:35 <jrandom> ах да 16:35 <+Complication> (о, и естественно уровень логирования там странный, я его менял для тестирования) 16:35 <jrandom> у нас там есть код, который пытается немного исказить периодичность, но он работает не совсем правильно (очевидно) 16:36 * perv только что угробил свою систему :( 16:36 <+Complication> Но я пробовал подобные вещи и пытался уменьшить коэффициент роста числа tunnels 16:36 <perv> есть ли undelete для reiser4? 16:36 <jrandom> по сути, если просто вести себя так, как будто tunnels истекают (случайно) раньше, чем на самом деле, это должно помочь 16:36 <+Complication> Сейчас читаю большую функцию "countHowManyToBuild" в TunnelPool.java :D 16:36 <+Complication> Но я ещё не дочитал 16:37 <jrandom> (хотя это очевидно увеличит частоту построения tunnels, что до 0.6.1.17 было бы неразумно) 16:37 <+Complication> perv: что‑то есть 16:37 <jrandom> хмм, Complication, вставить туда рандомизацию будет сложно, так как мы вызываем эту функцию довольно часто 16:38 * perv подумывает о спасении данных и переходе на gentoo 16:38 <jrandom> я бы рекомендовал посмотреть в сторону рандомизации времени истечения для успешно построенных tunnels 16:38 <+Complication> perv: с reiser тебе будет лучше, чем с ext3, определённо 16:38 <+Complication> perv: но наизусть не помню 16:38 <+Complication> jrandom: верно, иногда он может пере‑строить лишнего таким образом 16:38 <jrandom> (чтобы существующая countHowManyToBuild думала, что они нужны раньше, чем на самом деле) 16:38 <+Complication> (а иногда он неизбежно строит лишнее, когда tunnels ломаются и он спешит) 16:40 <+Complication> Хмм, вариант, о котором я не думал... 16:41 <+Complication> Так или иначе, тоже играюсь с этим, но полезных наблюдений пока нет 16:42 <jrandom> круто, у меня тоже есть некоторые твики, с которыми я экспериментирую, возможно, соберём их вместе к следующему билду и посмотрим, как это работает на более‑менее жизнеспособной сети ;) 16:43 <spinky> Есть ли статистика, где можно увидеть объём overhead, который сеть i2p добавляет к данным приложения? 16:43 <jrandom> «overhead» — такое загруженное слово... ;) 16:43 <jrandom> мы называем это ценой анонимности ;) 16:43 <spinky> хехе 16:45 <jrandom> (то есть не совсем. На идеальной сети с нулевой перегрузкой и 1+1 hops полезная нагрузка уровня приложений даёт порядка 70–80% эффективности для конечных точек) 16:45 <jrandom> ((последний раз так и измерял)) 16:45 <jrandom> но это реально лабораторные условия 16:45 <jrandom> живая сеть куда сложнее 16:47 <spinky> Верно, я имел в виду только объём дополнительных данных для установления tunnels, ключей, padding и т. п. 16:47 <spinky> ...по сравнению с переданными данными приложения 16:47 <jrandom> зависит от фрейминга сообщений, перегрузки, успешности построения tunnels и т. п. 16:48 <jrandom> 2‑hop tunnel может быть построен ценой ~20KB сетевого трафика 16:48 <+Complication> Я хотел когда‑нибудь это протестировать, главным образом чтобы оценить «расточительность» приложений массовой передачи вроде BitTorrent и I2Phex 16:48 <+Complication> Но так и не добрался до чистых измерений между двумя своими узлами 16:48 <+Complication> Когда‑нибудь я к этому вернусь, хотя 16:49 <jrandom> Complication: с болтливыми приложениями это довольно тяжело, куда проще померить wget :) 16:49 <+Complication> Чистая правда 16:50 <+Complication> В том, что мне удалось попробовать, и намёка на точность не было 16:54 <jrandom> ок, если по 1) больше ничего нет, давайте плавно перейдём к 2) I2Phex 16:55 <jrandom> Complication: чем занимаешься? :) 16:55 <+Complication> Ну, вчерашний коммит был фиксом некоторых проблем, с которыми у некоторых возникали трудности из‑за моего глупого детектора первого запуска 16:56 <+Complication> Детектор первого запуска теперь менее глупый, и bar сообщил, что он, похоже, начал вести себя нормально 16:56 <+Complication> Однако, поскольку I2Phex теперь, похоже, уже запускается в текущих условиях сети, 16:56 <+Complication> я попробую найти баг rehash тоже. 16:57 <+Complication> Если смогу 16:57 <jrandom> круто, знаю, этот баг тебя преследует уже месяцами 16:57 <+Complication> Интересно, что в основном Phex он тоже может быть, и я попробую найти и прочитать их наблюдения 16:58 <jrandom> но приятно слышать, что фикс старта уже внутри 16:58 <jrandom> о как 16:58 <+Complication> =это 16:58 <+Complication> Не могу сейчас подтвердить, есть ли он в основном Phex или нет — сам там его никогда не видел 16:59 <jrandom> (плавающие баги)— 16:59 <+Complication> Их сложно воспроизводить контролируемо, а значит и сложно находить 17:00 <+Complication> Со своей стороны это пока всё 17:00 <+Complication> Позже я подумал, не стоит ли ограничить число параллельных попыток контакта с пирами, которые I2Phex делает одновременно 17:01 <jrandom> ага, вероятно 17:01 <+Complication> Потому что они создают целую кучу запросов в NetDB за короткое время, а это потенциально не слишком приятно с точки зрения I2P router 17:02 <jrandom> и новые контакты с destination требуют elG вместо aes 17:02 <+Complication> Но я пока не читал и не писал никакого кода в этом направлении 17:04 <jrandom> ок, без проблем. возможно, мифический merge i2phex/phex привнесёт решение :) 17:04 <+Complication> А с моей стороны это примерно все новости с фронта I2Phex... 17:04 <jrandom> круто, спасибо за апдейт и за усилия в разборе! 17:05 <jrandom> ок, прыгаем к 3) ??? 17:05 <jrandom> есть ли ещё что‑нибудь, что стоит поднять на встрече? 17:05 <lsmith> привет! хочу похвалить девов за потрясающие улучшения в последнем релизе, у меня общий bw показывает 0.9/1.4 KBps, и я остаюсь подключён к irc... это... безумно круто :) 17:05 <+Complication> :D 17:06 <jrandom> спасибо за терпение на всём пути — поддержка пользователей с низким bw критически важна 17:06 <@cervantes> lsmith: это действительно хорошо 17:06 <@cervantes> * Connection Reset 17:06 <jrandom> хех 17:07 <lsmith> :) 17:09 <jrandom> о, ещё одна примечательная вещь — zzz вернулся, а с ним и stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> Довольно полезный источник сравнительных данных :) 17:11 <jrandom> определённо 17:11 <jrandom> ок, есть ли ещё что‑нибудь для встречи? 17:13 <jrandom> если нет... 17:13 <jdot> у меня есть один‑два вопроса после baf 17:13 <jrandom> хех ок, тогда запускаем baffer :) 17:13 * jrandom замахивается... 17:13 * jrandom *baf* закрывает встречу