Unsubscribe concept

[Uscher]

Hi

I have the problem, that for a single message multiple pushes are done due to obsolete subscriptions:

[Push][Info] 2014/09/05 14:31:21 RequestId=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== From=127.0.0.1:43579 Service=ajoy NrSubscribers=1 Subscribers="[41791336366]"
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:ff45d9d3fe2097d83428f3396026b6c9ec39a821 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281768366%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:5116a73c3d2981293aafa49c318a5e9de5a10554 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281767749%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:c5fecf3befc8c60495d0034f3654302a8f986633 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281767947%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:00a578fca5352fc1e1acf1921e51c4dbaaaa7ac1 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281767415%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:8e4a91f37f70f581fccafad54d5cf349948d511f MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281768063%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:cada49dafd2a92aa4ab95e3df6285b76bec795f1 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281767945%68a2998ff9fd7ecd Success!

For APNS the device token can change. And for GCM on each new app version the registration ID changes.
What is the concept for unsubscription?

In documentation is stated:

..you don’t need to consider if the GCM will update the registration ID for the device. Uniqush can handle it.

Does the device have to unsubscibe the obsolete ID when it subcribes the new ID?
The device could remeber the last ID. But after an app re-install or device reset this is not possible.

Thank you.

Best regards,
Urs

[Monnand]

Hi,

Thanks for using Uniqush. Please check out my answers below:

On Fri, Sep 5, 2014 at 2:10 PM, Uscher <urs.s...@gmail.com> wrote:

Hi

I have the problem, that for a single message multiple pushes are done due to obsolete subscriptions:

[Push][Info] 2014/09/05 14:31:21 RequestId=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== From=127.0.0.1:43579 Service=ajoy NrSubscribers=1 Subscribers="[41791336366]"
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:ff45d9d3fe2097d83428f3396026b6c9ec39a821 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281768366%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:5116a73c3d2981293aafa49c318a5e9de5a10554 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281767749%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:c5fecf3befc8c60495d0034f3654302a8f986633 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281767947%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:00a578fca5352fc1e1acf1921e51c4dbaaaa7ac1 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281767415%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:8e4a91f37f70f581fccafad54d5cf349948d511f MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281768063%68a2998ff9fd7ecd Success!
[Push][Info] 2014/09/05 14:31:21 RequestID=5409ad19-lu0Vq-D8zcvd1ZZKVz8RBA== Service=ajoy Subscriber=41791336366 PushServiceProvider=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea DeliveryPoint=gcm:cada49dafd2a92aa4ab95e3df6285b76bec795f1 MsgId=gcm:6ce5b2f53df06067b4744d81efbdd31efbe7c5ea:0:1409920281767945%68a2998ff9fd7ecd Success!

For APNS the device token can change. And for GCM on each new app version the registration ID changes.
What is the concept for unsubscription?

According to the log, uniqush treats these registration IDs as different delivery points.
 

In documentation is stated:

..you don’t need to consider if the GCM will update the registration ID for the device. Uniqush can handle it.

Well. I was intended to say that uniqush will update the registration ID if GCM told uniqush to do so. GCM (and APNS) will reply a special message if the a registration ID or device ID is updated. Uniqush will handle this case smoothly.

Does the device have to unsubscibe the obsolete ID when it subcribes the new ID?

Yes. Because from the perspective of uniqush, it does not know if two registration IDs are on the same device. It is totally valid if a user has two android devices with two different registration ID.
 

The device could remeber the last ID. But after an app re-install or device reset this is not possible.

The device will not remember its old ID, but the server should. You may not want to expose uniqush to the public Internet directly for security reasons. That means the client should not talk with uniqush directly. Whenever you add a new device in uniqush, you may want to store this relationship in some database because redis, which is used by uniqush, is only an in memory data store.

Thank you.

Best regards,
Urs

--
You received this message because you are subscribed to the Google Groups "uniqush" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uniqush+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Uscher]

OK, thank you Monnand, I will do that.

But how can I clean up those obsolete subscriptions? I do not know the oblsolete IDs.
Is there a way to remove a subscriber completely?

Best regards,
Urs

[Monnand]

Hi Uscher,

Here's a hack: You can access redis directly and remove corresponding
key-value pairs. Here's how you'd do it:

- use redis-cli to log into redis data store.
- Assuming the subscriber name is username; the service name is srvname.
- Run this command in redis client: SMEMBERS
srv.sub-2-dp:srvname:username (NOTE: replace srvname and username
accordingly)
- Redis will return a list of delivery points associated with the user
under the service. Let's say it returns two strings:
* gcm:somehashvalue1
* gcm:somehashvalue2
- Then you could find keys corresponding to those delivery points.
Given the examples above, you will find the following keys:
* delivery.point:gcm:somehashvalue1
* delivery.point:gcm:somehashvalue2
To make sure they are there, you could use the GET command in redis
client: GET delivery.point:gcm:somehashvalue1
- Delete those delivery point keys:
* DEL delivery.point:gcm:somehashvalue1
* DEL delivery.point:gcm:somehashvalue2
- Delete the counters corresponds to those delivery points:
* DEL delivery.point.counter:gcm:somehashvalue1
* DEL delivery.point.counter:gcm:somehashvalue2
- Delete the set of deliver point names:
* DEL srv.sub-2-dp:srvname:username

Please let me know if this works.

Regards,
-Nan

[Uscher]

Hi Nan

Works like a charm. I was able to clean up. And it also helped me to resolve this issue.

Thank you for your excellent support again.

Urs

[Monnand]

No problem. Glad to know it solved your problem.

May be I should add a function to remove a subscriber.

[Misha Nasledov]

On Friday, September 5, 2014 at 3:35:58 PM UTC-7, Monnand wrote:

The device will not remember its old ID, but the server should. You may not want to expose uniqush to the public Internet directly for security reasons. That means the client should not talk with uniqush directly. Whenever you add a new device in uniqush, you may want to store this relationship in some database because redis, which is used by uniqush, is only an in memory data store.\

Very good points. uniqush should definitely not be exposed to public clients, consider something in between that defines the exact interface clients speak. In my case, the PHP application layer is what interfaces with uniqush-push.

As far as keeping a relational database for adding devices to uniqush, I've considered that unnecessary and have found this one of the great benefits of uniqush. I have set up a sharded Redis tier with persistence -- so one has the benefit of it being an in-memory data store but persistent as well. I'd rather not keep two data sets of devices -- it seems optimal to have uniqush as the sole source of authority here.

[nick2100]

Hi, 

  I have some questions related to this topic, so I just ask here.

1. For a scenario: 

User installs an Android App and subscribes to an event. Now in Redis db there is an associated delivery point. 

Then user uninstalls the App without unsubscribing the event. The delivery point is still there in Redis.

The user installs the App again without subscribing any event. But now the user will receive push notifications by the old delivery point.

If user subscribes now, there will be 2 delivery point with different reg_id. 

According to the discussion above, do I need to recognize the device from a front end and unsubscribe the old one manually?

But how can I recognize these 2 reg_id as the same device?

2.

 Well. I was intended to say that uniqush will update the registration ID if GCM told uniqush to do so. GCM (and APNS) will reply a special message if the a registration ID or device ID is updated. Uniqush will handle this case smoothly.

When a reg_id is updated, how uniqush know this information? In my thought: When uniqush send a push to GCM using the old reg_id, then GCM will reply with the information about the update. Is that correct? 

Thank you!