Project

General

Profile

Can we use "XEP-0198: Stream Management" to know that a stanza has been received by the recipient

Igor Khomenko
Added over 4 years ago

We discussed in the related topic https://projects.tigase.org/boards/4/topics/2639 that we can get a status that server received sender's stanza.

And this works great.

But after some period of acceptance testing I found another side of this issue.

For example, User1 sends a message to UserB. UserA sends a message and requests acknowledgement by sending element.

Server receives this messages and sends an element to acknowledge handling of the stanza.

So, User1 knows that his messages was received by server.

At this time User2 switches of his wi-fi connection. But server still thinks that User2 is online and sends him a message.

In this case message will be lost.

My question is how server can also requests acknowledgement and if it didn't receive an element from User2(recipient) - it stores a message to the offline storage?

Does this covered by XEP-0198 and Tigase?


Replies (11)

Added by Wojciech Kapcia TigaseTeam over 4 years ago

Yes, this is handled by Tigase and was implemented in #1933 task.

Added by Igor Khomenko over 4 years ago

I use Tigase 5.2 - does it support this?

If not - can I easily move this commit to Tigase 5.2 src code instead of updating to Tigase 5.2 snapshot?

Added by Wojciech Kapcia TigaseTeam over 4 years ago

It was introduced after 5.2 release.

You should be able to backport related commits.

Added by Igor Khomenko over 4 years ago

How can I find this commit?

can you please send a link

Added by Igor Khomenko over 4 years ago

Okay, I found it

https://projects.tigase.org/projects/tigase-server/repository/revisions/f12d7d05527687398baa6301ff37e7c20f32c0f9

Wojciech, could you clarify some things please

What will happen with this fix?

Does Tigase will be sending element each time and check for element from the recipient?

Or will it automatically realise broken connection of the recipient and won't send a message to him, but save it to the offline storage?

Added by Wojciech Kapcia TigaseTeam over 4 years ago

Igor Khomenko wrote:

How can I find this commit?

can you please send a link

If you open the issue #1933 there you can find all commits related to that particular issue.

Igor Khomenko wrote:

Wojciech, could you clarify some things please

What will happen with this fix?

Does Tigase will be sending element each time and check for element from the recipient?

Or will it automatically realise broken connection of the recipient and won't send a message to him, but save it to the offline storage?

The latter, the message will be saved to offline storage.

Added by Igor Khomenko over 4 years ago

Thanks,

I looked at src code of StreamManagementIOProcessor class at found that the value of default_ack_request_count is 10.

What is the reason of 10? why don't use 1?

Added by Igor Khomenko over 4 years ago

Let me rescale a bit my question

Is there any reason to send **** element by server?

Actually recipient can send an element each time he has received a stanza

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam over 4 years ago

The default ack count set to 10 is an optimization to reduce traffic on the mobile network and load on the server.

Both, the server and the client can send element and both should send to acknowledge packets receipt. Our implementation follows the specification in XEP-0198, so for all the details, please refer to documentation.

Added by Igor Khomenko about 4 years ago

I have one more question about a flow

For example, user sent a message and then sent **** element to check was his message delivered or not

How much time does he need to wait for the **** response?

Let's say user has a very bad internet connection, can he just waits for 3-5 seconds timeout and then decides that a message was lost and resend it?

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

It is really hard to tell after what amount of time you can consider a message as lost. Tigase XMPP Server will respond with **** element when it receives **** element so there is only small delay on server side, while I cannot tell how long it will take to deliver TCP packet containing **** request to server and packet containing **** response to client as I depends on network speed, network quality, operating system retransmission times for lost TCP packets and so on.

XEP-0198 considers lost XMPP stanzas as stanzas which where send over TCP and no **** response was received for this stanza while connection was closed/broken so only in this case we can consider this packet/stanza lost and we should resend it.

    (1-11/11)