Встреча разработчиков I2P - 30 декабря 2003

<jrandom> 0) привет <jrandom> 1) статус router <jrandom> 2) i2ptunnel <jrandom> 3) im <jrandom> 4) планы на 0.3 <jrandom> 5) синхронизация времени <jrandom> 6) ??? <jrandom> привет, mihi, polo <polo> привет! <mihi> hi jrandom <jrandom> 0) hi <jrandom> :) <rsk> hi <i2p> <duck> hi <jrandom> 1) статус router <jrandom> 0.2.3.3 вышла, и похоже, всё работает <jrandom> конечно, ещё полно задач <jrandom> но это должен быть последний релиз ветки 0.2 <jrandom> 0.3 добавит профилирование пиров, чтобы router могли избегать плохих router <jrandom> (а 0.3.1 — это переработка транспортов) <jrandom> hola Ophite1 <Ophite1> Heya. <rsk> значит, для 0.3 будет больше накладных расходов? <jrandom> и да и нет <jrandom> будет peer testing, но более сфокусированный <rsk> увидим ускорение за счёт выбора маршрута (path selection)? <jrandom> да <jrandom> есть те калькуляторы «liveliness», и будут добавлены новые калькуляторы задержки и пропускной способности <jrandom> плюс люди смогут настраивать свои предпочтения для конкретных пиров <jrandom> например, если вы знаете, что хотите предпочитать пира X пирам Y, вы сможете дать им бонус веса на сколько‑то случайных очков <mihi> будет ли «чистое» завершение работы? *g* <jrandom> на самом деле, это хороший вопрос, mihi <jrandom> i2p дошёл до точки, когда нужен интерфейс администрирования. <jrandom> самая долгая Job, которая тормозит работу, — GenerateStatusConsoleJob <jrandom> сейчас она может занимать до 4–6 секунд <jrandom> (блокируя всё остальное) <jrandom> её нужно сделать асинхронной и «по запросу». <jrandom> но мне не хочется писать веб‑листенер / и т. п. <jrandom> возможно, наоборот — servlet, который запускает router и общается с ним <mihi> тебе не нужен полноценный веб‑сервер. просто увидел GET — верни свои данные. <jrandom> верно <jrandom> ты прав, это тоже стоит включить в 0.3. <mihi> а если увидел что‑то другое (типа SHUTDOWN), делай как считаешь нужным. конечно, только с localhost ;) <jrandom> да ну, брось <mihi> тогда кто‑нибудь сможет сделать хороший админский софт <jrandom> верно <mihi> у тебя же были триггеры по файлам, да? это где‑нибудь задокументировано? >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom <jrandom> это было в IDN, не в самом router <jrandom> но это может быть неплохим вариантом <jrandom> это тривиально простая система <jrandom> хорошая идея, пойдём так <jrandom> (и я смогу просто переиспользовать тот код :) <i2p> <duck> эта магическая файловая штука начинает походить на plan9 <jrandom> лол <mihi> но файловые триггеры требуют polling <jrandom> верно, mihi, читать директорию каждые 30 с — не так уж плохо <mihi> но ServerSocket#accept дешевле. <mihi> так как не тратит время. (если ОС хорошая) <mihi> окей, файловые триггеры лучше, чем ничего, само собой. <jrandom> server socket позволил бы удалённое администрирование <jrandom> (когда уместно) <jrandom> не знаю. <jrandom> нужно проработать. <jrandom> (или если кто‑то хочет запрыгнуть и закодить... :) <mihi> и server socket мог бы отдавать routerConsole тоже. <jrandom> верно <jrandom> ок, 2) i2ptunnel <jrandom> :) <jrandom> i2ptunnel всё ещё рулит, и похоже, мы хотим добавить socket‑based API для его управления <i2p> <anon> планы aum по ic2cp2pc пока отменены? <jrandom> да, ci2cp «мертв в воде», его заменит socket‑based API для управления I2PTunnel <jrandom> Думаю, смогу накинуть этот API в ближайшие дни, чтобы он мог взяться за реализацию <mihi> просто используй сокет, сделай in.readLine() и отдай эту строку в runCommand() ;) <rsk> что этот api даст i2p? <jrandom> примерно так, как говорит mihi (только форматирует результаты и возвращает их в стандартном виде) <mihi> с подходящим «logger», чтобы отправлять команды обратно. <mihi> s/commands/results/ <jrandom> rsk> он позволит разработчикам приложений строить клиентские и серверные сокеты поверх i2p без необходимости разбираться с шифрованием I2CP <jrandom> ага‑ага <jrandom> у i2ptunnel /есть/ накладные расходы в случаях, когда много i2ptunnel <jrandom> независимо от JVM <jrandom> клиенты i2ptunnel создают новый destination (адрес назначения в I2P) на каждого подключаемого клиента, и router будет работать гораздо хуже по мере роста количества локальных destination. <rsk> ага <jrandom> это из‑за требований анонимности сети, связанных с тем, как у нас устроено шифрование <jrandom> для приложений, которым нужно открыть один‑два tunnel к пиру, этот новый api будет РУЛИТЬ <jrandom> но для приложений, которым нужно говорить со множеством других пиров, I2CP — это то, что нужно. <jrandom> (так как это один destination, мультиплексируемый i2cp) <jrandom> Пожалуй, это вечный баланс TCP vs UDP, в каком‑то смысле <jrandom> mihi> есть мысли или идеи насчёт будущего i2ptunnel? <rsk> как дела с ip over i2p или с темой VPN? <mihi> jrandom: пусть кто‑то напишет хороший streaming api, и тогда i2ptunnel будет его использовать. <mihi> то же для naming server. <mihi> возможно, добавить номера последовательностей, если никто не сделает вышеперечисленное. <mihi> что приведёт к несовместимому изменению. <jrandom> несовместимые изменения — не плохо, мы на ранней стадии разработки <jrandom> (и если бы мы могли увеличить размер ID тоже до двух или четырёх байт на сторону?) <mihi> streaming api всё равно будет несовместимым изменением. а если бы i2p работал, нам не нужны были бы номера последовательностей. <jrandom> rsk> на паузе, пока у кого‑нибудь не найдётся времени взяться? ≡ rsk/#i2p считает, что несовместимые изменения — самые лучшие <jrandom> верно, mihi <mihi> сейчас ID 3‑байтовые, так зачем *увеличивать* до 2 байт? <jrandom> mihi> на самом деле, я бы хотел постепенно депрекейтнуть mode=GUARANTEED и реализовать это в streaming api ≡ mihi/#i2p тоже <jrandom> оставив i2p = IP, а не TCP или UDP <jrandom> чёрт, вот бы ещё 14 часов в сутках. <mihi> всего 14? ;) <jrandom> ;) <jrandom> разве 3‑байтовые id не вычисляются обеими сторонами соединения? или я путаю <mihi> у каждой стороны свой 3‑байтовый ID, однако в каждый момент нужно отправлять только один. <jrandom> пожалуй, я реализую streaming API, выпилю GUARANTEED и добавлю этот socket‑контроллер дальше. <jrandom> ага, ясно <mihi> см. /apps/i2p/i2ptunnel/java/src/protocol.txt <jrandom> ага‑ага <mihi> кстати, кто сунул этот файл *туда*? ≡ jrandom винит eco ;) <jrandom> подожди, нет, это ты их туда положил <jrandom> не так? <jrandom> а, нет, это я их импортировал ≡ jrandom винит себя за тупость. <jrandom> (ля‑ля‑ля) <jrandom> чёрт. ладно, да, работа над streaming API и socket‑контроллером позволит мне обдумать манифест по тестированию пиров / профилированию / выбору <jrandom> через пару дней выложу это для комментариев <jrandom> (и это вытащит мою голову из router. variety++) <jrandom> mihi> что‑нибудь ещё про i2ptunnel? <mihi> насколько знаю, нет <jrandom> круть <jrandom> (ещё раз спасибо, что находишь время врезаться в эти темы, знаю, ты занят с fiw и остальным) <jrandom> ок, thecrypto не здесь, но он продвигается с IM‑приложением. <jrandom> (это пункт повестки 3) <jrandom> 4) планы на 0.3 <jrandom> 0.3.0 ~= профилирование пиров, и теперь туда также войдут streaming api и тот socket‑контроллер для i2ptunnel <jrandom> но, если не догадались, релиза 1 января не будет <jrandom> 15 января — теоретически возможно. посмотрим по ходу. <jrandom> 0.3.1 — это не целый месяц работы, так что, возможно, её сдвигать не придётся. <jrandom> кроме того, дорожная карта всё ещё в целом соответствует тому, куда мы движемся <jrandom> 5) синхронизация времени <jrandom> новый FAQ опубликован на http://wiki.invisiblenet.net/iip-wiki?I2PTiming <jrandom> mihi, у тебя было предложение насчёт четвёртого варианта там (строим собственную синхронизацию времени внутри i2p)? <jrandom> привет, brawl <mihi> ага. ∙φ∙ brawl теперь известен как eco_ <eco_> привет, ребята <jrandom> о, привет, eco <mihi> нужно подключаться к 3 случайным узлам и запоминать разницу между средним временем и локальным. <jrandom> мы как раз обсуждали streaming API / tunnel api <mihi> а потом подпилить свой getTimeMillis, который это корректирует. <Ophite1> mihi: Нет, не нужно. <jrandom> mihi> если атакующий создаст 1000 узлов с неправильным временем, всем придёт конец <jrandom> (поскольку среднее будет хаотично сдвигаться) <mihi> если атакующий создаёт 1000 узлов, всем в любом случае конец...? <rsk> разве это не будет самоисправляться? <Ophite1> mihi: ОК, 3. <jrandom> нет, мы должны уметь это переваривать, mihi. <mihi> хорошо, тогда используй среднее только если стандартное отклонение меньше 1 сек или около того. <rsk> если у всех одно и то же время, всё ок, даже если оно неверное, так? <jrandom> rsk> если все 1000 узлов синхронизированы, да, но что если они все случайно размазаны <mihi> используй только времена, которые достаточно близки друг к другу. если нет — бери 3 новых узла. <jrandom> mihi> верно, мы могли бы реализовать NTP (который по сути делает то, что ты говоришь, используя серию кандидатов средних значений, чтобы итеративно сузить к правильному времени <mihi> но нам не обязательно учитывать всё (как ping‑задержки), как делает ntp. <Ophite1> если этого не делать, mihi, время будет медленно «ползти» назад. ≡ mihi/#i2p считает, что это лучше, чем заставлять пользователей вручную ставить время. <jrandom> значит, любой, кто случайно выберет 3 таких смещённых узла, окажется в своей отдельной частной сети? <jrandom> как насчёт третьего варианта — <jrandom> i2p имеет компонент, который проверяет реальный NTP‑сервер через NTP или SNTP <mihi> если у тебя в netDB только смещённые узлы, ты и так в этой частной сети... <jrandom> вместо того, чтобы изобретать колесо заново <Ophite1> хотя отчасти мне это нравится... <Ophite1> NTP не подписан, он уязвим для MITM‑атаки. <Ophite1> или отравления DNS‑кэша для, скажем, time.nist.gov <jrandom> верно, Ophite1, хотя с 200 000+ SNTP или NTP‑хостов это большой набор для атаки. <jrandom> мы точно не будем синхронизироваться с time.nist.gov. <Ophite1> подключения из i2p к серверу времени NSA могут вызвать вопросы, не? :) <jrandom> и если атакуют time.nist.gov, пострадают все и везде <jrandom> хех <mihi> тогда совмещаем оба. спрашиваем «реальный» ntp‑сервер и своего соседа. если оба говорят одно и то же — ок. <jrandom> то есть ещё /больше/ кода ;) <jrandom> но да, это разумно. <Ophite1> Интересно. А если нет? <Ophite1> выбрать другой ntp‑сервер? <jrandom> отказать пиру. <mihi> попробуй другой ntp‑сервер и другого пира. <mihi> пока не будет совпадения. потом откажи всем предыдущим пирам. ≡ mihi/#i2p печатает медленнее, чем jrandom :( <Ophite1> совпадение в пределах порога, скажем, 1 сек? <jrandom> 1 с подойдёт. <jrandom> принимать пиров до 30 с или около того (чтобы учесть лаг) <Ophite1> 1 сек — ок на СИЛЬНО ЗАГРУЖЕННЫХ подключениях? <jrandom> 1 с — для синхронизации, 30 с — для коммуникаций. <Ophite1> Я видел, как задержка на DSL доходила до 5 секунд, когда творишь с ним зло. <jrandom> по tcp или udp? <Ophite1> но тогда, возможно, этот хост в любом случае не тот, с кем надо синхронизировать время ;) <jrandom> верно <Ophite1> udp. <jrandom> хмм, ок <Ophite1> казалось бы, это должно было бы потеряться :) <i2p> <duck> Думаю, проблема больше в том, чтобы дать пользователю понять, что есть проблема <jrandom> duck> верно. <i2p> <duck> только пройдясь по здоровенным логам, они видят, что их часы сбились (если найдут) <Ophite1> Может быть. Отчасти. <i2p> <duck> или что порт уже занят <jrandom> интерфейс администрирования был бы кстати. <i2p> <duck> мир лучше, когда все используют NTP, подключённый к своему локальному stantrum (sp) 2 серверу CTCP Cloaking is now [On] <jrandom> возможно, у нас будет релиз 0.4 с кучей чисток и вещей для конечного пользователя перед тем, как идти к 1.0? <jrandom> верно (stratum) <i2p> <duck> только у клиентов Windows этого, скорее всего, нет <i2p> <duck> но они и так вряд ли стабильны <jrandom> в Windows есть NTP <i2p> <duck> так какая разница <Ophite1> duck: Windows XP и Windows Server 2003 включают NTP. <jrandom> на порядки проще, чем в unix <Ophite1> по умолчанию синхронизируется с time.windows.com, если правильно помню. <jrandom> с выпадающим списком для других <Ophite1> Это важная часть Windows Product Activation. <Ophite1> нельзя истечь сроком, если не знаешь время :) <jrandom> хех <mihi> нет такой опции в моём университете... все часы отстают на 1–5 часов. но, возможно, мне вообще нельзя запускать i2p там... <Ophite1> mihi: i2p должен стараться работать особенно хорошо в такой ситуации... <jrandom> mihi> отлично! поможешь протестировать скрытую работу :) <jrandom> к слову, летом я буду в поездках <jrandom> скорее всего буду офлайн, без ноутбука. <i2p> <duck> мысль в сторону: ntp.duck.i2p :) <Ophite1> Посмотри так: Брианна из Kazaa качает классный новый анонимный клиент файлообмена, о котором ей рассказала лучшая подруга — мол, очень крутой и позволяет тайно чатиться и всё такое. Мы хотим сказать ей, что нужно выставить часы с точностью до 30 секунд (откуда она их возьмёт?)? Или хотим, чтобы оно просто работало? <jrandom> но я собираюсь убедиться, что всё ещё смогу быть в I2P только с публичных терминалов. CTCP Cloaking is now [Off] <jrandom> без вопросов, Ophite1. просто работает (и есть доки для гиков) <jrandom> duck> bootstrap ;) <jrandom> и i2p /не/ будет требовать root. <Ophite1> В этом и суть. <Ophite1> jrandom: ты бы стал запускать router на машине, где у тебя нет root? <jrandom> так что да, смесь между вариантом 3 и 4 <Ophite1> вариант 3.5 звучит круто ;) <jrandom> Ophite1> я бы запустил сотню :) <mihi> вариант 3.1415926... <jrandom> (и пошёл бы в следующую лабораторию, запустил ещё сотню) <Ophite1> О, пай. Вкусно.;) <Ophite1> jrandom: я сказал — без root. Любитель. :) <jrandom> лол <jrandom> вот к этому мы и склоняемся. <jrandom> пока реализация времени не готова, все должны использовать вариант 1 или 2. <jrandom> для варианта 2, если кто‑то мог бы написать документацию, буду признателен <Ophite1> это приемлемо на сейчас, так как мы ещё Не Готовы для Брианны из Kazaa и прочих ;) <mihi> для протокола: я не буду тестировать «hidden operation». мой универский аккаунт уже однажды отключали, и я не хочу, чтобы его снова блокировали... <Ophite1> mihi: Ты — лучший тест, какой только может быть. <jrandom> Ophite1 > не для теста. <jrandom> ок, mihi, мы найдём способ, и когда будет готово, ты сможешь это использовать. <Ophite1> ОК, может, и не тест. В некоторых универах настолько придирчивы, что лучше выпихнут тебя, чем просто заблокируют. <Ophite1> Я знаю человека в самом анти‑файлообменном, про‑RIAA университете США. Он держит 2‑гбитный dumpsite. <jrandom> лол, круто <Ophite1> Понимаю, что очень немногие настолько отважны. <jrandom> ок, с синхронизацией времени всё. <jrandom> eco_> привет. есть что рассказать по bt? {или оставим до следующей недели} <Ophite1> но помни, что в будущем, вероятно, большинство интернета станет университетским/корпоративным. i2p могут запретить. i2p вполне МОГУТ счесть абузой крупные ISP. i2p должен будет работать всё равно. <Ophite1> У меня есть несколько интересных идей в этом направлении, представлю их в будущем. <jrandom> word <Ophite1> (transport) <rsk> i2p считается абузой у крупных ISP, почитай свой контракт <Ophite1> rsk: запуск распределённого прокси‑кэша? <rsk> запуск любого «сервера» <Ophite1> rsk: Не если он не ретранслирует SMTP или WWW. <jrandom> запуск сервисов любого рода <jrandom> верно <Ophite1> rsk: Хе‑хе, у меня есть решение ;) <eco_> jrandom: могу дать краткое обновление <jrandom> сцена твоя :) <eco_> я порчу Java‑клиент bittorrent — snark (www.klomp.org/snark), чтобы познакомиться с i2p <eco_> первый порт работает поверх i2ptunnel, напрямую вызывая Java‑классы <eco_> текущее состояние: работает с 2 пирам, всё ломается при > 2, очистка tunnel не происходит, так что перезапуск — боль <eco_> ETA: в эти выходные ≡ eco_/#i2p сознаёт, что это может считаться > 2003 <jrandom> w00t! ≡ jrandom взламывает time.nist.gov <eco_> «настоящий» порт, вероятно, сократил бы накладные расходы tunnel, но это следующий шаг <jrandom> круто ≡ eco_/#i2p возвращает сцену мс jrandom <jrandom> ок, думаю, это всё <jrandom> 6) ??? <jrandom> у кого‑нибудь ещё что‑нибудь есть? ≡ eco_/#i2p хочет выразить благодарность за отличную работу, проделанную jrandom cs до сих пор <eco_> и что сон всё же полезен для homo sapiens, хотя jrandom, кажется, опровергает это <jrandom> ;) <jrandom> как вы смотрите на встречи здесь вместо iip, пока i2p не станет достаточно надёжным? <jrandom> лично я устал от того, что встречи каждую неделю рвутся в клочья. <i2p> <anon> lilo отстой! <eco_> мы можем кого‑то отрезать, перейдя сюда <jrandom> да, знаю. <jrandom> если сможем сделать мост iip<-->сюда <i2p> <duck> IIP отрезает людей каждый день <jrandom> было бы хорошо. <jrandom> верно. <jrandom> к сожалению, iip непригоден для надёжного dev‑сообщества. <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html <i2p> <duck> это код, на котором основаны eyeKon и т. п. <jrandom> и хотя мне нравится уходить кодить в одиночку, вы все придумываете действительно хорошие идеи и делаете нужные вещи, что критично ≡ rsk/#i2p пишет скрипт обновления для windows <i2p> <duck> теоретически он мог бы подключаться к 3 серверам и зеркалить каждый из них <jrandom> слово, duck, возможно, я попробую запустить один на i2p.dnsalias.net <jrandom> пинговый флуд из ада ;) <eco_> irc на duck.i2p сегодня был довольно хорош, обошёл iip <jrandom> согласен <jrandom> правда, пару раз меня выкинуло. <jrandom> возможно, на следующей неделе будет надёжнее <eco_> это в твоих руках :-) <jrandom> надёжность, вероятно, не улучшится до 0.3, что примерно через ~2 недели <jrandom> (1 неделя на дела с tunnel/streaming, 1 неделя на профилирование/тестирование пиров) <jrandom> потом будут баги, которые это принесёт :) <jrandom> хотя должен сказать, я был очень рад постримить аудио от aum прошлой ночью <jrandom> и ardvark смог стримить 42 минуты без буферизации! <jrandom> так что, возможно, мы достаточно надёжны <jrandom> (мой локальный router — только phttp, что, вероятно, слегка влияет) <jrandom> ок, у кого‑нибудь ещё что‑нибудь? <i2p> <duck> ничего в голову не приходит ≡ eco_/#i2p мне тоже ≡ jrandom сворачивает... ≡ jrandom *baf* закрывает собрание