ubuntu-push-devs team mailing list archive

[Lucio Torre <lucio.torre@xxxxxxxxxxxxx>]

On Mon, Oct 7, 2013 at 4:55 PM, Peter Saint-Andre <stpeter@xxxxxxxxxx>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/7/13 1:37 PM, Ted Gould wrote:
> > On Mon, 2013-10-07 at 11:00 -0300, Lucio Torre wrote:
> >> On Mon, Oct 7, 2013 at 1:01 AM, Ted Gould <ted@xxxxxxxxxx
> >> <mailto:ted@xxxxxxxxxx>> wrote:
> >>
> >> It seems like the critical issue here is how XMPP
> >> implementations deal with scaling.  Do you know how that's
> >> typically done?  Is that per-implementation or are there some
> >> standard strategies?
> >>
> >
> >> Not only that, but also that there is no spec on
> >> Once-And-Only-Once delivery. At-Most-Once is the standard fire
> >> and forget delivery, At-Least-Once is the one that you get with
> >> unreliable acks.
> >
> >> So, xmpp also means non-trivial dev work and inventing our own
> >> standards.
> >
> > I'm not sure exactly the use-case you're going for here,
>
> I'm not either. Is there a design document that would help clear this
> up? For example, are there specific requirements driving "once and
> only once" as opposed to "at least once" (with de-duping to happen on
> the receiver side)?
>
>
If anything the use case for notifications delivery is "don't lose them and
don't bother the user with expired/redundant notifications". De-duping on
the client side is part of making Once-and-only-once. In the same way that
"unreliable" messages can be used to build "reliable" communication.


> Also, I'd be curious what you mean by "reliable" because, in my
> experience, "reliable" is about as clearly defined as "secure".
>
>
It obviously means having a known set of failure modes that we consider
acceptable ;)

In this scenario, for at-least-once or better, i would describe reliable
as: Once we ack the request to the third party server, we guarantee
delivery to the client unless:
1- the client never connects again
2- we suffer a storage level incident which produces data loss.

This is at the protocol level. At the implementation level we also get to
decide that loss of one storage node should not cause data loss.

Using only offline messaging for notifications and pure messages for
wakeups, we could do:

Http service receives notification from 3party service.
  - Sends message to be stored as offline message
  - Waits for ack
  - Sends wakeup to the device if connected
  - reply OK to the 3rd party

Client connects to the server to get notifications:
  - upon connect, process offline messages
  - wait for wakeup to process offline messages

Process offline messages is:
  - get-all-offline-message
  - for each:
      - if not seen
          - generate local notification
          - mark locally as seen
      - send delete
      - remove seen mark.

This would be reliable against network issues, but not client failure
(duplicate deliveries)

Lucio.