Реализовал протокол OSCAR (написал свой мини-ICQ-клиент). Обещаю, если потребуется, _обязательно_ разъясню, как и на чем (это не стандартно, поэтому объяснять долго), но он в принципе работает, а вопрос идет именно по _протоколу_, поэтому пока пропустим этот момент. Возникла следующая досадная проблема.
При выполнении авторизации на login.icq.com серевер присылает пакет FLAP, называемый srv_cookie и обычно содержащий в TLV 05 текст:
адрес:порт
основного сервера для подключения, например,
205.188.8.175:5190
Проблема: иногда вместо TLV 05 пакет содержит TLV 04, в которой вместо <адрес:порт> в виде, указанном выше, содержится текст
http://www.aol.com?ccode=us&amp;lang=en
либо просто
http://www.aol.com
, представляющий собой ссылки, ведущие на соответствующий сайт. Естественно, что логин обламывается.
Мне известно, что при указании неверного пароля присылается та же TLV 04 с следующей ссылкой:
http://www.aim.com/errors/MISMATCH_PASSWD.html?ccode=us&amp;lang=en
, ведущая на страницу восстановления пароля, и я это соответствующим образом обрабатываю. Первая же ссылка приходит непонятно с какой периодичностью и/или при каких условиях. Я настроил клиент на автореконнект при возникновении такого прецедента. И дело в том, что иногда все работает вообще без этих ссылок как часы, иногда нормальные реквизиты приходят после 1-2 попыток, а иногда можно долбить целый день — и нормального SRV_COOKIE так и не придет. При этом с тем же уином обычные клиенты тоже иногда логинятся, иногда — перестают.
Тестировалось примерно на десятке уинов.
Вопросы:
1. В каких случаях это происходит? Вообще, встречался ли кто-то с таким явлением?
2. Если это официальная реклама, почему не удается воспроизвести данное явление на других клиентах (Миранда, ICQ Pro, ICQ Lite и пр.)? Т.е. сколько я ни тестировал, снифферинг ИХ процесса логина никогда не отклонялся от канонического (не было никаких реконнектов, им вообще не приходили такие пакеты, только с TLV 05).

Здравствуйте, Ozean Engel, Вы писали:

OE>Реализовал протокол OSCAR (написал свой мини-ICQ-клиент). Обещаю, если потребуется, _обязательно_ разъясню, как и на чем (это не стандартно, поэтому объяснять долго), но он в принципе работает, а вопрос идет именно по _протоколу_, поэтому пока пропустим этот момент. Возникла следующая досадная проблема.
OE>При выполнении авторизации на login.icq.com серевер присылает пакет FLAP, называемый srv_cookie и обычно содержащий в TLV 05 текст:
OE>адрес:порт
OE>основного сервера для подключения, например,
OE>205.188.8.175:5190
OE>Проблема: иногда вместо TLV 05 пакет содержит TLV 04, в которой вместо <адрес:порт> в виде, указанном выше, содержится текст
OE>http://www.aol.com?ccode=us&amp;lang=en
OE>либо просто
OE>http://www.aol.com
OE>, представляющий собой ссылки, ведущие на соответствующий сайт. Естественно, что логин обламывается.
OE>Мне известно, что при указании неверного пароля присылается та же TLV 04 с следующей ссылкой:
OE>http://www.aim.com/errors/MISMATCH_PASSWD.html?ccode=us&amp;lang=en
OE>, ведущая на страницу восстановления пароля, и я это соответствующим образом обрабатываю. Первая же ссылка приходит непонятно с какой периодичностью и/или при каких условиях. Я настроил клиент на автореконнект при возникновении такого прецедента. И дело в том, что иногда все работает вообще без этих ссылок как часы, иногда нормальные реквизиты приходят после 1-2 попыток, а иногда можно долбить целый день — и нормального SRV_COOKIE так и не придет. При этом с тем же уином обычные клиенты тоже иногда логинятся, иногда — перестают.
OE>Тестировалось примерно на десятке уинов.
OE>Вопросы:
OE>1. В каких случаях это происходит? Вообще, встречался ли кто-то с таким явлением?
OE>2. Если это официальная реклама, почему не удается воспроизвести данное явление на других клиентах (Миранда, ICQ Pro, ICQ Lite и пр.)? Т.е. сколько я ни тестировал, снифферинг ИХ процесса логина никогда не отклонялся от канонического (не было никаких реконнектов, им вообще не приходили такие пакеты, только с TLV 05).

login.icq.com возвращает целую кучу IP адресов, тн. DNS рулетка,
посмотрите закономерность между IP к которому идет коннект и возврат.
подозреваю что у вас в реализации возможна какая-то ошибочка,

Здравствуйте, NeuroVirus, Вы писали:

NV>login.icq.com возвращает целую кучу IP адресов, тн. DNS рулетка,
NV>посмотрите закономерность между IP к которому идет коннект и возврат.
NV>подозреваю что у вас в реализации возможна какая-то ошибочка,

