Встреча разработчиков I2P - 27 марта 2007

16:02 <jrandom> 0) привет 16:02 <jrandom> 1) Статус сети 16:02 <jrandom> 2) предложения zzz по NTCP/SSU 16:03 <jrandom> 3) статус разработки Syndie 16:03 <jrandom> 4) статус DNS/регистратора 16:03 <jrandom> 5) ??? 16:03 <jrandom> 0) привет 16:03 * jrandom машет рукой 16:03 <jrandom> еженедельные заметки о статусе выложены на http://dev.i2p.net/pipermail/i2p/2007-March/001342.html 16:04 <jrandom> переходим к 1) статус сети 16:04 <jrandom> всё выглядит довольно неплохо, и, как уже говорилось, предстоит ещё провести исследования по последним изменениям 16:05 <+Complication> Я хотел немного пожаловаться на подключение к IRC (в остальном всё вроде нормально), но за последний день у меня было всего около 6 разрывов — не так уж плохо 16:05 <cervantes> /mute Complication 16:05 <jrandom> хех 16:05 <+Complication> :D 16:06 <+Complication> Успешность сборки tunnel очень радует, впрочем 16:06 * Complication на всякий случай проверяет ещё раз 16:06 <jrandom> да, я видел некоторую чехарду с дисконнектами (хотя, если честно, я читаю историю через grep -v -\!- и поэтому никогда не вижу дисконнекты ;) 16:06 <cervantes> в последнее время со стороны ISP были всякие косяки на фронте IRC — postman ищет альтернативные варианты хостинга 16:06 <jrandom> показатели сборки tunnel в статистике пошли вверх, хотя в целом это похоже на циклы на stats.i2p 16:06 <cervantes> надеюсь, мы сможем улучшить избыточность сети 16:06 <jrandom> ага, ок, cervantes 16:07 * jrandom предложил бы помочь с dev.i2p.net, но не помнит, когда в последний раз нагрузка на нём была ниже 4 16:08 <jrandom> ок, у кого-нибудь есть ещё что добавить по поводу статуса сети? 16:10 <jrandom> если нет, переходим к 2) предложениям zzz по NTCP/SSU 16:10 <jrandom> zzz, похоже, сейчас нет, а свои сообщения в Syndie с ответами в эту ветку я оставил дома (эх) 16:11 <jrandom> в любом случае, выкладывайте свои мысли в блоге zzz (или читайте там для получения дополнительной информации) 16:11 <jrandom> но есть ли что обсудить по этому поводу прямо сейчас здесь? 16:12 <+Complication> Ну, я лично написал там ответ, выразив обеспокоенность слишком сильной зависимостью от UDP (так как у меня лично у UDP довольно высокие показатели повторных передач) 16:12 <jrandom> ага 16:12 <+Complication> Однако я подумал об одном подходе... 16:12 <+Complication> Сейчас оценки (bids) полностью детерминированы (в отличие от вероятностных с случайной компонентой), верно? 16:13 <jrandom> ага, полностью детерминированные 16:13 <+Complication> Я думал, будет ли польза (в смысле избегания крайностей), если добавить им вероятностную составляющую 16:14 <+Complication> Например, «60% шанс получить NTCP, 40% шанс получить SSU» 16:14 <+Complication> (при условии отсутствия предыдущих данных — если бы были данные о неудачах/успехах, вероятности, вероятно, стоило бы сместить в пользу более эффективного транспорта для этой связи) 16:15 <jrandom> ну, зависит от того, чего мы хотим добиться — насколько я понимаю предложение zzz, цель — использовать SSU когда это возможно 16:15 <+Complication> (разумеется, при условии, что оба транспорта применимы для данной связи — иногда это, конечно, не так) 16:15 <jrandom> рандомизация этому не поможет, хотя и даст больше возможностей собирать данные о работе обоих транспортов «в природе» 16:16 <+Complication> Просто мысль о возможном способе попытаться найти между ними баланс (потому что если один всегда даёт более высокий bid, routers, вероятно, не будут особо «экспериментировать») 16:19 <jrandom> Это метод, который мы могли бы использовать для сбора дополнительных данных, стоит иметь в виду 16:19 <jrandom> ок, как уже говорилось, пишите в ту ветку для дальнейшего обсуждения :) 16:20 <jrandom> переходим к 3) статусу разработки Syndie 16:20 <jrandom> мне особо нечего добавить сверх того, что в письме 16:20 <jrandom> у кого-нибудь есть вопросы/комментарии/замечания? 16:21 <+Complication> Пока нет. :) 16:22 <jrandom> хе-хе 16:22 * Complication лелеет надежду помочь побольше — либо на фронте I2P, либо Syndie, но сначала мне действительно нужно выпустить ту штуковину с webcache 16:22 <jrandom> w3rd, с нетерпением жду обоих :) 16:24 <jrandom> ок, давайте пропустим 4 и перейдём к 5) ??? 16:25 <jrandom> есть ли ещё что-то, что хотите поднять на встрече? 16:26 <TrevorReznik> есть интерес к генератору hashcash для I2P? 16:26 <TrevorReznik> то есть через интерфейс браузера. 16:26 <TrevorReznik> я думал об этом как о способе устранить возможные сценарии DoS внутри I2P. 16:27 <jrandom> хмм, на JavaScript или C/Java? 16:27 <jrandom> думаю, есть несколько генераторов hashcash 16:27 <TrevorReznik> на Java. 16:28 <+Complication> ну, исследование схем hashcash, вероятно, в какой-то момент потребуется 16:28 <TrevorReznik> www.hashcash.org имеет некоторые, как мне кажется. 16:28 <TrevorReznik> это инициатива по внедрению его в почтовые клиенты как антиспам-механизма. 16:28 <+Complication> возможно, не исследование в строгом смысле, а в плане реализации и best practice 16:28 <+Complication> =sense 16:28 <TrevorReznik> у них есть коллекция реализаций на множестве языков. 16:28 <TrevorReznik> там есть 2 класса на Java и как минимум один апплет, хотя сейчас я не знаю точных параметров лицензии. 16:30 <+Complication> где это можно применить: 1) регистрация nym в Syndie 2) регистрация имён в I2P 16:30 <+Complication> 3) электронная почта, очевидно 16:30 * TrevorReznik соглашается. 16:30 <+Complication> 4) в менее оптимистичных сценариях — обычные сообщения в Syndie 16:31 <+Complication> на уровне самой сети I2P... 16:31 <+Complication> хмм 16:31 <jrandom> можно встроить их в сообщения создания tunnel, но по CPU у нас и так всё плохо ;) 16:39 <jrandom> ок, есть ли что-нибудь ещё для встречи? 16:41 <jrandom> если нет 16:41 * jrandom сворачивает 16:41 * jrandom *baf* закрывает встречу