Встреча разработчиков I2P - 28 февраля 2006 г.

15:11 <jrandom> 0) привет 15:11 <jrandom> 1) Состояние сети и 0.6.1.12 15:11 <jrandom> 2) Путь к 0.6.2 15:12 <jrandom> 3) Минипроекты 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) привет 15:12 * Complication быстро пробегает заметки глазами 15:12 * jrandom машет рукой 15:12 <jrandom> еженедельные заметки о статусе опубликованы на http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 15:12 <jrandom> (а я, между прочим, выложил заметки более чем за 15 минут до встречи! ;) 15:13 <jrandom> ок, пока вы читаете эти ох-какие-захватывающие кусочки, давайте перейдём к 1) Состояние сети и 0.6.1.12 15:14 <jrandom> как уже говорилось, основных целей релизов 0.6.1.10–0.6.1.12, похоже, удалось достичь: мы учли изменение криптографии при создании tunnel и значительно повысили надёжность создания 15:16 <jrandom> те «кочки», что мы видели на 0.6.1.10, исчезли, стабильность IRC снова довольно хорошая 15:16 <jrandom> есть что добавить по 1) Состояние сети и 0.6.1.12, или потихоньку перейдём к 2) Путь к 0.6.2? 15:17 <+Complication> У меня по сети: больше не падает ниже 20 KB/s :) 15:18 <jrandom> круто, да, 0.6.1.12 исправил довольно крупную ошибку в 0.6.1.11, из‑за которой не использовалась доступная полоса пропускания. теперь должно лучше использовать доступные ресурсы 15:20 <jrandom> ок, перейдём к 2) 15:20 <jrandom> как уже говорилось, есть несколько вещей, которые надо уладить перед последним функциональным изменением для 0.6.2, но мы движемся вперёд 15:20 <nymisis> со статусом сети всё в порядке :) 15:22 <jrandom> угу. по спецификам новых стратегий упорядочивания пиров будет больше информации до их выхода, но суть понятна из краткого упоминания в заметках 15:23 <jrandom> есть вопросы/комментарии/опасения по 2) Пути к 0.6.2? 15:23 <postman> jrandom: в этот раз будут тестовые сети? 15:24 <postman> (нужны какие‑нибудь router и участники, чтобы погонять тесты) 15:24 <postman> ? 15:24 <+Complication> Суть показалась довольно простой — ограничить возможность противника собирать разнообразные статистические данные 15:25 <+Complication> Выглядит весьма желательной фичей 15:25 <jrandom> postman: новое должно прозрачно работать в живой сети, используя только локальную информацию, так что отдельная сеть для тестов не понадобится 15:25 <jrandom> ага, именно, Complication 15:26 <postman> ок 15:26 <postman> jrandom: осмелишься назвать ETA для 0.6.2? :) 15:27 <blubb> 1 апреля 15:27 <jrandom> ну, раз сегодня конец февраля, предположу март или апрель 15:27 <postman> хехе 15:27 <jrandom> blubb: у нас на это время уже запланирован backdoor MI6 ;) 15:29 <@cervantes> скорее лаза для кошек MI6 15:29 <@cervantes> (сокращение бюджета) 15:29 <postman> в слоновнике 15:30 <nymisis> Если уж быть точным, это SIS, а не MI6. :) 15:30 <jrandom> ладно, давайте просто звать их Они ;) 15:31 <jrandom> ок, что‑нибудь ещё по 2)? 15:31 <jrandom> если нет, плавно перейдём к 3) минипроектам 15:31 <@cervantes> извиняюсь, «Фирма» 15:34 <jrandom> ок, хотел просто отметить пару классных вещей, которые 1) просто сделать и 2) они действительно полезны 15:34 <+Complication> По минипроектам: не уверен, дошёл ли мой ответ по Syndie, но думаю, не занять ли один. 15:34 <+Complication> Пока не решил какой. Сейчас немного практикуюсь в Java (делаю микро‑проект :D), чтобы быть увереннее, что, когда возьмусь, справлюсь 15:35 <DeltaQ> хмм, если я повышу пропускную способность в консоли, изменения вступят в силу сразу или нужен перезапуск? 15:35 <+Complication> Когда закончу с «микро‑проектом» (если, конечно, список ещё не разберут), попробую выбрать один 15:35 <jrandom> w3wt, здорово, Complication 15:36 <jrandom> DeltaQ: сразу 15:36 <@cervantes> разве 1) планировщик Syndie не связан с 4) Download Manager / планировщиком eepget 15:36 <+Complication> DeltaQ: начинает действовать практически сразу (в пределах периода усреднения пропускной способности) 15:37 <@cervantes> мне кажется, более общий менеджер загрузок и выгрузок закроет обе потребности 15:37 <jrandom> cervantes: не обязательно. 1) довольно узконаправлен и включает push‑операции, а 4) довольно общий 15:37 <+Complication> cervantes: звучит, что может 15:37 <jrandom> но да, «движок» за обоими — EepGet 15:37 <jrandom> (eepget делает для syndie HTTP‑передачи программно) 15:38 <DeltaQ> среднее, похоже, не поднимается выше 13kb/s 15:38 <DeltaQ> я выставил 64kb/s с 192 burst на загрузку 15:38 <DeltaQ> 32/64 на отдачу 15:38 <@cervantes> то есть универсальный eepget для push/pull с планировщиком и API управления... 15:39 <@cervantes> хотя на этом этапе это, вероятно, перестаёт быть мини‑проектом 15:39 <+Complication> DeltaQ: среднее также зависит от того, сколько нагрузки создают твои клиентские tunnel (и participating tunnels других узлов) 15:39 <+Complication> сорри, s/среднее/фактическая пропускная способность 15:39 <jrandom> cervantes: да, но в части syndie там немало логики. 15:40 <DeltaQ> хех, наконец‑то поднялось 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> видимо, надо было поднять BW отдачи 15:40 <jrandom> DeltaQ: на среднее будет влиять и то, как другие воспринимают тебя, а это зависит от твоего поведения, а не от заявленной скорости, так что потребуется время 15:40 <+Complication> DeltaQ: для проходящего трафика (participating tunnels): что входит, то должно и выходить 15:41 <+Complication> DeltaQ: поэтому сильно разные скорости отдачи/загрузки будут ограничивать participating traffic до меньшей из них 15:42 <+Complication> DeltaQ: также participating traffic зависит от того, как другие узлы «оценивают» маршрутизационные возможности твоего узла 15:42 <DeltaQ> окей 15:43 <+Complication> Если они считают, что он хорошо маршрутизирует, будут чаще обращаться 15:43 <jrandom> ок, если по 3) минипроектам больше ничего, давайте перейдём к 4) ??? 15:43 <jrandom> есть что ещё поднять по встрече? 15:43 <DeltaQ> ну я за router, но пробросил порт 8887 на этот ПК 15:43 <+Complication> Если узел новый или недавно увеличил ресурсы, они немного осторожничают 15:44 <DeltaQ> о, сорри, не хотел вмешиваться в встречу ^^ 15:44 <+Complication> На днях кто‑то спрашивал о возможных атаках на основе смещения часов. Кажется, видел твой ответ относительно части с tunnel (сообщение создания содержит только период валидности tunnel, а не время с точки зрения его создателя)... 15:44 <@cervantes> (спасибо за упоминание в заметках о статусе) ;-)_ 15:46 <+Complication> Я подумал, собственно, спросить... какие места, если вообще есть, в сообщениях I2P могут содержать время с точки зрения отправителя? 15:47 <+Complication> Я не успел разобраться до текущего состояния, так что немного плаваю в теме 15:47 <jrandom> Complication: ничего явно не говорит «я считаю, что сейчас $time», но при достаточном объёме трафика и анализе таймингов можно, вероятно, сильно сузить диапазон 15:48 <jrandom> мы квантируем времена с большим периодом, хотя и не таким большим, как наш максимальный clock skew, так что там есть зазор 15:49 <+Complication> Как думаешь, была бы в итоге польза от более «отточенного» клиента NTP? 15:49 <+Complication> Того, который будет/сможет легче удерживать меньшие скосы? 15:50 <jrandom> ну, с тех пор как в i2p появился клиент sntp, он становился всё лучше, так что теперь мы не видим прежних колебаний 15:51 <jrandom> возможно, можно снизить порог минимального skew с 10s до 2–3s, или даже меньше 15:51 <jrandom> или позволить ему смотреть и на clock skew по SSU, чтобы избегать лишних смещений 15:52 <+Complication> Или, наоборот, можно ли ещё сильнее ограничить возможность угадывать возможное значение часов другого peer'а? 15:53 * Complication не знает, какой путь практичнее, просто накидывает варианты :D 15:53 <jrandom> нет, мы знаем clock skew напрямую подключённых узлов 15:55 <Magii> можно как‑нибудь понять, что обновление прошло успешно? 15:55 <+Complication> Ага, то есть протокол сессии действительно зависит от этой информации.. 15:55 <tethra> посмотри на номер версии 15:55 <+Complication> Magii: он должен записать в логи CRIT вроде «update verified, restarting to install» 15:55 <tethra> :/ 15:55 <+Complication> Затем он должен начать обратный отсчёт до корректной перезагрузки 15:56 <+Complication> И, в конце концов, перезапуститься 15:57 <+Complication> О, кстати: знаком ли внутренний клиент NTP с понятием «скорость дрейфа часов»? 15:58 <jrandom> да, номер версии в левом верхнем углу http://localhost:7657/index.jsp должен выдать это :) 15:58 <jrandom> Complication: нет, он не гарантирует последовательные тики часов 15:59 <jrandom> s/последовательные/упорядоченные/ 15:59 <+Complication> И не умеет получать знание вроде «наши системные часы идут быстрее нужного в 0.00345 раза»? 16:00 <jrandom> ах, нет, хотя добавить это в net.i2p.util.Clock было бы несложно (хочешь минипроект? :) 16:00 <+Complication> Я как раз об этом и думал 16:01 <+Complication> Пожалуй, подумаю об этом ещё чуть‑чуть :) 16:01 <+Complication> Но сперва другие минипроекты :) 16:02 <jrandom> ок, есть что‑то ещё для встречи? 16:03 <nymisis> Маффины? 16:04 <jrandom> нет, панкейки 16:04 <jrandom> (ммММмм панкейки) 16:04 <jrandom> кстати об этом 16:04 * jrandom сворачивает 16:04 <nymisis> Ох, чёрт, хорошее замечание. 16:04 * jrandom закрывает встречу *baf*