| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\ |
|
| |
| |
| |
| |
| | |
Will hopefully save future confusion about sessions being destroyed when
they are in fact not.
|
| |
| |
| |
| | |
So that happens in a single place, where it can be changed easier.
|
|\ \
| |/
|/| |
|
| |
| |
| |
| | |
Required due to track_session() having moved here
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conversations 2.10.10 and earlier expect this to be literally 'true' and don't
recognise '1'. This leads to it not attempting resumption with Prosody at all
since this change was introduced in 36ba170c4fd0.
Thanks to Zash for noticing, debugging and diagnosing this issue.
This issue is fixed in Conversations commit 052c58f3 (unreleased at the time
of writing).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The use of the error helpers creates an `<error/>` child element
containing the error condition. This is however not allowed as per
XEP-0198, which specifies that the error condition is to be a direct
child of the `<failed/>` stream management element.
This has triggered a fun reconnect loop in aioxmpp where it was
reported by a user [1].
[1]: https://github.com/horazont/aioxmpp/issues/382
|
| | |
|
| | |
|
| |
| |
| |
| | |
...with opportunistic writes enabled.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This will allow us to return the success/failed as part of the SASL2 response,
and *then* perform the stanza sync as a second step.
|
| | |
|
| | |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | | |
Could arguably be implied by 'recipient-unavailable' since if it was
available, this error wouldn't happen.
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
Cuts down on noise as well
|
| |\ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | | |
For consistency and easier correlation of session events.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Those lines are long and the risk of mistakes if another one needs to be
added seems high, but lower when factored out like this.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Setting the .smacks field enables code paths that expects the queue to
be present. The queue is initialized in wrap_session_out(). With
opportunistic writes enabled this happens immediately on .sends2s(), so
the sending <enable> must happen before OR after these two lines, not in
the middle.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Using a timer was a hack to get around that stream features are not
available at the right time and sendq stanzas were stored as strings
so could not be counted properly. The later has now been fixed and the
former is fixed by recording the relevant stream feature on the session
so that the correct version of XEP-0198 can be activated once the
connection has been authenticated and is ready to start.
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since resumption is not supported on s2s currently, there is no point in
allocating resumption tokens. The code that removes entries from
session_registry is only invoked for c2s sessions, thus enabling
resumable smacks on s2s adds an entry that never goes away.
|
| |_|/
|/| |
| | |
| | |
| | |
| | | |
This ensures that the flag is set even if the pre-drain callback is
called from send(), as would be the case if opportunistic writes are
enabled.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sending stanzas with a remote session as origin when the stanzas have a
local JID in the from attribute trips validation in core.stanza_router,
leading to warnings:
> Received a stanza claiming to be from remote.example, over a stream authed for localhost.example
Using module:send() uses the local host as origin, which is fine here.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes #1758
Introduced in 1ea01660c79a
In e62025f949f9 to and from was inverted since it changed from acting on
a reply to acting on the original stanza (or a clone thereof)
Unsure of the purpose of this check, you don't usually send stanzas to
your own full JID. Perhaps guarding against routing loops?
The check was present in the original commit of mod_smacks,
prosody-modules rev 9a7671720dec
|
|/
|
|
|
|
|
|
|
| |
Fixes #1757
These places seem to have been left since e62025f949f9
The logic around expected_h in should_ack() misbehaved, always comparing
with 0 + unacked instead of acked + unacked.
|
|
|
|
|
| |
This seems like the thing to do for time, which is usually divided into
divisors divisible by 60, or multiplied by multiples of 60
|
| |
|
|
|
|
|
|
| |
Doing this when creating a whole new session seems reasonable because it
is already expensive and this is when it may be adding to the old
session store, while a successful resumption should be plus-minus zero.
|
|
|
|
|
| |
For future cleanup routine when people inevitably complain about this
data being stored there forever
|
| |
|
| |
|
|
|
|
|
|
| |
UUID seems like insane overkill for something user-scoped and not
security-sensitive. All that is needed is to avoid conflicts among what
should be relatively long-lived sessions.
|
|
|
|
|
| |
The vision: All the queueing and counting and session replacement logic
in core, with mod_smacks only hooking this up to the XEP-0198 protocol.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
It could have been resumed without going into hibernation first, i.e.
when the client notices the disconnect before the server, or if it
switches networks etc.
|
|
|
|
|
| |
Errors sent from handle_unacked_stanzas() should usually not be sent to
the session itself, but if one is, it should not be queued.
|
|
|
|
|
| |
Fixes that an extra watchdog was set, leaking the previous one, which
went on to do behave as if the session times out.
|
|
|
|
|
|
| |
Still having the connection on the session may cause unintentional
behavior, such as the session being treated as if connected, even tho
the connection has been closed.
|
| |
|
|
|
|
| |
Was this the last place using the delay? Nice!
|
|
|
|
|
| |
Otherwise it can get stuck waiting indefinitely for an ack that made it
notice the connection was stale.
|