Прокси-чекер - доработать и интегрировать с php-скриптом
Прокси-чекер - доработать и интегрировать с php-скриптом
Всем привет!
Чекать прокси внутри скрипта в один поток, писать код для чекинга - это, имхо, какое-то извращение.
Нужно доработать встроенный прокси-чекер, дабы автоматизировать его и обеспечить его взаимодействие с работающим php-скриптом:
1. Прокси-чекер должен уметь автоматически скачивать список проксей с заданного url, причем делать это через установленный в опциях промежуток времени (параллельно с работой скрипта).
2. Прокси-чекер должен уметь автоматически чекать список проксей через установленный в опциях промежуток времени (также параллельно с работой скрипта) и упорядочивать этот список по времени отклика.
3. Прокси-чекер должен отдельно хранить список проксей, заюзанных работающим в настоящий момент скриптом или заюзанных за последний день или последнюю неделю и т. п. (какое из этих "или" использовать - устанавливливается в опциях).
4. Скрипт по команде enable_fastest_proxy() должен получать от прокси-чекера самый быстрый из прочеканных проксей, а по команде enable_nonused_fastest_proxy () - самый быстрый прочеканный из ранее незаюзанных проксей.
Полагаю также, что данные усовершенствования следует внести в прогу в приоритетном порядке, т. к. они будут реально полезны большинству пользователей.
Чекать прокси внутри скрипта в один поток, писать код для чекинга - это, имхо, какое-то извращение.
Нужно доработать встроенный прокси-чекер, дабы автоматизировать его и обеспечить его взаимодействие с работающим php-скриптом:
1. Прокси-чекер должен уметь автоматически скачивать список проксей с заданного url, причем делать это через установленный в опциях промежуток времени (параллельно с работой скрипта).
2. Прокси-чекер должен уметь автоматически чекать список проксей через установленный в опциях промежуток времени (также параллельно с работой скрипта) и упорядочивать этот список по времени отклика.
3. Прокси-чекер должен отдельно хранить список проксей, заюзанных работающим в настоящий момент скриптом или заюзанных за последний день или последнюю неделю и т. п. (какое из этих "или" использовать - устанавливливается в опциях).
4. Скрипт по команде enable_fastest_proxy() должен получать от прокси-чекера самый быстрый из прочеканных проксей, а по команде enable_nonused_fastest_proxy () - самый быстрый прочеканный из ранее незаюзанных проксей.
Полагаю также, что данные усовершенствования следует внести в прогу в приоритетном порядке, т. к. они будут реально полезны большинству пользователей.
Только что в хэлпе заметил класс proxychecker и все с ним связанное. Спасибо.
$proxycheker->get_fastest_proxy($param_proxy=”all”);
$param_proxy = “all” – все прокси в списке
$param_proxy = “good” – только хорошие прокси из списка
$param_proxy = “bad” – только только прокси из списка
$param_proxy = “post” – только Post прокси из списка
$param_proxy = “anonym” – только анонимные прокси из списка
Так вот, надо еще сделать возможность выборки из списка неиспользованных прокси, как я писал в п. 4.
Если этого не сделать, то при постоянной скорости проксей в get_fastest_proxy будет один и тот же прокси, в социалки постить будет невозможно.
Вот поэтому-то я и написал там enable_nonused_fastest_proxy. Ну или в get_fastest_proxy соответствующий параметр добавьте.
$proxycheker->get_fastest_proxy($param_proxy=”all”);
$param_proxy = “all” – все прокси в списке
$param_proxy = “good” – только хорошие прокси из списка
$param_proxy = “bad” – только только прокси из списка
$param_proxy = “post” – только Post прокси из списка
$param_proxy = “anonym” – только анонимные прокси из списка
Так вот, надо еще сделать возможность выборки из списка неиспользованных прокси, как я писал в п. 4.
Если этого не сделать, то при постоянной скорости проксей в get_fastest_proxy будет один и тот же прокси, в социалки постить будет невозможно.
Вот поэтому-то я и написал там enable_nonused_fastest_proxy. Ну или в get_fastest_proxy соответствующий параметр добавьте.
Сейчас подумал - можно сделать и попроще, для этого надо просто добавить в get_fastest_proxy возможность случайной выборки прокси из n штук (или n %) самых быстрых прокси в списке. n - указывать в качестве параметра в вызове функции.
Конечно, лучше всего сделать, как я написал в предыдущей мессаге, но, если список проксей большой, функциональность будет практически та же, а в проге список заюзанных проксей не придется хранить.
Конечно, лучше всего сделать, как я написал в предыдущей мессаге, но, если список проксей большой, функциональность будет практически та же, а в проге список заюзанных проксей не придется хранить.
Не, я тут не согласен. Вот например, у awm огромная разница в скоростях на разных шлюзах. Если брать из списка полудохлые - то сложные скрипты реально глючить начинают.medar2 писал(а):Да вообще fastest не нужно брать. Нужно просто взять другой. Нет нужды, чтобы он был быстрым, лишь бы работал. А вот нужда, чтобы он был новым - есть.
мы еще будем много работать над улучшениями прокси чекера, если есть предложения, просьба писать тут, потом обобщим и сделаем чтобы все было как надо ))
2 месяца работали над хелпом ну и по мелочи, а также еще одним полезным проектом, часть которого скоро будет представлена в хумане, в планах развитие до начала середине июля по максимуму, потом небольшой отпуск у разработчиков будет, я надеюсь ))
так что предложения что сделать сюда на форум или в саппорт - сделаем ))
2 месяца работали над хелпом ну и по мелочи, а также еще одним полезным проектом, часть которого скоро будет представлена в хумане, в планах развитие до начала середине июля по максимуму, потом небольшой отпуск у разработчиков будет, я надеюсь ))
так что предложения что сделать сюда на форум или в саппорт - сделаем ))
Сегодня поставил 4.0.9. Как-то сыровато сделано.
Хэлп по проксичекеру (кроме описания функций) имеется?
$proxycheker->run() вообще работает у кого?
Просто когда вставляю $proxycheker->run(); в скрипт, ничего не происходит.
Потом когда скрипт финишировал, захожу в проксичекер через интерфейс, и вижу - опа, они там все добавились, но не проверены, нажимаю кнопочку "Запустить проверку" - проверяются, так отчего же они в скрипте не проверились?...
Хэлп по проксичекеру (кроме описания функций) имеется?
$proxycheker->run() вообще работает у кого?
Просто когда вставляю $proxycheker->run(); в скрипт, ничего не происходит.
Потом когда скрипт финишировал, захожу в проксичекер через интерфейс, и вижу - опа, они там все добавились, но не проверены, нажимаю кнопочку "Запустить проверку" - проверяются, так отчего же они в скрипте не проверились?...
Не нахожу функции $proxycheker->add_proxy_from_file($path);
add_proxy_from_url() не смотрел, но наверное тоже нет.
Которая заявлена в справке и должна быть в версии 12, но её там не вижу.
И еще, с саппортом по аське разговаривал уже месяц назад, пока не риализовано.
Это важнее:
При добавлении в чекер соксов в формате "socks=ip:port"
подстрока "socks=" автоматически обрезается. Поправьте пожалуйста, сам посмотрел, но не нашёл где режится. Просто без этого приходится пользоваться своим чекером и ваш класс бесполезен. Дел на 5 мин, как я понимаю.
add_proxy_from_url() не смотрел, но наверное тоже нет.
Которая заявлена в справке и должна быть в версии 12, но её там не вижу.
И еще, с саппортом по аське разговаривал уже месяц назад, пока не риализовано.
Это важнее:
При добавлении в чекер соксов в формате "socks=ip:port"
подстрока "socks=" автоматически обрезается. Поправьте пожалуйста, сам посмотрел, но не нашёл где режится. Просто без этого приходится пользоваться своим чекером и ваш класс бесполезен. Дел на 5 мин, как я понимаю.
Re: Прокси-чекер - доработать и интегрировать с php-скриптом
Даже не ожидал, что у вас будут такие траблы с проксичекером.
Тогда, может быть лучше просто выделить его в отдельную утилиту?
Чтоб эта прога работала совершенно независимо от всех скриптов - через заданный промежуток времени автоматом скачивала прокси-лист с заданного url, потом сразу его чекала и сохраняла в заданный файл. А потом скрипты уже сами будут брать прокси из этого файла (http://www.umaxforum.com/showthread.php?t=34760).
Посколько это отдельная прога будет, то не нужно будет парится с ее интеграцией в хуман и до следующего апдейта не ждать.
Ведь реально нужная вещь. Из-за отсутствия (ненадежности) прокси-чекера скрипты приходится усложнять.
И как же это так - с соксами не работает? Зачем тогда вообще было делать? На бесплатных проксях далеко не уедешь. А почти все платные прокси в виде соксов сейчас поставляются.
Тогда, может быть лучше просто выделить его в отдельную утилиту?
Чтоб эта прога работала совершенно независимо от всех скриптов - через заданный промежуток времени автоматом скачивала прокси-лист с заданного url, потом сразу его чекала и сохраняла в заданный файл. А потом скрипты уже сами будут брать прокси из этого файла (http://www.umaxforum.com/showthread.php?t=34760).
Посколько это отдельная прога будет, то не нужно будет парится с ее интеграцией в хуман и до следующего апдейта не ждать.
Ведь реально нужная вещь. Из-за отсутствия (ненадежности) прокси-чекера скрипты приходится усложнять.
И как же это так - с соксами не работает? Зачем тогда вообще было делать? На бесплатных проксях далеко не уедешь. А почти все платные прокси в виде соксов сейчас поставляются.