Разрывы соединений (проблема мобильных или медленных прокси) - кубик DISCONNECT.

  • Автор темы Автор темы wtfowned
  • Дата начала Дата начала

wtfowned

Client
Регистрация
07.04.2020
Сообщения
40
Реакции
11
Баллы
8
Добрый день! Мобильные прокси набирают популярность последние годы, и занимают все бОльшую долю рынка. Чаще всего, на них происходит смена IP с ротацией в заданный заранее интервал времени. Такие смены IP, чаще всего, сопровождаются разрывом соединения на 2-10 сек (например, такое наблюдаю у топовых провайдеров). Также, такая проблема наверняка есть и на медленных прокси или других, работающих нестабильно.

Все вышесказанное - чтобы подчеркнуть важность и массовость проблемы, указать на большую долю пользователей которые испытывают сложности. Я прошерстил форум, и эта проблема всплывает все чаще, но доступных и адекватных универсальных решений нет. Усложнять шаблон проверками на каждом шагу - не вариант (хотя-бы потому, что например у меня 50+ шаблонов разной сложности), поэтому нужно кардинальное решение от разработчиков.

Варианты решения:
1. На уровне шаблона / настроек ZP установить интервал времени получения ответов на отправленные POST/GET запросы для определенного типа контента (все, кроме медийного контента: видео, аудио, картинки, css). Например, настройка, варианты:
- если ответ не получен в течение N секунд (5 секунд) , отправить запрос автоматически ПОВТОРНО
- если ответ не получен в течение N секунд (5 секунд) , перезагрузить страницу

2. Все тоже самое, на уровне кубиков.

3. Дополнительный кубик уровня GOOD / BAD END , например кубик DISCONNECT . На который будет переходить шаблон в случае улавливания любой из ошибок соединения из возможных (ERR_CONNECTION_CLOSED / timeout / и все остальные, не получение ответа на GET запрос в течение N секунд), который будет отрабатывать по тому же принципу что и GOOD/BAD END кубик (возможность задать любые действия на этом этапе, например - перезагрузка страницы или смена прокси или что угодно) + вернет шаблон к {-Project.LastExecutedActionId-} . Считаю, это наиболее оптимальный и наиболее эффективный способ решения проблемы.
 
Нужно не экономить и не использовать общий канал, а брать выделенный под себя, тогда таких проблем не будет. Там перезагрузка происходит по GET запросу.
 
Не успел тему создать, как уже со своей рекламой прибежали. Для ваших "полезных" и "умных" сообщений есть раздел РЕКЛАМЫ.

Я говорю о существующих проблемах пользователей, и вариантах их решения, а не о том как купить канал мобилки за 2к рублей от условного нонейма, который по факту абсолютно ничего не гарантирует (ни скорости, ни стабильности). Оверселл и шейвинг как был, так и будет всегда, а следовательно и проблема дисконнектов и прочего.
 
Не успел тему создать, как уже со своей рекламой прибежали. Для ваших "полезных" и "умных" сообщений есть раздел РЕКЛАМЫ.

Я говорю о существующих проблемах пользователей, и вариантах их решения, а не о том как купить канал мобилки за 2к рублей от условного нонейма, который по факту абсолютно ничего не гарантирует (ни скорости, ни стабильности). Оверселл и шейвинг как был, так и будет всегда, а следовательно и проблема дисконнектов и прочего.
Это вовсе не реклама.
Просто люди хотят за копейку(образно) что то купить, и что бы все работало как часы. Такого не бывает. Качественный любой продукт и товар стоит горазда дороже обычного ширпотреба.
 
Это вовсе не реклама.
Просто люди хотят за копейку(образно) что то купить, и что бы все работало как часы. Такого не бывает. Качественный любой продукт и товар стоит горазда дороже обычного ширпотреба.
Это именно реклама, и всегда ей была. Нативочка такая. В теме о проблемах коннекта/скорости сайта, приходить и рекламировать свои суперкачественные Proxy/VPS. Это скорее негатив вызывает.

Конечно, с вашей стороны это может выглядеть как "рука помощи" и "ценный совет", придти и посоветовать свою супер услугу. Не льстите себе. И да, пользовователи которые в той или иной степени испытывали проблемы со связью - большинство, и тема об этом.

