333.i2p

1. Корректный останов по сигналу SIGINT
2. Можно задавать ограничения трафика в килобайтах
3. джампы через вебконсоль
4. Новая реализация логов и записать в syslog
5. Иконка в системном лотке для windows версии
6. Больше статистики в вебконсоли
7. Новые имена для конфигов (i2pd.conf и tunnels.conf)

zazaza wrote:

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

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

Да, логично туда положить хотя бы пустые файлы.

xcps wrote:

А если еще сделать, чтоб какой нибудь бот раз в сутки netDB актуализировал в архивах на сервере, то вообще круто было.

А чем это лучше ресида?

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

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

Релиз 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 минут) и затем строится новый. То есть проблема в отсутствии адекватной сигнализации на транспортном уровне. Может, тогда стоит и говорить о внедрении уровня сигнализации в протокол?

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

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

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

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