-
Существует ли возможность получить реальное время отклика от хоста при подключении, а также время передачи некоторого объёма данных?
Исходные данные:
- Сокет в неблокирующем режиме (используется WSAEventSelect)
- Несколько десятков потоков, в каждом из которых отдельное подключение
Столкнулся с проблемой оценки времени доступа к различным хостам.
Сокет в неблокируещем режиме для того, чтобы можно было прервать соединение в том же потоке.
Необходимо получать данные о времени ответа сервера.
Так как система достаточно нагружен, то метод временных меток до и после выполнения команды (connect, например), не подходит, так как дополнительный поток может проснуться в произвольный момент времени.
-
> получить реальное время отклика от хоста при подключении
ping?
-
Нужно время именно во время подключения по TCP.
-
Так как система достаточно нагружен, то метод временных меток до и после выполнения команды (connect, например), не подходит, так как дополнительный поток может проснуться в произвольный момент времени.
То есть ты как бы хочешь узнать каким бы было реальное время отклика, если бы ниток была всего одна?
Сделай одну нитку и замерь.
Только что тебе даст эта абстрактная величина, если ниток у тебя много и каждая конкретная может проснуться в произвольный момент времени
-
А что такое "отклик хоста" применительно именно к TCP ?
Как ты вообще мыслишь себе это, если циклограмма алгоритма установления TCP-соединения заведомо включает в себя более одного "отклика" ?
-
> Сделай одну нитку и замерь.
Одна нить не подойдёт. Для обработки нескольких десятков тысяч хостов уйдт неоправданно много времени.
> Сергей М. © (31.03.10 13:25) [4]
> А что такое "отклик хоста" применительно именно к TCP ?Как
> ты вообще мыслишь себе это, если циклограмма алгоритма установления
> TCP-соединения заведомо включает в себя более одного "отклика"
> ?
Предполагаю так:
Если говорить относительно connect, то момент от выдачи connect до срабатывания сигнала события FD_CONNECT.
По поводу чтения - время с момента отправки запроса (системой) и до получения ответа (FD_READ).
-
Одна нить не подойдёт. Для обработки нескольких десятков тысяч хостов уйдт неоправданно много времени.
чего тормозишь-то?
Для замера сделай одну.
Тебя же волнует что когда ниток много, то мерящая нитка может уснуть и проснуться и внести искажения в измерения.
Как замеришь, - включай остальные.
-
только зачем это еще раз задаюсь вопросом?
нарисовать правдивый прогрессбар и сколько времени осталось до конца?
так это пустая затея.
если и рисовать прогресс бар, то в относительно количества общего числа необходимых запросов и количества уже выполненных
-
> чего тормозишь-то?Для замера сделай одну.Тебя же волнует
> что когда ниток много, то мерящая нитка может уснуть и проснуться
> и внести искажения в измерения.Как замеришь, - включай остальные.
>
Так нитки все делают одно и то же. Какой смысл мне включать их по очереди? Я тогда смог бы вообще без доп. потоков обойтись.
> Медвежонок Пятачок © (31.03.10 16:44) [7]
> только зачем это еще раз задаюсь вопросом?
Зачем скажу.
У жены аську украли. Из принципа решил вернуть. Для этого брутфорсер пишу.
Задача со временем - отсеять нерабочие и медлительные HTTPS прокси-сервера из большого списка.
Для этого создаётся порядка 80-100 потоков, в каждом из которых осуществляется подключение к прокси-серверу.
Для того, чтобы отсеять медлительные, хотелось бы поточнее определить время, затраченное на подключение и на приём данных через прокси-сервер.
-
Хотя появилась одна мысль.
Можно попробовать замерить время работы потока в режиме ядра...
-
> аську украли ..решил вернуть. Для этого брутфорсер пишу
Наивный чукотский юноша думает что аськины логин-серверы будут спокойно взирать на многократные массированые неудачные попытки входа с одним и тем же UIN, пусть даже и с разных адресов ?)
-
> Сергей М. © (31.03.10 17:51) [10]
> > аську украли ..решил вернуть. Для этого брутфорсер пишуНаивный
> чукотский юноша думает что аськины логин-серверы будут спокойно
> взирать на многократные массированые неудачные попытки входа
> с одним и тем же UIN, пусть даже и с разных адресов ?)
Ну не знаю. Ну а как же тогда крадут? Разве не так?
Сервера проверяют именно многократные попытки регистрации с оного IP.
Или что-то ещё есть?
-
По крайней мере во время промежуточной отладки не заметил, что была блокировка...
-
Демо © (31.03.10 17:59) [11]
> Ну не знаю. Ну а как же тогда крадут? Разве не так?
Как крадут - не знаю. Мне непонятно - зачем крадут ?
-
> а как же тогда крадут?
В подавляющем большинсве случаев крадут впариванием "жертве" троянов и прочей spy-непотребщины.
> Разве не так?
В очень редких случаях возможно и так.
Но это из разряда выпадения джекпота в лотерее)
-
> Демо © (31.03.10 18:06) [12]
Просто ты не достиг порога.
-
> > Ну не знаю. Ну а как же тогда крадут? Разве не так?Как
> крадут - не знаю. Мне непонятно - зачем крадут ?
Чтобы спамить через них...
-
> Сергей М. © (31.03.10 18:13) [15]
> > Демо © (31.03.10 18:06) [12]Просто ты не достиг порога.
>
Да я готов ждать это время блокировки.
Обработаю эту ситуацию, а после разблокировки снова начну брутить. Хоть десять лет.
-
> В подавляющем большинсве случаев крадут впариванием "жертве"
> троянов и прочей spy-непотребщины.
Вполне и такой варант возможен... По свалкам в инете периодически что она, что я шляемся...
-
Демо © (31.03.10 18:19) [16]
> Чтобы спамить через них...
Странно. А зарегистрировать новый UIN и спамить через него не ? Или спам будет только по контакт-листу ? Нафиг такой спам сдался ?
Кроме всего прочего - а разве не существует "официальной службы восстановления угнанных асек" ? Вроде как где-то когда-то встречал объявления (чуть ли не в спаме), что "поможем, найдем, накажем". Всяко наверное быстрее, чем самому париться.
-
> Кроме всего прочего - а разве не существует
> "официальной службы восстановления угнанных асек" ? Вроде
> как где-то когда-то встречал объявления (чуть ли не в спаме),
> что "поможем, найдем, накажем". Всяко наверное быстрее,
> чем самому париться.
Ситуация такая:
В самом севисе 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
Хочется же максимальной эффективности-)
Чем больше потоков, тем большее процессорное время каждый из них занимает.
А учитывая, зависимость загрузки процессора (и в целом системы) от количества потоков нелинейная, хочется выбрать правильное число;)
-
а что именно сейчас делает нитка в течение своей жизни?
-
Для проверки прокси:
каждый поток:
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')
Вот и всё, собственно.
-
то есть хочешь сказать, что нитка проверяет один-единственный пароль, после чего помирает?
-
> то есть хочешь сказать, что нитка проверяет один-единственный
> пароль, после чего помирает?
Забыл написать, что в цикле выбирается следующий прокси.
Это алгоритм проверки прокси, а не пароля.
-
Проверка пароля - немного отличается алгоритм.
1. Выборка в цикле из общего списка следующего прокси
2. connect к прокси
3. Передача строки на подключение к моему сайту (send 'CONNECT icq.login.com:5190 HTTP/1.1')
4. Ожидание от прокси ответа 'HTTP/1.0 200 Connection established'+#13#10#13#10
5. Ожидание сигнатуры-запроса по протоколу OSCAR
6. Формирование и отправка запроса на подключение с логином/паролем
7. Получение блока данных с ответом от сервера о подключении/отказе и его проверка
-
что-то мне как-то кажется, что создавать брут-нитки надо в количествах ну не больше сотни (если не меньше).
а задачу отыскать сотню быстрых проксей можно поручить одной-двум ниткам.
брут-нитки запускать по мере нахождения очередного быстрого прокси.
-
> а задачу отыскать сотню быстрых проксей можно поручить одной-
> двум ниткам. брут-нитки запускать по мере нахождения очередного
> быстрого прокси.
Хорошая мысль.
Думаю, что можно это так сделать:
Десяток потоков сортируют прокси (в зависимости от количества это может от одной до 10 минут занимать), передаютупорядоченный список на обработку в потоки-бруты, сами продолжают работать с новым списком.
Бруты работают, пока полностью не исчерпают список (независимо от того, медленные или нет прокси), затем переключаются на новый, и так в цикле.
Во время работы можно подкладывать новые списки (либо этот процесс процесс автоматизировать - поиск по сайтам со списками)...
-
стоп время.
посылка пакета
отклик от сервера
стоп время
сверка времен.
-
Если попробовать менее геморройные методы? В саппорт написать? Должен же какой-то саппорт у аси быть?
-
И - почему именно украли? Может просто глюк? У меня с гмэйлом так было - отписал им - восстановили, новый юзер и пасс выслали.
>В интернете почитал - официально восстанавливать - гиблое дело.
Ну, то есть - заранее - похороны? Имхо зря.
-
> Дмитрий Белькевич (01.04.2010 23:34:48) [48]
Воостанавливать, зря
Как с мобильниками, уронил не обращай внимания, иди дальше.
-
> [true]TRIx © (01.04.10 23:01) [46]
> стоп время.
> посылка пакета
> отклик от сервера
> стоп время
> сверка времен.
Вот как раз второе "стоп время" не может быть определено корректно.