Hi,
I am trying to Flexible Offline Message Retrieval (XEP-0013) to get the headers of the offline messages after a user connects.
According to the protocol, if I request to retrieve messages headers prior to sending the initial presence, I should not receive a flood of offline messages after the initial presence is sent.
However, I still seem to get the flood after the initial presence, no matter what I do.
I also tried to get the number of offline messages instead of the headers (), but even then I get the flood.
This is the flow:
1. Connect to ejabberd server with user's credentials
2. Get the roster of this user
3.After the roster is received, get the offline headers ()
4. After the headers are received
5. Send initial presence
6. Delete offline messages ()
-> Server sents flood of offline messages (although should not)
I am using Ejabberd version 17.07.
Is this a bug or am I doing something wrong?
Thanks
When you send initial
When you send initial presence in step 5, if it has positive priority, mod_offline sends all the messages, as specified in See:
> Now the recipient authenticates with the server and sends initial presence (with a non-negative priority) to the server. [...] The recipient's server now delivers the offline message to that resource
Thanks for the quick
Thanks for the quick response!
If you look at the Process Flow in the doc you mentioned (), you can see in #5:
"When the recipient next sends non-negative available presence to the server, the server delivers the message to the resource that has sent that presence. (Alternatively, the server may support Flexible Offline Message Retrieval (XEP-0013), although that functionality is not described herein.)"
This tells me that the alternative of Flexible Offline Message Retrieval is ignored in this document, when it says:
"Now the recipient authenticates with the server and sends initial presence (with a non-negative priority) to the server. [...] The recipient's server now delivers the offline message to that resource"
Also, in XEP-0013 it states:
"The protocol enables a connecting client to retrieve its offline messages on login in a controlled fashion, without receiving a flood of messages"
And
"Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request [...] or a disco#items request [...]), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session."
So if Flexible Offline Message Retrieval is enabled before the initial presence, I think it shouldn't send the offline messages after the initial presence is sent.
It's not a critical issue, but it's a lot of traffic to the client that could be avoided.
Do I understand this wrong?
Thanks again.
> So if Flexible Offline
> So if Flexible Offline Message Retrieval is enabled before the initial presence, I think it shouldn't send the offline messages after the initial presence is sent.
Right, and that behavior works correctly for me using ejabberd 17.07, as described in the second flow shown in
See this example:
1. user1 sends a message to his contact user33, which is offline
2. user33 logins with negative priority. Consequently, user33 does not receive the offline message
3. user33 sends IQ as XEP-13 says, and receives a response indicating he has offline messages pending:
<iq type='get' id='asd'><query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/offline'/>
</iq>
<iq xml:lang='es'
to='user33@localhost/tka1'
from='user33@localhost'
type='result'
id='asd'>
<query node='http://jabber.org/protocol/offline'
xmlns='http://jabber.org/protocol/disco#items'>
<item node='1499979486413720'
name='user1@localhost/tka1'
jid='user33@localhost'/>
</query>
</iq>
4. Now user33 sets a positive presence priority. He receives a response, but not the offline message flood. So, it works correctly:
<presence xml:lang='es'><show>away</show>
<priority>1</priority>
<status>Busy</status>
<c hash='sha-1'
node='http://tkabber.jabber.ru/'
ver='r8V40m6ZPI/XkmBng8oguZ139bA='
xmlns='http://jabber.org/protocol/caps'/>
</presence>
<presence xml:lang='es'
to='user33@localhost/tka1'
from='user33@localhost/tka1'>
<c hash='sha-1'
node='http://tkabber.jabber.ru/'
ver='r8V40m6ZPI/XkmBng8oguZ139bA='
xmlns='http://jabber.org/protocol/caps'/>
<x xmlns='vcard-temp:x:update'/>
<priority>1</priority>
<show>away</show>
<status>Busy</status>
</presence>
I've also tried not using XEP-0013: if client doesn't send IQ in step 3, then in step 4 he receives the offline message flood.
So the key here is to send a
So the key here is to send a presence with a negative priority after logging in and before the headers are fetched.
If I add this step, it acts as expected, and I don't get the flood of messages.
Thanks!