On 30.12.22 11:05, Dave Cridland wrote:
On Thu, 22 Dec 2022 at 09:23, Matthew Wild <[email protected]
<mailto:[email protected]>> wrote:
On Wed, 21 Dec 2022, 15:05 Florian Schmaus, <[email protected]
<mailto:[email protected]>> wrote: > Zash's proposal is, as far as
I understand it, just an
optimization
allowing a sending entity to determine if a stanza will hit the
limit or
not, without trying to actually send it.
>
It is and it isn't. Right now, if a stanza is over the limit then
most implementations will close the connection with a stream error.
Not closing the connection is non-trivial for implementations if
they want to avoid DoS and use a standard parser.
I think this is a good summary of why the <max-bytes/> is needed - it
allows a sending implementation to alter its behaviour for the better.
I don't think there's the same justification for <idle-seconds/>,
though, is there? What would a sending implementation do?
Uh, there is much value in the information found in <idle-seconds/>.
Simply put, it allows the receiving side to delay liveness checks for
the connection until it has been idle longer than idle-seconds.
I actually have some very unfinished ProtoXEP from 2017 with similar
goals (and a bit more [1]):
https://geekplace.eu/xeps/xep-dpmipy/xep-dpmipy.html
I think many initial implementations of (bidirectional) XMPP connections
start with some sort of periodic ping to check if the connection is
still alive. Then, at some point later some nifty developer recognizes
that such checks only need to be performed after the connection has been
idle for a while. Now the developer changes the implementation to check
every N minutes if the connection has been idle for M minutes, and only
performs the liveness check if this is the case. This avoid unnecessary
pings, which is especially important for mobile devices so that they are
not unnecessary woken up by pings.
Now the question is how to determine M? If the mobile client tells the
server that it will perform liveness check every 60 minutes, because
that is when other scheduled actions will take place on the mobile
device and hence the device won't be in deep sleep anyway, then the
server could simply set M to 60 minutes [2].
That, at least, was my motivation for said ProtoXEP. But it appears,
from the description of <idle-seconds/>, that it also shares the
motivation (but maybe there is more to it?).
- Flow
1: The idea of my ProtoXEP is that the client tells to the server that
the server should not ping the client, as the client will ping the
server after the connection has been idle an client-announced period of
time. With the goal to reduce unnecessary wakeups of the mobile device
because of server-to-client pings.
2: The situation is actually a tiny bit more complex because scheduled
actions on mobile devices are typically coalesced. But that only means
that clients have to add the maximum coalescing period to the scheduled
interval when calculating M.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
