985388 - Loop Server — Decide if we want TTL on user registration to manage expired data.

Status: VERIFIED INVALID

(Hello (Loop) :: Server, defect)

Description

[Rémy Hubscher (:natim)]

Today we store a SimplePush URL per User that will be replace by a new one.
In the future, we will store a SimplePush URL per user device and replace by new ones for a specific device.

Do we want this registration to expire after some time?

We cannot know when the SimplePush URL will expire.

What we could do is defined a TTL and ask the client to register after this amount of time?

Comment 1

[Alexis Metaireau (:alexis)]

The current design is made such that simple push urls never expire; We could either put a really high value there (like 6 months) or just don't expire it.

Comment 2

[Rémy Hubscher (:natim)]

For now I think we should expire the record in the database at the same time as the session expiration time.

Comment 3

[Rémy Hubscher (:natim)]

Attachment: Link to GitHub PR.

Comment 4

[Fernando Jiménez Moreno [:ferjm]]

Does this mean that a device won't be able to receive calls after its session expires if it doesn't register itself again?

Comment 5

[Rémy Hubscher (:natim)]

Yes. Btw for now the sessionDuration default to 300 days and the registration is done each time Firefox starts.

Comment 6

[Fernando Jiménez Moreno [:ferjm]]

Can I ask why? :)

I mean, why do we want users to stop receiving calls after some time of inactivity?

In Firefox OS the app is not going to be opened during the boot process of the device, so it is possible that the user doesn't open the app for a long time and so her push endpoint expires. In that case, the user won't be able to receive calls until she opens the app again.

Comment 7

[Fernando Jiménez Moreno [:ferjm]]

If we are worried about keeping dead push endpoints the Simple Push server already handles this with its garbage collection policy.

Comment 8

[Rémy Hubscher (:natim)]

Well we don't want the user to stop receiving calls, what we want is to loose information about dead devices.

We know that Simple Push URL may become invalid after some amount of time but we don't know how much time.

Also calls urls expire after maximum one month so if the user want to be call again, it must to be register and create a new call-urls.

What do you propose to forget about dead Simple Push URLs?

Comment 9

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #7)
> If we are worried about keeping dead push endpoints the Simple Push server
> already handles this with its garbage collection policy.
Actually, it doesn't handle it the way I thought.

https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Garbage_collection

(In reply to Rémy Hubscher (:natim) from comment #8)
> Well we don't want the user to stop receiving calls, what we want is to
> loose information about dead devices.

I guessed so :).

> 
> We know that Simple Push URL may become invalid after some amount of time
> but we don't know how much time.
> 
> Also calls urls expire after maximum one month so if the user want to be
> call again, it must to be register and create a new call-urls.

Call urls won't be the only way to contact an user.

We will be allowing users to be called by other users by using their FXA emails and/or MSISDNs, so we need their push endpoints alive so the server can notify them about other users wanting to call them.

This is of course for MVP. If this bug is for MLP only, then I have no other objections :).

> What do you propose to forget about dead Simple Push URLs?

I'm not sure if a simple ping would fail in case of dead push endpoints.

If that doesn't work, maybe we can ask the Simple Push server folks to expose a way for us to check the health status of an specific push endpoint. If the session expires and the push endpoint is dead, we can remove it.

Comment 10

[Rémy Hubscher (:natim)]

I see two solutions for that:

  - Either we keep all SP URL without TTL (It doesn't matter to PING dead SP urls)
  - Either we ask the client to register itself at least one time a month (or so) and we know for sure the exact list of user device at all time.

Comment 11

[Fernando Jiménez Moreno [:ferjm]]

We've been talking this over IRC. There's another alternative:

- We could register two different push endpoints per user client (device), the one that we are currently registering for call notifications and another one for "ping" notifications. (There might be more push endpoints in the future anyway).
- We can use the "ping" endpoint to check the health status of the client. When a client receives a "ping" notification, it should reply back to the server with the notification version.
- If the server doesn't get the response from the client after a reasonable TTL, we can remove the endpoint then.
- We can send these "ping" notifications when registering new devices or when the session expires.

Comment 12

[Alexis Metaireau (:alexis)]

Just adding some information because it's not already in there. The decision set the TTL of the SP URL to the duration of the session is only for MLP.

On the long run (for MVP), we will be able to identify the devices, and we will have only one SP URL per device. Since the number of devices per user is limited, I guess that would work okay?

Comment 13

[Adam Roach [:abr]]

(In reply to Alexis Metaireau (:alexis) from comment #12)
> On the long run (for MVP), we will be able to identify the devices, and we
> will have only one SP URL per device. Since the number of devices per user
> is limited, I guess that would work okay?

That was my assumption, at least for the short term. Long-term, we will probably want a ttl on the order of a year or so, to account for people switching out equipment. It's probably safe to assume that if someone has neither opened the application nor received a call in over a year from a specific device, they are either no longer using that device or no longer using the service. Either way, the push endpoint is no longer useful.

Comment 14

[Alexis Metaireau (:alexis)]

Comment on attachment 8406877 [details] [review]
Link to GitHub PR.

LGTM, but we don't want tests?

Comment 15

[Rémy Hubscher (:natim)]

Yes we do want tests.

Comment 16

[Alexis Metaireau (:alexis)]

Rémy, can you add tests there so we can merge?

Comment 17

[Alexis Metaireau (:alexis)]

Closing as invalid. We want to go with /unregister. See bug 1016886 for more info.

Comment 18

[James Bonacci [:jbonacci]]

OK.