333.i2p

Предлагаю идею для более правильной реализации в клиенте i2pd outproxy, которую так многие хотят использовать на свою голову.
Я исхожу из того предположения, что для i2p выход в клирнет вреден. Для этого специально придуман tor. Поэтому каждый инструмент необходимо использовать по его прямому назначению.
Каждый современный браузер поддерживает Proxy Auto-Configuration (PAC). Раз в i2pd-слиенте есть http-сервер, использующийся для консоли, то есть возможность малыми средствами отдавать через него же и файл автоконфигурации, который может лежать в каталоге рядом с файлами конфигурации демона и туннелей. Например, включить в дистрибутив файл <i2pd_work_dir>/pac/i2p_tor.pac:

function FindProxyForURL(url, host) {
if (dnsDomainIs(host, ".i2p"))
// i2pd
// return "SOCKS5 127.0.0.1:9051";
return "PROXY 127.0.0.1:4444";

// Tor in other cases
return "SOCKS5 127.0.0.1:9050";
}

и указывать его url в настройках браузера. Например, в firefox в <Preferences><Advanced><Network><Settings...> выбрать <Automatic proxy configuration URL:> и указать "http://localhost:7070/pac/i2pd_tor.pac";

Во-первых, таким образом, из кода i2pd можно удалить лишний (и потенциально кривой) код outproxy. Во-вторых, пользователь может конфигурить пути выхода в инет как ему вздумается на свой страх и риск.
В файле PAC употребление "return "SOCKS5" гарантирует использование "remote DNS" без дополнительных телодвижений. (http proxy делает это по-умолчанию, насколько я знаю).

Еще один момент, считаю, необходимо очевидным образом отобразить в документации: для нормальной работы i2p обязательно должна быть настроена синхронизация с точным временем.
Я, например, вроде бы и в курсе был, но т.к. на ноуте изредка синхронизирую время вручную, то разница была где-то в 1.5-2 минуты. При попытке поднять i2pd на нем часа полтора тупил на 3-4 известных роутера и пару сиротливых туннелей. Пока не синхронизировался, наконец. По-моему, очень знакомая картина, когда люди жалуются, что у них сутками не поднимается ничего.

Я полагал, что в дебиановские пакеты конфиги из каталога debian попадают. В Archlinux тоже пакет формируется с этими конфигами.
Для тех, кто из исходников ставит, надо просто в документации уточнить, где брать готовые примеры. Или создать каталог examples.
А вот в subscriptions.txt, IMHO, было бы правильнее b32 адреса прописать. Это помогло бы быстрее получить addressbook при первых запусках.

А сейчас механизм проверки туннеля разве существует? Судя по задержкам и зависаниям просто тупо ожидается окончание жизни туннеля (10 минут) и затем строится новый. То есть проблема в отсутствии адекватной сигнализации на транспортном уровне. Может, тогда стоит и говорить о внедрении уровня сигнализации в протокол?
Просто, если рассуждать технически, грубо упрощая из-за нехватки понимания деталей, для двунаправленного туннеля ты создаешь те же два сокета, что и для двух однонаправленных. Просто на логическом уровне манипулируешь другой единицей, даже еще и половинкми (туда и обратно). Как-то не совсем очевидна выгода.
Вот есть старый добрый ipsec, например. Там до сих пор туннели однонаправленные, и никого это не парит.

Выглядит, с точки зрения озвученных задач, привлекательно. Но для полноценной дискуссии лично мне не хватает глубокого понимания архитектуры сети.
Поэтому, вопрос, который, как я понимаю, волнует басурманских девелоперов в первую очередь: не снизит ли это нововведение анонимность сети? То есть, верно ли то, что в этом случае в два раза проще отследить конечные узлы туннеля, т.к. в два раза сокращается количество транзитных узлов для прохождения сообщения туда-обратно?
В плане снижения нагрузки на проц и проброс через другие сети - да, перспективно.