Hi, I'm very busy for weeks now but will try to rebase it this weekend and post to ML. When it will be accepted depends from developers.
Khary Sharpe wrote: > 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 >>> >> >> -- Thanks, Alex
