Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement stream management requesting ACKs #1005

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

singpolyma
Copy link
Contributor

Queue outgoing stanzas and periodically request ACK. Remove from the queue anything ack'd and notify of the ack so apps can know the stanza has for sure sent.

On resume, anything not ack'd is re-sent. On reconnect, anything not ack'd notify of the failure to send this stanza so apps can know the stanza failed.

Even when there is no traffic, send an at least every 5 minutes to check the connection. If there is no inbound traffic (such as an ) within timeout (default 60 seconds) then consider the connection disconnected.

singpolyma and others added 2 commits November 14, 2023 16:59
Queue outgoing stanzas and periodically request ACK.  Remove from the
queue anything ack'd and notify of the ack so apps can know the stanza
has for sure sent.

On resume, anything not ack'd is re-sent.  On reconnect, anything not
ack'd notify of the failure to send this stanza so apps can know the
stanza failed.

Even when there is no traffic, send an <r/> at least every 5 minutes to check the
connection.  If there is no inbound traffic (such as an <a/>) within
timeout (default 60 seconds) then consider the connection disconnected.
Copy link
Member

@sonnyp sonnyp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you

Tests are needed, in particular because this implements quite a complex behavior

In general I try to avoid "internal" XMPP events on entity . They also don't appear to be used. Are they needed? What for and in which case they should be documented. Possibly also emitted on the object returned by function streamManagement

@@ -2,6 +2,7 @@

const Element = require("ltx/lib/Element");
const createElement = require("ltx/lib/createElement");
const clone = require("ltx/lib/clone");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clone is not exported on purpose from @xmpp/xml to keep the size to a minimum

qStanza.name === "message" &&
!qStanza.getChild("delay", "urn:xmpp:delay")
) {
qStanza = xml.clone(stanza);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wdyt of not cloning the stanza? I think we can document that we don't guarantee immutability past send()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, any mutation of arguments to a library that is visible by the caller makes my uncomfortable, and I'm not sure avoiding it just to lose 1KB is worth it IMO. But I don't think it would actually break anything I'm using it for, so if you feel strongly we should drop the clone I could I think.

@@ -52,7 +52,7 @@
"bundlesize": [
{
"path": "./packages/client/dist/xmpp.min.js",
"maxSize": "16 KB"
"maxSize": "17 KB"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needed if we're gonna make use of clone

@singpolyma
Copy link
Contributor Author

In general I try to avoid "internal" XMPP events on entity . They also don't appear to be used. Are they needed?

Yes I am using these events in the snikket SDK to eg know when a message has been acknowledged or not, so I can update my state to know if it made it to the server. Most apps even show this status information (eg one check in conversations means "stream management ack")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants