Hi, please try patch just posted to ML.
Alexander Malysh wrote: > 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
