We have a queue load balancer in front of Kannel, that through a "statusbox" monitors Kannel, and knows extended information about each gateway that kannel is connected to. This way we can control the throughput of any of the Kannel connections, as well as load balance them
If messages are going to throttle I would rather see the throttling happening before a messages is commited to a particular smsc, so one can reroute it if need be.
nisan
At 03:26 PM 6/19/03 +0000, Bruno Rodrigues wrote:
Alexander Malysh <[EMAIL PROTECTED]> wrote:
> Hi Bruno,
>
> Am Donnerstag, 19. Juni 2003 16:03 schrieb Bruno Rodrigues:
>> Stipe Tolj <[EMAIL PROTECTED]> wrote:
>> > Bruno Rodrigues wrote:
>> >> You need to "sleep" right after sending the message for it to work.
>> >> We can have configuration code in smsccon abstraction and only that
>> >> "usleep" inside smsc_* modules.
>> >
>> > why not having the whole throttling mechanism inside the abstracted
>> > layer?
>> >
>> > This would also help in AT2 module, because most GSM modems don't like
>> > be hit by 100 msg/sec. ;)
>>
>> If I'm not mistaken, EMI has a list feed by SMSConn or something and
>> smsc_emi reads it and feeds it into smsc, so you can't sleep before
>> filling that list, you have to sleep right after sending the message (in
>> emi case, sleep AFTER receives ack) to take in consideration received
>> messages and other particularities.
>>
>> As I told, sleep is one line, just copy/paste it into every module in
>> the right place and move microsecond calculation and config file
>> processing to smscconn.
>
> hmm, sleep is very bad (imho). In this sleep time you can maybe handle 100
> delivery receipts instead just sleeping. It would be great to add abstracted
> bandwidth calculation code to kannel and then send only if bandwidth allow
> this.
EMI uses one thread for sending and another for receiving. This latter sends itself ACKs by managing locking with send thread. In this case, its ok to sleep in sending thread because it won't affect receiving one.
I even once needed something to limit incoming messages because I was receiving more messages than the other java service could handle, and store.lock was growing madly with mt-reply messages. If we have some kind of throthling in input, we can let them stay in smsc queue instead of kannel queue. Maybe a automatic throtling in smsc if queue-out larger than something. I don'tknow...
>
