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

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

- Сокет в неблокирующем режиме (используется 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 и спамить через него не ? Или спам будет только по контакт-листу ? Нафиг такой спам сдался ?

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