These are the things I want know.
1.Is there a way to send bulk messages using kannel?
2.We can use fakesmsc in the following way, but it sends the same sms to same number, multiple times
fakesmsc -r port -i interval -m count "from to text your message"
Is there a way to send same sms using fakesmsc with different recipient numbers?
For eg, using a file with recipient numbers
fakesmsc -r 13010 -i 0.1 -m 100 "66456 /root/recipient.number.list text test message"
3.Is there a way to send sms using cgi-bin url with a time interval?
for ex, like this url, is there a parameter like interval that we can say the interval?
cgi-bin/sendsms?from=66456&to=111+222+333+444+555&text=message&interval=0.1
4.Is there any other way to do this
5.What is the maximum incoming rate and outgoing rate (msg/sec) in Kannel?
Thank you!
Is there a way to send bulk messages using kannel?
Yes. You can use mtbatch command line utility from Kannel package. Just run mtbatch without arguments to see help message.
Is there a way to send same sms using fakesmsc with different recipient numbers?
Yes. It is possible to randomize messages in fakesmsc (see -z parameter description in fakesmsc -h output).
Example from fakesmsc -h output:
fakesmsc -z 7 -m 1000 "123<rand> 345<rand> text nop <rand>
Is there a way to send sms using cgi-bin url with a time interval?
No. You only can limit throughput on certain SMSC connection.
Is there any other way to do this?
Yes. You can use external software that will handle outgoing bandwidth. For example you can use mtbatch -d seconds to send messages with proper rate.
What is the maximum incoming rate and outgoing rate (msg/sec) in Kannel?
It depends on too many factors (hardware, networking, used protocols, configuration).
In practice I have reached 2,500 msg/sec rate on SMPP connection.
Related
I want to delete the sent deley message or modify the sent deley message expiration time.
You can reset the consume offset by RocketMQ DashBoard or command line sh mqadmin resetOffsetByTime,
sh mqadmin resetOffsetByTime -s timestamp -t topic -g group -n namesrv
No way to do that since RocketMQ does not support a message deletion in api.
You may consider achieving your goal when consuming.
For example, maybe you can define a consumer group called DelayMessageAdjuster, in this consumer you can check if the delay message should be aborted and adjust. If the answer is yes, then just send another new delay messages and something like this. I am not sure if this can achieve your goal.
I want to send a UDP packet from bash (perhaps using netcat or socat) and then receive the one-packet reply, or time-out after three seconds.
(Strictly, the listening needs to start before the initial packet is sent.)
Is this possible, or do I need to write my own small C program?
Netcat lets me either send or receive, so it won't do the job.
Likewise for socat.
Perhaps there is already a UDP request/response tool, but I don't know how to find it.
I need to write my own program for this use case.
Socats datagram mode works asynchronously. In particular, something like
socat -t 3 - UDP-DATAGRAM:localhost:7777,bind=:6666
might come near your requirements.
Currently I'm working on a SaaS with support for multiple tenants that can enable push notifications for their user-bases.
I'm thinking of using a message queue to store all pushes and send them with a separate service. That new service would need to read from the queue and send the push notifications.
My question now is: Do I need to come up with a complex sending strategy? I know that with GCM has a limit of 1000 devices per request, so this needs to be considered. I also can't wait for x pushes to fly in as this might delay a previous push from being sent. My next thought was to create a global array and fill it with pushes from the queue. A loop would then fetch that array every say 1 second and send pushes. This way pushes would get sent for sure and I wouldn't exceed the 1000 devices limit.
So ... although this might work I'm not sure if an infinite loop is the best way to go. I'm wondering if GCM / FCM even has a request limit? If not, I wouldn't need to aggregate the pushes in the first place and I could ditch the loop. I could simply fire a request for each push that gets pulled from the queue.
Any enlightenment on this topic or improvement of my prototypical algorithm would be great!
Do I need to come up with a complex sending strategy?
Not really. GCM/FCM is pretty simple enough. Just send the message towards the GCM/FCM server and it would queue it on it's own, then (as per it's behavior) send it as soon as possible.
I know that with GCM has a limit of 1000 devices per request, so this needs to be considered.
I think you're confusing the 1000 devices per request limit. The 1000 devices limit refers to the number of registration tokens you add in the list when using the registration_ids parameter:
This parameter specifies a list of devices (registration tokens, or IDs) receiving a multicast message. It must contain at least 1 and at most 1000 registration tokens.
This means you can only send to 1000 devices with the same message payload in a single request (you can then do a batch request (1000/each request) if you need to).
I'm wondering if GCM / FCM even has a request limit?
AFAIK, there is no such limit. Ditch the loop. Whenever you successfully send a message towards the GCM/FCM server, it will enqueue and keep the message until such time that it is available to send.
As I know concatenated sms are split in GSM handset and delivered to network. Does GSM standard talk about order of these packets? Will it be always sent in order? That is first sequence packet first and next later?
My questions regarding this.
1. Does SMPP talk about order of long sms segments? Like is it possible for SP to get out of order messages?
2. Does GSM handset deliver long messages always in order or not?
"long sms" officially known as concatenated sms can and will turn up in any order. Therefore the receiving device / system must be able to cater for this. Concatenated sms come in the form of multiple sms. Encoded within is the part number and the total number of parts for the concatenated sms (you can search for information on the "UDH - User Data Header" to get more information).
So answering your questions:
1) There is no ordering in the sending / receiving of concatenated sms. Only information within each concatenated sms part which says which part it is and how big the complete concatenated sms is.
2) GSM handsets tend to send out in order. The order is lost usually during the store and forward process on the SMSC side. On a side note GSM handsets when receiving a concatenated sms build the sms once all parts are received.
Twilio limits long code SMS to 1/sec. To improve my throughput, I split my batch into 5 phone numbers. I've found each HTTP POST to the Twilio API takes about 0.5 seconds.
One would think using 5 twilio phone numbers to send a message to 1000 cell phones would take 200 seconds, but it will take 500 seconds just to POST the requests. So two phone numbers will double my throughput, but more would not make a difference.
Am I missing something? I was thinking it would be nice if the API would take a list of phone numbers for the "To" parameter. I don't want to pay for a short code, but even if I do it seems the maximum throughput is 2/sec unless you resort to the complexity of having multiple threads feeding Twilio.
I've noticed TwiML during a call let's you include multiple sms nodes when constructing a response so it seems like there should be a way to do the same for outbound SMS.
Twilio Evangelist here. At the moment, we require that you submit each outgoing SMS message as its own API request.
The current rate limit on a longcode is 1 message per second. If more messages per second are sent, Twilio queues them up and sends them out at a rate of 1 per second.
A potential workaround is to make async requests across multiple phone numbers. This can be accomplished with the twilio node.js module or an evented framework such as EventMachine for Ruby or a similar toolset for your language of choice.
Hope this helps!
Here's a more modern answer. Twilio now supports Messaging Services. It basically lets you create a service that can group multiple outbound phone numbers together. So, when you fire off requests for a text to be sent, it can use ALL the numbers in the message group to perform the sending. This effectively overcomes the 1 text per second limit.
Messaging services also comes with Copilot. It adds several features such as "sticky sender". This ensures the same end user always gets texts from the same number in the pool instead of getting a text from different numbers.
If you are using the trial account, even looping with a 5s timeout between each item in the array did not work for me. And that was for just two numbers. Once I upgraded the account the code worked immediately without needing a timeout.
You know it's the trial account if the SMS you receive (when sending to only one number) says "Sent from your Twilio trial account - ".