И плз, хватит пререкаться. "Ценные советы" про качественные прокси = флуд и реклама.
 
Последнее редактирование:
ейбогу, как дети малые))

то, что на беспроблемную работу надо брать качественные расходники - это факт.

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

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

все мы платим либо временем, либо деньгами. либо колхозим производные в разных вариациях.
 
  • Спасибо
Реакции: dmitriy1384
Давно надо это сделать. Помню когда писал свои проекты на моб. проксях. Это были муки.

Я понял одно, для Zenno надо:
1) Брать прокси с бесшовной сменой IP.
2) Время работы не должно превышать время ротации.
3) В конце или начале проекта ждем смены IP, что бы гарантированно начать работу нового потока с новый IP и исключить разрыв в середине работы.
 
  • Спасибо
Реакции: deukech, GREXA и wtfowned
Либо просим доработку?
Смысл от этой доработки ?
В какой момент завис шаблон, на каком этапе, куда возвращаться и что делать после этой ошибки ?
Это нужно лепить кучу лишних проверок всех действий, каждую обрабатывать и вылавливать момент, когда интернет отвалится, после пробовать возвращаться именно к тому месту.
 
Смысл от этой доработки ?
В какой момент завис шаблон, на каком этапе, куда возвращаться и что делать после этой ошибки ?
Это нужно лепить кучу лишних проверок всех действий, каждую обрабатывать и вылавливать момент, когда интернет отвалится, после пробовать возвращаться именно к тому месту.
Вы либо стартпост не читали (там все описано что куда и как возвращать), либо имеете очень поверхностное представление о веб разработке.
 
Либо просим доработку?
То есть пытаемся расплатиться чужим временем. Увеличивая количество слоев адаптации для юзера, но уменьшая гибкость инструмента.
Зенка и так позволяет не кодить, просто умея в логику.

upd.
использовал шаред моб под инсту, просто доработав задержки и логику.
 
То есть пытаемся расплатиться чужим временем. Увеличивая количество слоев адаптации для юзера, но уменьшая гибкость инструмента.
Зенка и так позволяет не кодить, просто умея в логику.
Один простой запрос имеет логику на 50+ кубиков. Это ошибки сервера, капча, некорректная прогрузка, ошибки ссылок, отвал прокси, инета и куча всего еще. Не так то просто, даже для опытного пользователя Zenno Poster.
 
Один простой запрос имеет логику на 50+ кубиков. Это ошибки сервера, капча, некорректная прогрузка, ошибки ссылок, отвал прокси, инета и куча всего еще. Не так то просто, даже для опытного пользователя Zenno Poster.
я о том, что тут вопрос возможностей. надо шаред, ждать реконнекта со всеми вытекающими - надо готовиться вот к этому вот всему..
штатный инструмент что изменит по сути?

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

а потом просто ушел на норм прокси по ссылке.

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

Взять тот же Шифтер, Люминати или любого другого residential провайдера: порт может упасть в любую секунду (банально - юзер отключил ПК) и приходится городить кучу проверок после каждого запроса, чтобы выполнение шаблона не упало, а просто подцепило новый порт.

Пункт #3 из первого поста достаточно сильно бы упростил жизнь.

PS: расскажите мне, что условный Люминати это прокси "за копейку" и я хочу "сэкономить".
 
  • Спасибо
Реакции: gonzo и wtfowned
Окей, писал неделю назад на запросах под резики, со всеми их вышеперечисленными приколами, любая смена ip или дисконнект = разлогин. А это, как следствие, паузы и вылет на bad end с любого запроса или зависимого от него следующего действия. Всё прекрасно обрабатывается в частном порядке.
Приведите свой пример, я действительно пока не вижу в этом проблемы, настолько глобальной, чтоб пилить штатное средство обработки, в то время пока семерка сыровата)
Думаю, если еще матерые зенщики выскажутся будет неплохо, рассмотрим проблему со всех сторон.
 
