Скажите пожалуйста, а есть ли системы, симулирующие правдоподобно поведение лимитных заявок.
То есть учащийся трейдер ставит лимитную заявку по своей стороне в очередь и она исполняется приблизительно в то же самое время как если бы была поставлена на настоящий рынок?
Добавил все пропущенные файлы и обновил устаревшие.
Положил временный 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 участникам. Проблема только в том, что эти узлы скорее всего окажутся в разных странах. А вот что все они могут принадлежать одному владельцу (спецслужбе) это запросто.
Вы должны его, в зависимости от стороны, зашифровать/расшифровать вашим ключем для IV, затем полученное значение использовать в качестве IV для шифрования самого содержимого, затем то же самое проделать с IV повторно, потом сообщение с уже перешифрованным IV идет дальше.
На этот вопрос я бы тоже хотел знать ответ. Я когда на это наткнулся, то не мог понять, откуда следует брать IV для шифрования IV, пока не осознал что используется ECB (кстати этот момент в официальной документации опущен). Более того, шифровать IV нужно дважды.
У меня сложилось впечтление, что I2P был начат студентами, пытавшимся применить на практике знания, полученные на лекциях, возможно не всегда целесообразно.
В любом случае при разработке клиента мы не имеем возможности изменить протокол, а вынуждены реализовывать то, что есть, чтобы взаимодествовать с другими узлами сети.
В целом да. Иначе произвольный маршутизатор не сможет переслать ему никакое сообщение если не сможет установить с ним соединение, что резко ограничивает возможности. В первую очередь такой маршутизатор фактически не сможет участовать в передаче транзитного трафика, кроме того входящие тоннели можно строить только через маршутизаторы, с которыми уже имеется соединение.
С другой стороны хостить, например, свой сайт можно и не имея «белого» ай-пи — достаточно надлежашим образом тоннели для LeaseSet-а.
Запрос другого маршутизатора можно и напрямую.
То есть учащийся трейдер ставит лимитную заявку по своей стороне в очередь и она исполняется приблизительно в то же самое время как если бы была поставлена на настоящий рынок?
Положил временный 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 адреса требуется знать только для пересылки сообщений между тоннелями.
www.i2p2.de/tunnel_message_spec.html
Вы должны его, в зависимости от стороны, зашифровать/расшифровать вашим ключем для IV, затем полученное значение использовать в качестве IV для шифрования самого содержимого, затем то же самое проделать с IV повторно, потом сообщение с уже перешифрованным IV идет дальше.
У меня сложилось впечтление, что I2P был начат студентами, пытавшимся применить на практике знания, полученные на лекциях, возможно не всегда целесообразно.
В любом случае при разработке клиента мы не имеем возможности изменить протокол, а вынуждены реализовывать то, что есть, чтобы взаимодествовать с другими узлами сети.
С другой стороны хостить, например, свой сайт можно и не имея «белого» ай-пи — достаточно надлежашим образом тоннели для LeaseSet-а.