C2DM collapse_key implementation explanation needed - android-c2dm

hi
I cannot see any explanation of the implementation of the collapse_key.
I think i understand what it does but not how it do it!
Android Cloud to Device Messaging Framework
I have a C2DM framework set up and sending 4 types of messages to many phones.
String messages very basic looks kind of like this:
type:name:uuid
type:name:uuid:number
type:uuid:id
If the phone is off many of this can get piled up waiting for phone on-line.
as far as i can tell my system works but what will the collapse_key do for me here?
addEncodedParameter(sb, "collapse_key", "no_ide_what_to_put_here");

You mentioned retrying the same message 3 times and using the same key value. It doesn't really have to be the same message. If you've got a message that indicates the current price of a stock, for instance, and you really only care about the latest price, then you could send different messages with the same key. When the device comes back online, it only gets the latest price quote message.
This may have been what you were saying already, but wanted to make it clear it's not only for "retrying sending same message".

I found this text: “collapse key” used for overriding old messages with the same key on the Google C2DM servers" I think if im retrying sending same message 3 times I must use same key value right. Google cloud server will send the latest msg with the same key value

...but be aware of the following (from http://code.google.com/intl/sv-SE/android/c2dm/):
"Note that since there is no guarantee of the order in which messages get sent, the "last" message may not actually be the last message sent by the application server."
But maybe this is not an issue if you don't generate a lot of messages.

Related

Firebase Error Message - The document has moved https://fcm.googleapis.com/batch?google_abuse=GOOGLE_ABUSE_EXEMPTION

We are sending lots and lots of FCM Messages to our millions of users. As the message is triggered by an external event (Kick off in a football match) we sent many messages at the same time.
Sometimes the sending of an FCM message fails and we get an error message like this:
<H1>302 Moved</H1> The document has moved
<A HREF="https://fcm.googleapis.com/batch?
google_abuse=GOOGLE_ABUSE_EXEMPTION%3DID%....3B+expires%3DTue,+22-Nov-
2022+19:04:17+GMT">here</A>. </BODY></HTML>
(I removed some text for privacy reasons.)
For sending the messages we use
implementation 'com.google.firebase:firebase-admin:9.1.0'
We got thousands of error messages like this in one minute. In the next minute everthing worked fine again.
I have search the internet for information about it. But i couldn't find any abuse rules for FCM. Does anybody has information about this kind of error?
firebaser here
At first glance, your project may be getting throttled, but it may also be another problem in the API calls or the FCM backend. It’ll be challenging to pinpoint or even narrow down what is the specific cause of the error on a public forum without going into project-specific details. I would recommend reaching out to Firebase support as they can offer personalized help. Please provide the latest request and response (with timestamp) you have so they can check what happened to the message delivery.

TimedOut in python-telegram-bot but message is sent

I've got following error while trying to send a message to a specific telegram channel:
TimedOut: Timed out
The read operation timed out
the method which I used from python-telegram-bot was send_message.
Although my bot got this error but it still sent the message to the channel and because I did not catch that exception all data from the message was lost but I really need to remove my messages from that channel after a specific period of time.
Is this OK that the bot sent the message even though it got Timed Out? How can I prevent this from happen again or remove this kind of messages from the channel after being sent?
Time out errors mean that TG didn't send a response to your send_message request quick enough. It does not necessarily mean that the request wasn't processed - that's why the message may still be sent. However, without response from TG, you don't have the message id of the resulting message and it will be hard to impossible to delete it.
You can try to increase the time that PTB waits for a response from TG. THis can be done in different ways:
with the timeout parameter of send_message
with Defaults.timeout, if you're using PTBs Defaults setup
by specifying it via the request_kwargs that you pass to Updater
You may want to have a look at this wiki page on networking.
Disclaimer: I'm currently the maintainer of python-telegram-bot
After a couple of hours reading here and there, and passing timeout=30 to context.bot.send_audio and getting an error that says unknown parameter even though send_audio's docs clearly states it takes a timeout param, I found that you can fix this by passing the timeouts to the Application upon building it:
application = ApplicationBuilder()
.token(bot_data["token"])
.read_timeout(30)
.write_timeout(30)
.build()
This fixed my bot. Hope this helps you as well.

Can you update a message on google nearby message API?

I have 2 simple questions that I did not find by reading the official documentation about google nearby message API
https://developers.google.com/nearby/messages/android/pub-sub
If you publish multiple messages with the publish method (on the same instance of an app), the messages are saved as several different messages or are updated and overwritten (on cloud console)?.
Is it possible with the publish method to update a message?
I'm building an application where each user sees what others are posting, but I just need to know the most up-to-date data of each user, I don't need all the messages.
Thank you.
With PubSub, you publish message in a queue. Then you can't update or delete them, they are published.
On the consumer side, the messages are usually distributed in the order, but without any guarantee. In each message, you have a published timestamp.
In your use case, it could be interesting to keep in memory the userID and the latest processed timestamp. If you application is distributed, the best is to store these data in memorystore.
Like that, when a message comes in
Either it is newer than the value in memory store and your process it
Or, it's older and your trash it.

depth of channel showing in nsqadmin increasing fast when producer send message to same topic via different nsqd

I play with nsqd a little bit and met the prob mentioned in the title. But when I send message via single nsqd, there is no such prob. Does this mean message should always be sent via same nsqd?
Here is my project. https://github.com/hoozecn/nsqd-cluster
It's resolved by set a higher MaxInFlight value.
ref: https://github.com/nsqio/nsq/issues/1213

Process SMS when notified via websocket

So I managed to connect to the websocket with my API token and I do get notifications. For incoming calls, I do get a push with all info like so:
{"type":"push","targets":["stream"],"push":{"type":"mirror","source_device_iden":"XXXXXXX","source_user_iden":"ujC7S24sQxw","client_version":206,"dismissible":true,"title":"5555551212","body":"Incoming call","application_name":"Pushbullet","package_name":"com.pushbullet.android","notification_id":"6","icon"
"Big value here"}}
So I can see that call came from 555-1212 (I changed number for privacy) and it all makes sense. However, for SMSs, all I get is a notification that SMS changed. No body field so I can't see where it came from and what the message is. All it says is sms_changed for type:
{"type":"push","targets":["stream"],"push":{"type":"sms_changed","source_device_iden":"XXXXXXXXX"}}
What am I doing wrong? I would like to get the SMS message and sender info so that I can publish it. Any and all help will be greatly appreciated.
This is not publicly documented yet and we might be changing the implementation in the near future so I'm hesitant to make it public. Also I don't know the specifics of the current implementation.
You can view how it works right now by using www.pushbullet.com and looking at the network traffic (in chrome inspector) when you do SMS stuff on the website.