Краткое резюме
Присутствовали: ailouros, bar, bla, cervantes, Complication, gott, jrandom, modulus, polecat, Pseudonym, tethra, zzz
Журнал встречи
15:26 <jrandom> 0) привет 15:26 <jrandom> 1) 0.6.1.7 и состояние сети 15:26 <jrandom> 2) Экспериментальные сбои tunnel 15:26 <jrandom> 3) SSU и NAT 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) привет 15:26 * jrandom машет рукой 15:26 <jrandom> еженедельные заметки о статусе опубликованы по адресу http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 15:26 * ailouros прочитал заметки 15:27 * jrandom опоздал, так что дам вам минутку, чтобы почитать :) 15:29 <jrandom> ок, можно сразу перейти к 1) 0.6.1.7 и состояние сети 15:29 <@cervantes> *кашляет* 15:29 <jrandom> Мне особо нечего добавить сверх того, что в письме по этому пункту. У кого-то есть ещё комментарии/вопросы/идеи? 15:30 <Pseudonym> кажется, оптимизировать производительность перед изменением алгоритма создания tunnel — это как-то наоборот 15:30 <gott> У меня много "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " 15:30 <@modulus> задержка в tunnel значительно ниже, не знаю, вы что-то поменяли или мой ISP внезапно стал лучше. 15:30 <gott> из I2PTunnel Webmanager 15:31 <jrandom> gott: это похоже на неправильные http-запросы или вещи, которые eepproxy не мог понять 15:31 <jrandom> modulus: круто, мы много работали над улучшениями 15:31 <jrandom> Pseudonym: ну, пока что создание tunnel не было нашим узким местом — узкое место было на гораздо более высоком уровне 15:32 <jrandom> с другой стороны, улучшения последних ревизий выявили некоторые проблемы и там внизу 15:32 <Pseudonym> о, то есть оптимизация касалась других частей кода? 15:32 <Pseudonym> круто 15:33 <jrandom> ага, на уровне SSU, а также на уровне работы tunnel. создание tunnel — не операция, чувствительная к производительности [кроме тех случаев, когда она чувствительна ;] 15:34 <jrandom> я, впрочем, провожу нагрузочное тестирование в живой сети, собирая неанонимную статистику нагрузки по разным пирам, чтобы точнее сузить круг 15:34 <ailouros> Интересно, почему иногда я вижу больше tunnel, чем настроено для назначения (например, eeProxy, inbound 7 tunnels 4 outbound) 15:34 <jrandom> так что в ближайшие дни, когда увидите, что router 7xgV гоняет много данных, ну, не обращайте внимания ;) 15:35 <jrandom> ailouros: когда создание tunnel занимает время, он строит дополнительные, на всякий случай. 15:35 <jrandom> zzz также описывает несколько странностей на этом фронте, и есть патч, над которым работают, чтобы чуть улучшить ситуацию 15:35 <ailouros> Понятно... но тогда почему они все истекают одновременно? 15:35 <@cervantes> jrandom: из любопытства, когда ты начал эти тесты? 15:35 <jrandom> cervantes: несколько дней назад 15:36 <@cervantes> ах, круто, значит это не то ;-) 15:36 <jrandom> не знаю, ailouros, зависит от нескольких условий. но в коде создания tunnel есть некоторые... *кхм* странности, к которым я не лез, так как он переписывается к 0.6.2 15:38 <ailouros> Понял. Я думал, это вопрос политики... Я бы предпочёл, чтобы tunnel умирали в разное время, если нет веской причины делать иначе 15:38 <ailouros> то есть, создания tunnel были бы смещены 15:39 <jrandom> ага, для 0.6.2 будет лучше рандомизация, а патч zzz добавляет немного рандомизации и для текущей ревизии 15:40 <+Complication> Интересно, почему в остальном нормальный экземпляр i2phex... решает пересчитать хэши файлов через раз при запуске? 15:40 <jrandom> без понятия 15:40 <+Complication> Пока что наиболее вероятной причиной кажется повреждённая конфигурация, но я ещё не удалял свою конфигурацию. 15:40 <jrandom> возможно, смещённые метки времени? 15:42 <+Complication> Нет, они тоже корректные 15:42 * jrandom не знает. никогда не смотрел на ту часть кода phex'а 15:42 <jrandom> э, code 15:42 <+Complication> Посмотрю, поможет ли удаление старых конфигурационных файлов 15:42 <jrandom> круто 15:43 <jrandom> ок, что-нибудь ещё по 1) Состояние сети / 0.6.1.7? 15:43 <jrandom> если нет, переходим к 2) Экспериментальные сбои tunnel 15:44 <jrandom> мы уже немного затронули это, и в заметках и на zzz.i2p есть больше 15:44 <jrandom> zzz: хочешь что-нибудь добавить/поднять? 15:46 <jrandom> если нет, давайте перейдём к 3) SSU и NAT 15:46 <jrandom> bar: хочешь что-то добавить? 15:46 <+bar> нет, у меня нет ничего сверх того, что в письме 15:47 <jrandom> круто, да, мне ещё надо ответить на некоторые детали — думаю, наша ретрансляция уже покроет часть затронутых тобой вопросов 15:48 <jrandom> фокус будет в том, чтобы определять, какая ситуация имеет место, чтобы мы могли автоматизировать правильную процедуру (или сообщать пользователю, что ему не повезло) 15:48 <+bar> всему своё время, не спешим 15:49 <+bar> да, я предложил временно ручную пользовательскую настройку, чтобы обойти эту проблему, возможно, это и невозможно, но обсудим позже 15:50 <jrandom> да, ручные переопределения помогут, но мой опыт с ранними ревизиями i2p таков, что все (*все*) облажались ;) так что автоматизация предпочтительнее 15:50 <jrandom> (под «все» я имею в виду и себя тоже ;) 15:52 <+bar> согласен 15:52 <ailouros> лол, если и я тоже, значит что-то не так с документацией, я же следовал ей шаг за шагом :D 15:53 <+bar> тем временем, потрачу время на изучение peer testing 15:53 <jrandom> круто, спасибо, bar! 15:54 <+bar> (возможно, смогу сгенерировать немного бесполезного спама и по этому поводу :) 15:54 <jrandom> :) 15:55 <jrandom> ок, если по 3) больше ничего, перейдём к 4) Syndie 15:56 <jrandom> в последнее время тут много прогресса, с довольно существенными переделками интерфейса с момента выхода 0.6.1.7 15:57 <jrandom> также есть новый автономный установщик/сборка, хотя, поскольку у всех нас установлен i2p, отдельный нам не нужен 15:57 <ailouros> Мне кажется, что раскладка 6.1.7 сложнее в использовании, чем у 6.1.6 15:58 <jrandom> хмм, ты запускаешь syndie в однопользовательском режиме? и/или ты используешь последний CVS build или официальный билд 0.6.1.7? 15:58 <ailouros> официальный 0.6.1.7, однопользовательский 15:58 <jrandom> ты из сторонников блогообразного интерфейса, в отличие от древовидной навигации? 15:58 <ailouros> Нет, хотя я не совсем понимаю, что именно «блогообразный» 15:58 <ailouros> лично я предпочитаю древовидную навигацию 15:59 <ailouros> (и цветовую маркировку новых сообщений в виде ветки) 15:59 <+Complication> Относительно поздний CVS, однопользовательский 15:59 <+Complication> Нашёл одну небольшую странность (кажется, это может быть непреднамеренно) 15:59 <jrandom> ах, по этому фронту в CVS много прогресса, ailouros 15:59 <ailouros> отлично :) 16:00 <jrandom> у нас есть новый древовидный режим отображения, используя предложенный cervantes полный обход только одной ветки, а не всех веток 16:00 <@cervantes> эти изменения выложены на syndiemedia.i2p.net? 16:00 <+bla> Было бы хорошей идеей показать пару примеров по умолчанию для location в http://localhost:7657/syndie/syndicate.jsp ? 16:00 <jrandom> syndiemedia.i2p.net — это CVS head, да 16:00 <+Complication> Когда открываешь ветку и читаешь её посты... а затем применяешь фильтр, под который ничего не подходит (например, открыть ветку "Syndie threading", применить фильтр "i2p.i2phex")... 16:00 <jrandom> ага, возможно, bla. новые установки будут иметь три значения по умолчанию, но примеры были бы полезны 16:01 <@cervantes> (дерево самой ветки тоже должно полностью раскрываться) 16:01 <+Complication> ...кажется, текущие посты остаются отображаться, как будто они подходят под фильтр или что-то такое... 16:01 <+Complication> Хотя я точно нажал кнопку "Go". 16:01 <@cervantes> Complication: да, меня это тоже сбило с толку 16:02 <jrandom> хмм, Complication, общая идея была дать возможность бродить по навигации, продолжая смотреть на пост, но, возможно, лучше убирать отображаемые посты 16:02 <jrandom> cervantes: ага, разворачивать до листа было бы хорошо, и должно быть тривиально 16:02 <+Complication> Только что заметил, и раз бросилось в глаза, решил сказать 16:02 <@cervantes> (или сделать ещё очевиднее, что совпадений нет) 16:03 <jrandom> ну, в навигаторе веток написано *no matches* :) 16:03 <ailouros> возможно, он ищет зажигалку 16:03 <jrandom> !thwap 16:03 <@cervantes> (или сделать ещё более очевидно, что совпадений нет) 16:03 <jrandom> <blink>No matches</blink> 16:03 <+Complication> Упс :) 16:04 <tethra> кажется, твой !thwap достал spaetz__, а не того, jr! 16:04 <+Complication> Верно, иногда навигатор веток действительно кажется где-то далеко :) 16:04 <jrandom> да, экспериментируем с некоторым css, чтобы закрепить его сбоку, как опцию 16:05 <@cervantes> с поддержкой скинов можно будет располагать навигатор веток сверху, снизу, слева, справа и т.д. 16:05 <@cervantes> ах, как jr и сказал 16:05 <+Complication> Ссылка "Threads" приводит туда довольно быстро 16:05 <+Complication> ...если она сейчас в области просмотра. 16:06 <+Complication> А привыкшие к клавиатуре могут, естественно, нажать "End" 16:06 <jrandom> разумеется, это всё очень просто менять (что видно по быстрым изменениям в CVS :), так что если есть предложения (или макеты — html / png / и т.п.), пожалуйста, выкладывайте когда угодно 16:07 <jrandom> Ожидаю, что в CVS в ближайшие дни появится основная обзорная страница блога 16:08 <jrandom> ок, по Syndie происходит ещё много всего, так что заглядывайте на http://localhost:7657/syndie/ за подробностями :) 16:08 <jrandom> кто-нибудь хочет что-то ещё по этой теме, или перейдём к 5) ??? 16:09 <zzz> привет, только подошёл. по 2) я ищу тестеров для моего патча. 16:10 <zzz> У меня результаты — улучшения в задержке заданий и надёжности и уменьшение подвисаний router. Надеюсь, другие тоже попробуют. 16:10 <ailouros> звучит достаточно убедительно. что мне нужно сделать? 16:11 <jrandom> привет, zzz, ок, круто, я тоже тут его погоняю. там много разных компонентов, так что, возможно, стоит разбить на части, но выглядит хорошо и идёт в релиз 0.6.1.8 16:11 <ailouros> (средний аптайм здесь около 10 часов :( 16:11 <zzz> Если у тебя есть исходники и ant, просто применяй патч — или я могу выложить i2pupdate.zip, если хочешь 16:12 <zzz> jrandom, поработаю над разбиением 16:12 <ailouros> Я за обновление, спасибо 16:13 <zzz> ailouros, выложу на zzz.i2p в течение часа — спасибо 16:13 <jrandom> zzz: не переживай, если только есть свободное время... я могу просмотреть diff :) 16:13 <ailouros> спасибо 16:14 <zzz> jrandom, ок. Там есть разное, что можно легко выкинуть — хоть тебе, хоть мне. 16:16 <ailouros> Думаю, мы уже на 5) ???, да? 16:16 <zzz> jrandom, другая тема — OOM у router (исчерпание памяти) с i2phex и возможные проблемы SAM 16:16 <jrandom> ага, ailouros 16:16 <jrandom> ах да, zzz, было бы здорово выяснить, что не так с SAM 16:17 <ailouros> j346, у тебя была возможность посмотреть моё приложение? 16:17 <jrandom> было бы круто, если бы кто-то подключился и взял на себя поддержку SAM bridge, так как я не делал там существенной работы, а human давно не появлялся. 16:19 <jrandom> ещё нет, ailouros, к сожалению. Я не до конца понял, как оно работает, так что сначала должен прочитать исходники 16:20 <ailouros> не стесняйся спрашивать 16:20 <ailouros> (и удачи в путешествии по исходникам, это хорошее определение слова «бардак») 16:20 <jrandom> хехе 16:21 <zzz> поправка: у меня OOM случались при использовании i2p-bt, а не i2phex. Случается примерно через 24 часа при одном i2p-bt и через несколько часов при двух i2p-bt 16:22 <+Complication> У меня случилось после ночных стресс-тестов. 16:22 <+Complication> (во время которых, заметьте, я видел 5-минутное среднее в 50 KB/s) 16:22 <bar_> напомни, пожалуйста, что твоё приложение делает, ailouros? У меня память хорошая, но короткая... 16:22 <+Complication> Входящий трафик, то есть. 16:22 <+Complication> Исходящий был ограничен 35 KB/s 16:22 <@cervantes> Complication: раньше я не слышал, чтобы это называли «ночными стресс-тестами»... 16:22 <jrandom> неплохо, Complication 16:23 <+Complication> cervantes: ну, можно назвать это полуежедневным мега-личингом :P 16:23 <ailouros> bar_: это рабочий прототип (proof-of-concept) распределённого файлового обмена, который делится общими блоками между разными файлами (как предложил polecat) 16:23 <bar_> ах да, верно, спасибо, ailouros 16:24 <tethra> cervantes: хехехе ;) 16:24 <ailouros> пожалуйста (если кто хочет получить исходники, это c/c++) 16:25 <+polecat> ailouros: Осторожнее, вероятность совпадения двух бинарных блоков достаточно мала, я в основном говорю о чистой теории, которая на практике может быть бесполезной. 16:25 <ailouros> polecat, согласен. Мой лучший прогноз — это полезно, когда у тебя разные версии одних и тех же файлов 16:25 <ailouros> например, фильм с повреждённым блоком 16:25 <+polecat> Можно передавать блоки из нулей с молниеносной скоростью! ("Следующий блок — нули" "о, этот у меня уже есть" "следующий блок — нули" "о, этот у меня уже есть") 16:26 <ailouros> или архив из других zip-файлов 16:26 <jrandom> или, например, изменённые ID3-теги и т.п. 16:26 <ailouros> точно 16:26 <+polecat> Верно. Но простой способ «починить» фильм с повреждённым блоком — сказать bittorrent скачать поверх него. Большинство клиентов сохранят блоки с теми же хэшами и перезапишут отличающиеся. 16:26 <jrandom> архивы файлов, вероятно, не сработают, поскольку им нужно будет разбиваться по границам файлов 16:27 <ailouros> j636, поэтому я хочу реализовать идею LBFS о разбиении по меткам данных, а не по фиксированным размерам блоков 16:27 <@cervantes> сообщество DC использовало этот метод, распространяя раздачи файла в rarset'ах 16:27 <+polecat> Что могло бы быть полезно — сделать общий алгоритм бинарной коррекции ошибок и внедрить его в большом масштабе. Все блоки могли бы «корректироваться» друг в друга, и нужно было бы передавать только данные коррекции, которые могут быть меньше, чем передача самого блока. 16:29 <@cervantes> и тогда поиск основан на tiger-хэшах этих rar-частей 16:29 <+Complication> Неплохо... звучит сложно :) 16:29 <+polecat> Но как эквивалент хэш-к-хэшу... ты никогда не найдёшь два одинаковых блока! 16:29 <ailouros> cervantes, что такое "rarset"? :D (кроме "RAR-файла", конечно) 16:29 <+polecat> Если только у обеих сторон уже был файл, у одной из них повреждённый. 16:29 <ailouros> polecat, а? 16:29 <@cervantes> ailouros: это разбитый на части rar-архив, при необходимости с файлами паритета 16:30 <ailouros> cervantes: не понимаю преимущества этого 16:31 <@cervantes> его основная польза была в добавлении псевдомульти-сорс скачивания в DC 16:32 <ailouros> ну, это часть механизма совместного использования блоков между файлами, не так ли? 16:34 <ailouros> polecat: насчёт перезаписи повреждённых файлов bittorrent'ом — это не помогает, когда ты пытаешься получить несколько версий одновременно 16:35 <@cervantes> твой клиент сопоставляет/скачивает только валидные части, если есть файлы паритета, можно восстановить повреждённые части 16:35 <ailouros> в моей системе нет повреждённых частей (файлы собираются только когда составляющие блоки скачаны и повторно проверены) 16:36 <@cervantes> вещи, которые bittorrent делает по умолчанию, за исключением того, что нельзя искать индивидуальные части 16:36 <+polecat> Несколько версий вряд ли будут иметь ни одного общего бита... вот почему это глупо. Какой-то тип решает перекодировать фильм в формат почтовой марки и даёт ему то же имя. 16:37 <+polecat> Или другой тип берёт случайные данные и называет их именем файла, который ты хочешь скачать. 16:37 <ailouros> лол, верно 16:37 <@cervantes> именно, и rarset-релизы к этому устойчивы... 16:37 <ailouros> но имей в виду, что файлы из других сетей (emule, kazaa, и т.д.) часто приходят повреждёнными 16:38 <+polecat> rarset-релизы не устойчивы... 16:38 <+polecat> Тебе всё равно надо понять, какой rarset правильный. 16:38 <ailouros> cervantes, как rarset устойчив к идиоту, публикующему случайный мусор? 16:38 <@cervantes> (при условии, что у тебя надёжный источник) 16:39 <@cervantes> потому что релиз-группа публикует хэши/информацию о раздаче 16:39 <ailouros> хаха, это легко :D 16:39 <@cervantes> и если что-то помечено как nuked за плохое качество, люди убирают это из шаринга 16:40 <ailouros> cervantes, это мой прототип уже умеет 16:40 <@cervantes> круто 16:40 <ailouros> ты получаешь дескриптор файла от доверенного источника, мультискачиваешь файл быстро 16:41 <@cervantes> звучит хорошо ;-) 16:41 <ailouros> ты не ищешь файлы, но можешь просматривать общий каталог каждого пользователя, так что можно использовать веб-краулер и кэшировать результаты 16:42 <ailouros> хотя я могу добавить функцию поиска в будущем, если это покажется нужным 16:44 <ailouros> Я считаю, что мой прототип, будучи нормально развит в приложение, может предложить кеширование и устойчивость, которые пытаются предложить freenet-люди 16:44 <ailouros> в смысле распространения и кеширования статического контента 16:45 <ailouros> ты читаешь мой блог, ты его кэшируешь и отдаёшь другим, когда они хотят. ты не делаешь ничего больше, чем просто держишь там контент 16:45 <ailouros> не нравится контент? удаляешь его — и дело с концом 16:45 <jrandom> хмм, то есть ты видишь это как бэкенд-хранилище, которое можно использовать для syndie? 16:46 <ailouros> МОЖНО использовать как бэкенд-хранилище 16:46 <ailouros> в текущем виде ты даже можешь использовать это вместо jetty в дефолтных установках i2p 16:46 <jrandom> например, вложения/ссылки на [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (ну, с парой мелких правок :D ) 16:46 <jrandom> хех 16:47 <jrandom> ок, да, я определённо не понимаю, как работает clunk... хочешь написать об этом в syndie или поднять eepsite? :) 16:47 <ailouros> хэши файла скачиваются по запросу файла, и эти хэши автоматически скачиваются до полного файла 16:48 <jrandom> верно, но «скачиваются» — это вопрос откуда и куда и т.д. Полезно было бы описание общей сетевой архитектуры 16:48 <ailouros> Сначала напишу внятную доку, потом опубликую где-нибудь 16:48 <jrandom> r0x0r, спасибо 16:48 <ailouros> скачиваются откуда ты получил хэш 16:48 <ailouros> плюс от всех остальных, кто шарит эти блоки 16:49 <ailouros> представь go!zilla и download accellerator :) 16:49 <jrandom> Думаю, ты недооцениваешь, насколько я запутался 16:49 <ailouros> но прозрачно и внутри i2p 16:49 <ailouros> лол, похоже на то :D 16:50 <jrandom> очень-очень базовое объяснение, типа «ты запускаешь clunk-клиент, скачиваешь с clunk-сервера, получаешь информацию о clunk-пирах» и т.д. 16:50 <jrandom> я использую веб-браузер, чтобы обращаться к clunk-клиенту? или серверу? или пиру? 16:51 <jrandom> (вот настолько я потерян) 16:51 <ailouros> перезапуск с 0 :) 16:51 <ailouros> ты используешь свой веб-браузер 16:51 <ailouros> ты подключаешься к своему клиенту 16:51 <ailouros> ты просматриваешь чужие каталоги через свой браузер 16:51 <ailouros> ты выбираешь, какие файлы скачать, через браузер 16:51 <ailouros> твой клиент делает всю грязную работу 16:52 <ailouros> ты получаешь скачанный файл обратно 16:52 <ailouros> так лучше? :) 16:52 <jrandom> ок, отлично, спасибо — то есть «просмотр чужого каталога» делает твой клиент, опрашивая их клиент и возвращая HTML-представление 16:52 <ailouros> именно 16:52 <jrandom> (или тянет с какого-то сервера/суперпира/и т.д.) 16:53 <jrandom> круто 16:53 <ailouros> вся грязная работа (поиск дубликатов, многопоточное скачивание и т.п.) выполняется твоим (локальным) клиентом прозрачно 16:54 <ailouros> по сути ты видишь дерево каталогов и некоторые файлы, которые можно скачать 16:54 <jrandom> круто 16:55 <ailouros> чтобы публиковать свои данные, ты отдаёшь свой публичный (p2p) адрес 16:55 <ailouros> а чтобы шарить файлы, ты копируешь их (или делаешь симлинки) в каталог pub/ (или какой-то подкаталог). Это так просто 16:57 * jrandom ещё покопается в исходниках и с нетерпением ждёт подробностей :) 16:57 <jrandom> ок, у кого-то ещё есть что-нибудь для встречи? 16:57 <bar_> эмм... можно спросить, в чём разница между публиковать и шарить? публиковать — это пушить данные в какое-то хранилище? 16:58 <ailouros> bar_: шарить — это отдавать блоки для скачивания. публиковать — это давать миру знать, что ты шаришь 16:58 <ailouros> публиковать — это подмножество шаринга 16:58 <bar_> ага, понял, спасибо 16:58 <ailouros> например, если у тебя половина файла, ты его шаришь, но не публикуешь 16:59 <jrandom> как же люди узнают, что они могут взять эти блоки у тебя? 16:59 <ailouros> и у тебя полный контроль над тем, какие файлы ты публикуешь (в отличие от emule, где каждый скачанный файл публикуется) 16:59 <ailouros> потому что каждый клиент периодически отправляет в сеть информацию о том, какие блоки он готов предложить 17:00 <jrandom> круто 17:00 <ailouros> отправляет в сеть, то есть на сервер (как сейчас) или в DHT (в будущем) 17:00 <jrandom> то есть это в стиле mnet, с трекером блоков 17:00 <ailouros> эмм, mnet-esque? 17:01 <jrandom> похоже на то, как работает mnet (mnetproject.org) 17:01 * ailouros читает mnetproject.org 17:02 <ailouros> ну, у тебя только личные пространства, без общих пространств 17:02 <ailouros> и ты не PUSH'ишь блоки туда-сюда 17:02 <jrandom> да, это не совсем то же самое, что mnet, но структурно похоже 17:03 <jrandom> это как mnet, где все слишком на мели, чтобы кто-то хостил их данные ;) 17:03 <ailouros> ага 17:03 <ailouros> :D 17:03 <jrandom> ок, кто-нибудь ещё хочет что-нибудь поднять? 17:04 <jrandom> если нет... 17:04 * jrandom сворачивает 17:04 * jrandom *baf*'ом закрывает встречу