Встреча разработчиков I2P - 04 апреля 2006

16:21 <jrandom> 0) привет 16:21 <jrandom> 1) Состояние сети и 0.6.1.14 16:21 <jrandom> 2) Планирование Syndie 16:21 <jrandom> 3) Локальные оптимизации jbigi 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) привет 16:21 * jrandom машет 16:21 <jrandom> еженедельные заметки о статусе выложены на http://dev.i2p.net/pipermail/i2p/2006-April/001275.html 16:21 * Complication читает 16:22 <jrandom> пока вы читаете этот (быстро накиданный) пост, давайте перейдём к 1) Состояние сети 16:23 <@cervantes> (форум вернулся) 16:23 <jrandom> есть несколько проблем, влияющих на использование 0.6.1.13, и большинство из них уже найдены и решены 16:24 <Complication> У меня тут, с «четвёртой» сборкой из CVS, я заметил изменения на графиках 16:24 <jrandom> хотя ещё тестируются и переделываются некоторые шероховатости, релиз должен выйти в ближайшие пару дней 16:24 <Complication> В целом всё стало стабильнее и менее дёргано 16:24 <jrandom> чёрт, я же забыл поднять до -4, да? 16:24 <jrandom> (ок, -5 выйдет позже этим вечером) 16:24 <jrandom> круто, Complication 16:25 <Complication> Но мои ощущения могли повлиять и jbigi, я не предпринял шагов, чтобы это исключить 16:25 <Complication> Сейчас, спустя некоторое время, доля повторных передач тоже снизилась до 15% 16:28 <jrandom> хмм, я тоже вижу, что мой средний SSU rto приближается к потолку в 3s 16:28 <jrandom> (при этом доля повторных передач всё ещё очень низкая, менее 5%) 16:29 * Complication смотрит на это ещё раз 16:29 <Complication> Скажем, сырое среднее чуть больше 1500 16:29 <Complication> (у меня) 16:30 <+fox> <BrianR___> jrandom: Существует ли де-факто «MTU» для пакетов I2P? 16:30 <jrandom> ага, ок, возможно по мере роста этого показателя доля повторных передач будет снижаться 16:30 <Complication> Я заметил, что у меня сначала были меньшие MTU, сейчас поднялось до 1350 16:30 <jrandom> BrianR___: да, либо 1350, либо 608 (как показано на `http://localhost:7657/peers.js)` 16:31 <jrandom> если уровень ошибок слишком высок на большем MTU, он откатывается к меньшему MTU (а если слишком низок на меньшем MTU, поднимается к большему MTU) 16:31 <+fox> <BrianR___> jrandom: Это для внутренней полезной нагрузки или для видимых IP-пакетов? 16:31 <+fox> <BrianR___> То есть если я отправлю блок данных по I2P stream, какой идеальный размер кусков для минимизации накладных расходов? 16:31 <jrandom> это для полезной нагрузки UDP 16:32 <jrandom> streams на два уровня выше 16:32 <jrandom> (есть фрагментация для tunnels, а затем фрагментация на уровне stream/I2CP) 16:32 <+fox> <BrianR___> Да... Есть ли идеальный размер, чтобы минимизировать фрагментацию? 16:32 <jrandom> идеальный размер блока для приложения, использующего стриминговую библиотеку, — «большой», чтобы сама библиотека могла выбрать подходящий размер. 16:33 <jrandom> (иначе говоря, не обращайте внимания на человека за занавеской) 16:33 <+fox> <BrianR___> Ага... Может, тогда подумать о конвейеризации (pipelining) или чем-то таком... 16:34 <+fox> <BrianR___> Я планирую приложение с кучей трафика запрос/ответ... 16:34 <jrandom> тогда я бы рекомендовал батчировать, чтобы снизить болтливость 16:34 <Complication> Возможно, концентрация трафика до некоторой степени тоже поможет 16:37 <jrandom> ок, что-нибудь ещё по 1) Состояние сети, или пританцуем к 2) Планирование Syndie 16:38 * jrandom покачивается 16:39 <jrandom> это в основном заглушка и приглашение к предложениям (CFP) — планируется существенная переработка Syndie, как в части работы, так и в интерфейсе (UI), так что если у вас есть ключевые фичи или сценарии использования, которые стоит учесть, — дайте знать 16:40 <jrandom> (подробностей, разумеется, будет больше по мере проработки) 16:42 <jrandom> это всё, что я пока хотел сказать об этом, так что переходим к 3) оптимизации jbigi 16:42 <@frosk> а я-то думал, что «plotting» — это про какие-то jrobin-графики в Syndie :) 16:43 <jrandom> хехе 16:43 <jrandom> было бы интересно строить графики: постов/день, постов/автор, новых авторов/день и т. п. ;) 16:44 <Complication> О, одна мелочь про Syndie (сорри, только что вспомнил) 16:44 <Complication> = один бит 16:44 <@frosk> какой хочешь, 0 или 1? :) 16:44 <Complication> Как думаете, было бы практично, и насколько легко/сложно, разделить любимых авторов и авторов из чёрного списка (спамеров) на два разных списка? 16:45 <Complication> На addresses.jsp 16:45 <jrandom> о, да, без особых проблем 16:46 <jrandom> это хорошая идея и для переделки в целом, но, возможно, мы успеем засунуть это в сборку 0.6.1.14 16:47 <Complication> Да нет, меня это не беспокоит, просто вспомнил то, что тогда заметил 16:47 <Complication> В любом случае, jbigi становится быстрее на Linux/AMD64, если собирать локально и использовать GMP 4.2 16:48 <jrandom> круто 16:48 <jrandom> сравнивал это с -O3 -m64 на GMP 4.1.2? 16:48 <Complication> И я был тем ещё дураком, погнался за совсем не теми флагами компиляции :O 16:48 <@cervantes> релевантная ссылка была `http://forum.i2p/viewtopic.php?t=1523&start=30` кстати 16:48 <jrandom> ах, спасибо, cervantes 16:48 <Complication> jrandom: пока не сравнивал, но сравню 16:49 <Complication> Во время следующей плановой перезагрузки 16:50 <jrandom> процесс сборки jbigi по сути «собрать GMP, затем собрать jbigi.o и слинковать их вместе», так что любые оптимизации, которые хочется сделать для GMP, можно сделать на первом шаге 16:50 <@cervantes> Я не видел большой разницы между -O3 и -O2 в предыдущих тестах, будет ли по-другому на x86_64 ... *пожимает плечами* 16:50 <jrandom> ага, может зависеть и от версии компилятора 16:50 <jrandom> (особенно с этими вопросами 3.3/3.4/4.0/4.1) 16:51 <@cervantes> чтобы повторить то, что я упоминал в той теме... оптимизированного под windows64 jbigi мы вряд ли скоро увидим 16:51 <+fox> <BrianR___> Делает ли i2p stream lib сжатие полезной нагрузки? 16:52 <Complication> BrianR: да 16:52 <@cervantes> если только у кого-то нет M$ VC 2005 с 64-битным SDK и не захочется тяжело поработать, чтобы собрать gmp 16:52 <Complication> По крайней мере, насколько мне известно 16:53 <@cervantes> (где-то был проект по портированию gmp в проект vc) 16:53 <jrandom> cervantes: ну, у нас есть то, что /работает/ для amd64/win, но это не выжимает максимум из железа ;) 16:53 <jrandom> (когда приедет мой новый ящик, возможно, смогу это подкрутить, так как он amd64) 16:53 <+fox> <BrianR___> пытаюсь понять, стоит ли использовать бинарный протокол ради экономии битов или zlib/что-то подобное хорошо ужмёт ASCII-протокол до маленького размера.. 16:54 <@cervantes> крутяк — к сожалению, MinGW64 или Cygwin64 на горизонте не видно... 16:54 <jrandom> BrianR___: преждевременная оптимизация — корень всех зол и всё такое... 16:55 <Complication> по крайней мере частично человекочитаемые протоколы обычно легче отлаживать, но думаю, зависит от задачи 16:56 <Complication> (потому что некоторые вещи, как шифрование, не любят быть человекочитаемыми, как ни крути :) ) 16:57 <Complication> Но если I2P делает шифрование и ещё и сжимает, есть хорошие шансы, что многое поверх этого можно делать человекочитаемыми протоколами 16:58 <jrandom> ага 16:58 <jrandom> ок, что-нибудь ещё по 3) jbigi? 16:58 <jrandom> если нет, перейдём к 4) ??? 16:59 <jrandom> у кого-нибудь есть ещё что-то для встречи? 17:01 <+tethra> помню, недавно говорили про инструменты анонимного совместного взаимодействия 17:01 <+tethra> не расскажешь, какие именно и будут ли они в стиле Syndie или нет? 17:02 <@cervantes> irc и syndie — это анонимный инструмент совместной работы :) 17:02 <jrandom> хмм, не уверен, о чём ты — или ты имеешь в виду планируемые переделки syndie? :) 17:02 <+tethra> верно. 17:02 * tethra и сам не уверен, поэтому и спросил 17:02 <+tethra> об этом говорили на форуме — причины анонимности и всё такое 17:03 <+tethra> найду тему, чтобы привести цитату 17:03 <jrandom> ах да 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> ветка с вариантами использования 17:03 <+tethra> - анонимно размещаемые и публично доступные форумы/доски/вики 17:03 <+tethra> да 17:04 <+tethra> будет ли проект наподобие i2wiki, основанный на чём-то вроде syndie, или это на усмотрение пользователей? 17:04 <jrandom> там были хорошие идеи и неплохая обратная связь 17:05 <jrandom> возможность редактировать посты в syndie — часто запрашиваемая фича, и с ней можно было бы провернуть вики с богатым редактором 17:05 <jrandom> но, конечно, ничего не существует в вакууме — если кто-то считает это необходимым, пусть скажет «вики необходима, и вот почему» 17:06 <jrandom> существует бесконечное число приложений, которые /можно/ построить, но так как мы нацелены на сильную анонимность и сильную безопасность, важно тщательно подходить к тому, что делать 17:07 <+tethra> верно 17:07 <+tethra> то есть некоторые из более сложных вещей, которые трудно держать анонимными и безопасными, возможно, лучше поручить тем, кто хорош в обеспечении анонимности и безопасности, так? 17:08 <jrandom> вероятно, да, хотя никакого тайного кружка нет — любой может научиться 17:08 <+tethra> (ключевые вещи, по сути. я сейчас ничего конкретного не называю, но вы поняли.) 17:08 <+tethra> верно 17:09 <+tethra> но учиться ценой своей и чужой анонимности — не лучший способ 17:10 <jrandom> каждый с чего-то начинает, конечно 17:10 <+tethra> (может, если бы кто-то сделал что-то вроде песочницы, где можно запускать $software и позволять людям атаковать это и прочее, то это помогло бы новичкам/неопытным?) 17:10 <+tethra> ага 17:14 <jrandom> ок, у кого-нибудь ещё есть что-то к встрече? 17:15 <jrandom> если нет 17:15 * jrandom начинает заканчивать 17:15 <@cervantes> *кхм* 17:15 * jrandom замирает 17:16 <jrandom> что там, cerv? 17:16 <Complication> Круто, я нашёл баф ;P 17:17 <jrandom> баф-блокирован ;) 17:17 <@cervantes> упс, сорри, продолжай бафать 17:17 * jrandom продолжает закручивать 17:18 * jrandom *baf* закрывает встречу