Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 3 >
Демо © (2010-03-30 23:00:00)
Существует ли возможность получить реальное время отклика от хоста при подключении, а также время передачи некоторого объёма данных?

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

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

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

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

Демо (2010-04-02 15:05:00) [1]

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

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

Anatoly Podgoretsky (2010-04-02 07:36:00) [2]
> Дмитрий Белькевич (01.04.2010 23:34:48) [48]

Воостанавливать, зря
Как с мобильниками, уронил не обращай внимания, иди дальше.

Дмитрий Белькевич (2010-04-01 23:34:00) [3]
И - почему именно украли? Может просто глюк? У меня с гмэйлом так было - отписал им - восстановили, новый юзер и пасс выслали.

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

Ну, то есть - заранее - похороны? Имхо зря.

Дмитрий Белькевич (2010-04-01 23:31:00) [4]
Если попробовать менее геморройные методы? В саппорт написать? Должен же какой-то саппорт у аси быть?

[true]TRIx (2010-04-01 23:01:00) [5]
стоп время.

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

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

стоп время

сверка времен.

Демо (2010-04-01 17:37:00) [6]

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

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

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

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

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

Медвежонок Пятачок (2010-04-01 17:24:00) [7]
что-то мне как-то кажется, что создавать брут-нитки надо в количествах ну не больше сотни (если не меньше).

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

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

Демо (2010-04-01 16:47:00) [8]
Проверка пароля - немного отличается алгоритм.

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. Получение блока данных с ответом от сервера о подключении/отказе и его проверка

Демо (2010-04-01 16:43:00) [9]

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

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

Это алгоритм проверки прокси, а не пароля.

Медвежонок Пятачок (2010-04-01 16:19:00) [10]
то есть хочешь сказать, что нитка проверяет один-единственный пароль, после чего помирает?

Демо (2010-04-01 16:16:00) [11]
Для проверки прокси:

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

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

Медвежонок Пятачок (2010-04-01 16:01:00) [12]
а что именно сейчас делает нитка в течение своей жизни?

Демо (2010-04-01 15:49:00) [13]

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

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

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

Сергей М. (2010-04-01 14:47:00) [14]

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

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

Медвежонок Пятачок (2010-04-01 14:41:00) [15]
Но как тогда соблюсти баланс между количеством потоков и эффективностью системы для переключения между ними?

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

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

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

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

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

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

Демо (2010-04-01 14:17:00) [16]

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

Думаешь?

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

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

Сергей М. (2010-04-01 13:47:00) [17]

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

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

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

Демо (2010-04-01 10:42:00) [18]
Ладно, спасибо.

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

Медвежонок Пятачок (2010-04-01 09:56:00) [19]
нужно всего лишь изменить скелетный алгоритм перебора и отслеживать текущую производительность нитки на текущем прокси.
если она упала и продолжает тормозить в течение какого-то кванта времени (не случайный затык, а есть тенденция) то переключать нитку в режим поиска нового прокси, после чего продолжить брут со старого места на новом прокси

Сергей М. (2010-04-01 09:15:00) [20]

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

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

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »