Конференция "Сети" » Определение реального времени доступа к хосту
 
  • Демо © (30.03.10 23:00) [0]
    Существует ли возможность получить реальное время отклика от хоста при подключении, а также время передачи некоторого объёма данных?

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

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

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

    Сокет в неблокируещем режиме для того, чтобы можно было прервать соединение в том же потоке.
    Необходимо получать данные о времени ответа сервера.
    Так как система достаточно нагружен, то метод временных меток до и после выполнения команды (connect, например), не подходит, так как дополнительный поток может проснуться в произвольный момент времени.
  • brother © (31.03.10 06:09) [1]
    > получить реальное время отклика от хоста при подключении

    ping?
  • Демо © (31.03.10 12:22) [2]
    Нужно время именно во время подключения по TCP.
  • Медвежонок Пятачок © (31.03.10 13:21) [3]
    Так как система достаточно нагружен, то метод временных меток до и после выполнения команды (connect, например), не подходит, так как дополнительный поток может проснуться в произвольный момент времени.

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

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

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

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


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


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


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

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

    По поводу чтения - время с момента отправки запроса (системой) и до получения ответа (FD_READ).
  • Медвежонок Пятачок © (31.03.10 16:36) [6]
    Одна нить не подойдёт. Для обработки нескольких десятков тысяч хостов уйдт неоправданно много времени.

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

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

    Как замеришь, - включай остальные.
  • Медвежонок Пятачок © (31.03.10 16:44) [7]
    только зачем это еще раз задаюсь вопросом?
    нарисовать правдивый прогрессбар и сколько времени осталось до конца?
    так это пустая затея.
    если и рисовать прогресс бар, то в относительно количества общего числа необходимых запросов и количества уже выполненных
  • Демо © (31.03.10 17:27) [8]

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


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


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


    Зачем скажу.

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

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

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

    Для того, чтобы отсеять медлительные, хотелось бы поточнее определить время, затраченное на подключение и на приём данных через прокси-сервер.
  • Демо © (31.03.10 17:36) [9]
    Хотя появилась одна мысль.
    Можно попробовать замерить время работы потока в режиме ядра...
  • Сергей М. © (31.03.10 17:51) [10]

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


    Наивный чукотский юноша думает что аськины логин-серверы будут спокойно взирать на многократные массированые неудачные попытки входа с одним и тем же UIN, пусть даже и с разных адресов ?)
  • Демо © (31.03.10 17:59) [11]

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


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

    Сервера проверяют именно многократные попытки регистрации с оного IP.
    Или что-то ещё есть?
  • Демо © (31.03.10 18:06) [12]
    По крайней мере во время промежуточной отладки не заметил, что была блокировка...
  • Игорь Шевченко © (31.03.10 18:07) [13]
    Демо ©   (31.03.10 17:59) [11]


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


    Как крадут - не знаю. Мне непонятно - зачем крадут ?
  • Сергей М. © (31.03.10 18:09) [14]
    > а как  же тогда крадут?

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

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

    В очень редких случаях возможно и так.
    Но это из разряда выпадения джекпота в лотерее)
  • Сергей М. © (31.03.10 18:13) [15]

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


    Просто ты не достиг порога.
  • Демо © (31.03.10 18:19) [16]

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


    Чтобы спамить через них...
  • Демо © (31.03.10 18:21) [17]

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


    Да я готов ждать это время блокировки.
    Обработаю эту ситуацию, а после разблокировки снова начну брутить. Хоть десять лет.
  • Демо © (31.03.10 18:23) [18]

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


    Вполне и такой варант возможен... По свалкам в инете периодически что она, что я шляемся...
  • Игорь Шевченко © (31.03.10 18:51) [19]
    Демо ©   (31.03.10 18:19) [16]


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


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

    Кроме всего прочего - а разве не существует "официальной службы восстановления угнанных асек" ? Вроде как где-то когда-то встречал объявления (чуть ли не в спаме), что "поможем, найдем, накажем". Всяко наверное быстрее, чем самому париться.
  • Демо © (31.03.10 19:01) [20]

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


    Ситуация такая:
    В самом севисе ICQ где-то в районе 2006г. были сбои, связанные с обновлением ПО, версий протокола и пр.
    В это время для идентификации пользователя при восстановлении пароля прикрутили дополнительные вопросы.
    После этого некоторые UIN, зарегистрированные очень давно, перестали при восстановлении пароля воспринимать вопросы, а также primary email, с помощью которого можно было бы восстановить утраченный номер.
    Вот такой и был номер. У него и праймари правильный, но пароль на адрес, в нём указанный, не высылается.
    В интернете почитал - официально восстанавливать - гиблое дело.
    Да и не столько уже необходимость сколько упрямство...
  • Медвежонок Пятачок © (31.03.10 19:20) [21]
    Да я готов ждать это время блокировки.
    Обработаю эту ситуацию, а после разблокировки снова начну брутить. Хоть десять лет.


    И в чем тогда тайный смысл замера времени одной абстрактной нитки?
  • Демо © (31.03.10 19:43) [22]

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


    Смысл в том, чтобы отбросить прокси-сервера, которые слишком медлительные.
    Например, смысл использовать прокси-сервер, подключение к которому происходит дольше, чем за 1-2 секунды?
    Это лишь инструмент для дальнейшей работы.
    Перебрать предстоит э-э-э... очень большое количество вариантов, и хочется выйти хотя бы на число 1000 вариантов в секунду (как минимум).
    Понятно, что с одного ПК то достаточно сложно сделать, но думаю, что удастся запустить с разных компов и подсетей хотя бы несколько согласованных между собой экземпляров.
  • Игорь Шевченко © (31.03.10 20:37) [23]

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


    насколько я помню, это было аж в 1999-м году, дополнительные вопросы
  • Демо © (31.03.10 21:23) [24]

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


    Может и раньше, конечно...
    Прочитал про эту проблему буквально пару недель назад.
  • Сергей М. © (31.03.10 22:16) [25]

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


    Не выйдешь.
    Даже не думай.
  • Демо © (31.03.10 22:57) [26]

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


    А ты как думаешь - какое число реально?
  • Сергей М. © (31.03.10 23:18) [27]
    Ни о каких "реалиях" в твоей задаче рассуждать нет смысла.
    Можно получить решение за пол-секунды, перебрав не более десятка вариантов, а можно искать и так и не найти его до седых фаберже)

    Касаемо же тех самых анонимно-халявных прокси, на которые ты уповаешь - тут твоя ошибка в другом: даже если коннект к прокси произойдет со скоростью света, нет никакой гарантии, что последующий инф.обмен с "целью" при посредничестве данного прокси будет происходить с той же скоростью.
    И потом - львиную долю драгоценного времени ты будешь тратить на поиск и проверку прокси-серверов, коих для решения задачи в обозримое время потребуется всякоразных великое множество, а не сотня-другая, фигурирующая во всяких там публичных списках сомнительной халявы)
  • Демо © (01.04.10 00:04) [28]

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


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

    Да пусть хоть 10-15 лет перебор идёт. Мне не к спеху...-)
  • Медвежонок Пятачок © (01.04.10 00:22) [29]
    Смысл в том, чтобы отбросить прокси-сервера, которые слишком медлительные.

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

    Бессмысленно.
    Ибо найденные "быстрые" прокси (быстрые на момент проверки) через час могут превратиться в медленные.
  • Демо © (01.04.10 00:30) [30]

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


    Имеет место и такое быть.
    Может и не стоит выбирать лучшие, а просто брать все подряд.
  • Сергей М. © (01.04.10 09:15) [31]

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


    Ну тогда изначальный вопрос теряет всякий смысл.
  • Медвежонок Пятачок © (01.04.10 09:56) [32]
    нужно всего лишь изменить скелетный алгоритм перебора и отслеживать текущую производительность нитки на текущем прокси.
    если она упала и продолжает тормозить в течение какого-то кванта времени (не случайный затык, а есть тенденция) то переключать нитку в режим поиска нового прокси, после чего продолжить брут со старого места на новом прокси
  • Демо © (01.04.10 10:42) [33]
    Ладно, спасибо.

    Похоже, что если способ есть, то он далеко не очевиден, и закопан в недра системы...
  • Сергей М. © (01.04.10 13:47) [34]

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


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

    imho, время, требуемое системе на "пробуждение" потока, на переключение контекстов потоков и на свопинг в сравнении со временами "откликов" этих самых прокси - это просто ловля блох
  • Демо © (01.04.10 14:17) [35]

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


    Думаешь?

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

    Попробовать засечь время работы одного потока в user-mode, и вычислить примерно - какое количество потоков суммарно будут в среднем дотягивать до 100%...
  • Медвежонок Пятачок © (01.04.10 14:41) [36]
    Но как тогда соблюсти баланс между количеством потоков и эффективностью системы для  переключения между ними?

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

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

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

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

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

    можно все что хочешь.
  • Сергей М. © (01.04.10 14:47) [37]

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


    Тогда о чем забота ?
    Система не квантует  потоки, которые "спят" или находятся в kernel-mode
  • Демо © (01.04.10 15:49) [38]

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


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

    Чем больше потоков, тем большее процессорное время каждый из них занимает.
    А учитывая, зависимость загрузки процессора (и в целом системы) от количества потоков нелинейная, хочется выбрать правильное число;)
  • Медвежонок Пятачок © (01.04.10 16:01) [39]
    а что именно сейчас делает нитка в течение своей жизни?
  • Демо © (01.04.10 16:16) [40]
    Для проверки прокси:

    каждый поток:
    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')

    Вот и всё, собственно.
  • Медвежонок Пятачок © (01.04.10 16:19) [41]
    то есть хочешь сказать, что нитка проверяет один-единственный пароль, после чего помирает?
  • Демо © (01.04.10 16:43) [42]

    > то есть хочешь сказать, что нитка проверяет один-единственный
    > пароль, после чего помирает?


    Забыл написать, что в цикле выбирается следующий прокси.

    Это алгоритм проверки прокси, а не пароля.
  • Демо © (01.04.10 16:47) [43]
    Проверка пароля - немного отличается алгоритм.

    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. Получение блока данных с ответом от сервера о подключении/отказе и его проверка
  • Медвежонок Пятачок © (01.04.10 17:24) [44]
    что-то мне как-то кажется, что создавать брут-нитки надо в количествах ну не больше сотни (если не меньше).

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

    брут-нитки запускать по мере нахождения очередного быстрого прокси.
  • Демо © (01.04.10 17:37) [45]

    > а задачу отыскать сотню быстрых проксей можно поручить одной-
    > двум ниткам. брут-нитки запускать по мере нахождения очередного
    > быстрого прокси.


    Хорошая мысль.

    Думаю, что можно это так сделать:

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

    Бруты работают, пока полностью не исчерпают список (независимо от того, медленные или нет прокси), затем переключаются на новый, и так в цикле.
    Во время работы можно подкладывать новые списки (либо этот процесс процесс автоматизировать - поиск по сайтам со списками)...
  • [true]TRIx © (01.04.10 23:01) [46]
    стоп время.

    посылка пакета

    отклик от сервера

    стоп время

    сверка времен.
  • Дмитрий Белькевич (01.04.10 23:31) [47]
    Если попробовать менее геморройные методы? В саппорт написать? Должен же какой-то саппорт у аси быть?
  • Дмитрий Белькевич (01.04.10 23:34) [48]
    И - почему именно украли? Может просто глюк? У меня с гмэйлом так было - отписал им - восстановили, новый юзер и пасс выслали.

    >В интернете почитал - официально восстанавливать - гиблое дело.

    Ну, то есть - заранее - похороны? Имхо зря.
  • Anatoly Podgoretsky © (02.04.10 07:36) [49]
    > Дмитрий Белькевич  (01.04.2010 23:34:48)  [48]

    Воостанавливать, зря
    Как с мобильниками, уронил не обращай внимания, иди дальше.
  • Демо © (02.04.10 15:05) [50]

    > [true]TRIx ©   (01.04.10 23:01) [46]
    > стоп время.
    > посылка пакета
    > отклик от сервера
    > стоп время
    > сверка времен.


    Вот как раз второе "стоп время" не может быть определено корректно.
 
Конференция "Сети" » Определение реального времени доступа к хосту
Есть новые Нет новых   [134437   +30][b:0][p:0.002]