Am 12.09.2012 11:51, schrieb Toby Phipps:
Ahmed,
Why not just bind BearerBox1 as a SMPP transceiver and BearerBox2 as a
SMPP receiver? This way the transceiver will be used for all PDUs but
you'll also have a dedicated BB just for DLRs. Obviously, both would
need to be bound to the same operator-end SMSC with the same account and
you'd need a database or other shared DLR storage between the BBs.
In this configuration you could still conceivably receive DLRs on your
BB1 connection, but if its busy with submit_sm then most of these are
likely to arrive on your dedicated receiver bind, but in the end, how
these are spread between the connections would be up to your upstream
operator and is out of your control no matter how much you hack the code.
Toby is right here. Let me extend this a bit.
What you do is having bearerbox1 connect as the MT channel, and
bearerbox2 as the MO/DLR channel. IF both run within the same machine
scope, then there is NO benefit in terms of "load-balancing", as both
concurrently run on the same CPU scope and use the same DB engine
connectivity.
Anyway, if you want to have it "separated" as you describe, then make
sure you have this kind of config setup:
bearerbox1.conf:
...
group = smsc
smsc = smpp
smsc-id = operator_A
...
port = xxxx
...
means no 'receive-port' is set, which ensures it's only binding as
bind_transmitter. You can use multiple of these groups if you need to
scale in terms of bind sessions.
Now, for the bearebox2 it looks this way:
bearerbox2.conf:
...
group = = smsc
smsc = smpp
smsc-id = operator_A
...
receive-port = xxxx
...
important(!) is that the smsc-id values match, otherwise you won't be
able to resolve the temporary DLR data in the DLR storage (i.e. in the
MySQL table) to the message.
As mentioned, load-balancing in this sense makes only a benefit if the
bearerboxes are running on separate instances.
Typically people "think" they have bottle-necks here, but almost NO user
runs Kannel on it's full power scope. Typically the DB queries are the
bottle-neck here. Make sure you have an adequate index on the DLR table,
so that lookups can happen fast.
Stipe
--
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