Вот я и говорю, что после отправки первого же своего пакета на login.icq.com (пакета cli_ident) я вместо ответного srv_cookie с одним из адресов из этой DNS-рулетки получал srv_cookie с вышеприведенной ссылкой.
В общем, спасибо, с этим разобрался. Подсказали, что, возможно, защита от частых подключений. Я на это не грешил, т.к. казалось, что таких ситуаций не возникало. Однако проснифферил частое подключение/отключение Мирандой и ICQ 2003 Pro и убедился, что в этом случае аська присылает тот же пакет, что и на мой клиент. В нем еще содержится TLV 08 — Error code. Видимо, надо выдерживать бОльшую паузу при автореконнекте.
Тогда последний пока что вопрос (не задал сразу, чтобы не запутывать). Поясняю детали про свой клиент: он держит одновременно много соединений с ICQ-серверами, т.е. через него работают многие абоненты. Это своего рода шлюз. И, бывает, возникает такая ситуация: начинаю процесс логина, получаю правильный srv_cookie, подтверждаю Rate Limit, настраиваю и активирую сервисы и пр. согласно login sequence, и где-то в это время процесс логина прерывается. Момент разрыва "плавает" и происходит не после какого-либо конкретного отправленного в сокет пакета. В этом случае от аськи никаких пакетов протокола AIM не приходит, приходит только пакет TCP, содержащий "rst". Соответственно, на уровне Windows Sockets получаю ошибку WSAECONNRESET (10054) — Connection reset by peer. An existing connection was forcibly closed by the remote host. MSDN подтверждает, что эта ошибка может выдаваться в случае если удаленный хост использует hard close. Но вот в каких случаях аськин сервер может так со мной поступать? Оговорю, что перелогин в этом случае тоже помогает, при том, что, как вы понимаете, каждый раз я шлю одни и те же пакеты.

Здравствуйте, Ozean Engel, Вы писали:

OE>Здравствуйте, NeuroVirus, Вы писали:

NV>>login.icq.com возвращает целую кучу IP адресов, тн. DNS рулетка,
NV>>посмотрите закономерность между IP к которому идет коннект и возврат.
NV>>подозреваю что у вас в реализации возможна какая-то ошибочка,

OE>Вот я и говорю, что после отправки первого же своего пакета на login.icq.com (пакета cli_ident) я вместо ответного srv_cookie с одним из адресов из этой DNS-рулетки получал srv_cookie с вышеприведенной ссылкой.
OE>В общем, спасибо, с этим разобрался. Подсказали, что, возможно, защита от частых подключений. Я на это не грешил, т.к. казалось, что таких ситуаций не возникало. Однако проснифферил частое подключение/отключение Мирандой и ICQ 2003 Pro и убедился, что в этом случае аська присылает тот же пакет, что и на мой клиент. В нем еще содержится TLV 08 — Error code. Видимо, надо выдерживать бОльшую паузу при автореконнекте.
OE>Тогда последний пока что вопрос (не задал сразу, чтобы не запутывать). Поясняю детали про свой клиент: он держит одновременно много соединений с ICQ-серверами, т.е. через него работают многие абоненты. Это своего рода шлюз. И, бывает, возникает такая ситуация: начинаю процесс логина, получаю правильный srv_cookie, подтверждаю Rate Limit, настраиваю и активирую сервисы и пр. согласно login sequence, и где-то в это время процесс логина прерывается. Момент разрыва "плавает" и происходит не после какого-либо конкретного отправленного в сокет пакета. В этом случае от аськи никаких пакетов протокола AIM не приходит, приходит только пакет TCP, содержащий "rst". Соответственно, на уровне Windows Sockets получаю ошибку WSAECONNRESET (10054) — Connection reset by peer. An existing connection was forcibly closed by the remote host. MSDN подтверждает, что эта ошибка может выдаваться в случае если удаленный хост использует hard close. Но вот в каких случаях аськин сервер может так со мной поступать? Оговорю, что перелогин в этом случае тоже помогает, при том, что, как вы понимаете, каждый раз я шлю одни и те же пакеты.

ну не знаю я этого протокола, но вот что приходит в голову:

ограничение на кол-во коннектов от одного IP,
ограничение на этот самый "rate limit" от одного IP,
неполучение каких либо служебных (ping/anti-idle) пакетов

причем сервера периодически синхронизируют свои таблицы абонентов
и "нахальных" или "умерших" отрубают (вот тебе и hard close)

Здравствуйте, NeuroVirus, Вы писали:

NV>ну не знаю я этого протокола, но вот что приходит в голову:

NV>ограничение на кол-во коннектов от одного IP, (1)
NV>ограничение на этот самый "rate limit" от одного IP, (2)
NV>неполучение каких либо служебных (ping/anti-idle) пакетов (3)

NV>причем сервера периодически синхронизируют свои таблицы абонентов
NV>и "нахальных" или "умерших" отрубают (вот тебе и hard close)

Это все мне в голову тоже приходило но все равно большое спасибо за советы.
(1) — облом происходит при разном количестве подключений с одного IP — от 1 до 15, при этом у нас вся корпоративная сетка (около 100 хостов) выходит в ICQ с одного IP — и все пучком
(2) — rate limit связан со слишком частым подключением, я это убрал
(3) — настроено на отправку keep alive каждую минуту, но это тут вообще не при чем, т.к. обрыв идет именно _во время_ логина, когда идет активная отправка пакетов и клиент не idle