Возникла необходимость использовать одну учетную запись Jabber для нескольких пользователей. Почитав RFC наткнулся на приоритеты для ресурсов в XMPP. Это то что мне нужно! На практике не все оказалось столь радужным. На мой взгляд многие популярные клиенты не правильно поддерживают протокол.
Идея заключалась в том что клиенты соединяться с Jabber сервером с одной учетной записи но с разных ресурсов и с отрицательным приоритетом.
Поведение сервера в данном случае описано в XMPP IM RFC:
То есть сообщение будет доставлено либо client@example.com/resource1 либо любому другому ресурсе с наивысшим не отрицательным приоритетом. Пока меня все устраивало и только радовало.
Потом в этом же XMPP IM RFC я почитал о том как должны вести себя Jabber клиенты с ресурсами:
Как я это понял если чат начат не этим клиентом то он должен отсылать ответ на полный JID(с ресурсом) во всех случаях кроме того когда инициализатор чата через presence сообщил что этот ресурс недоступен.
На практике все так и есть в случае если оба клиента видят друг друга. В случае с не авторизованными клиентами поведение несколько отличается… Посмотрим на общение через миранду между не авторизованными пользователями:
Я создал нового пользователя(client1@example.com) на своем сервере и подключился к нему из миранды:
После этого я отправил этому пользователю(client1@example.com) 2 сообщения от client@example.com/resource1 и client@example.com/resource2 и сильно удивился их общению…
вот так миранда показала мне эти сообщения:
А просканировав их общение я увидел следующие:
А ответ миранда послала вот так:
Ни один из клиентов не посылал тега presence миранде, да и не должен был потому как они не авторизованы и не сообщают друг другу о своем присутствии. Из всего этого я сделал вывод что миранда не соблюдает RFC. Если я где то не прав сообщите пожалуйста.
Так же я протестировал и другие клиенты:
Так как Psi кросплатформенный я могу остановиться на использовании этого клиента, но хотелось бы разобраться чей на самом деле это баг?
Идея заключалась в том что клиенты соединяться с Jabber сервером с одной учетной записи но с разных ресурсов и с отрицательным приоритетом.
Поведение сервера в данном случае описано в XMPP IM RFC:
11.1. Inbound Stanzas 1.4.1:
For message stanzas, the server SHOULD deliver the stanza to the highest-priority available resource (if the resource did not provide a value for the <priority/> element, the server SHOULD consider it to have provided a value of zero). If two or more available resources have the same priority, the server MAY use some other rule (e.g., most recent connect time, most recent activity time, or highest availability as determined by some hierarchy of <show/> values) to choose between them or MAY deliver the message to all such resources. However, the server MUST NOT deliver the stanza to an available resource with a negative priority; if the only available resource has a negative priority, the server SHOULD handle the message as if there were no available resources (defined below). In addition, the server MUST NOT rewrite the 'to' attribute (i.e., it MUST leave it as <user@domain> rather than change it to <user@domain/resource>).
То есть сообщение будет доставлено либо client@example.com/resource1 либо любому другому ресурсе с наивысшим не отрицательным приоритетом. Пока меня все устраивало и только радовало.
Потом в этом же XMPP IM RFC я почитал о том как должны вести себя Jabber клиенты с ресурсами:
4.1. Specifying an Intended Recipient
An instant messaging client SHOULD specify an intended recipient for a message by providing the JID of an entity other than the sender in the 'to' attribute of the <message/> stanza. If the message is being sent in reply to a message previously received from an address of the form <user@domain/resource> (e.g., within the context of a chat session), the value of the 'to' address SHOULD be of the form <user@domain/resource> rather than of the form <user@domain> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available. If the message is being sent outside the context of any existing chat session or received message, the value of the 'to' address SHOULD be of the form <user@domain> rather than of the form <user@domain/resource>.
Как я это понял если чат начат не этим клиентом то он должен отсылать ответ на полный JID(с ресурсом) во всех случаях кроме того когда инициализатор чата через presence сообщил что этот ресурс недоступен.
На практике все так и есть в случае если оба клиента видят друг друга. В случае с не авторизованными клиентами поведение несколько отличается… Посмотрим на общение через миранду между не авторизованными пользователями:
Я создал нового пользователя(client1@example.com) на своем сервере и подключился к нему из миранды:
После этого я отправил этому пользователю(client1@example.com) 2 сообщения от client@example.com/resource1 и client@example.com/resource2 и сильно удивился их общению…
вот так миранда показала мне эти сообщения:
А просканировав их общение я увидел следующие:
<message type='chat' from='client@example.com/resource1' to='client1@example.com' id='uid12'>
<body>сообщение с resource1</body>
<thread>uid11</thread>
<x xmlns='jabber:x:event'>
<offline/>
<delivered/>
<displayed/>
<composing/>
</x>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message type='chat' from='client@example.com/resource2' to='client1@example.com' id='uid6'>
<body>сообщение с resource2</body>
<thread>uid5</thread>
<x xmlns='jabber:x:event'>
<offline/>
<delivered/>
<displayed/>
<composing/>
</x>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
А ответ миранда послала вот так:
<message from='client1@example.com/Miranda' to='client@example.com' xml:lang='en' type='chat' id='mir_12'>
<body>ответ из миранды</body>
</message>
Ни один из клиентов не посылал тега presence миранде, да и не должен был потому как они не авторизованы и не сообщают друг другу о своем присутствии. Из всего этого я сделал вывод что миранда не соблюдает RFC. Если я где то не прав сообщите пожалуйста.
Так же я протестировал и другие клиенты:
- Miranda-im v0.7.8 — сообщения скидывает в одно окно и отвечает на JID без русурса.
- Pidgin 2.4.3 — сообщения скидывает в одно окно и отвечает на JID без русурса.
- Gajim 0.11.4 — сообщения скидывает в одно окно и отвечает на JID без русурса.
- mcabber 0.9.5-1 — сообщения скидывает в одно окно и отвечает на JID без русурса.
- Pandion 2.5 — сообщения скидывает в одно окно но отвечает на русрс с которого было отправлено последнее сообщение.
- Exodus 0.10.0.0 — открывает новое окно для нового ресурса но сообщение кладет в первое открытое окно :) после 10 сообщений сходит с ума :)
- psi 0.12 — Открывает новое окно для разных ресурсов. Отвечает на полны JID!
Так как Psi кросплатформенный я могу остановиться на использовании этого клиента, но хотелось бы разобраться чей на самом деле это баг?