фигня какая то, а не предложение *lol*
нафига брать в работу мобильный прокси, если не понимаешь его предназначение ? какой смысл от всех этих автоматических проверок если в результате реконекта произойдет смена ip ?
надо логику работы шаблона правильно проектировать под таймауты смены прокси, а не заебывать разработчиков своими проблемами.
одно дело когда серверный прокси получил дисконект и простая перезагрузка ресурса через N-секунд помогла продолжить работу, другое дело когда ребутнулся мобильник. раз он ребутнулся во время работы шаблона, значит кривая логика шаблона, раз он не успел все сделать в отведенный интервал. И тут надо не автоматически переходить на кубик который сосбоил на ребуте прокси, а выходить на BADEND и предварительно вывеси сообщение "алярм, алярм, смена ip :)" Тут надо над логикой работы шаблона работать, а не ждать манны чудесной.
 
  • Спасибо
Реакции: Wide
Окей, писал неделю назад на запросах под резики, со всеми их вышеперечисленными приколами, любая смена ip или дисконнект = разлогин. А это, как следствие, паузы и вылет на bad end с любого запроса или зависимого от него следующего действия. Всё прекрасно обрабатывается в частном порядке.
Приведите свой пример, я действительно пока не вижу в этом проблемы, настолько глобальной, чтоб пилить штатное средство обработки, в то время пока семерка сыровата)
Думаю, если еще матерые зенщики выскажутся будет неплохо, рассмотрим проблему со всех сторон.
Окей.

1. Что за сайт где смена ип приводит к разлогину?
2. Как в частном порядке обрабатывали дисконнекты и прочее, с продолжением выполнения шаблона, можно пожалуйста пример реальный?
 
фигня какая то, а не предложение *lol*
нафига брать в работу мобильный прокси, если не понимаешь его предназначение ? какой смысл от всех этих автоматических проверок если в результате реконекта произойдет смена ip ?
надо логику работы шаблона правильно проектировать под таймауты смены прокси, а не заебывать разработчиков своими проблемами.
одно дело когда серверный прокси получил дисконект и простая перезагрузка ресурса через N-секунд помогла продолжить работу, другое дело когда ребутнулся мобильник. раз он ребутнулся во время работы шаблона, значит кривая логика шаблона, раз он не успел все сделать в отведенный интервал. И тут надо не автоматически переходить на кубик который сосбоил на ребуте прокси, а выходить на BADEND и предварительно вывеси сообщение "алярм, алярм, смена ip :-)" Тут надо над логикой работы шаблона работать, а не ждать манны чудесной.
Виталий, уровень токсичности ваших сообщений и прямопропорциональной пользы от них зашкаливают. Придти, все обосрать вокруг, и никакого конструктива, как будто сообщения за деньги пишете и набиваете посты.

1. Это пост о предложении функционала на будущее. Ваш аргумент что надо шаблоны под прокси проектировать - это бред, уж простите, а не аргумент. У менч на прокси уходит 200-500$ в месяц и еще 400$ на сервера (под сайты), и уже поверьте я знаю как и с чем их варить. Ну давайте вообще доработки не предлагать. Выше уже писали что 1 кубик заменит 50 различных ошибок и условий дисконнектов. Речь о глобальной проблеме дисконнектов и некачественных прокси, а не о частностях которые вы под себя смогли решить.

2. Знаете как решить проблему - дайте ссылку на код или приложите шаблон. Вангую - такого решения у вас нет и быть не может.

3. Есть предложение лучше по существу программной реализации внутри зенки помимо озвученных мной 3х вариантов? Предложите, ждем, просим, настаиваем!

Просьба многобукав не по существу решения проблемы, не писать. Хотя, впрочем, пишите. Администрация и модераторы уже обратили внимание на тему, и ваш флуд только апает ее вверх.
 
не совсем, пока вы пытаетесь спорить требуя с меня каких-то примеров, я таки пытаюсь обсудить. разница огромна.
апает ее вверх.
уже неплохо

Что за сайт где смена ип приводит к разлогину?
один из нужных мне региональных форумов, да такие еще живы.
Как в частном порядке обрабатывали дисконнекты и прочее
руками. какой вопрос - такой ответ. на то он и частный порядок, чтоб индивидуально головой думать над происходящим. как минимум это будет bad end

а пока жду ответы на свои вопросы) если из этого родится что-то полезно, то будет весьма неплохо.
 
