← All posts tagged dialback

ma1uta

часть третья, заключительно-поучительная. В заключение к juick.com и juick.com А итог простой, методом пристального взгляда заметил, что для исходящего соединения в dialback-е перепутал from и to, поэтому исходящее соединение было к самому себе вместо удаленного сервера (отсюда и второе соединение от сервера), дальше происходил handshake с самим собой и сам себе отсылал <db:verify/>, на котором радостно падал. В остатке имеем порефакторный код, попутное исправление нескольких мелких ошибок, более-менее нормальное логирование и осознание собственной никчемности...

ma1uta

В продолжение к juick.com Взял ejabberd вместо openfire, ничего не изменилось. В итоге у ежа два открытых исходящих соединения и одно входящее на другой хост. Картина такая же: ёж отправляет <db:result from="ej_server" to="myapp">secret</db:result>, приложение в ответ отправляет <db:verify xmlns:db="jabber:server:dialback" from="myapp" to="ej_server" id="someid">secret</db:verify>, и затем ёж возвращает эту же станзу, даже from и to не меняет местами. Описание namespace-а добавилось из-за баблера (пока не придумал, как убрать объявление).

ma1uta

словил забавный баг (?). Openfire открывает исходящее соединение s2s и после handshake-а присылает <db:result/> (префиксы в именах тегов без namespace в xml — это что-то с чем-то). В ответ открываем соединение на Authoritive Service, в качестве которого выступает тот же openfire и отправляем <db:verify/> ему обратно. В итоге мало того, что openfire на входящее соединение открывает ещё одно исходящее вдобавок к самому первому, так он через это новое исходящее соединение присылает тот же самый <db:verify/>. Даже from и to не меняет местами. Сходу не нашёл место, где он происходит, буду копать дальше.