Pull to refresh

Comments 20

Могу сказать, что сеть достаточно быстра, а новые ноды в i2p могут только ускорить сеть.
На сколько быстро чем тор? Помню как поставил себе ТОР-брайзер то скорость была 1/10 моего канала.
Гораздо, гораздо медленнее, чем Tor. Максимум видел 2 мегабита/с.
Два мегабита через i2p — это фантастика. Обычно там байты в секунду, ну, максимум, килобайты.
Да нет, вроде, я даже на hiddenbooru.i2p иногда заглядываю, нормально открывается. Байт в секунду никогда не видел, отклик больше 5 секунд тоже редко бывает.

У меня floodfill-нода с несколькими тысячами подключений, которая запущена круглосуточно. Может быть, в этом и дело.
Откуда столько коннектов?
У меня 24\7, динамика+noip, ограничение 2Мбит\с в обе стороны, нода транзитная. Показывает совсем скромные статы:

Активные: 17 / 152
Быстрые: 29
Высокоемкие: 74
интегрированные: 177
Известные: 242

Что-то принципиально изменится если дам ей статику?
У Вас слабоинтегрирован в сеть роутер. Или проблема на стороне сайта. Скорости с порядком «байты в секунду» были в i2p года три назад. Год назад, один мой приятель там торренты раздавал на сотнях килобит в секунду.
Это очень странно, потому что я специально выделенный сервер под это дело поднял и он на ipv4/ipv6 почти 24\7 в онлайне.
планируется ли добавлять фильмы с русскоязычной озвучкой?
Если бы еще I2P был написан на компилируемом языке (как Tor) и не требовал бы Java VM…
Только второй развивается и юзабелен, судя по коду и коммитам. Но я говорил о другом — о том, чтобы этот i2pd стал официальным, а не в позиции догоняющего.
Ну вот когда все функции сети будут реализованы в сишной клиенте тогда и можно говорить об замене официальной версии на сишную (особенно если разработчики основной версии знают си)
Такая задача не стоит. i2pd он для тех ниш, где джава не подходит
А жаль, тем не менее удачи с его разработкой!
Какое это имеет значение? Это же деталь реализации.
В случае десктопных компьютеров — да. В случае же установки на роутер (или что-то подобное) — java не подойдет. Да и для слабых компьютеров не подходит: проблема не в скорости, а в объеме памяти для работы.
Java тут не совсем при делах. На С можно написать программу, которая без гигабайта работать не будет. И на Java можно написать программу, нетребовательную к памяти. Например на любой SIM-карте работает Java-программа, код и память которой умещаются в 64 килобайта памяти. Там, конечно, не совсем та Java, которая на десктопе, но и десктопная/серверная Java не требует сама по себе кучу памяти, если речь не идёт о считанных мегабайтах. Например при запуске java -Xmx16m ей позволяется использовать около 16 мегабайтов оперативной памяти. При этом мой тест показывает, что приложение может выделить на свои нужды около 10 мегабайтов оперативной памяти. Вообще говоря 10 мегабайтов это много и в них можно уместить много функционала.
тут несколько нюансов возникает (где-то с год назад смотрел почему так много cpu выедается):
1) шифрование (луковая архитектура заставляет хорошенько погреть воздух, да и памяти кушает порядочно в режиме router именно он)
2) SSU (он же udp, очень часто замечал что выступает в приоритете), так как он любит порождать на по потоку на соединение, а отсюда и context switch вылазит и wait на сокетах. NTCP уже nio и от многих проблем избавлен, но он уже tcp.

в связке этих 2 пункта дают как неплохое потребление памяти (буфера на чтение-запись, шифрование, стек под каждый новый поток-соединение) и cpu (context switch, постоянное шифрование),

так что получаем:
1) режем скорость и количество соединений — работаем шустро
2) даем много ресурсов — проц захлебывается, поедание памяти и то не настолько заметно даже становится
Only those users with full accounts are able to leave comments. Log in, please.