1. Что за сайт где смена ип приводит к разлогину?
Например в авито. Регаешь себе акк, и просто без каких либо причин выкидывает из сессии. Но я предполагаю дело не в прокси, а в криворукости сайтоделов.
 
Виталий, уровень токсичности ваших сообщений и прямопропорциональной пользы от них зашкаливают. Придти, все обосрать вокруг, и никакого конструктива, как будто сообщения за деньги пишете и набиваете посты.

1. Это пост о предложении функционала на будущее. Ваш аргумент что надо шаблоны под прокси проектировать - это бред, уж простите, а не аргумент. У менч на прокси уходит 200-500$ в месяц и еще 400$ на сервера (под сайты), и уже поверьте я знаю как и с чем их варить. Ну давайте вообще доработки не предлагать. Выше уже писали что 1 кубик заменит 50 различных ошибок и условий дисконнектов. Речь о глобальной проблеме дисконнектов и некачественных прокси, а не о частностях которые вы под себя смогли решить.

2. Знаете как решить проблему - дайте ссылку на код или приложите шаблон. Вангую - такого решения у вас нет и быть не может.

3. Есть предложение лучше по существу программной реализации внутри зенки помимо озвученных мной 3х вариантов? Предложите, ждем, просим, настаиваем!

Просьба многобукав не по существу решения проблемы, не писать. Хотя, впрочем, пишите. Администрация и модераторы уже обратили внимание на тему, и ваш флуд только апает ее вверх.
если флуд, то удалят. это их работа. зачем лезть туда куда не просят ?
потом, не суди да не судим будешь. если ты не понимаешь о чем я написал, то это не мои проблемы.
Так то я просто высказал свою точку зрения, и мне вообще пофигу, нравится она тебе или нет. твое дело маленькое, создал тему с предоложением и успокоился, там наверху разберутся нужна эта очередная фигня в функционале зенке или лучше стабильностью заняться.
насчет ссылки на решение , думаю что поиском умеешь пользоваться :) .так же думаю человек который тратит столько денег на прокси и на сервера, найдет финансы для найма специалиста который решит его проблему, раз уж сам не можешь.
насчет программной реализации, думается деньги есть, закажешь себе решение :) вообще то в любом программном обеспечении логика выстраивается так, что бы была обработка ошибок работы, и открою тебе секрет, реализует ее как ни странно программист который пишет это обеспечение, а не авторы визуал студия к примеру. Странно конечно, шаблон твой, а обработку ошибок ты предлагаешь делать другим. красавчик :)
 
Например в авито. Регаешь себе акк, и просто без каких либо причин выкидывает из сессии. Но я предполагаю дело не в прокси, а в криворукости сайтоделов.
У гугла тоже такой есть прикол, но там не от прокси зависит, а что то с куками в зенке.
 
если флуд, то удалят. это их работа. зачем лезть туда куда не просят ?
потом, не суди да не судим будешь. если ты не понимаешь о чем я написал, то это не мои проблемы.
Так то я просто высказал свою точку зрения, и мне вообще пофигу, нравится она тебе или нет. твое дело маленькое, создал тему с предоложением и успокоился, там наверху разберутся нужна эта очередная фигня в функционале зенке или лучше стабильностью заняться.
насчет ссылки на решение , думаю что поиском умеешь пользоваться :-) .так же думаю человек который тратит столько денег на прокси и на сервера, найдет финансы для найма специалиста который решит его проблему, раз уж сам не можешь.
насчет программной реализации, думается деньги есть, закажешь себе решение :-) вообще то в любом программном обеспечении логика выстраивается так, что бы была обработка ошибок работы, и открою тебе секрет, реализует ее как ни странно программист который пишет это обеспечение, а не авторы визуал студия к примеру. Странно конечно, шаблон твой, а обработку ошибок ты предлагаешь делать другим. красавчик :-)
Слив засчитан по всем пунктам, ни одного предложения из многобукав по существу. Продолжайте в том же духе, надеюсь бан вас настигнет.
 
не совсем, пока вы пытаетесь спорить требуя с меня каких-то примеров, я таки пытаюсь обсудить. разница огромна.

уже неплохо


один из нужных мне региональных форумов, да такие еще живы.

