333.i2p

Роутеру задать конфигурационный параметр чтобы, помимо основного NTCP порта, он также слушал какой то из них.
Это свойство публикуется в RouterInfo.
Соединения, установленный по такому порту разрываются после более длительного периода неактивности.
Нужно для тех, у кого наружу открыты только 80 и 443.
В такой ситуации следует найти такой роутер и использовать соединение с ним в качестве последнего хопа тоннелей.

partizan wrote:

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

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

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

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

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

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

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