Re: [PATCH] Guaranteed throughput smsc-independent

here is a link to throttling branch:
	http://github.com/amalysh/kannel/tree/smpp-throttling
only smpp implemented for now.

Thanks,
Alex

Am 10.06.2009 um 10:20 schrieb Nikos Balkanas:

> Actually, I don't think that even this patch can guarantee solid  
> throughput. All I/O (including SMSc) is handled by a polling thread.  
> AFAIK bb_smscconn_sent just puts the sms in the connection queue,  
> where the connection layer takes over and sends it. If there is a  
> queue for that SMSc, the connection layer will still try to empty it  
> as fast as it can.
>
> IMHO, any robust throughput should be implemented in the connection  
> layer.
>
> BR,
> Nikos
> ----- Original Message -----
> From: Nikos Balkanas
> To: Donald Jackson ; Damian Viano
> Cc: [email protected]
> Sent: Wednesday, June 10, 2009 9:51 AM
> Subject: Re: [PATCH] Guaranteed throughput smsc-independent
>
> 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: Damián Viano
> Cc: [email protected]
> 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 <[email protected]>
> 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 <[email protected]>
>
> 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