[PATCH] Guaranteed throughput smsc-independent

[Nikos Balkanas]

Hi Donald,

I think you hit the nail exactly on the head. AFAIK, there is a single thread at this point, sms_router, that is implementing bb_smscconn_sent. Therefore all sms in the outgoing smscs should be delayed. Kannel doesn't raise threads on demand.

There may be an additional issue. This approach, which delays everything by a set amount if there is a throughput constraint, will utilize exactly half the available bandwidth. If for example an smsc has a throughput of 10 sms/1', and there is a queue of 20 sms, In the old way, assuming it works correctly, the first 10 should be send at once at time 0, and the rest at atime 1' with an average delay of 30"/sms. With this approach, 1 sms would be sent every 6", with an average delay of 1'/sms.

Coupled with the previous point, it could spell problems for queues in large installations that use many smscs to load balance.

The advantage is that it offers solid throughput handling.

I am a wap person, so I leave this decision for peoaple with a lot of smss.

BR,
Nikos
  ----- Original Message ----- 
  From: Donald Jackson 
  To: Damian Viano 
  Cc: devel at kannel.org 
  Sent: Wednesday, June 10, 2009 12:06 AM
  Subject: Re: [PATCH] Guaranteed throughput smsc-independent


  Ignore my last mail!

  I see these will be called per thread :)


  2009/6/9 Donald Jackson <donaldjster at gmail.com>

    I will review in more detail when I get a moment, my concern here is that you are now sleeping at the bearerbox layer which could effect delivery to other SMSC's.

    The current throughput limits although the logic is per-smsc, they sleep within their own threads as to not delay any others.

    Have you addressed this scenario?


    2009/6/9 Damiαn Viano <damian.viano at buongiorno.com>


      Hi list:

             I've seen kannel not respect throughput at all, at least with the fakesmsc
      and looking around find the following bug:

      http://redmine.kannel.org/issues/show/332

      With the following patch attached:

      http://redmine.kannel.org/attachments/104/0000332-emi_patch_ack_v3.txt

      Inspired by that one, I've implemented a smsc-independent throughput patch. The
      idea is to enforce the throughput from the beaberbox side instead of having to
      implement the same login in every smsc. This is possible due to the
      bb_smscconn_sent() and bb_smscconn_send_failed() callbacks from the smscs
      implementation. They MUST call one of this callbacks after sending a message
      either successfully(_sent) or with failure(_failed), so we can make them sleep
      there, making sure they NEVER go over the configured throughput.

      There's only one downside to this smsc-independent approach which is that we
      don't, and can't (without cluttering the interface, AFAIK) know how much time
      the smsc takes in actually sending the sms, so we assume it takes nothing, this
      would, practically give us a somewhat smaller real throughput, but I though
      that's better than the previous behaviour (which for me, flooded the smsc).

      I've only tested this with fakesmsc so far, and only commented out the previous
      throughput implementation in that smsc, doing the rest is trivial and I can do
      it (or anyone else can), but this first iteration is to gather opinions about
      this approach.

      Once again the patch is against the current stable release, I can update it if
      needed, just let me know.

      Again I would love comments, questions, commits, rants, whatever :)

      For reference:
      diffstat kannel-1.4.3-throughput.patch
       bb_smscconn.c    |   46 ++++++++++++++++++++++++++++++++++++++++++++++
       smsc/smsc_fake.c |    9 +++++++--
       smscconn_p.h     |    2 ++
       3 files changed, 55 insertions(+), 2 deletions(-)

      Hope to help.

         Damiαn Viano(Des).

      P.D.: Also there's an info line in smsc_fake.c to count the number of sms,
      which should be removed from the final version, is only there for debugging
      purposes.




    -- 
    Donald Jackson
    http://www.ddj.co.za/
    donaldjster(a)gmail.com




  -- 
  Donald Jackson
  http://www.ddj.co.za/
  donaldjster(a)gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.kannel.org/pipermail/devel/attachments/20090610/b5ff02a5/attachment-0001.html>