333.i2p

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

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

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

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

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

partizan wrote:

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

Сейчас у меня регулярно выбираются пары тоннелей и через них посылаются тестовые сообщения. Если оно не приходит, то какой из двух тоннелей сломан непонятно.
В джаве определяют только по недоставке сообщения в стримах по таймауту и только потом переключают тоннели, что приводит к жутким тормозам.
В том и проблема однонаправленных тоннелей, что нет возможности сообщить владельцу исходящего тоннеля, что какой то узел больше не функционирует - тоннель то идет в другую сторону. А в случае двунаправленных такая возможность будет всегда, как именно я написал в оригинальном посте - продублирую сюда тоже.

Коммитом 9403fba на гитхабе начинаем написание кода для двунаправленных тоннелей.

вместо того чтобы выдумывать велосипед, лучше взять аналог из реального мира - операторская технология SDH STM ITU-T G.707
Там для защиты колец используется специальная сигнализация, которая может работать по однонаправленному кольцу: смотреть стандарт ITU-T G.841
там надо-то всего два байта в каждом пакете.

zazaza wrote:

вместо того чтобы выдумывать велосипед, лучше взять аналог из реального мира - операторская технология SDH STM ITU-T G.707

А как в существующую I2P сеть встраиваться?