Re: [Webpush] Message expiration (TTL) and Negative Acknowledgements

[Benjamin Bangert <[e-mail]>]

I'd prefer to not have to send NACK's in the event that the Push Service
has to clear them out for a user that stored too many. But that's possibly
not an option?

For the NACK's, speaking of server constraints, how many receipts is a Push
Service expected to buffer for an App-Server? If an App-Server sends 500k
notifications in, and happens to not be connected to the receipt server at
the time.... how many of those is the Push Service supposed to hold onto
until the app-server starts pulling them?

If the stream of NACK's is several magnitudes higher than an App-Server can
process them, at what point can a Push Service start dropping NACK's on the
floor?

On Thu, Oct 15, 2015 at 10:10 AM, Martin Thomson <[e-mail]>
wrote:

> On 15 October 2015 at 09:07, Benjamin Bangert <[e-mail]>
> wrote:
> > What steps are being taken with NACK's to ensure an app-server doesn't do
> > something like this? Is there going to be some status code or something
> to
> > indicate that these messages shouldn't be retried for some period of
> time?
> >
> > Or is it going to be up to a Push Service to try and detect these loops,
> and
> > when they occur, the Push Service is just going to have to fully expire
> all
> > the clients subscriptions to stop the loop?
>
>
> What steps do you think are appropriate.  I'd have to think some more
> on it, but I think that the only reasonable option is to have the push
> service do something.  We could recommend the use of Retry-After on
> nacks.
>
> Other than that, I guess that this is something the push service needs
> to handle.
>