Project

General

Profile

Server is not resending stanzas in XEP 0198

Mauro Carrio
Added about 5 years ago

Hi!

I'm implementing this XEP on client side, and I cannot make the server to resend me the stanzas that differs from the counter.

These are the steps:

1) Client enable SM.

2) Server confirms with enabled.

3) Client start sending stanzas iq, messages or presences.

4) Server requests the client to inform stanzas received ()

5) Client sends in "h" attribute a value that does not match with the quantity of stanzas sent by the server, and it never resends stanzas. (whatever quantity the client sends in "h" attribute, the server never resends stanzas).

In my init.properties I added:

c2s/processors[s]=urn:xmpp:sm:3

Let me know if you need some extra information.

Thanks in advance.


Replies (7)

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam about 5 years ago

Hi,

Server is never resending stanzas not matter what is value of h attribute, as connection was not broken. Server only resends stanzas after resumption of a stream if in stanza there is h attribute that does not match counter on server side.

This is done this way as server could send other stanzas after sending stanza and they would be already counted while client still needs to process them - so counters would not match very often.

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam about 5 years ago

What does the spec say about this?

Added by Mauro Carrio about 5 years ago

Reading the specification again, apparently it does not specify that the server MUST resend all stanzas still not acked when the counter does not match in any moment. Only after resuming a stream if the h attribute does not match.

Particularly, I'm implementing this XEP because of a serious lost messages problem, mostly because of lacking of the mobile network. But I dont know if this implementation will solve the 100% of the problem.

What do you think about making the server to resend all not acked stanzas after an ack message with attribute h that does not match with the server counter?

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam about 5 years ago

Please note, that if you connect over a standard XMPP protocol, thus TCP/IP then, it is not possible to loose or receive out of order packet on the TCP/IP link as long as it is active and working. Of course, the connection is broken then messages may be lost, but then you have to reconnect and use session resumption to retrieve lost messages.

Therefore, I think your test case is incorrect as it assumes messages may be lost or out of order on a properly working TCP/IP connection.

I think the XEP is enough to ensure there is no packets loss and should well solve your problem with the mobile network.

Added by Mauro Carrio about 5 years ago

Ok, thanks for your clear answer.

Actually, Stream Management is delivering an unavailable-recipient error message to the sender when the session is not resumed. The XEP-0198 offers two posibilities:

"A server SHOULD treat unacknowledged stanzas in the same way that it would treat a stanza sent to an unavailable resource, by either returning an error to the sender or committing the stanza to offline storage."

I would prefer to commit the stanzas to offline storage, I'll try to develop it and add a configuration parameter to choose between this two actions.

Regards,

Mauro

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam about 5 years ago

Right now Stream Managment is created in such a way that it returns unavailalble-recipient error for every unacknowledged stanza. I does so for every stanza because of possibilities offered by XEP-0198 and because messages and other stanzas which are usually not acknowledged are addressed to full jid.

  1. In case of stanza sent to a full jid - stanzas sent to a full jid are storred in offline message store and then, it can be restored from offline store ONLY if same recipient will be available (same full jid) which in case of some clients using dynamic resource generation might cause and overflow in offline message store as some messages might be never delivered. Moreover, sender of those messages would be unaware of this situation. Taking this into accout and knowing that by default Tigase XMPP Server returns unavailable-recipient if there is no connection authorized for full jid for which message is sent we decided to return this error in case of unacknowledged packets as well.

  2. In case of stanza sent to a bare jid - stanza could be delivered to other resources, as it might be cloned to all available resources. In this case if you would sent it to offline store it might be redelivered to other resources and/or might cause message archive to store this message once again. Due to that we decided to send unavailable-recipient error as well.

Added by Daniele Ricci about 4 years ago

Hello,

I'm testing various scenarios for lost messages, and I can see, in some special cases (e.g. mobile devices) where connections can be very unstable, some messages are lost.

If I understand correctly how SM works in Tigase (I'm using SM without resumption between server and clients):

  • Alice sends a message to Bob (bare JID) and requests

  • Alice receives from the server

  • Bob receives the message but, before being able to send a for it, network link is interrupted (so no TCP/IP shutdown handshake)

  • SM processor will queue the message for some time (waiting for resumption? Even if it was not enabled by the client?), then send it to StreamManagementIOProcessor#sendErrorsForQueuedPackets (right?)

  • that method will generate some sort of delivery-error packet which are sent back to the sender

This means that the actual message is lost, and Alice must send it again, right? Shouldn't the server send Alice's message to offline storage?

Thanks.

    (1-7/7)