Всем привет, на этой неделе — запоздалые заметки о статусе

  • Index
  1. Статус сети 2) Статус разработки Router 3) Продолжение обоснования Syndie 4) Статус разработки Syndie 5) Распределённая система контроля версий 6) ???
    1. Net status

Последнюю неделю или две на irc и других сервисах всё было довольно стабильно, хотя на dev.i2p/squid.i2p/www.i2p/cvs.i2p случались небольшие перебои (из-за временных проблем, связанных с ОС). Похоже, в данный момент всё стабильно.

    1. Router dev status

Обратная сторона обсуждения Syndie — “итак, что это означает для router?”, и чтобы ответить на это, позвольте немного пояснить, в каком состоянии сейчас находится разработка router.

В целом, по моему мнению, то, что мешает router (маршрутизатор I2P) достичь версии 1.0, — это его производительность, а не характеристики анонимности. Безусловно, есть аспекты анонимности, которые можно улучшить, но, хотя для анонимной сети мы действительно получаем весьма неплохую производительность, её недостаточно для более широкого использования. Кроме того, улучшения анонимности сети не повысят её производительность (в большинстве случаев, которые я могу вспомнить, улучшения анонимности снижают пропускную способность и увеличивают задержку). Нам нужно сначала разобраться с проблемами производительности, потому что если производительность недостаточна, то вся система недостаточна, независимо от того, насколько сильны её методы обеспечения анонимности.

Итак, что же сдерживает нашу производительность? Как ни странно, похоже, это использование процессора. Прежде чем перейти к тому, почему именно, сначала немного предыстории.

  • to prevent partitioning attacks, we all need to plausibly build our tunnels from the same pool of routers.
  • to allow the tunnels to be of manageable length (and source routed), the routers in that pool must be directly reachable by anyone.
  • the bandwidth costs of receiving and rejecting tunnel join requests exceeds the capacity of dialup users on burst.

Следовательно, нам нужны уровни routers - некоторые глобально доступные с высокими пределами пропускной способности (tier A), некоторые нет (tier B). Это уже по сути реализовано через информацию о пропускной способности в netDb, и по состоянию на день или два назад соотношение tier B к tier A было около 3 к 1 (93 routers с cap L, M, N или O, и 278 с cap K).

Теперь, на уровне A по сути есть два дефицитных ресурса, которыми нужно управлять - пропускная способность и CPU. Пропускной способностью можно управлять обычными средствами (распределять нагрузку по широкому пулу, позволять некоторым пирам обрабатывать огромные объёмы [напр., на линиях T3], а также отклонять или ограничивать скорость отдельных tunnels и соединений).

Управление потреблением CPU сложнее. Основной узкий момент CPU, наблюдаемый на routers уровня A, заключается в дешифровании запросов на построение tunnel. Крупные routers могут быть (и бывают) полностью поглощены этой операцией — например, среднее за всё время значение времени дешифрования tunnel на одном из моих routers составляет 225ms, а средняя за всё время частота дешифрования запросов на построение tunnel составляет 254 события за 60 секунд, или 4.2 в секунду. Просто перемножив эти два значения, видно, что 95% CPU расходуется только на дешифрование запросов на построение tunnel (и это без учёта всплесков числа событий). Этот router при этом всё же каким-то образом успевает одновременно участвовать в 4-6000 tunnels, принимая примерно 80% расшифрованных запросов.

К сожалению, из‑за того, что CPU на этом router настолько сильно загружен, ему приходится отбрасывать значительное число запросов на построение tunnel ещё до того, как их вообще можно расшифровать (иначе запросы так долго бы висели в очереди, что, даже будь они приняты, исходный инициатор запроса всё равно счёл бы их потерянными или что нагрузка слишком высока, чтобы вообще что‑то делать). В этом свете уровень принятия в 80% у этого router выглядит гораздо хуже - за всё время его работы он расшифровал около 250 тыс. запросов (то есть было принято около 200 тыс.), но из‑за перегрузки CPU ему пришлось отбросить около 430 тыс. запросов в очереди на расшифровку (сведя те 80% принятия к 30%).

