Всем привет, извините за опоздание…
Указатель:
Предоставьте ТОЛЬКО перевод, ничего больше:
- 0.4
- Capacity and overload
- Website updates
- I2PTunnel web interface
- Roadmap and todo
- ???
1) 0.4
Как, уверен, вы все уже видели, релиз 0.4 вышел на днях, и в целом всё идёт довольно неплохо. Трудно поверить, что прошло 6 месяцев с тех пор, как вышла 0.3 (и год с момента выхода 1.0 SDK), но мы проделали большой путь, и ваш тяжёлый труд, энтузиазм и терпение творят чудеса. Поздравляю и спасибо!
Like any good release, as soon as it hit the door we found some problems, and over the last few days we’ve been accumulating bug reports and patching like mad (you can watch the changes as they’re fixed). We do still have a few more bugs left to squash prior to pushing out the next rev, but that should be done in the next day or so.
2) Пропускная способность и перегрузка
Мы наблюдали довольно перекошенное распределение tunnels за последние несколько релизов, и хотя часть из этого связана с багами (два из них исправлены после выхода 0.4), всё же остаётся общий вопрос по алгоритму — когда router должен перестать принимать новые tunnels?
Несколько ревизий назад мы добавили код ограничения (throttling), чтобы отклонять запросы на участие в tunnel, если router перегружен (локальное время обработки сообщений превышает 1s), и это существенно помогло. Однако у этого простого алгоритма есть два аспекта, которые не учитываются: - когда наша пропускная способность загружена до предела, локальное время обработки может по-прежнему быть быстрым, поэтому мы продолжали бы принимать больше запросов на участие в tunnel - когда один пир участвует в “слишком большом числе” tunnels, при их отказе это наносит сети больший ущерб.
Первая проблема решается довольно просто — достаточно включить ограничитель пропускной способности (поскольку ограничение пропускной способности увеличивает время обработки сообщений в соответствии с задержкой, обусловленной пропускной способностью). Вторая сложнее, и здесь необходимы и дальнейшие исследования, и дополнительное моделирование. Я думаю о чем-то вроде вероятностного отклонения запросов на tunnel на основе отношения количества tunnel, в которых мы участвуем, к количеству tunnel, запрашиваемых из сети, включая некоторый базовый “коэффициент доброты”, при этом P(reject) = 0, если мы участвуем меньше этого.
Но, как я уже сказал, необходимы дальнейшая работа и моделирование.
3) Обновления сайта
Теперь, когда у нас появился новый веб-интерфейс I2P, практически вся наша старая документация для конечных пользователей устарела. Нам нужна помощь в том, чтобы пройтись по этим страницам и обновить их, чтобы они описывали, как всё устроено сейчас. Как предлагали duck и другие, нам нужно новое руководство «быстрый старт» помимо readme на http://localhost:7657/ - что-то, что поможет людям быстро начать пользоваться системой.
Кроме того, наш новый веб-интерфейс предоставляет достаточно возможностей для интеграции контекстно-зависимой справки. Как вы можете видеть в поставляемом файле help.jsp, “хм. наверное, здесь стоило бы разместить какой-нибудь текст справки.”
Было бы, наверное, здорово, если бы мы могли добавить на различные страницы ссылки ‘about’ и/или ’troubleshooting’, объясняющие, что означает то или иное и как этим пользоваться.
4) Веб-интерфейс I2PTunnel
Назвать новый интерфейс http://localhost:7657/i2ptunnel/ «аскетичным» — это мягко сказано. Нам предстоит проделать много работы, чтобы приблизить его к состоянию, пригодному для использования — сейчас функциональность технически уже есть, но чтобы в нём разобраться, нужно понимать, что происходит «под капотом». Думаю, у duck могут быть дополнительные идеи по этому поводу, которые он поднимет на встрече.
5) Дорожная карта и список задач
Я подзабросил поддержание дорожной карты в актуальном состоянии, но по факту нам предстоит дальнейший пересмотр. Чтобы объяснить, какие «большие проблемы» я вижу, я составил новый список задач, в котором по каждой из них даны некоторые детали. Думаю, на данном этапе нам стоит достаточно открыто подойти к пересмотру наших вариантов и, возможно, переработке дорожной карты.
Я забыл упомянуть ещё одну вещь в том списке дел: при добавлении легковесного протокола соединения мы можем включить (необязательное) автоопределение IP-адреса. Это может быть ‘опасным’ (поэтому оно будет необязательным), но это значительно сократит число запросов в поддержку :)
В любом случае, те задачи, указанные в списке задач, мы планировали для разных релизов, и уж точно не все они попадут в 1.0, да и в 2.0 тоже вряд ли. Я набросал несколько разных возможных вариантов приоритизации/релизов, но пока не зафиксировал их окончательно. Однако, если кто-то сможет указать на другие крупные вещи в перспективе, мы будем очень признательны, поскольку незапланированная задача всегда большая головная боль.
6) ???
Ладно, на этом у меня пока всё (и это, кстати, к лучшему, поскольку встреча начинается через несколько минут). Заглядывайте в #i2p на irc.freenode.net, www.invisiblechat.com или irc.duck.i2p в 9 вечера по GMT, чтобы пообщаться дальше.