Всем привет, время еженедельного обновления

Указатель:

  1. 0.4.1.1 status
  2. Pretty pictures
  3. 0.4.1.2 and 0.4.2
  4. Bundled eepserver
  5. ???

1) 0.4.1.1 статус

После довольно проблемного релиза 0.4.1 (и последующего оперативного обновления 0.4.1.1) сеть, похоже, вернулась к нормальной работе - сейчас активно пятьдесят с чем-то пиров, и доступны как irc, так и eepsites(I2P Sites). Большая часть проблем была вызвана недостаточным тестированием нового транспорта вне лабораторных условий (например, сокеты разрывались в неожиданные моменты, наблюдались чрезмерные задержки и т. п.). В следующий раз, когда нам потребуется внести изменения на этом уровне, мы обязательно проведём более широкое тестирование до релиза.

2) Красивые картинки

За последние несколько дней в CVS было сделано множество обновлений, и одной из новинок стал новый компонент журналирования статистики, позволяющий нам просто извлекать сырые данные статистики по мере их генерации, а не иметь дело с грубыми средними, получаемыми на /stats.jsp. С его помощью я наблюдаю за несколькими ключевыми показателями на нескольких router (маршрутизаторах), и мы всё ближе к выявлению оставшихся проблем со стабильностью. Сырые данные статистики довольно объёмны (20-часовой прогон на машине duck сгенерировал почти 60 МБ данных), но именно поэтому у нас есть красивые графики - http://dev.i2p.net/~jrandom/stats/

Ось Y на большинстве из них — миллисекунды, а ось X — секунды. Есть несколько интересных моментов. Во-первых, client.sendAckTime.webp довольно хорошо аппроксимирует время одного прохода туда-обратно (RTT), поскольку ACK-сообщение (подтверждение) отправляется вместе с полезной нагрузкой, а затем возвращается по полному маршруту tunnel — таким образом, подавляющее большинство из почти 33 000 успешно отправленных сообщений имели RTT менее 10 секунд. Если затем рассмотреть client.sendsPerFailure.webp вместе с client.sendAttemptAverage.webp, мы увидим, что 563 неудачные отправки почти все исчерпали максимально допустимое число повторных попыток (5 при мягком таймауте 10s на попытку и жестком таймауте 60s), тогда как большинство остальных попыток завершались успехом с первой или второй попытки.

Ещё одно интересное изображение — client.timeout.webp, которое серьёзно ставит под сомнение мою гипотезу — что сбои отправки сообщений коррелировали с некоей локальной перегрузкой. Нанесённые на график данные показывают, что использование входящей полосы пропускания сильно варьировалось во время сбоев, не наблюдалось устойчивых всплесков локального времени обработки отправки и, по‑видимому, вовсе отсутствовала какая‑либо закономерность в задержке теста tunnel.

Файлы dbResponseTime.webp и dbResponseTime2.webp похожи на client.sendAckTime.webp, за исключением того, что они соответствуют сообщениям netDb, а не сквозным клиентским сообщениям.

Файл transport.sendMessageFailedLifetime.webp показывает, как долго мы удерживаем сообщение локально, прежде чем признать его неуспешным по какой-либо причине (например, из-за истечения срока действия или недоступности пира, на которого оно нацелено). Некоторых сбоев не избежать, но на этом изображении видно, что значительное число сообщений «падает» сразу после локального таймаута отправки (10 с). Есть несколько вещей, которые мы можем сделать, чтобы это исправить: - во-первых, мы можем сделать shitlist (временный «черный список») более адаптивным- экспоненциально увеличивать период, на который пир заносится в shitlist, вместо фиксированных 4 минут. (это уже внесено в CVS) - во-вторых, мы можем заблаговременно признавать сообщения неуспешными, когда, по-видимому, они все равно завершатся неудачей. Для этого каждое соединение должно отслеживать свою скорость отправки, и всякий раз, когда в его очередь добавляется новое сообщение, если число уже поставленных в очередь байт, деленное на скорость отправки, превышает оставшееся до истечения время, немедленно помечать сообщение как неуспешное. Этот показатель также можно использовать при определении, принимать ли еще запросы на создание tunnel (туннеля) через данного пира.

