With the introduction of topics in android gcm I was evaluating this option to easen the work that should be done to mantain in sync our server with some subscriptions.
However I have read in the documentation that the use of topics is limited to 1 million subscriptions. Does this mean that you can't have more than one million users (with one or more topics) or that you can only have 1 million topics subscribed (for example 100.000 users subscribed to 10 topics each) ?
It's a limit on subscriptions in your app in total, across all topics created within your app.
You will get a TOO_MANY_SUBSCRIBERS error when the number of subscriptions per app exceeds the 1 million limit.
I think the limit has now been scrapped:
GCM topic messaging allows your app server to send a message to
multiple devices that have opted in to a particular topic. Based on
the publish/subscribe model, topic messaging supports unlimited
subscriptions per app.
https://developers.google.com/cloud-messaging/topic-messaging
You could try to work around this limit by using multiple SENDER_IDs when registering devices.
Since the 1 million subscriptions limit is enforced application-wide, I'm pretty sure that Google's way of tracking that is via the SENDER_ID.
And then, on the server-side, you'd have to issue multiple publish requests to GCM (each time with a different Server API Key, to support more than 1 million devices).
I'm going to test this theory out and let you know what I find. The worst-case scenario is that it is enforced via the application's package name (com.example.package), and then there is no elegant workaround.
Update: The limit has now been removed!
We’re now happy to announce that we’re allowing unlimited free topics for your app. This means app developers can place an unlimited number of devices within each topic and create an unlimited number of topics.
http://googledevelopers.blogspot.co.il/2015/12/google-cloud-messaging-weve-come-long.html?utm_source=Android+Weekly&utm_campaign=1cb848077c-Android_Weekly_184&utm_medium=email&utm_term=0_4eb677ad19-1cb848077c-337844217
GCM now removed the limit, check this: https://developers.google.com/cloud-messaging/topic-messaging
Also Firebase Cloud Messaging (FCM) the same. https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
GCM topic messaging allows your app server to send a message to
multiple devices that have opted in to a particular topic. Based on
the publish/subscribe model, topic messaging supports unlimited
subscriptions per app. The app server sends messages with payloads up
to 2KB to the topic, and GCM handles the message routing and delivers
the message reliably to the right devices. For example, users of a
weather forecasting app could opt in to a "severe weather alerts"
topic and receive notifications of storms threatening specified areas.
Topic messaging supports unlimited topics and subscriptions for each app.
Check This
[FCM Notifications][1]https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
Related
we're currently working on the design for an UCMA application that should be able to subscribe to presence updates of up 15k users. Reading the (rather outdated) documentation we noted the following:
Lync Server 2013 also places a limit on the subscription response body length, so an application that subscribes to a large number of users (typically more than 1000 users) might receive an error response from Lync Server 2013.
Does anyone know if this still true for Skype for Business 2015/2019 or where to find current docs?
Further down the same doc states that, for a large number of subscriptions, it is recommended to limit the categories we subscribe to. We're only interested in the presence state, so that's a good workaround for us. However I can't find much information about what difference that makes, like if we subscribe to only the presence state, can we have 2x or 5x or 100x the number of subscriptions?
Searching around I found this post that seems to say we can subscribe to many more users if we create batches of a few hundreds. So does the above limit of 1000 users apply per BeginSubscription() call?
Many thanks in advance!
Sounds like you are reading the UCMA 4 (Lync 2013) documentation.
There is the UCMA 5 (SfB 2015) documentation but there are no real differences.
UCMA 6 (SfB 2019) is available but there isn't any documentation.
From personal experience, you can use any of the UCMA versions to get the job done. The details haven't changed.
If you want to subscribe to SfB online accounts, you will have to use UCMA 5 on SfB 2015 or UCMA 6 on SfB 2019 as UCMA 4 on SfB 2015 / 2019 doesn't work for SfB online accounts. The is the only gotcha I have found.
I've gone up into a 100's of subscriptions and I think some of our customers are up to around the 1k mark using batch subscriptions. I use a batch size of 100 and it's working ok for me.
You are not going to know until you test it yourself to see how to performs with batch sizes you test with if it's to slow or fast enough.
At the 15k mark, it's getting to be a lot of subscriptions to take care of. This may start putting unwanted overhead onto the SfB system at that level of subscriptions due to the extra messages / subscription polling going on. You may need to look into splitting the subscriptions between applications / machines to load balance the work.
If you find that it's not working very well you may need to think about switching from a UCMA application to a Server App (sip proxy) application that runs on the FE machines and sniffs the sip traffic to view the presence change traffic as they happen. It's a lot more work but would not generate as much overhead as a UCMA application.
I'm using OpenTok Web Client SDK and OpenTok .NET Server SDK to generate TokBox sessions that are always going to be multiparty conferences with video being published by many.
I'd like to limit the number of streams that can be published and somehow set that as a session property. Right now I know this value - the number of current publishers - in the client side, and I can of course prevent a new user to publish, but I'm running into this scenario where two users try to publish at the same time, and both are accepted. Ideally the user who published the very first of the two should be accepted, so I'm wondering if there is a way to set this property in the TokBox "server side", as a session property, so the server would reject a new publisher if max. reached.
Please notice that I don't have any server state on my own that keeps track of the created sessions nor how many publishers they have, etc.
Thanks!
Adam here from the OpenTok team.
There is no server-side setting available in OpenTok to limit the number of streams allowed. You could do something like I suggest in this answer though. Where you keep track of streamCreated Events and look at the creationTime property and if your stream is the n-th then you unpublish. Or you can forceUnpublish the n-th stream.
I want to send OTP , first to Telegram with usual SMS fallback.
Therefore i have to detect read callback of OTP message from user only with telegram cli API, unfortunately(Telegram bots doesn't provide read ack. feature).
There is no any concrete info in Telegram.
Is there any limit related to telegram bot (and telegram cli) subscribers(contacts) count? Except report spam.
Also what is the limit with native telegram api sendMessage? Which density i have to keep to not banned? Also do i need more numbers or accounts for this?
I searched everywhere and can't find relevant numbers although there are some users with plenty number of accounts.
Thanks for help!
UPDATE
Limitations on bot like 30q/sec and etc. is explicit in FAQ. i have to know all other limitations, especially on CLI(max contacts, requests frequency limit). For example, i have to know is this number registered in telegram - This is possible only with cli.Therefore i don't want to abuse platform restrictions, cause of commercial cause. Glad to hear more official ways.
You can check out Bot FAQ:
If you're sending bulk notifications to multiple users, the API will
not allow more than 30 messages per second or so. Consider spreading
out notifications over large intervals of 8—12 hours for best results.
Also note that your bot will not be able to send more than 20 messages
per minute to the same group.
I'm looking at the Quickblox demo for Video chat, and am interested in perhaps signing up, can someone provide some information on how much resources are needed to run an instance of the Video chat application, per conversation would be fine, may be able to calculate the total for the desired usage. As I understand it the service is a broker for the connection so in theory should be quite small? But would that mean with the Free for instance I would be limited to a single connection being limited to 20 connections per any 20 second period, so if I had a class of 30 I'd need to throttle 10 to have all connect to the chat?
http://quickblox.com/plans/
http://quickblox.com/developers/Sample-webrtc-web
Thanks
I have a use case to implement a 'like' feature for messages using GCM. One approach that comes to mind is to make each post a 'topic' and then send all likes on a post as a separate GCM message on that topic.
However, in order to achieve this, the client has to register for each topic corresponding to the post that it has loaded on the UI in real time. This brings me to the following questions:
This is approach right?
How long will it take for a client's subscription to a topic to reflect at GCM's end? Same for unsubscription?
Can I get a list of all subscribers to a given topic?