I am currently doing the same separate bulks thing, i.e. First running intro bulk and waiting for bbox to clear (painfully manual), and then triggering the content bulk. It is pretty tedious process where I have to manually sit and watch when the first batch is cleared and then trigger the second one. Because of lack of any priority feature in sqlbox or bbox, I cannot really put both bulks in one program, since the second bulk (content msg) overrides the outgoing queue in bearerbox and starts broadcasting before the already-queued intro msgs.
Both msgs themselves standalone are 2 SMS long. So further concatenation is also not possible, as it makes msgs very very long for receiver handsets. On Tue, Nov 12, 2013 at 10:49 PM, Alvaro Cornejo <[email protected]>wrote: > Hi > > Can't you split your batchs into intro and content messages? Then you > can send all your intros and once they are gone send the content > message. > > Another option can be to concatenate them so the phone will reassemble > the message in the correct order. > > Just a couple of ideas. > > Regards > > Alvaro > > |-----------------------------------------------------------------------------------------------------------------| > Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier > celular y Nextel > en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via > SMS y GPRS online > Visitenos en www.perusms.com > > > On Tue, Nov 12, 2013 at 11:35 AM, [email protected] <[email protected]> wrote: > > 20k is just an example batch I am trying to play around in order to find > the > > solution. My actual bulk is in millions. > > > > As for sequence, the application logic is such that it should first send > an > > intro message to the user and then send the actual content message. The > > intro message has to go before content, else the effectiveness of content > > message is compromised because of less user response. It makes less > sense if > > the content message reaches the user first and the intro message is > coming > > later. > > > > In my experience, operator SMSCs hardly ever change the order of the > > messages, unless there is some problem. For 99.99% of the time, the > message > > sequence to the end users are the same in which I have sent it to the > SMSC. > > > > > > > > On Tue, Nov 12, 2013 at 8:52 PM, Ghulam Mustafa /HQ/NW/Network Engineer > > <[email protected]> wrote: > >> > >> 20k SMS will take few seconds then why worry about the sequence since > DLR > >> is not available and operator is not going to obey your sequnce/order at > >> all. > >> > >> > >> Sent from Samsung Mobile > >> > >> > >> -------- Original message -------- > >> From: [email protected] > >> Date:12/11/2013 8:03 PM (GMT+05:00) > >> To: Rene Kluwen > >> Cc: kannel users > >> Subject: Re: SQLBOX working - LIFO or FIFO > >> > >> Yup, I have tried this already. But enabling DLR with remote SMSC comes > at > >> the cost of reducing the overall SMS sending speed by half. Meaning, if > I > >> have a bandwidth of 100 SMS/sec, enabling DLR will actually give me 50 > >> SMS/sec effective speed, with remaining speed being taken by DLRs. > >> Additionally, DLR handling will put more load on my DB, as well as > >> additional application DB reads (for checking status 8). On paper, it > seems > >> like more performance sacrifice than the gain. > >> > >> > >> On Tue, Nov 12, 2013 at 7:57 PM, Rene Kluwen > >> <[email protected]<mailto:[email protected]>> wrote: > >> If you are going to fiddle with your php code anyhow. > >> A possible solution is to send message 2 whenever the dlr with status = > 8 > >> arrives. > >> You don’t need a sleep then and you will be sure that the message has > been > >> sent out before sending the next one. > >> > >> Just an idea. > >> > >> == Rene > >> > >> > >> From: [email protected]<mailto:[email protected]> > >> [mailto:[email protected]<mailto:[email protected]>] > >> Sent: dinsdag 12 november 2013 15:51 > >> To: Rene Kluwen > >> Cc: spameden; kannel users > >> > >> Subject: Re: SQLBOX working - LIFO or FIFO > >> > >> This is OK if SMSC does the re-ordering for congestion or some other > >> reasons. But my concern is that messages should at least leave bbox in > the > >> same order by which they left the application. > >> > >> Since kannel is not giving me a proper method to sequence the messages, > I > >> am forced to use SLEEP method in PHP programming. It is hanging my > server > >> horribly in the presence of big traffic, choking both HTTP web server > >> connections as well as backend database. I would be happy to find > some/any > >> method to maintain the sequence of msgs in kannel in FIFO order. > >> > >> On Tue, Nov 12, 2013 at 7:38 PM, Rene Kluwen > >> <[email protected]<mailto:[email protected]>> wrote: > >> But having said the below, sms messages are not guaranteed to arrive in > a > >> particular order. > >> The remote smsc may still send out message 2 first, even when they > >> received message 1 first. > >> > >> From: users > >> [mailto:[email protected]<mailto:[email protected]>] On > Behalf > >> Of Rene Kluwen > >> Sent: dinsdag 12 november 2013 15:35 > >> To: [email protected]<mailto:[email protected]>; 'spameden' > >> Cc: 'kannel users' > >> Subject: RE: SQLBOX working - LIFO or FIFO > >> > >> There’s a ‘priority’ field in the Msg structure. > >> I think it serves for the purpose that you want to. > >> Just it’s you cannot set it in the send_sms table. Not sure why, but > >> probably the field was added later. > >> It shouldn’t be difficult to add though if anyone wants to send in a > >> patch. > >> > >> == Rene > >> > >> From: users [mailto:[email protected]] On Behalf Of > >> [email protected]<mailto:[email protected]> > >> Sent: dinsdag 12 november 2013 15:28 > >> To: spameden > >> Cc: kannel users > >> Subject: Re: SQLBOX working - LIFO or FIFO > >> > >> Actually, if my understanding is correct (i.e. SQLBOX is already doing > the > >> right thing by giving messages in FIFO order to bbox, but bbox is > shuffling > >> the outgoing messages from within its buffer), then there is no point of > >> adding priority column. > >> > >> What do you say? > >> > >> On Tue, Nov 12, 2013 at 6:28 PM, spameden > >> <[email protected]<mailto:[email protected]>> wrote: > >> For priority I'd suggest adding a column called priority (typically > >> int(3) integer between 0 and 999) and doing ORDER by that column. > >> > >> Do not forget to add an index as well or it might slow things down! > >> > >> 2013/11/12 [email protected]<mailto:[email protected]> > >> <[email protected]<mailto:[email protected]>>: > >> > Hi, > >> > > >> > Many thanks. I tried and tested it. It works fine for small chunks of > >> > data > >> > (I can see SMS going out of bbox in a sequence they were entered in > >> > send_sms > >> > table). However, for large amount of data (e.g. I sent a bulk of 20k > SMS > >> > via > >> > SQLBOX), it does not follow the same rule. Is it bearerbox which > >> > shuffles > >> > the order of the SMS present in its buffer (not SQLBOX)? Any > >> > thoughts/experiences? > >> > > >> > Is there any parameter tweak in send_sms by which I could raise the > >> > priority > >> > of some SMS higher than others? > >> > > >> > Regards, > >> > > >> > > >> > > >> > On Mon, Nov 11, 2013 at 9:23 PM, spameden > >> > <[email protected]<mailto:[email protected]>> wrote: > >> >> > >> >> Yes you can do this. > >> >> > >> >> Just alter gw/mysql_sqlbox.h and edit > >> >> > >> >> #define SQLBOX_MYSQL_SELECT_QUERY > >> >> > >> >> add there ORDER by sql_id ASC :) > >> >> > >> >> 2013/11/11 [email protected]<mailto:[email protected]> > >> >> <[email protected]<mailto:[email protected]>>: > >> >> > Hi, > >> >> > > >> >> > Does SQLBOX work in LIFO or FIFO order? For me, it's working as > LIFO > >> >> > which > >> >> > is bad if I intend to send sequential message (message 1 needs to > go > >> >> > first, > >> >> > but since message 2 comes later, it goes out first). > >> >> > > >> >> > Is there a way to make it operate in FIFO sequence, like ID'ing the > >> >> > messages > >> >> > or something? > >> >> > > >> >> > Regards, > >> >> > Hamza > >> > > >> > > >> > >> > >> > > >
