> Кроме всего прочего - а разве не существует
> "официальной службы восстановления угнанных асек" ? Вроде
> как где-то когда-то встречал объявления (чуть ли не в спаме),
>  что "поможем, найдем, накажем". Всяко наверное быстрее,
>  чем самому париться.


Ситуация такая:
В самом севисе ICQ где-то в районе 2006г. были сбои, связанные с обновлением ПО, версий протокола и пр.
В это время для идентификации пользователя при восстановлении пароля прикрутили дополнительные вопросы.
После этого некоторые UIN, зарегистрированные очень давно, перестали при восстановлении пароля воспринимать вопросы, а также primary email, с помощью которого можно было бы восстановить утраченный номер.
Вот такой и был номер. У него и праймари правильный, но пароль на адрес, в нём указанный, не высылается.
В интернете почитал - официально восстанавливать - гиблое дело.
Да и не столько уже необходимость сколько упрямство...

Да я готов ждать это время блокировки.
Обработаю эту ситуацию, а после разблокировки снова начну брутить. Хоть десять лет.

И в чем тогда тайный смысл замера времени одной абстрактной нитки?

> И в чем тогда тайный смысл замера времени одной абстрактной
> нитки?


Смысл в том, чтобы отбросить прокси-сервера, которые слишком медлительные.
Например, смысл использовать прокси-сервер, подключение к которому происходит дольше, чем за 1-2 секунды?
Это лишь инструмент для дальнейшей работы.
Перебрать предстоит э-э-э... очень большое количество вариантов, и хочется выйти хотя бы на число 1000 вариантов в секунду (как минимум).
Понятно, что с одного ПК то достаточно сложно сделать, но думаю, что удастся запустить с разных компов и подсетей хотя бы несколько согласованных между собой экземпляров.

> В это время для идентификации пользователя при восстановлении
> пароля прикрутили дополнительные вопросы.


насколько я помню, это было аж в 1999-м году, дополнительные вопросы

> Игорь Шевченко ©   (31.03.10 20:37) [23]
> > В это время для идентификации пользователя при восстановлении
> > пароля прикрутили дополнительные вопросы.насколько я помню,
>  это было аж в 1999-м году, дополнительные вопросы


Может и раньше, конечно...
Прочитал про эту проблему буквально пару недель назад.

> Перебрать предстоит э-э-э... очень большое количество вариантов,
>  и хочется выйти хотя бы на число 1000 вариантов в секунду
> (как минимум)


Не выйдешь.
Даже не думай.

> Сергей М. ©   (31.03.10 22:16) [25]
> > Перебрать предстоит э-э-э... очень большое количество
> вариантов,>  и хочется выйти хотя бы на число 1000 вариантов
> в секунду > (как минимум)Не выйдешь.Даже не думай.


А ты как думаешь - какое число реально?

Ни о каких "реалиях" в твоей задаче рассуждать нет смысла.
Можно получить решение за пол-секунды, перебрав не более десятка вариантов, а можно искать и так и не найти его до седых фаберже)

Касаемо же тех самых анонимно-халявных прокси, на которые ты уповаешь - тут твоя ошибка в другом: даже если коннект к прокси произойдет со скоростью света, нет никакой гарантии, что последующий инф.обмен с "целью" при посредничестве данного прокси будет происходить с той же скоростью.
И потом - львиную долю драгоценного времени ты будешь тратить на поиск и проверку прокси-серверов, коих для решения задачи в обозримое время потребуется всякоразных великое множество, а не сотня-другая, фигурирующая во всяких там публичных списках сомнительной халявы)

> И потом - львиную долю драгоценного времени ты будешь тратить
> на поиск и проверку прокси-серверов, коих для решения задачи
> в обозримое время потребуется всякоразных великое множество,
>  а не сотня-другая, фигурирующая во всяких там публичных
> списках сомнительной халявы)


Ну рабочих прокси не так много конечно.
Но из огромного списка присутствуют и такие, которые работают практически постоянно.
Просто одни сервера периодически "проваливаются",.
Поэтому скорость будет явно нелинейной, придётся списки постоянно подпитывать свежими серверами, убирать плохие...

Да пусть хоть 10-15 лет перебор идёт. Мне не к спеху...-)

Смысл в том, чтобы отбросить прокси-сервера, которые слишком медлительные.

Да пусть хоть 10-15 лет перебор идёт. Мне не к спеху...-)

Бессмысленно.
Ибо найденные "быстрые" прокси (быстрые на момент проверки) через час могут превратиться в медленные.

> Смысл в том, чтобы отбросить прокси-сервера, которые слишком
> медлительные.Да пусть хоть 10-15 лет перебор идёт. Мне не
> к спеху...-)Бессмысленно.Ибо найденные "быстрые" прокси
> (быстрые на момент проверки) через час могут превратиться
> в медленные.


Имеет место и такое быть.
Может и не стоит выбирать лучшие, а просто брать все подряд.

> Может и не стоит выбирать лучшие, а просто брать все подряд.


Ну тогда изначальный вопрос теряет всякий смысл.

нужно всего лишь изменить скелетный алгоритм перебора и отслеживать текущую производительность нитки на текущем прокси.
если она упала и продолжает тормозить в течение какого-то кванта времени (не случайный затык, а есть тенденция) то переключать нитку в режим поиска нового прокси, после чего продолжить брут со старого места на новом прокси

Ладно, спасибо.

Похоже, что если способ есть, то он далеко не очевиден, и закопан в недра системы...

> и закопан в недра системы


Причем здесь вообще "недра системы" - не понятно ..

imho, время, требуемое системе на "пробуждение" потока, на переключение контекстов потоков и на свопинг в сравнении со временами "откликов" этих самых прокси - это просто ловля блох

> imho, время, требуемое системе на "пробуждение" потока,
> на переключение контекстов потоков и на свопинг в сравнении
> со временами "откликов" этих самых прокси - это просто ловля
> блох


Думаешь?

Но как тогда соблюсти баланс между количеством потоков и эффективностью системы для  переключения между ними?
Большую часть времени поток будет спать, ожидая ответа от удалённого хоста.

Попробовать засечь время работы одного потока в user-mode, и вычислить примерно - какое количество потоков суммарно будут в среднем дотягивать до 100%...

Но как тогда соблюсти баланс между количеством потоков и эффективностью системы для  переключения между ними?

число потоков равно числу проксей, через которые ты решил работать
каждый поток получает свой диапазон перебора.

дальше дело свободный полет фантазии архитектора системы.

можно анализировать производительность конкретного прокси.
если она упала, переключать нитку на другой прокси.

можно делать анализ - приводит ли увеличение ниток (используемых прокси) к увеличению числа обработанных запросов в секнду.

можно принимать решение увеличивать число ниток пока есть рост.
можно принимать решение снизить число ниток если нитки стали мешать вебсерфингу

можно все что хочешь.

> Большую часть времени поток будет спать


Тогда о чем забота ?
Система не квантует  потоки, которые "спят" или находятся в kernel-mode

> Сергей М. ©   (01.04.10 14:47) [37]
> > Большую часть времени поток будет спатьТогда о чем забота
> ?Система не квантует  потоки, которые "спят" или находятся
> в kernel-mode


Хочется же максимальной эффективности-)

Чем больше потоков, тем большее процессорное время каждый из них занимает.
А учитывая, зависимость загрузки процессора (и в целом системы) от количества потоков нелинейная, хочется выбрать правильное число;)

а что именно сейчас делает нитка в течение своей жизни?