Определение реального времени доступа к хосту

← →
Демо © (2010-03-30 23:00) [0]

Существует ли возможность получить реальное время отклика от хоста при подключении, а также время передачи некоторого объёма данных?

Исходные данные:

- Сокет в неблокирующем режиме (используется WSAEventSelect)
- Несколько десятков потоков, в каждом из которых отдельное подключение

Столкнулся с проблемой оценки времени доступа к различным хостам.

Сокет в неблокируещем режиме для того, чтобы можно было прервать соединение в том же потоке.
Необходимо получать данные о времени ответа сервера.
Так как система достаточно нагружен, то метод временных меток до и после выполнения команды (connect, например), не подходит, так как дополнительный поток может проснуться в произвольный момент времени.

← →
brother © (2010-03-31 06:09) [1]

> получить реальное время отклика от хоста при подключении

ping?

← →
Демо © (2010-03-31 12:22) [2]

Нужно время именно во время подключения по TCP.

← →
Медвежонок Пятачок © (2010-03-31 13:21) [3]

Так как система достаточно нагружен, то метод временных меток до и после выполнения команды (connect, например), не подходит, так как дополнительный поток может проснуться в произвольный момент времени.

То есть ты как бы хочешь узнать каким бы было реальное время отклика, если бы ниток была всего одна?

Сделай одну нитку и замерь.

Только что тебе даст эта абстрактная величина, если ниток у тебя много и каждая конкретная может проснуться в произвольный момент времени

← →
Сергей М. © (2010-03-31 13:25) [4]

А что такое "отклик хоста" применительно именно к TCP ?
Как ты вообще мыслишь себе это, если циклограмма алгоритма установления TCP-соединения заведомо включает в себя более одного "отклика" ?

← →
Демо © (2010-03-31 15:08) [5]

> Сделай одну нитку и замерь.

Одна нить не подойдёт. Для обработки нескольких десятков тысяч хостов уйдт неоправданно много времени.

> Сергей М. © (31.03.10 13:25) [4]
> А что такое "отклик хоста" применительно именно к TCP ?Как
> ты вообще мыслишь себе это, если циклограмма алгоритма установления
> TCP-соединения заведомо включает в себя более одного "отклика"
> ?

Предполагаю так:

Если говорить относительно connect, то момент от выдачи connect до срабатывания сигнала события FD_CONNECT.

По поводу чтения - время с момента отправки запроса (системой) и до получения ответа (FD_READ).

← →
Медвежонок Пятачок © (2010-03-31 16:36) [6]

Одна нить не подойдёт. Для обработки нескольких десятков тысяч хостов уйдт неоправданно много времени.

чего тормозишь-то?

Для замера сделай одну.
Тебя же волнует что когда ниток много, то мерящая нитка может уснуть и проснуться и внести искажения в измерения.

Как замеришь, - включай остальные.

← →
Медвежонок Пятачок © (2010-03-31 16:44) [7]

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

← →
Демо © (2010-03-31 17:27) [8]

> чего тормозишь-то?Для замера сделай одну.Тебя же волнует
> что когда ниток много, то мерящая нитка может уснуть и проснуться
> и внести искажения в измерения.Как замеришь, - включай остальные.
>

Так нитки все делают одно и то же. Какой смысл мне включать их по очереди? Я тогда смог бы вообще без доп. потоков обойтись.

> Медвежонок Пятачок © (31.03.10 16:44) [7]
> только зачем это еще раз задаюсь вопросом?

Зачем скажу.

У жены аську украли. Из принципа решил вернуть. Для этого брутфорсер пишу.

Задача со временем - отсеять нерабочие и медлительные HTTPS прокси-сервера из большого списка.

Для этого создаётся порядка 80-100 потоков, в каждом из которых осуществляется подключение к прокси-серверу.

Для того, чтобы отсеять медлительные, хотелось бы поточнее определить время, затраченное на подключение и на приём данных через прокси-сервер.

← →
Демо © (2010-03-31 17:36) [9]

Хотя появилась одна мысль.
Можно попробовать замерить время работы потока в режиме ядра...

