Лагает он как раз по причине того что народ все время поднимает и опускает маршутизаторы.
Вот допустим вы остановили ваш маршутизатор, а через вас куча тоннелей шло. Создатели этих тоннелей продолжают их использовать, посылая данные в никуда и ожидая ниоткуда.
Прямого способа узнать что тоннель уже не функционирует нет.
Правильным решением, по моему разумению, было бы сообщение, аналогичное сообщению для создания тоннеля, которое бы узел рассылал через все свои тоннели, что он отключается.
У меня для этого есть иная идея: все http запросы в I2P через встроенный web-сервер, который используется для администирования, работающий по принципу анонимайзера. И все ссылки в получаемых страницах заменяются на него и адрес в качестве параметров.
Тогда все обращения к I2P адресам будут обеспечивать должную анонимность, а обращения к обычным адресам дальше собственного узла не уйдут.
«Через i2p не проходят гигазы трафика. Ну никак не проходят. Я уж и сто мегабит давал, и гигабит. Свободного сервера с 10кой пока нет, хотя есть острое желание попробовать. Не берут такой полосы. Дай бог, 300-400 килобит.»
Floodfill включать не пробовали? Тогда всякая новая информация о каком либо узле будет обмениваться с вашими соседями, что резко повысит трафик.
>Пишете что для понимания всех этих деталей нужно анализировать трафик. Но не легче ли анализировать исходный код java клиента?
Так исходный код так или иначе приходится трассировать, а он достаточно запутанный. Потому проще распечатать сами сообщения.
>Насколько я понимаю, I2P нельзя использовать просто как proxy, таким же образом как используется Tor. Именно поэтому и приходится для каждого приложения писать какой-то свой код который должен знать о том как работает сама I2P, в то время как в Tor достаточно просто взять программу которая уже работает через обычный TCP, и пустить её через proxy, что разумеется существенно упрощает использование.
Все дело в разных задачах: Тор в первую очередь предназначен для анонимного доступа в обычный интернет, а I2P это самостоятельная сеть со своими ресурсами и адресами.
>После проведённой работы с клиентом, понимаете ли вы зачем нужно это уложнение в I2P, есть ли какая-то объективная причина, или это одна из очередных странностей (как например сам факт что он написан на java) и можно ли его исправить?
Разработчики говорят потому что проект делался в разное время разными людьми в разное время.
> Можно ли написать клиентский модуль для I2P который будет предоставлять к примеру Socks интерфейс для каждого клиента, через который можно будет пускать любой трафик? (Разумеется резолвя .i2p адреса через этот же самый proxy.)
В I2P есть понятие floodfill-ов, это такие узлы которые обладают достаточно полной информации о сети, и, кроме того, берут на себя обязательства сообщать всю новую информацию другим floodfill-ам. Фактические это некие «справочники» сети, сообщающие любому желающему как обратиться к тому или иному узлу. Обычные маршутизаторы занимаются только построением тоннелей и пересылкой через них данных.
Скажите пожалуйста, а есть ли системы, симулирующие правдоподобно поведение лимитных заявок.
То есть учащийся трейдер ставит лимитную заявку по своей стороне в очередь и она исполняется приблизительно в то же самое время как если бы была поставлена на настоящий рынок?
Добавил все пропущенные файлы и обновил устаревшие.
Положил временный Makefile.
Теперь все должно собираться.
boost и crypto++ установите сами из репозитория вашего линукса
Используется именно вариант a). Дважды тот же самый ключ.
Насколько я понимаю они таким образом пытались убрать IV, передаваемый открыто.
Согласен что идея дурацкая, как надевать два презерватива одновременно.
Я уверен лишь в том, что используется именно этот вариант — иначе другие узлы не смогли бы понять мои сообщения, равно как и я их.
Когда только начинал свой проект первым делом посмотрел на них. Там еще очень многое было не сделано: на тот момент не было даже туннелей. Сейчас они из добавили, но пока лишь транзитные.
В целом же у меня несколько иное видение по поводу развития проекта чем у них.
LeaseSet это множество тоннелей, ведущих к данной точке назначения. Для одного адреса LeaseSet всегда одинков, если в сети появится другой LeaseSet с тем же адресом, то правильным будет считаться более поздний.
Вы запрашиваете LeaseSet через тоннель, и если тот маршутизатор, который вы запрашиваете, окажется принадлежащими спецслужбам, то единственно что они могут узнать что некто интересуется этим адресом, а кто именно они не знают, потому как не знают, откуда идет ваш исходящий тоннель.
forum.i2p формирует LeaseSet сам, выбирая из списка входящих тоннелей какие считает нужным. Затем он рассылает его нескольким маршутизаторам, а те передают дальше друг друга.
Что будет если попытаться себя за кого то другого, я, честно говоря, не знаю. Самому интересно. Возможно это у них дыра.
Наоборот для построения исходящего тоннеля нужен входящий, потому что иначе нельзя будет узнать результат создания тоннеля.
На самом деле запросы на создание тоннелей можно посылать и непосрдественно, но чтобы не заморачиваться ввели понятие «нулевых тоннелей», который начинаются и заканчиваются на своем маршутизаторе и создаются автоматически при страрте. Вот через них и создают первые тоннели.
Когда вы вводите адрес то сначала маршутизатор найдет по вашему адресу 32-х байтный хэш I2P адреса вашего сайта. Теперь имея это число вам нужно найти его какой нибудь входящий тоннель, запросив для этого его LeaseSet. Для этого вы выбираете какой нибудь достаточно, как вы думаете хороший, маршутизатор и посылаете туда запрос с этим адресом. Тут возможно 3 варианта:
1. Маршутизатор вернул вам LeaseSet
2. Маршутизатор сказал вам что не знает такого и возвращает список других маршутизаторов, которые по его мнению знают
3. Ничего вообще не отвечает
В варианте 2 пытаемся послать запрос тем маршутизатором, которые сказали. В варианте 3 повторям попытку используя другие тоннели, и, возможно, другой маршутизатор.
Когда вы получили нужный вам тоннель, вы отсылаете и шифруете сообщение для маршутизатора ключем, указанным в LeaseSet-е с точкой назначения I2P адресом нужного вам сайта.
IP всех маршутизаторов публичны, более того текущий список можно скачать с ряда ftp-серверов.
Роутер сервера в принципе может узнать IP адресов всех узлов созданного им тоннеля, но на самом деле ему это не нужно — он формирует лишь цепочку I2P адресов, входящих в тоннель, и отсылает сообщение первому из них через какой нибудь свой исходящий тоннель.
В реальности IP адреса требуется знать только для пересылки сообщений между тоннелями.
Если вы держите веб-сайт, то задача спецслужбы заколючается в определении I2P адреса вашего маршутизатора, к которому прицеплен ваш сайт. Для этого нужно проследить маршрут какого нибудь из ваших входящих туннелей, который знаете только вы, как создатель этого тоннеля. Участники же знают только адреса следующих в тоннеле узлов. Посколько туннели как правило бывают в 3 узла, то достаточно придти в гости к этим 3 участникам. Проблема только в том, что эти узлы скорее всего окажутся в разных странах. А вот что все они могут принадлежать одному владельцу (спецслужбе) это запросто.
Вот допустим вы остановили ваш маршутизатор, а через вас куча тоннелей шло. Создатели этих тоннелей продолжают их использовать, посылая данные в никуда и ожидая ниоткуда.
Прямого способа узнать что тоннель уже не функционирует нет.
Правильным решением, по моему разумению, было бы сообщение, аналогичное сообщению для создания тоннеля, которое бы узел рассылал через все свои тоннели, что он отключается.
Тогда все обращения к I2P адресам будут обеспечивать должную анонимность, а обращения к обычным адресам дальше собственного узла не уйдут.
Floodfill включать не пробовали? Тогда всякая новая информация о каком либо узле будет обмениваться с вашими соседями, что резко повысит трафик.
Так исходный код так или иначе приходится трассировать, а он достаточно запутанный. Потому проще распечатать сами сообщения.
>Насколько я понимаю, I2P нельзя использовать просто как proxy, таким же образом как используется Tor. Именно поэтому и приходится для каждого приложения писать какой-то свой код который должен знать о том как работает сама I2P, в то время как в Tor достаточно просто взять программу которая уже работает через обычный TCP, и пустить её через proxy, что разумеется существенно упрощает использование.
Все дело в разных задачах: Тор в первую очередь предназначен для анонимного доступа в обычный интернет, а I2P это самостоятельная сеть со своими ресурсами и адресами.
>После проведённой работы с клиентом, понимаете ли вы зачем нужно это уложнение в I2P, есть ли какая-то объективная причина, или это одна из очередных странностей (как например сам факт что он написан на java) и можно ли его исправить?
Разработчики говорят потому что проект делался в разное время разными людьми в разное время.
> Можно ли написать клиентский модуль для I2P который будет предоставлять к примеру Socks интерфейс для каждого клиента, через который можно будет пускать любой трафик? (Разумеется резолвя .i2p адреса через этот же самый proxy.)
Именно так сейчас официальный клиент и работает.
Запрос другого маршутизатора можно и напрямую.
То есть учащийся трейдер ставит лимитную заявку по своей стороне в очередь и она исполняется приблизительно в то же самое время как если бы была поставлена на настоящий рынок?
Положил временный Makefile.
Теперь все должно собираться.
boost и crypto++ установите сами из репозитория вашего линукса
Log.h и Queue.h сейчас выложу.
Правильные main и Makefile еще не сделаны.
Насколько я понимаю они таким образом пытались убрать IV, передаваемый открыто.
Согласен что идея дурацкая, как надевать два презерватива одновременно.
Я уверен лишь в том, что используется именно этот вариант — иначе другие узлы не смогли бы понять мои сообщения, равно как и я их.
В целом же у меня несколько иное видение по поводу развития проекта чем у них.
Вы запрашиваете LeaseSet через тоннель, и если тот маршутизатор, который вы запрашиваете, окажется принадлежащими спецслужбам, то единственно что они могут узнать что некто интересуется этим адресом, а кто именно они не знают, потому как не знают, откуда идет ваш исходящий тоннель.
Что будет если попытаться себя за кого то другого, я, честно говоря, не знаю. Самому интересно. Возможно это у них дыра.
Все маршруты объединены в один LeaseSet
На самом деле запросы на создание тоннелей можно посылать и непосрдественно, но чтобы не заморачиваться ввели понятие «нулевых тоннелей», который начинаются и заканчиваются на своем маршутизаторе и создаются автоматически при страрте. Вот через них и создают первые тоннели.
Когда вы вводите адрес то сначала маршутизатор найдет по вашему адресу 32-х байтный хэш I2P адреса вашего сайта. Теперь имея это число вам нужно найти его какой нибудь входящий тоннель, запросив для этого его LeaseSet. Для этого вы выбираете какой нибудь достаточно, как вы думаете хороший, маршутизатор и посылаете туда запрос с этим адресом. Тут возможно 3 варианта:
1. Маршутизатор вернул вам LeaseSet
2. Маршутизатор сказал вам что не знает такого и возвращает список других маршутизаторов, которые по его мнению знают
3. Ничего вообще не отвечает
В варианте 2 пытаемся послать запрос тем маршутизатором, которые сказали. В варианте 3 повторям попытку используя другие тоннели, и, возможно, другой маршутизатор.
Когда вы получили нужный вам тоннель, вы отсылаете и шифруете сообщение для маршутизатора ключем, указанным в LeaseSet-е с точкой назначения I2P адресом нужного вам сайта.
Роутер сервера в принципе может узнать IP адресов всех узлов созданного им тоннеля, но на самом деле ему это не нужно — он формирует лишь цепочку I2P адресов, входящих в тоннель, и отсылает сообщение первому из них через какой нибудь свой исходящий тоннель.
В реальности IP адреса требуется знать только для пересылки сообщений между тоннелями.