Re: [Webpush] When UA should send an acknowledgement?

[Martin Thomson <[e-mail]>]

I'm sorry, I'm confused by your message.  I can't decide if you want
at-least-once, or at-most-once.  End-to-end ack, i.e., ack after
successful processing, is in support of at-least-once, which I think
is consistent with other decisions we've made in the overall design.

On 8 June 2016 at 15:15, Benjamin Bangert <[e-mail]> wrote:
> On Tue, Jun 7, 2016 at 9:36 PM, Martin Thomson <[e-mail]> wrote:
>> On 8 June 2016 at 13:17, Benjamin Bangert <[e-mail]> wrote:
>>> For our implementation, we will actually never send more notifications
>>> until all sent ones are ack'd. This means if a message is malformed or
>>> causes a UA error in a UA that actually follows the DOM spec, it will
>>> never get a notification again (except the notification it won't ack).
>>
>>
>> This is fine, as long as you regard unacknowledged messages that you
>> thought were delivered as poisonous after a certain amount of time (or
>> retries, if you do that).  If you follow that advice, then progress
>> will eventually be made.
>
> This recommendation isn't in the WebPush spec. By mandating that the UA
> MUST ack every message it's clear that failure to ack a message should
> result in redelivery attempts.
>
> If it's intended that a UA does not need to ack every message, the WebPush
> spec should be updated to reflect that. I could see a PS reasonably
> considering messages dead if other messages were ack'd or some other
> command came over the connection such that the server knew that
> the client is alive and likely processed it.
>
> Automatically ack'ing a message in this manner for the PS has as many
> problems if not more than requiring the UA to ack every message though.
> It also introduces a lot of complexity into the PS and may result in very
> long message delivery times should a UA get bogged down with many
> improperly encrypted messages.
>
>>
>> I expect that Costin will agree with you, but we've discussed this in
>> the past.  The problem here is that an acknowledgment from the user
>> agent doesn't constitute a useful signal.  You have moved the problem
>> to a second middle-man.  When the user agent acknowledges prior to
>> processing the message, how will the application know that it was
>> processed?  Can you guarantee that?  When the browser crashes, your
>> message is still lost.
>
> Why not change the DOM spec to indicate that if a message was
> processed and failed for some reason it should still be ack'd?
>
> If the same message consistently crashes the browser, I would expect
> the browser to track that fact and avoid the message again in the future.
>
> Clearly we have the choice of guaranteeing that a message will be
> processed at-most-once, or at-least-once, since a crash immediately
> after processing could stop the ack from making it back. If the desire
> is at-most-once, then the UA should ack immediately upon receipt of
> the message (or the PS can consider it ack'd if a PING frame is
> returned after sending a message, etc.).
>
> The Push DOM spec seems to favor the at-least-once model, in which
> case it would be appropriate for the UA to always ack a message even
> if it decrypts improperly, or the SW throws an exception, etc.
>
>>
>> The only way for this to be a good signal is to have the
>> acknowledgment be end-to-end.
>>
>> (p.s., I don't know if your assertion is true or not.  I don't think
>> that it matters.  I should know that code, but it's an absolute rats
>> nest, despite Kit's recent efforts at cleanup.)