← →
Сергей М. © (2010-03-31 17:51) [10]

> аську украли ..решил вернуть. Для этого брутфорсер пишу

Наивный чукотский юноша думает что аськины логин-серверы будут спокойно взирать на многократные массированые неудачные попытки входа с одним и тем же UIN, пусть даже и с разных адресов ?)

← →
Демо © (2010-03-31 17:59) [11]

> Сергей М. © (31.03.10 17:51) [10]
> > аську украли ..решил вернуть. Для этого брутфорсер пишуНаивный
> чукотский юноша думает что аськины логин-серверы будут спокойно
> взирать на многократные массированые неудачные попытки входа
> с одним и тем же UIN, пусть даже и с разных адресов ?)

Ну не знаю. Ну а как же тогда крадут? Разве не так?

Сервера проверяют именно многократные попытки регистрации с оного IP.
Или что-то ещё есть?

← →
Демо © (2010-03-31 18:06) [12]

По крайней мере во время промежуточной отладки не заметил, что была блокировка...

← →
Игорь Шевченко © (2010-03-31 18:07) [13]

Демо © (31.03.10 17:59) [11]

> Ну не знаю. Ну а как же тогда крадут? Разве не так?

Как крадут - не знаю. Мне непонятно - зачем крадут ?

← →
Сергей М. © (2010-03-31 18:09) [14]

> а как же тогда крадут?

В подавляющем большинсве случаев крадут впариванием "жертве" троянов и прочей spy-непотребщины.

> Разве не так?

В очень редких случаях возможно и так.
Но это из разряда выпадения джекпота в лотерее)

← →
Сергей М. © (2010-03-31 18:13) [15]

> Демо © (31.03.10 18:06) [12]

Просто ты не достиг порога.

← →
Демо © (2010-03-31 18:19) [16]

> > Ну не знаю. Ну а как же тогда крадут? Разве не так?Как
> крадут - не знаю. Мне непонятно - зачем крадут ?

Чтобы спамить через них...

← →
Демо © (2010-03-31 18:21) [17]

> Сергей М. © (31.03.10 18:13) [15]
> > Демо © (31.03.10 18:06) [12]Просто ты не достиг порога.
>

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

← →
Демо © (2010-03-31 18:23) [18]

> В подавляющем большинсве случаев крадут впариванием "жертве"
> троянов и прочей spy-непотребщины.

Вполне и такой варант возможен... По свалкам в инете периодически что она, что я шляемся...

← →
Игорь Шевченко © (2010-03-31 18:51) [19]

Демо © (31.03.10 18:19) [16]

> Чтобы спамить через них...

Странно. А зарегистрировать новый UIN и спамить через него не ? Или спам будет только по контакт-листу ? Нафиг такой спам сдался ?

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

← →
Демо © (2010-03-31 19:01) [20]

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

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

← →
Медвежонок Пятачок © (2010-03-31 19:20) [21]

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

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

← →
Демо © (2010-03-31 19:43) [22]

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

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

← →
Игорь Шевченко © (2010-03-31 20:37) [23]

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

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

← →
Демо © (2010-03-31 21:23) [24]

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

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

← →
Сергей М. © (2010-03-31 22:16) [25]

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

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

← →
Демо © (2010-03-31 22:57) [26]

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

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

← →
Сергей М. © (2010-03-31 23:18) [27]

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

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

← →
Демо © (2010-04-01 00:04) [28]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Думаешь?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для проверки прокси:

каждый поток:
1. Выборка из общего списка следующего прокси (с синхронизацией, конечно)
2. connect к прокси
3. Передача строки на подключение к моему сайту (send "CONNECT <HOST:PORT HTTP/1.1")
4. Ожидание от прокси ответа "HTTP/1.0 200 Connection established"+#13#10#13#10
5. Ожидание ответа моего сервера
6. Поиск сингнатуры в ответе (Например, со своего сервера я получаю строку "testproxy")

Вот и всё, собственно.

Определение реального времени доступа к хосту Найти похожие ветки