ПРОБЛЕМА: Зависают задачи

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

Данная проблема может воспроизводиться случайным образом. Она никак не связана с настройками задачи, а связана именно с фактом использования определённых мобильных прокси.

Больше информации о различных видах прокси можно получить из этой статьи.

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

Далее возможны два варианта развития событий. Либо задача "замрёт" на несколько часов, либо на несколько десятков минут - в каждом случае это абсолютно произвольно и зависит от целого ряда внешних факторов - об этом чуть ниже. Соответственно, если вы продвигаете аккаунты в одновременном режиме (по умолчанию), например, 10-20 аккаунтов на одном мобильном прокси-канале, то проблема будет приводить к тому, что произвольные аккаунты на том или ином прокси-канале просто замирают на длительное время и ничего не делают. Если вы продвигаете аккаунты в опоследовательном режиме (он же асинхронный режим, он же режим IP-синхронизации), то проблема будет приводить к тому, что в какой-то момент один из аккаунтов "замрёт" и, соответственно, "замрёт" весь процесс переключения аккаунтов в пределах проблемного прокси-канала.

При этом однократное нажатие на кнопку "Отмена" в главном окне на панели инструментов приводит не к завершению задачи, как это обычно происходит (надпись "Завершено" в колокнке "Состояние"), а к переходу в состояние её отмены - надпись "Отменено" в колокнке "Состояние". В этом состоянии задача пробудет ровно столько, сколько продлится такое "замирание" - от нескольких десятков минут до нескольких часов.

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

ИСТОРИЯ ПРОБЛЕМЫ И ПРИЧИНЫ ВОЗНИКНОВЕНИЯ

Мы долгое время "гонялись" за этой проблемой, пытаясь понять, в чём же причина. Просили различных провайдеров мобильных прокси предоставить нам прокси для тестов, тестировали подписку, лайки и другие задачи на своих мобильных прокси и на большом числе своих аккаунтов - всё работало идеально. Дополнительно ситуация также усложнялась тем, что некоторым клиентам помогала смена сборки одной ОС Windows на другую. Иными словами, с теми же исходными данными (аккаунтами и прокси) клиент переходил с одной версии Windows на какую-то другую (например, с серверной Windows 2012 на Windows 8 / 10 или наоборот) и проблема решалась. Это совершенно справедливо сформировало у нас представление (ошибочное, как выяснилось позже) о том, что виной всему ошибки в определённых сборках ОС Windows, которые проявляются при использовании определённого способа формирования запросов.

Всё оказалось куда сложнее, когда мы, наконец, нашли клиента, который согласился помочь нам докопаться до истины. Т.к. клиентов, которые сталкивались с данной проблемой на постоянной основе в первое время было совсем мало, то на это ушло достаточно много времени. Ситуация начала проявляться чаще по мере перехода всех, кто занимается продвижением на мобильные прокси и дальше станет понятно почему.

В конечном итоге, когда мы, наконец, нашли клиента, установившего себе предложенные нами сборки Windows с четким кейсом по воспроизведению проблемы, то мы смогли воспроизвести эту проблему и на своих тестовых стендах. Разумеется, лишь на его аккаунтах и мобильных прокси. Забавно то, что провайдером его мобильных прокси был тот же провайдер мобильных прокси, который использовали и мы, а это уже позволило сделать первые важные выводы:

1. Проблемных провайдеров нет. Есть проблемные мобильные прокси, а есть нормально работающие в пределах одного и того же провайдера мобильных прокси.

2. Сборка Windows и организация работы сокетов в ней оказывает влияние на ситуацию, но не является первопричиной возникновения проблемы, а, соответственно, смена сборки и версии ОС может не решить проблему.

3. При использовании прямого 3g/4g Интернет-соединения, мобильных прокси без автосмены оконцовочных IP, прокси IPv6 / IPv4, а также при работе с "родного" IP никаких "замираний" в задачах не наблюдалось. Это же констатировали и наши клиенты, столкнувшиеся с проблемой.

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

Неполный ответ от сервера Instagram во время выполнения одного из запросов, указывающий на принудительный разрыв Интернет-соединения - в HEX'е отчетливо виден обрыв строки в ответе.

Тестовым путём было установлено, что "замирание" задачи сопровождается разрывом соединения во время автоматической смены оконцовочного IP мобильного прокси и, как следствие, неполным ответом от сервера Instagram.

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

Неполный ответ от сервера Instagram во время выполнения одного из запросов, указывающий на принудительный разрыв Интернет-соединения - JSON не может быть разобран.

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

