Overview

Storage

The central storage is planned to be a MongoDB. The reason is thatit supports tailable cursors on capped collections, replication,atomic update of a document and the write concern for replication.

SMPP Inserter

Receive SMPP SubmitSM/DeliverSM and store in the database for store andforward. Multiple inserters must be able to run in parallel.

• Use existing Smalltalk SMPP framework to open or listen to connections

• After the content has been inserted add an event (which will lead to thedelivery agents waking up)

Delivery

The task is to wake up for the next delivery time or when a new SMS hasbeen inserted into the table. By using a capped collection for the notifcationcollection the cursor will become readable and the system can wake up andselect the message to be delivered. With a system of multiple delivery nodesrunning, all of them will wake up but only one will be able to lock the SMPPrecord with a CAS and process with the delivery process.

Once a SMS has been picked it will be checked if there are more SMS for thissubscriber and up to four for messages will be blocked and scheduled in thesame delivery run. If the delivery of a message fails the next delivery timewill be set and the delivery worker goes back to waiting for work.

In general we want to avoid two delivery nodes to deliver to the same subscriber.This might result in a more complicated CAS locking scheme. The first lock wouldbe to declare interest to deliver to the user and second lock would increasethe lock by checking that no other delivery node has reached that level. Oncethat lock level has been reached it can try to find up to four different messagesfor delivery on the same TCAP session.

We might decide to put the delivery history (attempts, timestamps, info) intothe record as well to help with debugging.

On delivery the encoded data might need to be converted. This can lead toconversion from any format to any other format. This might resolve in SMPP toGSM and Deliver to Submit.

Clean-up

As the locking process might leave some locked SMS behind and we need to removeSMS that were never delivered there should be a clean-up task with the followingresponsibilities:

• Remove old SMS that could not be delivered

• Reset SMS that are in the pending state for too long

Database locking protocol

There is one collection for "sms" and one for the "locks". Each SMS is one entryin the "sms" collection and for each destination MSISDN there is either one orno entry in the "locks" collection.

A worker will use Compare-And-Swap to lock one entry that is to be delivered. Itis possible that two workers lock two SMS to the same user. This means as the nextstep both workers will try to get a destination lock. This is by having a uniqueindex per destination MSISDN in the "locks" collection and then using CAS to tryto lock the destination.

The system that could not lock the destination will need to release the lock andit is done using a CAS as well.

The system that got the lock and will now continue. It will try to lock more SMSusing the CAS approach to lock matching SMS and ignore the current lock setting.The SMS will be either removed or unlocked depending on the delivery result. Thelock from the other system will either be used after it has been unlocked or itwill be stolen.

A third system might try to do delivery and needs to avoid always locking a SMSthat is currently been delivered to. This is done by maintaining a list of excludeddestMSISDN in the current round.