В любом случае, переходим к следующей симпатичной картинке — transport.sendProcessingTime.webp. На ней видно, что эта конкретная машина редко является причиной заметной задержки — обычно 10–100ms, хотя иногда бывают всплески до 1s и более.

Каждая точка на графике tunnel.participatingMessagesProcessed.webp показывает, сколько сообщений было передано по tunnel, в котором участвовал данный router. В сочетании со средним размером сообщения это дает нам оценочную сетевую нагрузку, которую пир берет на себя для других пользователей.

Последнее изображение — это tunnel.testSuccessTime.webp, которое показывает, сколько времени требуется, чтобы отправить сообщение наружу через один tunnel и вернуть его обратно домой через другой входящий tunnel, что дает нам оценку того, насколько хороши наши tunnel.

Ладно, с красивыми картинками пока хватит. Вы можете сгенерировать данные самостоятельно на любом релизе новее 0.4.1.1-6, задав параметр конфигурации router “stat.logFilters” как список названий статистик, разделённый запятыми (возьмите названия на странице /stats.jsp). Это записывается в stats.log, который вы можете обработать с помощью

java -cp lib/i2p.jar net.i2p.stat.StatLogFilter stat.log

который разбивает это на отдельные файлы для каждого показателя, пригодные для загрузки в вашу любимую утилиту (например, gnuplot).

3) 0.4.1.2 и 0.4.2

С момента выпуска 0.4.1.1 было сделано много обновлений (см. историю для полного списка), но критических исправлений пока нет. Мы выпустим их в следующем патч-релизе 0.4.1.2 позже на этой неделе после того, как будут устранены некоторые нерешённые ошибки, связанные с автоопределением IP.

Следующей крупной задачей на том этапе будет выпуск 0.4.2, который сейчас планируется как существенная переработка обработки tunnel. Это потребует много работы: пересмотр шифрования и обработки сообщений, а также пулов tunnel, но это довольно критично, поскольку злоумышленник сейчас может достаточно легко провести некоторые статистические атаки на tunnel (например, атака предшественника со случайным порядком tunnel или сбор данных из netDb).

dm, однако, поднял вопрос о том, имеет ли смысл сначала заняться стриминговой библиотекой (streaming lib) (на данный момент запланированной к релизу 0.4.3). Плюс этого в том, что сеть стала бы и более надежной, и обеспечивала бы лучшую пропускную способность, что стимулировало бы других разработчиков активнее работать над клиентскими приложениями. После того как это будет готово, я смогу вернуться к переработке tunnel и заняться (не видимыми пользователю) вопросами безопасности.

С технической точки зрения, две задачи, запланированные для 0.4.2 и 0.4.3, ортогональны, и обе в любом случае будут выполнены, поэтому, похоже, нет особых минусов в том, чтобы поменять их местами. Я склонен согласиться с dm, и если только кто-то не приведёт причины оставить 0.4.2 для обновления tunnel, а 0.4.3 — для стриминговой библиотеки, мы их поменяем местами.

4) Встроенный eepserver

Как было упомянуто в примечаниях к выпуску 0.4.1, мы включили программное обеспечение и конфигурацию, необходимые для запуска eepsite(I2P-сайта) «из коробки» - вы можете просто поместить файл в каталог ./eepsite/docroot/ и поделиться назначением I2P, найденным на консоли router.

Несколько человек пожурили меня за мой энтузиазм по поводу .war‑файлов — большинство приложений, к сожалению, требуют чуть больше работы, чем просто поместить файл в каталог ./eepsite/webapps/. Я подготовил краткое руководство по запуску блогового движка blojsom, и вы можете посмотреть, как это выглядит, на сайте detonate.

5) ???

Это примерно всё, что у меня есть на данный момент — загляните на встречу через 90 минут, если хотите это обсудить.

=jr