11
Разработка / Re: Протокол VKontakte
« Last post by Elzor on 23 06 2025, 12:45:16 »Еще раз повторяю:
Кратко:
Да, первый запрос users.get при старте протокола действительно делает только одно: возвращает информацию о текущем аккаунте. Если это не самый первый запуск после создания аккаунта, без этой информации действительно можно вполне стартовать. Тут разве что информация о смене собственного имени, пока миранда была в оффлайне будет пропущена. Стартовать без этого можно. Но не нужно. Если самый первый user.get вернул error 9, то и все оставшиеся user.get вернут то же самое. А на них много что завязано. В частности без них нельзя получить информацию ни о статусах контактов, ни вообще информацию о контактах и друзьях, ни информацию о пользователях мультичатов, ни об источниках пересылаемых сообщений. Да даже имена друзей без него не получить. Кому-то нужен в онлайне протокол, у которого в клисте все в оффлайне, а в чатах одни «Неизвестные контакты»? Ну, может спамерам разве что, но наверняка у них есть более специализированные инструменты.
Про лонгпул изменений статусов, если что, мне говорить не надо – он, во-первых, используется, во-вторых, очень часто он попросту не присылает изменений, когда они есть. Потому отдельно статусы и приходится опрашивать. И user.get сам по себе вдруг может вернуть пустой ответ, а через несколько секунд – уже нормальный.
Скорее всего, проблема в том, что при некоторых условиях опрос о статусах контактов сервер считает флудом. А в подавляющем большинстве случаев - не считает. Поэтому именно лог ДО получения бана важен, там проблема. После - просто следствие.
После "правильного" лога -Вовчик-а пришлось отказаться от опроса через серверные процедуры, унести это полностью на клиентскую сторону. Тут хоть паузу между запросам можно поставить и что-то динамически проанализировать, не говоря уже про то, что тут логирование принципиально лучше. Оказалось, этого недостаточно - нужен новый лог с причиной бана. Пока такого лога нет, я могу только рулить частотой опроса. Пока что (завтра, скорее всего) отключу повторный запрос статуса у пачки контактов, если вернулся пустой ответ и увеличу интервал между циклами опроса.
В любом случае нетлог нужен момента непосредственно перед "девяткой" (пара минут до). Именно перед, после - уже не интересно.Понятно, что если бан уже получен, то с этим ничего не сделать, кроме как подождать. Ценность информации о том, что кто-то получил бан за флуд users.get и теперь не может стартовать, без информации о том, при каких обстоятельствах этот бан получен, околонулевая. Ниже нее только ценность непрошеных советов и оценочных суждений о полезности каких-либо запросов к серверу.
Кратко:
Да, первый запрос users.get при старте протокола действительно делает только одно: возвращает информацию о текущем аккаунте. Если это не самый первый запуск после создания аккаунта, без этой информации действительно можно вполне стартовать. Тут разве что информация о смене собственного имени, пока миранда была в оффлайне будет пропущена. Стартовать без этого можно. Но не нужно. Если самый первый user.get вернул error 9, то и все оставшиеся user.get вернут то же самое. А на них много что завязано. В частности без них нельзя получить информацию ни о статусах контактов, ни вообще информацию о контактах и друзьях, ни информацию о пользователях мультичатов, ни об источниках пересылаемых сообщений. Да даже имена друзей без него не получить. Кому-то нужен в онлайне протокол, у которого в клисте все в оффлайне, а в чатах одни «Неизвестные контакты»? Ну, может спамерам разве что, но наверняка у них есть более специализированные инструменты.
Про лонгпул изменений статусов, если что, мне говорить не надо – он, во-первых, используется, во-вторых, очень часто он попросту не присылает изменений, когда они есть. Потому отдельно статусы и приходится опрашивать. И user.get сам по себе вдруг может вернуть пустой ответ, а через несколько секунд – уже нормальный.
Скорее всего, проблема в том, что при некоторых условиях опрос о статусах контактов сервер считает флудом. А в подавляющем большинстве случаев - не считает. Поэтому именно лог ДО получения бана важен, там проблема. После - просто следствие.
После "правильного" лога -Вовчик-а пришлось отказаться от опроса через серверные процедуры, унести это полностью на клиентскую сторону. Тут хоть паузу между запросам можно поставить и что-то динамически проанализировать, не говоря уже про то, что тут логирование принципиально лучше. Оказалось, этого недостаточно - нужен новый лог с причиной бана. Пока такого лога нет, я могу только рулить частотой опроса. Пока что (завтра, скорее всего) отключу повторный запрос статуса у пачки контактов, если вернулся пустой ответ и увеличу интервал между циклами опроса.