Решения, по‑видимому, заключаются в снижении соответствующих затрат CPU на расшифровку запросов на построение tunnel. Если мы сократим время CPU на порядок, это существенно увеличит пропускную способность router уровня tier A, тем самым уменьшив количество отказов (как явных, так и неявных, из‑за отброшенных запросов). Это, в свою очередь, повысит успешность построения tunnel, что снизит частоту истечения сроков действия lease (лизов), а затем уменьшит нагрузку на полосу пропускания сети из‑за перестроения tunnel.

Одним из способов было бы изменить запросы на построение tunnel, чтобы вместо 2048‑битного Elgamal использовать, скажем, 1024‑ или 768‑битный. Однако проблема в том, что если вы взломаете шифрование в сообщении запроса на построение tunnel, вы узнаете полный маршрут tunnel. Даже если бы мы пошли по этому пути, что бы это нам дало? Сокращение времени расшифровки на порядок может быть сведено на нет десятикратным увеличением соотношения tier B к tier A (так называемая проблема фрирайдеров), и тогда мы оказались бы в тупике, поскольку мы никак не сможем перейти на 512‑ или 256‑битный Elgamal (и при этом смотреть на себя в зеркало ;)

Одной из альтернатив было бы использовать более слабую криптографию, но отказаться от защиты от атак по подсчёту пакетов, которую мы добавили в новом процессе построения туннелей. Это позволило бы нам использовать полностью эфемерные согласованные ключи в телескопическом туннеле по типу Tor (хотя, опять же, это подвергло бы создателя туннеля тривиальным пассивным атакам по подсчёту пакетов, позволяющим идентифицировать сервис).

Другая идея — публиковать и использовать ещё более явную информацию о нагрузке в netDb, что позволит клиентам точнее обнаруживать ситуации, подобные описанной выше, когда router с высокой пропускной способностью отбрасывает 60% своих сообщений запроса tunnel, даже не просматривая их. Есть несколько экспериментов, которые стоит провести в этом направлении, и их можно выполнить с полной обратной совместимостью, так что мы вскоре должны их увидеть.

Итак, как я это вижу сегодня, узкое место — в router/сети. Мы будем очень признательны за любые предложения о том, как мы можем с этим справиться.

    1. Syndie rationale continued

На форуме появился содержательный пост о Syndie и о том, как она вписывается в общую схему - ознакомьтесь по адресу http://forum.i2p.net/viewtopic.php?t=1910

Также я хотел бы выделить два фрагмента из документации Syndie, над которой ведётся работа. Во‑первых, из irc (и из ещё не опубликованного FAQ):

вопрос, над которым я размышлял: у кого потом хватит смелости, чтобы размещать боевые серверы/архивы syndie? разве их не будет так же легко отследить, как и eepsites(I2P Sites) сегодня? публичные архивы syndie не имеют возможности читать содержимое, размещённое на форумах, если только форумы не публикуют ключи для этого и см. второй абзац usecases.html конечно, те, кто размещает архивы, получив законное предписание удалить форум, вероятно, так и поступят (но тогда люди могут перейти на другой архив, не нарушая работу форума) да, стоит упомянуть, что миграция на другую платформу пройдёт бесшовно если мой архив закроется, я смогу загрузить весь свой форум на новый архив, верно? именно, bar они могут использовать два метода одновременно во время миграции и любой может синхронизировать эти платформы верно, void

Соответствующий раздел (ещё не опубликованного) файла Syndie usecases.html:

Хотя многие разные группы часто хотят организовать обсуждения в онлайн‑форуме, централизованная природа традиционных форумов (веб‑сайты, BBS и т. п.) может быть проблемой. Например, сайт, на котором размещён форум, можно вывести из сети с помощью атак отказа в обслуживании или административного вмешательства. Кроме того, единый хост создаёт простую точку для наблюдения за активностью группы, так что даже если на форуме используются псевдонимы, эти псевдонимы могут быть привязаны к IP‑адресу, с которого публиковали или читали отдельные сообщения.

