On Fri, 30 Dec 2022 at 19:40, Florian Schmaus <[email protected]> wrote:
> 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. > > Really? So as a client, if a server says that connections can be idle for up to 1800s, you'd not bother checking them for a half hour? If a server sees the connection drop (TCP RST from NAT or something) then the client won't know about it, so surely both need to perform liveness checks as they see fit. I can see why the *server* might adapt its liveness checks to match the client's, but this XEP doesn't cover that. > 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?). > > This all makes (a lot of) sense, but isn't possible with the proposal. > - 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. > This feels like some guidance would be warranted, akin to (or part of) XEP-0286. > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