Со своей стороны мы неоднократно доводили до сведения провайдеров мобильных прокси, что логика автосмены оконцовочных IP должна учитывать эти потенциально возможные проблемы. Т.е. алгоритм, отвечающий за автосмену оконцовочных IP, должен: 1 - дождаться выполнения того или иного запроса на стороне Instagram, 2 - получить ответ от Instagram, 3 - отправить этот ответ клиенту, 4 - дождаться полной передачи ответа клиенту. Только после этого можно присутпать к смене оконцовочного IP. И, что самое интересное, один прокси в пределах одного и того же прокси-провайдера будет точно соответствовать этим правилам, а другой может уже не соответствовать им. Как и почему так получается мы, увы, не знаем, т.к. изучить логику работы мобильных прокси у нас возможности нет, но на данный момент это подтверждено экспериментально.

Дополнительно было установлено, что "оборванные" ответы от Instagram во время автосмены оконцовочных IP мобильных прокси, сопровождающиеся "замираниями" (они же зависания) задач в SocialKit, в большинстве случаев наблюдались во время выполнения запросов с объёмным ответом. В этой связи мы сделали предположение, что часть алгоритма автосмены оконцовочных IP, непосредственно отвечающая за реконнект, может не учитывать время на передачу самого контента в ответе, в результате чего большая часть ответа, всё же, приходит, но его полнота нарушена.

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

ВАЖНО! Подытожим. Экспериментальным путем было установлено, что проблема наблюдается исключительно при работе на мобильных прокси с автосменой оконцовочного IP, но не на всех прокси в пределах одного и того же прокси-провайдера; во время автосмены оконцовочного IP, но не при каждой такой автосмене.

Корректный ответ от сервера Instagram во время выполнения одного из запросов, указывающий на то, что запрос выполнен успешно - в HEX'е отчетливо виден логический конец строки в ответе.

Корректный ответ от сервера Instagram во время выполнения одного из запросов, указывающий на то, что запрос выполнен успешно - JSON корректно разобран и представлен в виде иерархической структуры.

СПОСОБЫ РЕШЕНИЯ ПРОБЛЕМЫ

В идеале, конечно же, нужно донести информацию выше до технических специалистов мобильных прокси-провайдеров, если вы столкнулись с такой проблемой. Однако, со своей стороны мы встроили в SocialKit целый арсенал противодействия проблеме.

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

Эти режимы могут работать совместно и отдельно друг от друга.

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

Глобальный режим контролируемых потоков

Активируется этот режим в экспертных настройках программы, как показано на скриншоте ниже.

Экспертные настройки в главном окне программы, активация глобального режима контролируемых потоков.

После этого программа будет следить за всеми активными задачами на всех аккаунтах и переводить задачи с "замершими" запросами в состояние "Отменено". Такие аккаунты будет очень просто идентифицировать в списке, т.к. для этого больше не нужно разбираться, когда была последняя запись в логе. После этого можно массово перезапустить по ним задачу через функцию "Возобновить" или через кнопку "Указать задачу". Соответственно, задачи в состоянии "Отменено" не будут тормозить и работу в режиме IP-синхронизации - программа будет пропускать такие аккаунты, переходя к следующим в пределах каждого прокси-канала.

Такой способ решения проблемы предпочтителен, если "замирания" встречаются крайне редко. Его реализация достаточно проста и никак не связана с работой задач непосредственно, т.к. "навешивается" сверху.

Информацию об аккаунтах, задачи которых были остановлены таким способом можно найти в логе критических ошибок

Общий лог критических ошибок с информацией об аварийном завершении "замерших" задач.

Индивидуальный режи контролируемых потоков

Данный режим может быть активирован во время настройки той или иной задачи для того или иного Instagram-аккаунта. В блоке настроек каждой задачи, поддерживающей этот режим, соответствующий переключатель находится на подзакладке "Тех. настройки" -> "Отладка", как показано на скриншоте ниже для задачи "Подписка (+Лайки)".

Активация режима контролируемых потоков в настройках задачи "Подписка (+Лайки)".

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

Время ожидания выполнения того или иного запроса в "песочнице" регламентируется настройками качества связи - соответствующий блок настроек находится на подзакладке "Общие" в главном окне программы.

Варианты предустановок, определяющие качество связи в главных настройках программы.

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

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

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

ВАЖНО! Ещё раз отметим, что мы не рекомендуем активировать режим контролируемых потоков в задачах, если вы не сталкиваетесь с этой проблемой достаточно часто, т.к. это сильно усложняет логику работы каждой задачи.