Hello,
On Mon, Nov 06, 2006 at 04:41:03PM +0000, Dave Cridland
wrote:
> Thanks, this looks like a great start.
>
> On Sun Nov 5 02:12:41 2006, Justin Karneges wrote:
> > 7. When a stanza is received, containing an 'r'
attribute
> >("request ack")
> > with a value of "true", the
recipient MUST acknowledge the
> >stanza by
> > sending an <a/> element qualified by the
> > 'urn:ietf:params ml:ns
mpp-a
ck' namespace back to the sender.
> > Stanzas not containing an 'r' attribute MUST
NOT be
> >acknowledged.
> > Several stanzas MAY be acknowledged at one
time by including
> >an 'n'
> > attribute in the <a/> element, set to
the integer value of the
> >number
> > of stanzas. An ack indicates stanza
acceptance, in that the
> >stanza is
> > now safe in the receiver's hands and that the
receiver will
> >take care
> > of it from that point. Acks do not indicate
successful
> >delivery to a
> > remote entity beyond the receiver. The sender
does not have
> >to wait
> > for an ack to continue sending stanzas. Acks
SHOULD be sent
> >as soon as
> > possible, and MUST NOT be withheld for any
condition other
> >than a
> > timeout. For example, a client with a slow
connection might
> >want to
> > collect many stanzas over a period of time
before acking, and
> >a server
> > might want to throttle incoming stanzas. As
acks indicate
> >stanza
> > acceptance, a server that is throttling
stanzas MUST defer the
> >acks
> > until the client is no longer being penalized.
>
> Okay, here I diverge more... I would say that a
receiver MAY send an
> ack even if not requested, if it is also sending other
stanzas. I'm
> not wedded to this by any means, but it might be nice.
The intention
> here is to allow a receiver to plonk an <a/> onto
the end of a packet
> if it's sending. An alternate here would be to give
several possible
> values for 'r', indicating whether you want an ack at
all, and if you
> do, whether "sometime" or
"immediate". I'm not wedded to that either,
> but I'd love to see some discussion.
>
> Also, I would replace "Acks SHOULD be sent as soon
as possible [...]"
> with something like:
>
> Acks SHOULD be sent in a timely manner, however
receivers MAY delay
> sending an ack for a short period in order to increase
efficiency.
> Receivers MUST NOT delay sending an ack for more than
15 seconds,
> allowing the requesting peer to timeout the connection
after 30
> seconds.
>
> Rationale is that you want mandatory timeouts here, and
I too was a
> little confused by what you meant there. Feel free to
adjust the
> mandatory timeout figures. The idea is that a client
gets to be
> assured that if it asks for an ack, if it hasn't had
one for 30
> seconds (in this case) the connection is dead.
IMHO, this should be configurable. I agree it is plenty of
time for most
people. However, I would set it to some 3 minutes for
myself. It happens
sometime I have a short (~1 minute) internet break. Now, I
just get all
the messages after the internet starts again. This way, I
would need to
reconnect and everyone would see I disconnected.
--
This email has not been checked by an antivirus system.
No virus found.
Michal "vorner" Vaner
|