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
<cornejo.alv...@gmail.com>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, ha...@aeon.pk <ha...@aeon.pk> 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
> > <g.must...@nadra.gov.pk> 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: ha...@aeon.pk
> >> 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
> >> <rene.klu...@chimit.nl<mailto:rene.klu...@chimit.nl>> 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: ha...@aeon.pk<mailto:ha...@aeon.pk>
> >> [mailto:ha...@aeon.pk<mailto:ha...@aeon.pk>]
> >> 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
> >> <rene.klu...@chimit.nl<mailto:rene.klu...@chimit.nl>> 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:users-boun...@kannel.org<mailto:users-boun...@kannel.org>] On
> Behalf
> >> Of Rene Kluwen
> >> Sent: dinsdag 12 november 2013 15:35
> >> To: ha...@aeon.pk<mailto:ha...@aeon.pk>; '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:users-boun...@kannel.org] On Behalf Of
> >> ha...@aeon.pk<mailto:ha...@aeon.pk>
> >> 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
> >> <spame...@gmail.com<mailto:spame...@gmail.com>> 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 ha...@aeon.pk<mailto:ha...@aeon.pk>
> >> <ha...@aeon.pk<mailto:ha...@aeon.pk>>:
> >> > 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
> >> > <spame...@gmail.com<mailto:spame...@gmail.com>> 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 ha...@aeon.pk<mailto:ha...@aeon.pk>
> >> >> <ha...@aeon.pk<mailto:ha...@aeon.pk>>:
> >> >> > 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
> >> >
> >> >
> >>
> >>
> >>
> >
>

Reply via email to