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

16:09 <jrandom> 0) привет 16:09 <jrandom> 1) Состояние сети и 0.6.1.16 16:09 <jrandom> 2) Построение tunnel и перегрузка 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) привет 16:10 * jrandom машет 16:10 <jrandom> еженедельные статус-заметки выложены на http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk тоже 16:10 <jrandom> (почти за два часа ДО встречи, между прочим :) 16:11 <jrandom> ок, раз уж я уверен, что вы все уже вдумчиво прочитали заметки, давайте прыгнем к 1) Состояние сети 16:12 <+Complication> Привет :) 16:12 * Complication быстро хватает заметки 16:12 <jrandom> релиз 0.6.1.16 исправил очень давний баг в нашем prng (генератор псевдослучайных чисел), из‑за которого происходило значительное количество произвольных отказов в построении tunnel 16:13 <jrandom> (первопричина была внесена прошлым октябрем, но теперь всё исправлено) 16:13 <+Complication> Статус у меня: терпимо работает с tunnel на 1 + 0..1 hop, отказывается вести себя нормально с 2 + 0..1 или 2 +/- 0..1 16:14 <jrandom> ага, это тоже понятно, особенно на медленных каналах 16:14 <jrandom> (к сожалению, «медленных» — это не то чтобы очень медленных) 16:15 <jrandom> работы всё еще много, и 0.6.1.16 — это не тот уровень, который нам нужен, но прогресс есть 16:17 <+Complication> Я тут думал о том, что ты назвал «congestion collapse» (коллапс из‑за перегрузки) 16:18 <+Complication> Один из способов ограничить его влияние — фактически требовать от router принимать определенную квоту запросов на участие 16:19 <+Complication> (что‑то, задаваемое пользователем напрямую или косвенно?) 16:19 <jrandom> каким пользователем это задается? 16:19 <+Complication> (например, частью share percentage (процент раздачи) или дополнительным параметром) 16:19 <jrandom> локальным пользователем или нами как удаленными пользователями? 16:19 <+Complication> Каждый задает для себя 16:19 <@frosk> может перейдём к 2)? :) 16:20 <jrandom> ага, давайте считать, что мы уже на 2) :) 16:20 <+Complication> Чтобы я мог, например, сказать своему router «даже если ты перегружен, продолжай маршрутизировать минимум 4 KB/s» 16:21 <jrandom> Complication: это не очень реально — если router слишком перегружен, другие (надеюсь ;) перестанут просить его участвовать в tunnel. 16:21 <+Complication> (это, конечно, могло бы означать, что какая‑то локальная destination будет офлайн подольше) 16:21 <jrandom> а если его не просят, он и не сможет проталкивать чужие данные 16:22 <+Complication> Ага, возможно, мне стоило сформулировать куда яснее 16:24 <+Complication> Я представлял, что при определенной квоте транзитного трафика он мог бы ограничивать свои собственные сообщения построения tunnel вместо того, чтобы ограничивать участвующие tunnel 16:24 <+Complication> например: «Я никогда не буду ограничивать свои участвующие tunnel ниже 4 KB/s. Если до этого дойдет, я лучше ограничу свой собственный трафик». 16:26 <jrandom> хм, тут есть риски для анонимности (хотя это всё из той же серии селективного DoS, от которого мы и так не защищаемся) 16:27 <jrandom> но ограничение наших локальных построений tunnel при перегрузке у меня сейчас в тестировании — добавить поддержку опционального игнорирования порога 4KBps должно быть достаточно просто 16:28 <spinky> Сейчас вы вообще не получаете cover traffic при передаче больших объемов данных. 16:29 <spinky> Пол (минимум) для participation bw звучит неплохо. 16:30 <jrandom> ну, у нас есть пол (и как share percentage, и внутренние 4KBps, резервируемые после распределения всей пропускной способности) 16:30 <+Complication> Эх, отвалился... Надеюсь, не многое потерялось из того, что я сказал, а ответы прочитаю по логу :) 16:32 <@frosk> есть ли что‑то особенное в 4KBps? 16:33 <jrandom> несколько моментов — 4KB ~= размер tunnel create message, и эвристически я не слышал о router, который успешно работал на меньшем 16:33 <spinky> Может, тогда баги мешают работе share percentage? 16:34 <jrandom> почему ты считаешь, что share percentage не работает? 16:34 <@frosk> ясно 16:34 <+Complication> frosk: нет, это просто число в текущем коде, и я ссылался на него, пытаясь объяснить свою идею 16:35 <+Complication> (не по содержательным причинам, а потому что задуманное мной было, в некотором смысле, его противоположностью) 16:35 <spinky> У меня выставлено 80%, а участие падает до 0 при локальной генерации данных. Возможно, я что‑то неправильно понимаю. 16:36 <jrandom> ага, это не то, что делает share percentage 16:36 <+Complication> spinky: это максимальный предел того, что может быть отдано, при условии, что пропускная способность вообще доступна для отдачи 16:37 <+Complication> Если локальный трафик занимает 70%, у тебя остается только 10% для отдачи 16:37 <+Complication> Если локальный трафик тяжелый, останется 0%, и верхний предел 80% так и не будет достигнут 16:37 <spinky> Ок. Вижу, там написано «до»... 16:38 <+Complication> И еще есть резерв 4 KB/s 16:38 <jrandom> ага, это share percentage от того, что у тебя доступно 16:38 <spinky> Может, еще одна настройка для минимального participation bw, ниже которого router будет принимать больше tunnel? 16:38 <jrandom> если ты используешь 95% своей пропускной способности, он будет шарить до 80% от оставшихся 5% 16:39 <+Complication> О, значит, я тоже частично неправильно это понял 16:40 <fox> <zorglu1> как i2p измеряет объем пропускной способности, используемый другими локальными приложениями? 16:40 <spinky> (Просто к слову: если вы считаете cover traffic хорошей вещью, возможно, сделать его настраиваемым даже при сильной локальной загрузке канала — это хорошо) 16:40 <+Complication> Я думал, это применимо к устойчивому лимиту 16:40 <jrandom> zorglu1: он измеряет использование пропускной способности самим i2p и знает лимиты пропускной способности i2p 16:41 <jrandom> о, хм, глядя на код, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> так что ты прав, Complication 16:42 <jrandom> spinky: cover traffic полезен только в микссети с низкой задержкой 16:42 <jrandom> он действительно добавляет стимулы для router с более высокой пропускной способностью, но у тех, у кого нет лишней пропускной способности, мало возможностей 16:49 <jrandom> в любом случае, проблема с перегрузкой tunnel существует давно, но недавно её усугубили безумные уровни отказов в построении tunnel 16:49 <jrandom> надеюсь, следующая ревизия прояснит это для нас 16:49 <jrandom> ок, есть ли ещё что‑нибудь по 2) построению tunnel и перегрузке? 16:50 <@frosk> похоже, это потребует некоторых изменений в схеме построения tunnel 16:50 <+Complication> Надеюсь, это поможет улучшить ситуацию :) 16:51 <+Complication> О, кстати... 16:52 <jrandom> ну, у нас есть дешевые фиксы, такие как снижение максимальной параллельности, ограничение наших попыток построения при перегрузке, снижение частоты «drop» (в отличие от явного отказа) и корректировка профилирования, чтобы стимулировать явные отказы вместо «drop» 16:52 <+Complication> ...не нашлось ли у тебя чего‑нибудь, что могло бы объяснить большую разницу между индикаторами сырой пропускной способности и индикаторами полезной нагрузки tunnel? 16:52 <+Complication> (например, общий трафик 1 GB, суммарная полезная нагрузка tunnel 300 MB) 16:52 <jrandom> но правда в том, что это влияет только на величину 16:52 <+Complication> (я в последнее время не бывал в IRC, не уверен, смотрел ли ты на это недавно) 16:54 <jrandom> особо не копался, но помни: запросы на построение исходящих tunnel — это не сообщения tunnel (и их очень много, если только 0.1% успешны. и по 4KB каждый...) 16:54 * Complication не уверен, дело ли в индикаторах или это реальный эффект 16:55 <+Complication> О... исходящие запросы на построение... действительно 16:55 <jrandom> грядущая сборка -1 добавляет кучу статистик для мониторинга пакетов по типам сообщений 16:55 <+Complication> Это может быть как раз оно 16:55 <jrandom> (в эти исходящие запросы на построение также входят запросы на участие в построении — пересылка ответа) 16:56 <jrandom> ((так что это не только локальные штуки)) 17:00 <+Complication>> Спасибо, это многое объясняет :) 17:00 <+Complication>> Значит, это не вуду, а вполне реальный трафик, о котором я просто забыл, поскольку он не учитывался в тех местах, где я смотрел 17:00 <+Complication> Он действительно должен происходить и действительно стоит много байт 17:00 <+Complication> Особенно при низких показателях успеха 17:01 <jrandom> ага, хотя это не должно стоить так много, ведь наши показатели успеха должны быть выше, чем есть :) 17:01 <jrandom> ок, что‑нибудь еще по 2)? 17:02 <jrandom> если нет, давайте перейдем к 3) Feedspace 17:02 <jrandom> frosk: дашь нам апдейт? 17:03 <jrandom> (или пошлёшь нас fsck'ом и отправишь читать eepsite? ;) 17:04 <@frosk> ну, для тех, кто не следил за frosk.i2p или feedspace.i2p, feedspace сейчас, по сути, работает (по моей собственной дефиниции «в общем») 17:04 <jrandom> (w00t) 17:05 <@frosk> в последнее время были приятные добавления, например инфраструктурная поддержка транспортов не только i2p (на ум приходят tor и неанонимный tcp/ip) 17:06 <@frosk> со временем мы планируем позволить syndie (в предстоящей и, вероятно, очень удачной переработке) использовать feedspace как один из методов синдикации 17:06 <@frosk> сейчас нет клиентских приложений, которые бы действительно ИСПОЛЬЗОВАЛИ feedspace для чего‑нибудь :) я тестирую с крайне грубым servlet‑приложением 17:07 <jrandom> (грубое + работающее)++ 17:07 <@frosk> так что вакансия для клиентского хакера, конечно, открыта ;) 17:08 <@frosk> всё еще есть необходимое, что нужно feedspace перед публичным тестированием, но это уже недалеко :) 17:08 <jrandom> nice1 17:08 <jrandom> чем‑нибудь можем помочь? 17:08 <@frosk> я также немного работал над документацией, которой не хватало 17:09 <spinky> Видишь ли ты feedspace пригодным для больших файлов? 17:10 <@frosk> 1) клиентские приложения, использующие (все ещё недокументированный) xmlrpc api, 2) http://feedspace.i2p/wiki/Tasks, 3) участие в тестировании, когда придет время 17:10 <@frosk> поддержка больших файлов сейчас не приоритет, возможно позже 17:10 <@frosk> фокус для «1.0» — небольшие сообщения, такие как записи блогов и обсуждений, и события любого рода 17:11 <jrandom> хотя подача .torrent‑файлов в RSS/feedspace‑включенный BT‑клиент не будет проблемой 17:11 <@frosk> большие файлы могут и заработать, а могут и нет :) 17:11 <@frosk> это было бы супер‑круто 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> надеюсь, мы увидим всякие такие приложения‑«адаптеры» :) 17:12 <+Complication> Ну, уверен, люди найдут способы передавать большие файлы через побочные... эм... каналы :) 17:15 <@frosk> я чувствую лёгкую вину за то, что код feedspace использует всякие фичи java1.5. Сейчас, наверное, его сложно компилировать/использовать на свободной java, но она подтянется, уверен :) 17:15 <jrandom> брр 17:16 <jrandom> ходят слухи, что gcj примет ecj для 1.5‑измов 17:16 <spinky> Complication: пони с седельными сумками, набитыми hdds? 17:16 <@frosk> ага 17:17 <+Complication> spinky: в моем предпочтительном случае — дроны :P 17:17 * jrandom всё ещё едва перебирается к 1.4‑измам 17:17 <+Complication> Но, полагаю, пони тоже сгодятся :P 17:17 <jrandom> хотя 1.6, конечно, приятная ;) 17:17 <@frosk> чтобы оставаться совместимым с gcj? 17:18 <@frosk> ну, у 1.6 не так много «измов» для большинства вещей, думаю :) 17:18 <+Complication> (или летающие ежи, сбрасывающие с воздуха карты памяти) 17:18 <jrandom> gcj/classpath/etc, но также ради производительности (я находил 1.5 более тяжёлой, чем 1.4) 17:19 <jrandom> верно, улучшения 1.6 в основном специфичны для VM/байткода 17:19 <@frosk> хм, ок 17:20 * jrandom не пытается переубеждать тебя не использовать 1.5‑измы. уверен, у тебя есть причины, и, например, azureus уже требует 1.5 17:21 <@frosk> ну пути назад нет :) надеюсь, будет не слишком ухабисто 17:24 <jrandom> ага, уверен, всё будет ок :) 17:25 <jrandom> ок, круто, есть ли ещё что‑нибудь по 3) feedspace? 17:25 * frosk обнимает свои generics и java.util.concurrent ;) 17:25 <jrandom> хехе 17:27 <jrandom> ок, если больше ничего по 3, перейдем к 4) ??? 17:27 <jrandom> есть ли что‑нибудь ещё для встречи? 17:27 <+Complication> Небольшой вопрос, который стоило задать в разделе 2) 17:28 <+Complication> Знаешь ли ты, как обычно появляются простаивающие участвующие tunnel? 17:28 <+Complication> Это в основном признак неудавшихся построений tunnel, о которых знает только создатель? 17:28 <+Complication> Или у них есть дополнительные причины? 17:28 <+Complication> (кроме, разумеется, очевидного — когда приложение простаивает) 17:29 <jrandom> простаивающее приложение не имело бы простаивающих tunnel (они бы тестировались) 17:29 <jrandom> простаивающие tunnel — это неудачные по тем или иным причинам 17:29 <jrandom> (либо не удалось полностью создать, либо отказали в процессе работы) 17:30 <+Complication> Верно, т.е. все tunnel всё равно тестируются, а тестирование должно генерировать трафик... действительно 17:30 <+Complication> Это подводит ко второй части вопроса: есть ли польза в том, чтобы заметить, что tunnel простаивает, и удалить его раньше срока? 17:31 <+Complication> Есть ли там какие‑то ценные ресурсы для экономии? 17:32 <jrandom> никаких — tunnel, который не гонит данные, не потребляет ресурсы 17:32 <jrandom> (ок, он использует немного RAM, может, 32 байта) 17:32 <+Complication> Или, возможно, это помогло бы router лучше понимать свою нагрузку и подобные параметры... 17:33 <jrandom> прогнозы использования пропускной способности на основании истории tunnel — это, конечно, открытый вопрос 17:33 <+Complication> Или это будет просто бессмысленная работа, и лучше дождаться естественного истечения срока? 17:33 <+Complication> (как сейчас) 17:34 <jrandom> раньше мы делали некоторые прогнозы, но явных выгод это не давало, так что сейчас используем более простой алгоритм 17:34 <+Complication> Ага, значит, выгоды нет... 17:34 <+Complication> Спасибо, в общем, это всё, что я хотел спросить :) 17:34 <jrandom> не за что, понятная озабоченность 17:34 <jrandom> ок, есть ли ещё что‑нибудь для встречи? 17:35 <+Complication> Да, если делать прогнозы, процент простаивающих tunnel может исказить оценки 17:35 <+Complication> (если он заметно варьируется) 17:36 <jrandom> ага, мы бы хотели учитывать процент простоя как часть оценки 17:36 <jrandom> (раньше учитывали — см. метод RouterThrottleImpl.allowTunnel) 17:37 <+Complication> О, не знал :) 17:37 <jrandom> и обрати внимание на новый комментарий: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication все еще листает к файлу, но спасибо :) 17:39 <jrandom> w3rd 17:40 <jrandom> ок, если для встречи больше ничего... 17:40 * jrandom сворачивает 17:41 * jrandom *baf* закрывает встречу