milliseconds precision for stream stanzas

kellogs .
Added over 1 year ago


I have noticed that 's timestamps are all written with microsecond precision and millisecond accuracy inside a 5.6 MySQL db. However, they are written out to clients with seconds precision:

<message from="" type="groupchat" to="" id="FF2F084A-E9C2-4A00-B148-E44CEA35C8C1">
<delay xmlns="urn:xmpp:delay" from="" stamp="2017-06-23T18:04:28Z"/>

XEP-0082 does not forbid millisecond precission. Any chance of having this implemented ? I am currently on a 7.2.0 nighlty build (dist max). Or perhaps there is a switch for this matter to put into etc/ ?

Thank you!

Replies (4)


Added by Artur Hefczyc TigaseTeam over 1 year ago

Could you please explain/provide some details on why you need such a precision?

Added by kellogs . over 1 year ago

That would be for more precise message ordering purposes.


Added by Artur Hefczyc TigaseTeam over 1 year ago

You know that the XMPP is called "near-real-time" protocol? So it is not real time protocol.

What it means, for example, is ,suppose, there are 2 users/devices sending a message at about the same time to the same destination. Even if there is a few seconds of time between each sender sends his message, there is no guarantee that they will be delivered in the same order. Messages can arrive to the destination at any order. There is no way the order can be guaranteed in such a case.

Of course, if 2 messages are sent by the same user/device to the same destination, both messages should be delivered in the same order and in most cases the order is preserved. Sometimes, however, for performance reasons, the order may not be preserved. Tigase has a special configuration option to enforce strict packets ordering. This however, reduces it's ability to use concurrent packets processing and performance.

So, increasing timestamp precision does not help here, because at the point when the timestamp is created, the packets can already be in an incorrect order.

I see your example is for a groupchat use-case. So, between a group chat component and a user who receives messages from group chat we have the second case, that is messages are sent from a single sender (groupchat) to a single destination (user). In this case messages order should be preserved. However, before messages get to the groupchat component they arrive from multiple users and this is where they can arrive at mixed order.

Added by kellogs . over 1 year ago

Ah, the strict packet ordering, forgot about that one.

Thanks for detailing.