333.i2p

И как его распространять? В .deb пакетах?

Народ не может заюзать i2pd, элементарно найти конфигов не могут, потому что они не создаются при запуске.
Предлагаю:
- создавать дефолтный конфиг
- tunnels.cfg с прописанным тоннелем на ирк и жабер
- subscriptions.txt тоже не создается
- поставлять в адресной книге адреса jump сервисов, а можно и вообще многих популярных ипсайтов, у которых например аптайм год и больше, ибо по джамп сервисам ходить тоже не великое удовольствие.

Еще бы придумать че то с торрентами и почтой, но видимо не на этом этапе.

Вместо консоли главное окно и иконка в трее

Релиз 2.5.0 i2pd
1. Серверные IRC тоннели
2. Перенаправление трафика с SOCK прокси в Тор
3. Получение обновлений адресной книги в сжатом виде
4. Поддержка семейств маршрутизаторов (family)
5. Разделяемые RTT/RTO между потоками к одному и тому же адресу
6. Новый код для работы с файловой системой

Выпущен

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

Выкладываем сюда выдающиеся цитаты известного персонажа.

Позволяет обмениваться с другими anoncoin узлами через I2P.
Внешнего I2P роутера не требует.
https://bitbucket.org/orignal/anci2pd

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

partizan wrote:

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

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

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

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

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

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

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

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