Hi,

no, please no DB things in bearerbox. It should be possible to set minimal
outgoing queue limit (I have patch for this, I have to rebase it against
current cvs) and use something like sqlbox.

So the chain would be:

smppbox -> DB -> sqlbox -> bearerbox


Khary Sharpe wrote:

> Hi Guys,
> 
> Firstly I would like to say thank you for a wonderful product, and keep
> up the good work.
> 
> I work with a company that is essentially an SMSC proxy (using kannel
> with smppbox).
> 
> We have several thousands of messages passing through our system and
> want a way to better handle the traffic.
> 
> Functionality:
> 
>    1. Removing unwanted message - e.g. Someone accidentally send out
>       50000 bulk alert service message
>    2. Prioritizing messages - e.g. Service requiring priority of others
>       e.g. a 119 (aka 911) reply message going out.
>    3. Postdated messages - Send at future date
>    4. Message on hold - Hold message in queue until we are ready to send
>       them out.
>    5. View Message Content - Allow for you to look ahead in queue and
>       view actual messages
> 
> 
> Suggested Implemention:
> 
> It could be possible to use a SQLite memory table and have an interface
> (similar to http status) that would allow for SELECT, UPDATE, and DELETE
> queries to be passed to it, or just exposing suggested fields so there
> would be no tampering with message content for example.
> 
> It perhaps would be better to store it to disk our having the option for
> a remote server like MySql. This would perhaps mean a performance hit
> but (IMHO) the benefits would out weigh it.
> 
> Table Design : [queue]
> 
>     * queueId - Auto incremented integer to uniquely identify each row.
>     * smsc-id - as the name suggests (perhaps this could be a source and
>       destination for sms-user | wap-user | esme-user etc)
>     * dateReceived - automatically populated upon insert
>     * deliveryDate - same as above
>     * priority - default value of zero, however the higher the value the
>       higher priority
>     * status - Pending - waiting to be sent by bearerbox; Processing -
>       being sent by bearerbox; HELD - waiting for admin to release back
>       to pending state
>     * sender - shortcode
>     * recipient - MSISDN
>     * binaryMessage - raw message to be broadcast (I don't know how this
>       is represented; however this could be broken down to match the
>       internalstructure that kannel uses. )
> 
> 
> bearerbox would then run simple queries like
> 
> Get next message to process (or batch just by changing the LIMIT)
> 
> Essential lock record for processing:
> UPDATE queue SET status= 'PROCESSING' WHERE deliveryDate <= now() AND
> status = 'PENDING' LIMIT 1
> 
> Get record locked for processing:
> SELECT * FROM queue WHERE status = 'PROCESSING' ORDER BY priority DESC
> 
> Administrators could then run updates like
> 
> UPDATE queue SET status = 'HELD' WHERE sender = '5555';
> 
> UPDATE queue SET status = 'PROCESSING' WHERE status = 'HELD' ;
> 
> etc;
> 
> What do you guys think of the concept?
> 
> - Khary

-- 
Thanks,
Alex


Reply via email to