333.i2p

partizan wrote:

Для тех, кто из исходников ставит, надо просто в документации уточнить, где брать готовые примеры. Или создать каталог examples.

Проблема в том, что создается папка ~/.i2pd/ с набором файлов, юзеры не находят там конфиг и им кажется, что его и не должно быть. Имхо, раз создается папка, то надо туда пихать все, что там должно быть.

orignal wrote:

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

А хз. Если не лучше, то не надо :)

Еще один момент, считаю, необходимо очевидным образом отобразить в документации: для нормальной работы i2p обязательно должна быть настроена синхронизация с точным временем.
Я, например, вроде бы и в курсе был, но т.к. на ноуте изредка синхронизирую время вручную, то разница была где-то в 1.5-2 минуты. При попытке поднять i2pd на нем часа полтора тупил на 3-4 известных роутера и пару сиротливых туннелей. Пока не синхронизировался, наконец. По-моему, очень знакомая картина, когда люди жалуются, что у них сутками не поднимается ничего.

xcps wrote:

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

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

Я полагал, что в дебиановские пакеты конфиги из каталога debian попадают. В Archlinux тоже пакет формируется с этими конфигами.
Для тех, кто из исходников ставит, надо просто в документации уточнить, где брать готовые примеры. Или создать каталог examples.
А вот в subscriptions.txt, IMHO, было бы правильнее b32 адреса прописать. Это помогло бы быстрее получить addressbook при первых запусках.

Ну вроде компилить умеют, а дальше не получается.
В идеале бы да, в деб пакетах. Они же вроде есть уже?
Можно кстати и просто архивом, чтоб распаковал в папку i2pd, и там тебе и конфиги и тоннели и бинарник, и работает все. Фаерфокс недавно качал - они так делают.

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

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

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