Вот и прекрасно — возьмите и реализуйте «на обычных сях, без всяких плюсов, фреймворков и прочего хипстерства» протоколы, кстати на настоящий момент отлично документированные.
Я попытался на плюсах как умел, у вас безусловно получится лучше.
Мессенджер поверх I2P существуют, и его действительно невозможно прослушать, и от MITM защищен потому что LeaseSet-ы подписываются.
К сожалению был несправедливо заброшен его разработчиками, однако в ближайшее время я намереваюсь им заняться.
А нельзя было в момент запроса пароля сделать core файл командой gcore, потом загрузить его в gdb, подняться вверх по стеку и дальше смотреть по контексту что там делается?
Зарплата в ИТ конкретно в Москве резко выросла примерно в 2005 году и с тех пор только растет (точнее росла до недавнего времени).
P.S.: Сам уехал в том самом 99-ом году когда х… ло активно пихали в президенты первый раз. Тогда я подумал что Россия точно сошла с ума если не прошло и 10 лет и готовы голосовать за ГБ-иста
Ну а если такие бездари в 2000-е годы стали почему ж тогда зарплаты так резко выросли. Получается что даже их перестало хватать.
То что вы кого то там доучивали, рассчитывая что будут работать у вас за зарплату, а они взяли и ушли в свой бизнес, воспользовавшись подвернувшимися возможностями, так это ваши и только ваши проблемы.
Почему обязательно «диссиденты»? Это просто глобализация, люди занимаются тем и живут там, где им выгодно без всякой идеологии. Если некто решил повернуть время вспять и возродить советскую идеологию, так чем заканчиваются попытки мочиться против ветра всем известно.
А если тупо всю ИТ инфраструктуру станет некому обслуживать? Они ж не станут разбираться в причинах, они тупо заявят раз негодяи посмели уехать запретить им уезжать, а уехавших объявить врагами народа.
Надо отдать должное в середине 2000-х отток замедлился, в перовую очередь из-за весьма конкуретных зарплат. Да и Медведев, будучи президентом делал в области ИТ весьма правильные вещи.
В разделе «Что делать?» отсутствует самый очевидный вариант — уехать. Разумеется у кого есть такая возможность, или постараться, ибо ИТ-шники люди весьма востребованные.
Тогда ответ на вопрос «Как вы думаете, какой следующий запрет будет в IT?» более не будет иметь значение.
Tun-интерфейс вместо использования отдельных портов как сейчас сделано в I2P.
Эта задача успешно решается кстати, данный проект же ориентирован в первую очередь на прикладное применение I2P.
Насчет LeaseSet-а в целом правильно — это текущий набор входящих тоннелей.
Маршруты могут быть какие угодно, тут идея иная.
Допустим вы хотите опубликовать LeaseSet вашего адреса, вы должен это делать на «ближайщем» к вам (в смысле DHT) floodfill-е. Сделали.
Теперь ваш товарищ хочет к вам обратиться и он станет искать ваш LeaseSet тоже на ближайщем вам floodfill-е. Но может оказаться так что эти floodfill-ы у вас и у него разные потому что в этот момент у вас и у него него разное содержимое netDb.
Мы же собираемся публиковать на своих серверах.
>Ну и нормально если любой из туннелей упал — перестроить оба. Это же не происходит ежеминутно чтобы требовало каких-то больших оптимизаций по снижению накладных расходов трафика. А по времени — они могут перестраиваться параллельно и времени уйдет столько же сколько на перестройку одного туннеля.
Именно так сейчас и делается. Но постройка тоннеля — удовольствие дорогое. Кроме того у многих маршрутизаторов стоит ограничение на число транзитных тоннелей. В итоге получается что висит масса неиспользумых тоннелей, потому что время жизни тоннеля строго 10 минут.
>Ну и степень анонимности снижается настолько же — этого эффекта (даже лучше) можно добиться если в настройках туннеля поставить на 1 хоп меньше.
Так наш сервер может располагаться в произвольном месте тоннеля, так что это не равносильно уменьшению на один хоп.
Кстати в некоторых запущенных случаях (когда клиент сидит за нат-ом и закрыто почти все) придется удлинять тоннели на один хоп, делая наш сервер первым.
>Как я понял — основная причина построения сети — повышение стабильности за счет раннего обнаружения отказов промежуточных узлов.
Более важная причина это заведомая полнота базы, на которых наши клиенты объявляют свои LeaseSet-ы, тем самым гарантируя, что если LeaseSet опубликован, то он будет найден другим клиентом всегда.
>А чем эта система лучше, чем отправка сообщение alive при tcp-соединениях через socks-прокси для I2P или каких-то пингов на уровне собственного приложения поверх обычной I2P сети, без использования специальных серверов?
Тоннели работают только в одну сторону, потому вы должны пинговать пару тоннелей, а если пинг не вернулся, то непонятно какой из двух помер.
Кроме того, введение одного заведомо надежного узла снижает вероятность отказа тоннеля на треть.
Техническая часть представляет собой в первую очередь реализацию и модификацию I2P. Мне не хотелось в это углубляться, чтобы не перегружать статью лишними деталями — даже без них, на мой взгляд, получилась несколько громоздкой.
Пользоваться услугами РедХата прекращаем, благо альтернатив достаточно.
Кидал — в игнор, безотносительно причин.
При выборе решений для своего ИТ помните про этот инцидент.
Я попытался на плюсах как умел, у вас безусловно получится лучше.
Потому релиз для OS X и не сделали. Разбираемся.
Раньше: Использует шифрование — значит есть что скрывать.
Теперь: Использует шифрование… потому что все используют.
К сожалению был несправедливо заброшен его разработчиками, однако в ближайшее время я намереваюсь им заняться.
P.S.: Сам уехал в том самом 99-ом году когда х… ло активно пихали в президенты первый раз. Тогда я подумал что Россия точно сошла с ума если не прошло и 10 лет и готовы голосовать за ГБ-иста
То что вы кого то там доучивали, рассчитывая что будут работать у вас за зарплату, а они взяли и ушли в свой бизнес, воспользовавшись подвернувшимися возможностями, так это ваши и только ваши проблемы.
Тогда ответ на вопрос «Как вы думаете, какой следующий запрет будет в IT?» более не будет иметь значение.
А номера слитков, принадлежащих клиенту, сообщаются?
Эта задача успешно решается кстати, данный проект же ориентирован в первую очередь на прикладное применение I2P.
Маршруты могут быть какие угодно, тут идея иная.
Допустим вы хотите опубликовать LeaseSet вашего адреса, вы должен это делать на «ближайщем» к вам (в смысле DHT) floodfill-е. Сделали.
Теперь ваш товарищ хочет к вам обратиться и он станет искать ваш LeaseSet тоже на ближайщем вам floodfill-е. Но может оказаться так что эти floodfill-ы у вас и у него разные потому что в этот момент у вас и у него него разное содержимое netDb.
Мы же собираемся публиковать на своих серверах.
>Ну и нормально если любой из туннелей упал — перестроить оба. Это же не происходит ежеминутно чтобы требовало каких-то больших оптимизаций по снижению накладных расходов трафика. А по времени — они могут перестраиваться параллельно и времени уйдет столько же сколько на перестройку одного туннеля.
Именно так сейчас и делается. Но постройка тоннеля — удовольствие дорогое. Кроме того у многих маршрутизаторов стоит ограничение на число транзитных тоннелей. В итоге получается что висит масса неиспользумых тоннелей, потому что время жизни тоннеля строго 10 минут.
>Ну и степень анонимности снижается настолько же — этого эффекта (даже лучше) можно добиться если в настройках туннеля поставить на 1 хоп меньше.
Так наш сервер может располагаться в произвольном месте тоннеля, так что это не равносильно уменьшению на один хоп.
Кстати в некоторых запущенных случаях (когда клиент сидит за нат-ом и закрыто почти все) придется удлинять тоннели на один хоп, делая наш сервер первым.
Более важная причина это заведомая полнота базы, на которых наши клиенты объявляют свои LeaseSet-ы, тем самым гарантируя, что если LeaseSet опубликован, то он будет найден другим клиентом всегда.
>А чем эта система лучше, чем отправка сообщение alive при tcp-соединениях через socks-прокси для I2P или каких-то пингов на уровне собственного приложения поверх обычной I2P сети, без использования специальных серверов?
Тоннели работают только в одну сторону, потому вы должны пинговать пару тоннелей, а если пинг не вернулся, то непонятно какой из двух помер.
Кроме того, введение одного заведомо надежного узла снижает вероятность отказа тоннеля на треть.
Кидал — в игнор, безотносительно причин.
При выборе решений для своего ИТ помните про этот инцидент.