Кроме того, форумы не только децентрализованы, они организованы в ad-hoc режиме (импровизированным образом), при этом полностью совместимы с другими методами организации. Это означает, что небольшая группа людей может вести свой форум, используя один метод (распространяя сообщения путём их размещения на wiki-сайте), другая может вести свой форум, используя другой метод (публикуя свои сообщения в распределённой хеш-таблице, такой как OpenDHT, и если один человек знаком с обоими методами, он может синхронизировать эти два форума друг с другом. Это позволяет людям, знавшим только о wiki-сайте, общаться с людьми, которые знали только о сервисе OpenDHT, ничего не зная друг о друге. Развивая это дальше, Syndie позволяет отдельным ячейкам контролировать степень собственной открытости, при этом общаясь в рамках всей организации.

    1. Syndie dev status

В последнее время в Syndie достигнут значительный прогресс: выпущено 7 альфа-версий, разданных участникам на IRC-канале. Большинство основных проблем в скриптовом интерфейсе было устранено, и я надеюсь, что нам удастся выпустить Syndie 1.0 позже в этом месяце.

Я только что сказал «1.0»? Ещё бы! Хотя Syndie 1.0 будет текстовым приложением и по удобству использования даже не будет сопоставимо с другими сходными текстовыми приложениями (такими как mutt или tin), оно предоставит весь спектр функциональности, позволит применять стратегии синдикации по HTTP и на основе файлов и, будем надеяться, продемонстрирует потенциальным разработчикам возможности Syndie.

Сейчас я предварительно намечаю релиз Syndie 1.1 (который позволит людям лучше организовать свои архивы и процесс чтения) и, возможно, релиз 1.2 для интеграции некоторой поисковой функциональности (как простого поиска, так и, возможно, полнотекстового поиска Lucene). Syndie 2.0, вероятно, станет первым выпуском с графическим интерфейсом (GUI), а плагин для браузера выйдет вместе с 3.0. Поддержка дополнительных архивов и сетей распространения сообщений появится по мере реализации, разумеется (freenet, mixminion/mixmaster/smtp, opendht, gnutella и т. п.).

Я, однако, понимаю, что Syndie 1.0 не произведёт того фурора, на который некоторые рассчитывают, ведь приложения с текстовым интерфейсом в основном для гиков, но мне бы хотелось попытаться избавить нас от привычки воспринимать «1.0» как окончательный релиз и, напротив, считать его началом.

    1. Distributed version control

До сих пор я возился с subversion как с системой контроля версий для Syndie, хотя на самом деле хорошо разбираюсь только в CVS и clearcase. Это потому, что я большую часть времени офлайн, а даже когда онлайн, модемное соединение медленное, так что локальные diff/revert/etc в subversion были весьма кстати. Однако вчера void подкинул идею вместо этого присмотреться к одной из распределённых систем.

Я рассматривал их несколько лет назад, когда оценивал систему контроля версий для I2P, но отказался от них, потому что мне не были нужны их возможности автономной работы (тогда у меня был хороший доступ к интернету), так что изучать их не имело смысла. Теперь это уже не так, поэтому сейчас изучаю их повнимательнее.

  • From what I can see, darcs, monotone, and codeville are the top

Среди претендентов патч-ориентированная система контроля версий (VCS) darcs кажется особенно привлекательной. Например, я могу делать всю работу локально и просто по scp загрузить на dev.i2p.net в каталог Apache gzip-сжатые и gpg-обработанные диффы, а люди могут вносить свои изменения, публикуя свои gzip-сжатые и gpg-обработанные диффы в выбранных ими местах. Когда придёт время пометить релиз тегом, я сделаю darcs diff, который указывает набор патчей, входящих в релиз, и отправлю этот .gz’ed/.gpg’ed diff так же, как и остальные (а также, конечно, выложу реальные файлы tar.bz2, .exe и .zip ;)

И, что особенно интересно, эти diff-патчи, сжатые с помощью gzip и/или зашифрованные gpg, могут быть отправлены в виде вложений к сообщениям Syndie, что позволяет Syndie самостоятельно хоститься.

У кого‑нибудь есть опыт работы с этими штуками? Какие‑нибудь советы?

    1. ???

На этот раз всего 24 экрана текста (включая сообщение на форуме) ;) К сожалению, я не смог присутствовать на встрече, но, как всегда, буду рад услышать ваши идеи и предложения - просто напишите в рассылку, на форум или загляните в IRC.

=jr