Alex, How long before this patch will be available in cvs.
I would like to test it to see if it meets our needs. Thanks, Khary Alexander Malysh wrote:
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
