On Mon Jul 12 18:25:32 2010, Bruce Campbell wrote:
On Mon, 12 Jul 2010, Dave Cridland wrote:
I missed these.
On Mon Jun 7 18:16:54 2010, Matthew Wild wrote:
Having recently implemented an initial version of XEP-0198
acknowledgements support for Prosody, I have some feedback:
2) I'm not sure how much sense it makes for the period between ack
requests to be determined by the number of sent stanzas. On
inactive
streams stanzas could be received but remain unacknowledged for
extended periods of time. Surely it would make more sense to say
"Each
stanza should be acknowledged within X seconds of sending"?
I'd actually say "a reasonable time". What the maximum is varies
depending on network conditions.
You could also specify an 'interval' attribute in the <enabled/>
stanza to determine how often to generate/respond to ack requests
in a busy stream, and how long after the last stanza to send an ack
request when the stream goes quiet.
Well, the thing is that you actually want to ack quickly - almost
instantly - most of the time.
As a server, acking is cheap. Doing so quickly means that you'll
catch a mobile client when the radio is in DCH, too, reducing
wake-ups.
As a client, however, transmission may be quite costly, so there's
advantage in buffering up an ack until you're sending something else
to reduce the TCP overhead (saving, erm, 57 octets or something). But
you don't want to wait if you don't think the user's typing a
message, or whatever, because otherwise you're going to wake the
radio again for nothing.
So I think the general rule would be to ack once you've processed all
the stanzas, just before a flush - unless the user is actively typing
a message, or you similarly know another flush will happen very soon,
in which case delay the flush.
FWIW, I think implementations which delay too long will get <r/>,
which will itself cause battery drain by raising the radio.
Of course, this is being very 3G-centric... If we're talking HF
radio, where you have a very low banwidth half-duplex link, then
expecting your peer to ack within a minute is pretty optimistic
because it'll take 30 seconds to turn around the modems. And if
you're over a LAN, then really, you just ack everything within a few
ms.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
