Как поменять интервал времени выбора случайного муршрута в TOR?
Как поменять интервал времени выбора случайного муршрута в TOR?
Возможно ли установить значение интервала времени выбора случайного муршрута для каждого приложения отдельно?
Комментарии
— spinore (13/11/2006 00:01)
>Возможно ли установить значение интервала времени выбора случайного муршрута для каждого приложения отдельно?
Вообще, вряд ли. Но этим могла бы заниматься сторнняя программа. Как одну из альтернатив могу предложить запустить несколько разных процессов tor, независимых, с разными конфигами, и каждую версию тора настроить по своему. Затем для конкретныхъ целевых приложений уже можно указывать, на какой порт (к какому из tor) следует обращаться. Например, можно забиндить 3 тора на порты 9050, 9040 и 9030 (аналогично поступить можно и с privoxy).
— SATtva (13/11/2006 19:56) В дополнение к ответу spinore'а добавлю, что непосредственно интервал перестройки цепочек регулируется следующими параметрами конфига:
MaxCircuitDirtiness [мин] — Tor может повторно использовать открытую цепочку для нового соединения, если она была создана меньше, чем [мин] назад (по умолчанию 10). Т.е. если Вы хотите, чтобы цепочки перестраивались чаще, установите здесь, допустим, 1.
NewCircuitPeriod [сек] — как часто Tor должен проверять, необходимо ли сформировать новые цепочки (по умолчанию 30). Если Вы уменьшили значение предыдущего параметра, сократите и этот примерно до 10-15.
— spinore (14/11/2006 09:40) С моими мозгами я всё же не понял.
Чем эти 2 параметра отличаются? Слова чуть разные, а сути не пойму. В чём идея? Я представлял себе, что тор по умолчанию создаёт новую цепочку каждые N минут, причём если какая-то из tcp-сессий не закончилась, она продолжает идти по предыдущей цепочке (а вновь открываемые сессии – не знаю – по новой сразу, или ждут, когда старая закончится ).. Итого получаем один параметр. Откуда второй? Или 2-й параметр показывает, что нельзя использовать уже использовавшийся маршрут чаще, чем раз в K минут, если даже таковой вскоре случайно выпадет при генерации новой цепочки (что приведёт к генерациям новых цепочек, пока не будет получена цепочка, не противоречащя условию "К")? Короче, фантазировать долго можно.
— SATtva (14/11/2006 18:00) Объясняю детали. Если что не понравится, критикуйте разработчиков, а не меня. Во-первых, уточню, что "чистыми" цепочками Tor считает такие, по которым после их открытия не пропускался полезный трафик.
Вообще Tor предпочитает пускать новые соединения через "чистые" цепочки, но если TCP-соединение в данной цепочке закрылось до того, как истёк её MaxCircuitDirtiness, новое соединение может быть также установлено через неё. Если же значение MaxCircuitDirtiness превышено и активных потоков в цепочке уже нет (предполагается, что были), Tor её убивает. (Кстати, есть ещё третий параметр, CircuitIdleTimeout [сек], определяющий, через какое время простоя Tor убьёт даже совершенно "чистые" цепочки.)
Второй параметр, NewCircuitPeriod, определяет, как часто Tor должен проверять, нужны ли новые цепочки и следует ли их построить. Если значение этого параметра слишком завысить, может сложиться ситуация, что все текущие цепочки убиты, а новых нет.
Вообще, вряд ли. Но этим могла бы заниматься сторнняя программа. Как одну из альтернатив могу предложить запустить несколько разных процессов tor, независимых, с разными конфигами, и каждую версию тора настроить по своему. Затем для конкретныхъ целевых приложений уже можно указывать, на какой порт (к какому из tor) следует обращаться. Например, можно забиндить 3 тора на порты 9050, 9040 и 9030 (аналогично поступить можно и с privoxy).
В дополнение к ответу spinore'а добавлю, что непосредственно интервал перестройки цепочек регулируется следующими параметрами конфига:
С моими мозгами я всё же не понял.
Чем эти 2 параметра отличаются? Слова чуть разные, а сути не пойму. В чём идея? Я представлял себе, что тор по умолчанию создаёт новую цепочку каждые N минут, причём если какая-то из tcp-сессий не закончилась, она продолжает идти по предыдущей цепочке (а вновь открываемые сессии – не знаю – по новой сразу, или ждут, когда старая закончится ).. Итого получаем один параметр. Откуда второй? Или 2-й параметр показывает, что нельзя использовать уже использовавшийся маршрут чаще, чем раз в K минут, если даже таковой вскоре случайно выпадет при генерации новой цепочки (что приведёт к генерациям новых цепочек, пока не будет получена цепочка, не противоречащя условию "К")? Короче, фантазировать долго можно.
Объясняю детали. Если что не понравится, критикуйте разработчиков, а не меня. Во-первых, уточню, что "чистыми" цепочками Tor считает такие, по которым после их открытия не пропускался полезный трафик.
Вообще Tor предпочитает пускать новые соединения через "чистые" цепочки, но если TCP-соединение в данной цепочке закрылось до того, как истёк её MaxCircuitDirtiness, новое соединение может быть также установлено через неё. Если же значение MaxCircuitDirtiness превышено и активных потоков в цепочке уже нет (предполагается, что были), Tor её убивает. (Кстати, есть ещё третий параметр, CircuitIdleTimeout [сек], определяющий, через какое время простоя Tor убьёт даже совершенно "чистые" цепочки.)
Второй параметр, NewCircuitPeriod, определяет, как часто Tor должен проверять, нужны ли новые цепочки и следует ли их построить. Если значение этого параметра слишком завысить, может сложиться ситуация, что все текущие цепочки убиты, а новых нет.