333.i2p

+ Использование Tor в качестве Socks outproxy

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

Сообщения будут ходить по прежнему через 4 тоннеля, то есть туда-обратно тоннели будут браться из разных пар.
Главное нововведение в том, что хозяин тоннеля будет знать о проблеме с ним непосредственно, а не косвенным путем как сейчас.

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

Продублирую здесь ранее высказанные соображения
http://zzz.i2p/topics/2041-proposal-i2pd-bi-dir...

С точки зрения I2P они буду выглядеть парой обычных однонаправленных тоннелей.
Задачи:
1. Уменьшение нагрузки на процессор за счет уменьшения числа запросов на построение тоннелей
2. Возможно узнать немедленно, что узел, входящий в тоннель, отключился и тоннель больше не функционирует
3. Более качественный профилировщик узлов
4. Возможность построение тоннелей через другие сети

Этого более чем достаточно

Предполагается включить:
1. Поддрежка семейств (family)
2. Новая реализация работы с файловой системой
3. Сжатые hosts.txt для подписок адресной книги
4. Серверные IRC тоннели

Обсуждаем, дополняем.