0

I am putting together an application for a bulk SMS solution. I am comfortable writing the application in Java, Perl or PHP.

Kindly advise on the best medium to handle asynchronous messaging delivery.

I do have credentials with the networks i.e:

  • IP
  • Port
  • Username
  • Password
  • etc

for SMPP connectivity.

I am looking at the following:

  1. User upload a CSV or XLS file from the web
  2. The numbers and messages are saved in a database
  3. I create a cron to check database periodically for messages that are queued to be sent
  4. Messages to be sent are forwarded to an active MQ (A messaging tool by APACHE).
  5. MQ forward to the network
  6. MQ receives acknowledgement and delivery status from network and update the database.

Kindly point out if my concept is on track or if there is a better solution.

Treffynnon
  • 21,365
  • 6
  • 65
  • 98
  • what spam? Am referring to Bulk SMS. Where a client is willing to send 20 - 50,000 SMS's using my system – James lubor Mar 28 '11 at 09:16
  • Can you tell me the difference? – fabrik Mar 28 '11 at 09:17
  • Are you saying the concept of bulk messaging is wrong? I have a working solution for one sms. I know a company that offer such solution. Are they spamming as well? I mean clickatell, etc have such services. Is this illegal? – James lubor Mar 28 '11 at 09:20
  • No, it isn't illegal when you have your users' agreement on this. But when you say 'user upload a csv' it smells like spam. – fabrik Mar 28 '11 at 09:21
  • No, am referring to clients that we have agreement with. Can you assist with the initial post please – James lubor Mar 28 '11 at 09:24
  • @fabrik I disagree re spam. This is normal procedure for SMS gateway providers. There is nothing in this to point strongly towards some illegitimate spamming – Pekka Mar 28 '11 at 09:24
  • @Pekka Look what i wrote. Concept is fine. – fabrik Mar 28 '11 at 09:25
  • I agree with @fabrik, the concept looks fine (I don't know this Apache MQ though so I can't say anything about it). – Pekka Mar 28 '11 at 09:34
  • Thanks guys - @fabrik, @Pekka . Am glad I have a working solution. From the cron's perspective, is it advisable to run it 24/7 or can i have some sort of a listener, that interact with my DB or something along those lines. – James lubor Mar 28 '11 at 10:04

1 Answers1

0

The fact that you are talking about SMS messages (which is an asynchronous message hanldling system) confuses things a little - in practice it doesn't matter - the important thing is that you are trying to write a asynchronous message handling system to do something.

There are no end of ready made solutions for queueing and processing messages. Previously I've used the BSD lpd for low volumes of SMS/fax. You could equally use an MTA, or a tool specifically designed for SMS handling such as Kannel. IME, dealing with aggregators providing multiple different APIs it proved more effective to roll my own solution.

If you are going to write your own solution, don't use cron.

When your cron job fires, do you only pick up one message and process it? Do you try to pick up all the available messages and process them? What if that takes more than the interval between the cron jobs? While the messaging subsystem (BEFORE your subscriber - NOT after) would take some of the complexity out of this, but it doesn't solve all the problems.

The right way to do this is with a daemon process either running as a single thread or with planned sharding.

symcbean
  • 47,736
  • 6
  • 59
  • 94
  • Thanks for your comment. I have to figure out a way to implement the daemon process you mentioned. I don't know where to start though :D – James lubor Mar 29 '11 at 07:33