We implemented the change notifications subscription for channel messages as per the Microsoft Teams guidelines. We received the messages within 1 minute until 12-July-2021. Now we see a latency of about 2 - 15 minutes for sometimes notably on PST day time.
According to this link (https://learn.microsoft.com/en-us/graph/webhooks#latency) channel messages will be notified within 1 minute.
Could you please let us know what is causing this delay serving the request ?
We would also like to know if there is policy or priority on serving the notifications based on tenant type.
Thanks in advance.
Related
For Silent-Push Notifications (SPNs), Apple suggests sending no more that 2 Pushes per device per hour. If you exceed this limit, the client's DASD (Duet Activity Scheduler Daemon) may throttle future SPNs to the target app. The decision heuristic for this throttling is not well documented, perhaps intentionally. But since SPNs are required to be set with apns-priority=5 (non-immediate, non-guaranteed delivery) what is the ideal send rate for getting a successful delivery to the app?
For example, are chances of successfully navigating the DASD better by sending 2 SPNs/device per HOUR (until an ACK is received by our server) or are the chances better with only 2 SPNs/device per DAY?
Any insight is appreciated. Thanks!
we are using Microsoft Graph notification to monitor certain resource changes such as group creation/deletion, etc.
In the MS doc it says "Send a 202 - Accepted status code in your response to Microsoft Graph. If Microsoft Graph doesn't receive a 2xx class code, it will retry the notification a number of times."
We'd want to have a better understanding on how this works, such as what are the timeout values (how long does Graph wait before it re-sends the notification?), and how many times it retries (is it a guaranteed delivery?), etc. Can anybody help shed some light on this?
The documentation for Microsoft Graph webhooks is not clear on the durability of events. If a client creates a subscription and then subsequently goes down (say, for maintenance), what happens to events that occur while the client is unavailable? Are they queued and retried by the Microsoft Graph until the client comes back online, or are they lost? If they are queued, for how long?
Graph Webhook will try to send the events a number of times within 4 hours window. If the client does not come back online after 4 hours, then these events will be deleted.
On their documentation they specify that "Users can keep a 30-day message history". I assume this means that after 30 days the messages are deleted,is there anyway of extending this or disabling this feature?
We should change the word history, we store the message for delivery for 30 days. There is not really an inbox with sinch, its a delivery process so every message will be stored for 30 days to be delivered to all the users devices.
The Apple APNS only allow up to 20 max connections from your server, so how does apps like WhatApp is able to deliver such high volume of message per seconds?
Even they can use multiple servers, but assuming they have 5M active users sending message, they also need 250K servers, that sound crazy, right?
What is the trick here?
It's very simple: You don't need one connection per user.
You can send multiple messages per APNS connection. Each message can be sent to a different device. The maximum payload length is 256 bytes plus 45 bytes of overhead; a 10Mbit connection can handle at least 4100 messages per second, or about 250k/min, or about 3 per hour per user.
Does the average "active user" send more than 3 per hour? It's hard to tell. "Active" might mean that they sent a message that month; such distributions have very long tails.
Either way, that's for a single 10M connection. I'm not sure how much contention there is on Apple's side, but it would not surprise me if you could exceed 50M without too much fuss.
Additionally, they almost certainly use their own servers when the app is in the foreground, and if they're clever they can keep the connection open for a few minutes after the app is backgrounded (and only use push notifications once the connection closes).