Многократно уже поднимались темы относительно встроенного в ЗП Проксичекера, в целом, программа хорошая, но там довольно много мелких недоработок, которые достаточно назойливо досаждают.
Никаких особых причин для того, чтобы НЕ исправлять эти недоработки я не вижу. Сейчас он работает по принципу - как-то работает и ладно, лишь бы крашей не было.
В отличие от ЗП движок непосредственно Проксичекера постоянно обновлять не надо, достаточно один раз довести до ума все существующие возможности, и продукт был бы идеальным, если конечно разработчики заинтересованы в том, чтобы сделать идеальный продукт, и если сам процесс обсуждения пользователями одних и тех же недоработок не доставляет удовольствия.
Попробую собрать все накопившиеся пожелания, которые уже давно и пока безуспешно хочется видеть в Проксичекере ЗПостера:
1. Что выдает гугл, если ввести адрес и порт прокси в поиске? Гугл выдает список страниц, на которых данный прокси, так или иначе упоминался.
При переходе на эти страницы в браузере, типа Оперы, мы довольно часто можем увидеть не только пост со списком прокси, где лежит и наш искомый прокси, но и обратить внимание на то, то сайт, или его конкретный раздел имеет РСС-ленту.
Нажимаем значок РСС и примерно в половине случаев обнаруживаем не один пост, а целую РСС-ленту, которая имеет ряд неоспоримых преимуществ:
- она содержит не один, а множество постов с проксями, то, как минимум, есть несколько списков прокси;
- как правило, на гораздо легче, чем страницы сайта, не содержит лишнего стилистического и графического оформления - уменьшается трафик.
Эти страницы РСС в гугле, как правило, не находятся и не отображаются, но легко могут быть найдены при заходе на соответствующую страницу через браузер, поддерживающий поиск РСС, то есть, насколько я понимаю, их несложно найти регулярками по сорсу страницы.
Проксичекер имеет встроенный автопоиск источников прокси, но он абсолютно не задействует эти возможности.
Было бы очень уместным добавить возможность автонахождения и автодобавления рсс-лент с найденных форумов, отдельных постов, отдельных категорий форумов, блогов, где публикуются прокси. Можно было бы даже реализовать это на уровне пользовательских регулярок для поиска этих самых лент.
Это очень хороший источник поиска бесплатных работающих проксей.
2. Многие сайты выдают списки прокси в, например, такого рода форматах:
http://www.proxiki.com/spisok10-03-2016
http://www.proxyashki.ru/socks5/2016-socks-02-17
Эти форматы содержат дату списка и при подстановке сегодняшней даты выдают актуальный список именно на сегодняшний день.
Проксичекер не имеет возможности выкачивать эти списки прокси, так как его списки источников статичны и будут все время выкачивать один и тот же список на заданную дату, который устаревает на следующий день.
Было бы здорово добавить возможность подстановки в урл списка прокси, как минимум, дат, а лучше еще и регулярок, это позволит получать каждый день актуальный список прокси с таких сайтов.
3. При пользовании бесплатными источниками прокси большая часть скачанных прокси, у меня процентов 70-80, находятся неанонимными, прозрачными.
Практическая значимость таких прокси для большинства пользователей программы нулевая.
Тем не менее, эти прокси:
- занимают место в списке, например, когда у вас стоит ограничение собирать 10000 проксей и останавливать потоки чекера, по факту вы получите неизвестное заранее неопределенное количество анонимных прокси, так как большую часть займет сколько-то прозрачных прокси. Нужного количества анонимных прокси вы не получаете;
- тратят ресурсы компьютера на различные проверки - на конкретные урл, на скорость, повторные проверки и т.д.
Необходим фильтр на стадии отбора прокси в список живых, который позволял бы отсеять прозрачные прокси сразу, до включения в список.
А лучше продублировать входные фильтры, аналогичные существующим фильтрам отбора прокси, чтобы каждый пользователь мог решить для себя, какие прокси ему не нужны вообще, а какие нужны в живом списке.
4. Рейтинг прокси - система звезд, о которой много писалось, так и стоит на том же месте.
В нынешнем виде рейтинг никак не отражает реальной полезности источников, четыре звезды имеют многие ресурсы, на которых нет ни одного живого прокси, три и две звезды получают ресурсы, на которых есть живые прокси. Отчего так происходит понять невозможно, да и совершенно нет никакого желания в этом разбираться, так как это только мешает основной цели программы.
Лучше было бы сделать в цифрах соотношение полученных/живых прокси, чтобы сразу было видно цифры - очень наглядно.
Например,
Столбец 1
общее количество прокси, скачанных с источника за все время/общее количество прокси, скачанных с источника за текущий сеанс
100000/2000
Столбец 2
количество живых прокси за все время/ количество живых прокси за сеанс
500/100
Столбец 3
количество анонимных прокси за все время/ количество анонимных прокси за сеанс
300/50
При это при хорошем соотношении они д.б. в зеленом цвете, при плохом в красном, в при среднем в желтом.
Что касается дублей, которые отсеиваются при скачивании списков - не надо их отсеивать на этапе скачивания, это бесполезная, даже вредная опция, в рейтинге надо учитывать все прокси, полученные с каждого источника, иначе объективной картины по источникам никогда не будет! Смысл этого отсеивания дублей на сегодня совершенно непонятен, наверное когда программу делали, невозможно было предусмотреть всех будущих проблем, это понятно, но на сегодня это отсеивание уже совершенно явно является ошибкой, которую надо исправлять, а не замалчивать, ведь из-за него невозможно нормально отследить результативность источников.
Просто проверять одну и ту же прокси, которая есть в разных источниках, нужно, естественно, один раз, и присваивать ей метки, что она скачана с разных источников через запятую, чтобы было понятно с какого источника она взялась. В живом списке при этом она также отображается один раз.
5. В Проксичекере имеется такая неправильная ситуация.
После того, как прокси попали в список живых прокси они висят там вечно, пока не будут удалены вручную, взятием проектом, или истечением заданного времени.
Но вручную все проверять и удалять - ясно не вариант. Проекты у меня не забирают прокси с удалением, думаю, я не один такой. Время, по истечении которого прокси очищаются, я не хочу ставить, так как оно убивает все прокси подряд в живом списке - и живые и умершие, никакого разделения не делает, а живые мне убивать ни к чему.
Повторная проверка прокси из списка живых то ли никогда не производится, то ли производится через несколько суток, я так и не понял, как это происходит.
Но ситуация эта довольно сильно напрягает, так как в живом списке треть проксей реально работают и две трети не откликаются.
Проставление повторной проверки прокси при этом ограничено максимум в 15 секунд, возможно какие-то мертвые прокси и могут на этом спалиться и выпасть из списка, но в отношении большей части мертвяков этого по факту не происходит, они продолжают висеть в списке.
Решить это можно, например, добавлением возможности задания периодичности приоритетных повторных проверок прокси живого списка и явно с периодом больше 15 секунд, например, раз в час.
6. База прокси, насколько я понимаю, хранит все скачанные когда-либо со всех источников прокси и живые и мертвые.
Не совсем понятен смысл хранения изначально мертвых прокси и их многократной проверки по кругу. Нужно сделать хотя бы опционально - "Добавлять в базу только когда-либо живые прокси"
7. Так как мы говорим о Проксичекере, встроенном в ЗенноПостер, а не о самостоятельном продукте, то вполне логично, что он должен быть к ЗенноПостеру каким-то образом адаптирован.
ЗенноПостер самостоятельная программа, которая использует различные возможности, предоставляемые проксями, выполняющая параллельно в многопоточном режиме множество проектов. Встроенный проксичекер предназначен для обслуживания именно Зеннопостера, именно его нужд и должен отвечать его требованиям.
Одна из особенностей ЗП - многопоточность - которая должна как-то учитываться встроенным проксичекером и иметь какую-то соответствующую адаптацию, коей на сегодняшний нет.
Многопоточность/многопроектность в сочетании с забиранием проксей из пула прокси для задач каждого отдельного проекта порождает искусственную проблему нехватки проксей, связанную как раз с отсутствием нужной адаптации прокичекера.
Так, один из проектов забирает какой-либо прокси и все, данный прокси недоступен более ни для одного из других проектов/потоков.
При этом другие проекты/потоки могут выполнять абсолютно иные задачи, но использовать данный прокси они уже не смогут.
Чтобы этой очевидно неверной ситуации не происходило должен быть какой-то внутренний учет Проксичекером проксей, использованных для разных проектов. Опционально прокси, использованная для одного проекта, должна оставаться доступной для других до тех пор, пока не будет использована всеми проектами.
Никаких особых причин для того, чтобы НЕ исправлять эти недоработки я не вижу. Сейчас он работает по принципу - как-то работает и ладно, лишь бы крашей не было.
В отличие от ЗП движок непосредственно Проксичекера постоянно обновлять не надо, достаточно один раз довести до ума все существующие возможности, и продукт был бы идеальным, если конечно разработчики заинтересованы в том, чтобы сделать идеальный продукт, и если сам процесс обсуждения пользователями одних и тех же недоработок не доставляет удовольствия.
Попробую собрать все накопившиеся пожелания, которые уже давно и пока безуспешно хочется видеть в Проксичекере ЗПостера:
1. Что выдает гугл, если ввести адрес и порт прокси в поиске? Гугл выдает список страниц, на которых данный прокси, так или иначе упоминался.
При переходе на эти страницы в браузере, типа Оперы, мы довольно часто можем увидеть не только пост со списком прокси, где лежит и наш искомый прокси, но и обратить внимание на то, то сайт, или его конкретный раздел имеет РСС-ленту.
Нажимаем значок РСС и примерно в половине случаев обнаруживаем не один пост, а целую РСС-ленту, которая имеет ряд неоспоримых преимуществ:
- она содержит не один, а множество постов с проксями, то, как минимум, есть несколько списков прокси;
- как правило, на гораздо легче, чем страницы сайта, не содержит лишнего стилистического и графического оформления - уменьшается трафик.
Эти страницы РСС в гугле, как правило, не находятся и не отображаются, но легко могут быть найдены при заходе на соответствующую страницу через браузер, поддерживающий поиск РСС, то есть, насколько я понимаю, их несложно найти регулярками по сорсу страницы.
Проксичекер имеет встроенный автопоиск источников прокси, но он абсолютно не задействует эти возможности.
Было бы очень уместным добавить возможность автонахождения и автодобавления рсс-лент с найденных форумов, отдельных постов, отдельных категорий форумов, блогов, где публикуются прокси. Можно было бы даже реализовать это на уровне пользовательских регулярок для поиска этих самых лент.
Это очень хороший источник поиска бесплатных работающих проксей.
2. Многие сайты выдают списки прокси в, например, такого рода форматах:
http://www.proxiki.com/spisok10-03-2016
http://www.proxyashki.ru/socks5/2016-socks-02-17
Эти форматы содержат дату списка и при подстановке сегодняшней даты выдают актуальный список именно на сегодняшний день.
Проксичекер не имеет возможности выкачивать эти списки прокси, так как его списки источников статичны и будут все время выкачивать один и тот же список на заданную дату, который устаревает на следующий день.
Было бы здорово добавить возможность подстановки в урл списка прокси, как минимум, дат, а лучше еще и регулярок, это позволит получать каждый день актуальный список прокси с таких сайтов.
3. При пользовании бесплатными источниками прокси большая часть скачанных прокси, у меня процентов 70-80, находятся неанонимными, прозрачными.
Практическая значимость таких прокси для большинства пользователей программы нулевая.
Тем не менее, эти прокси:
- занимают место в списке, например, когда у вас стоит ограничение собирать 10000 проксей и останавливать потоки чекера, по факту вы получите неизвестное заранее неопределенное количество анонимных прокси, так как большую часть займет сколько-то прозрачных прокси. Нужного количества анонимных прокси вы не получаете;
- тратят ресурсы компьютера на различные проверки - на конкретные урл, на скорость, повторные проверки и т.д.
Необходим фильтр на стадии отбора прокси в список живых, который позволял бы отсеять прозрачные прокси сразу, до включения в список.
А лучше продублировать входные фильтры, аналогичные существующим фильтрам отбора прокси, чтобы каждый пользователь мог решить для себя, какие прокси ему не нужны вообще, а какие нужны в живом списке.
4. Рейтинг прокси - система звезд, о которой много писалось, так и стоит на том же месте.
В нынешнем виде рейтинг никак не отражает реальной полезности источников, четыре звезды имеют многие ресурсы, на которых нет ни одного живого прокси, три и две звезды получают ресурсы, на которых есть живые прокси. Отчего так происходит понять невозможно, да и совершенно нет никакого желания в этом разбираться, так как это только мешает основной цели программы.
Лучше было бы сделать в цифрах соотношение полученных/живых прокси, чтобы сразу было видно цифры - очень наглядно.
Например,
Столбец 1
общее количество прокси, скачанных с источника за все время/общее количество прокси, скачанных с источника за текущий сеанс
100000/2000
Столбец 2
количество живых прокси за все время/ количество живых прокси за сеанс
500/100
Столбец 3
количество анонимных прокси за все время/ количество анонимных прокси за сеанс
300/50
При это при хорошем соотношении они д.б. в зеленом цвете, при плохом в красном, в при среднем в желтом.
Что касается дублей, которые отсеиваются при скачивании списков - не надо их отсеивать на этапе скачивания, это бесполезная, даже вредная опция, в рейтинге надо учитывать все прокси, полученные с каждого источника, иначе объективной картины по источникам никогда не будет! Смысл этого отсеивания дублей на сегодня совершенно непонятен, наверное когда программу делали, невозможно было предусмотреть всех будущих проблем, это понятно, но на сегодня это отсеивание уже совершенно явно является ошибкой, которую надо исправлять, а не замалчивать, ведь из-за него невозможно нормально отследить результативность источников.
Просто проверять одну и ту же прокси, которая есть в разных источниках, нужно, естественно, один раз, и присваивать ей метки, что она скачана с разных источников через запятую, чтобы было понятно с какого источника она взялась. В живом списке при этом она также отображается один раз.
5. В Проксичекере имеется такая неправильная ситуация.
После того, как прокси попали в список живых прокси они висят там вечно, пока не будут удалены вручную, взятием проектом, или истечением заданного времени.
Но вручную все проверять и удалять - ясно не вариант. Проекты у меня не забирают прокси с удалением, думаю, я не один такой. Время, по истечении которого прокси очищаются, я не хочу ставить, так как оно убивает все прокси подряд в живом списке - и живые и умершие, никакого разделения не делает, а живые мне убивать ни к чему.
Повторная проверка прокси из списка живых то ли никогда не производится, то ли производится через несколько суток, я так и не понял, как это происходит.
Но ситуация эта довольно сильно напрягает, так как в живом списке треть проксей реально работают и две трети не откликаются.
Проставление повторной проверки прокси при этом ограничено максимум в 15 секунд, возможно какие-то мертвые прокси и могут на этом спалиться и выпасть из списка, но в отношении большей части мертвяков этого по факту не происходит, они продолжают висеть в списке.
Решить это можно, например, добавлением возможности задания периодичности приоритетных повторных проверок прокси живого списка и явно с периодом больше 15 секунд, например, раз в час.
6. База прокси, насколько я понимаю, хранит все скачанные когда-либо со всех источников прокси и живые и мертвые.
Не совсем понятен смысл хранения изначально мертвых прокси и их многократной проверки по кругу. Нужно сделать хотя бы опционально - "Добавлять в базу только когда-либо живые прокси"
7. Так как мы говорим о Проксичекере, встроенном в ЗенноПостер, а не о самостоятельном продукте, то вполне логично, что он должен быть к ЗенноПостеру каким-то образом адаптирован.
ЗенноПостер самостоятельная программа, которая использует различные возможности, предоставляемые проксями, выполняющая параллельно в многопоточном режиме множество проектов. Встроенный проксичекер предназначен для обслуживания именно Зеннопостера, именно его нужд и должен отвечать его требованиям.
Одна из особенностей ЗП - многопоточность - которая должна как-то учитываться встроенным проксичекером и иметь какую-то соответствующую адаптацию, коей на сегодняшний нет.
Многопоточность/многопроектность в сочетании с забиранием проксей из пула прокси для задач каждого отдельного проекта порождает искусственную проблему нехватки проксей, связанную как раз с отсутствием нужной адаптации прокичекера.
Так, один из проектов забирает какой-либо прокси и все, данный прокси недоступен более ни для одного из других проектов/потоков.
При этом другие проекты/потоки могут выполнять абсолютно иные задачи, но использовать данный прокси они уже не смогут.
Чтобы этой очевидно неверной ситуации не происходило должен быть какой-то внутренний учет Проксичекером проксей, использованных для разных проектов. Опционально прокси, использованная для одного проекта, должна оставаться доступной для других до тех пор, пока не будет использована всеми проектами.
