Привет, команда, пришло время нашего еженедельного обновления
Указатель:
- 0.4.1.2
- 0.4.1.3
- 0.4.2
- mail discussions
- ???
1) 0.4.1.2
Новый релиз 0.4.1.2 вышел несколько дней назад, и в целом всё идёт как ожидалось — хотя с новым компонентом watchdog (сторожевой таймер) возникло несколько проблем: он убивает ваш router, когда всё идёт плохо, вместо того чтобы перезапускать его. Как я уже упоминал сегодня, я ищу людей, готовых воспользоваться новым инструментом логирования статистики и прислать мне немного данных, так что за вашу помощь буду весьма признателен.
2) 0.4.1.3
Перед выходом 0.4.2 будет ещё один релиз, так как я хочу, чтобы сеть была максимально надёжной, прежде чем двигаться дальше. Сейчас я экспериментирую с динамическим ограничением участия в tunnel (туннель) — давая указание routers (маршрутизаторам) с некоторой вероятностью отклонять запросы, если они перегружены или их tunnels работают медленнее обычного. Эти вероятности и пороги вычисляются динамически на основе собираемой статистики: если ваше 10‑минутное время теста tunnel больше, чем ваше 60‑минутное время теста tunnel, принимайте запрос на tunnel с вероятностью 60minRate/10minRate (и если ваше текущее количество tunnels больше вашего среднего за 60 минут количества tunnels, примите его с p=60mRate/curTunnels).
Ещё одним потенциальным ограничителем является сглаживание использования полосы пропускания в том же духе - отклоняя tunnels вероятностным образом, когда у нас происходят всплески её использования. В любом случае, цель всего этого — помочь равномернее распределить сетевую нагрузку и сбалансировать tunnels между большим числом участников. Основной проблемой, с которой мы сталкивались при балансировке нагрузки, был подавляющий избыток пропускной способности, и поэтому ни один из наших триггеров “чёрт, мы медленные, давайте отклонять” не срабатывал. Эти новые вероятностные механизмы, будем надеяться, помогут держать резкие изменения под контролем.
У меня нет конкретного плана, когда выйдет релиз 0.4.1.3 — возможно, на выходных. Данные, которые люди присылают (см. выше), должны помочь определить, имеет ли это смысл, или есть другие, более перспективные направления.
3) 0.4.2
Как мы обсуждали на встрече на прошлой неделе, мы поменяли местами релизы 0.4.2 и 0.4.3 - 0.4.2 будет новой библиотекой потоковой передачи, а 0.4.3 будет обновлением tunnel.
Я снова пересматриваю литературу по потоковой функциональности TCP, и там есть несколько интересных вопросов, представляющих интерес для I2P. В частности, наше большое время прохождения туда‑обратно тянет нас в сторону чего-то вроде XCP, и, вероятно, нам следует достаточно агрессивно использовать различные формы явного уведомления о перегрузке, хотя мы не можем воспользоваться чем-то вроде опции метки времени, поскольку наши часы могут быть рассинхронизированы до минуты.
Кроме того, нам нужно убедиться, что мы можем оптимизировать streaming lib (библиотеку потоковой передачи) для обработки краткоживущих соединений (с чем обычный TCP справляется весьма плохо) - например, я хочу иметь возможность отправлять небольшие (<32KB) запросы HTTP GET и небольшие (<32KB) ответы буквально в трех сообщениях:
Alice-->Bob: syn+data+close
Bob-->Alice: ack+data+close (the browser gets the response now)
Alice-->Bob: ack (so he doesn't resend the payload)
В любом случае, пока реализовано немного кода: протокольная часть в значительной степени похожа на TCP, а пакеты чем‑то напоминают смесь предложения human и старого предложения. Если у кого‑то есть предложения или идеи или вы хотите помочь с реализацией, пожалуйста, свяжитесь.
4) обсуждение по электронной почте
Были некоторые интересные обсуждения, касающиеся электронной почты в (и вне) I2P — postman опубликовал набор идей онлайн и ищет предложения. Также были связанные обсуждения на #mail.i2p. Возможно, мы сможем попросить postman сообщить последние новости?
5) ???
На этом пока всё. Загляните на встречу через несколько минут и принесите свои комментарии :)
=jr