On 3/31/09 6:07 AM, Fabio Forno wrote:
> On Tue, Mar 31, 2009 at 3:23 AM, XMPP Extensions Editor
> <[email protected]> wrote:
>> Version 0.7 of XEP-0198 (Stream Management) has been released.
>> 
>> Abstract: This specification defines an XMPP protocol extension for
>> active management of an XML stream between two XMPP entities,
>> including features for stanza acknowledgements and stream
>> resumption.
>> 
>> Changelog: Removed pings (use XEP-0199, whitespace pings, or TCP
>> keepalives instead); removed section on throttling, since it is
>> unworkable. (jjh/psa)
> 
> Imho some throttling "notification" is feasible only in one way: it's
>  up to the  server send unsolicited throttling notifications when it 
> knows it is throttling voluntary the stream (this means that if 
> packets are stuck in a TCP buffer it's likely that even the server 
> doesn't know that the stream is being throttled). Anything triggered 
> by a stanza sent by the client is unworkable since that stanza cannot
>  have higher priority and pass ahead the others. As optional I'd put
> a stanza for this purpose:
> 
> S: <t xmlns='urn:xmpp:sm:1' max="n"/>
> 
> It isn't perfect but it can work for most of the cases.

Either that or the server could send a special message stanza to the
client. But including this in XEP-0198 seems good.

> And what about reqs and acks? In the previous thread 
> (http://mail.jabber.org/pipermail/standards/2009-March/021409.html)
> we saw that <r/> stanzas after the regular ones could lead to some
> lack of reliability, while it's better to just count stanzas and send
> back <a/> acks

I would prefer the sequence number to be a stanza count, but Justin
talked me out of it while I was making revisions. However, from the post
you've pointed to, he seems to agree, so I'll fix that.

As to sending <r/> after the stanza, I'm not quite sure what you
propose. Do you think that the server will just send <a/> based on its
stanza count (perhaps after every stanza), without forcing the client to
request acks?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to