Re: smpp loadbalancer

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
-------------------------------------------------------------------