руками. какой вопрос - такой ответ. на то он и частный порядок, чтоб индивидуально головой думать над происходящим. как минимум это будет bad end

а пока жду ответы на свои вопросы) если из этого родится что-то полезно, то будет весьма неплохо.
Еще раз. Как обрабатываете дисконнекты? По существу. Примеры с вас требую в связи с вашим сообщениям что проблема не стоит выеденного яйца и вы ее решаете без проблем в частном порядке, поэтому доработка, на мой взгляд очень важная, не нужна. Аргументом будет код решения проблемы, пример. Пока вижу слова и критику, а не конструктив. Можно еще признать что решения у вас нет и вы из духа противоречия пришли пофлудить как Феникс в теме или другой товарищ рекламу своих проксей принёс.

У меня шаблон который выполняется 2 часа например, там циклы и все остальное, сотни переходов между страницами, я устал отлавливать этапы и проставлять все триггеры чтобы потом по новой после дисконнекта запускать шаблон с места в котором он остановился, из за этого механизм продолжения шаблона с места разрыва при повторном запуске уже чуть ли не больше чем сам шаблон.
 
По существу - любой дисконнект это после отсечки по ожиданию = bad end.
Что вам мешает по выходу по bad end сохранять профиль, переменные, в т.ч. {-Project.LastExecutedActionId-}, а перед стартом поставить switch с возможными вариантами. после загрузки состояния эта схема перекинет вас на нужное действие.
Да, нужно настраивать, но само ничего не делается.
Ведь по сути, как я понял, именно это вы хотите от разработчиков)
Принцип я изложил, от чего оттолкнуться, думаю, понятно.

Дожили, я начал на кофейной гуще гадать))
 
  • Спасибо
Реакции: wtfowned
У меня шаблон который выполняется 2 часа например, там циклы и все остальное, сотни переходов между страницами, я устал отлавливать этапы и проставлять все триггеры чтобы потом по новой после дисконнекта запускать шаблон с места в котором он остановился, из за этого механизм продолжения шаблона с места разрыва при повторном запуске уже чуть ли не больше чем сам шаблон.
конечно, конечно, мы все тут флудеры, один ты у нас работящий и только по делу. :)
нормальные люди, нормально задают вопросы и получают нормальные ответы. вот как раз недавно обсуждали подобную тему, сохранение и переход состояний шаблона. Но тебе даже вот ни малейшего желания нет давать ссылку на это обсуждение, и уж тем более тут давать какие то полезные советы. Любишь ставить себя выше других, любишь статусы другим выдавать, ну и шлепай в поиск тогда.
 
Примеры с вас требую в связи с вашим сообщениям что проблема не стоит выеденного яйца и вы ее решаете без проблем в частном порядке, поэтому доработка, на мой взгляд очень важная, не нужна. Аргументом будет код решения проблемы, пример. Пока вижу слова и критику, а не конструктив. Можно еще признать что решения у вас нет и вы из духа противоречия пришли пофлудить как Феникс в теме или другой товарищ рекламу своих проксей принёс.
Вы неприятный собеседник. Если бы я прочитал это раньше(а это добавлено после редактирования), то с удовольствием бы просто проигнорировал.
Вам тут никто ничего не должен, тем более на манипуляции "а ты докажи мне".
В следующий раз думайте сами, ждите когда добавят функционал. Я мимо пройду, пожалуй, не хочу больше укреплять вашу веру в эффективность такого подхода в общении.
 
Есть система голосования, спорить смысла нет. Голоса сами расставят приоритеты для разработчиков. Но как показал опыт, даже топ предложения не торопятся внедрять, т.к. технически это не всегда просто.
 
По существу - любой дисконнект это после отсечки по ожиданию = bad end.
Что вам мешает по выходу по bad end сохранять профиль, переменные, в т.ч. {-Project.LastExecutedActionId-}, а перед стартом поставить switch с возможными вариантами. после загрузки состояния эта схема перекинет вас на нужное действие.
Да, нужно настраивать, но само ничего не делается.
Ведь по сути, как я понял, именно это вы хотите от разработчиков)
Принцип я изложил, от чего оттолкнуться, думаю, понятно.

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

Похожие темы

Кто просматривает тему: (Всего: 0, Пользователи: 0, Гости: 0)