Re: [PATCH] Guaranteed throughput smsc-independent

This patch was only to show how it could be done. It's not complete  
for SMPP.
For SMPP the main loop should be reordered. I have local version that  
works
as expected but I need some time to extract it because of many  
differences.

I will try to extract it this weekend...

Thanks,
Alex

Am 10.06.2009 um 21:51 schrieb Damian Viano:

> On Wed, Jun 10, 2009 at 05:28:04PM +0200, Alexander Malysh wrote:
>>
>> Am 10.06.2009 um 17:16 schrieb Damian Viano:
>>
>>> On Wed, Jun 10, 2009 at 03:06:59PM +0200, Alexander Malysh wrote:
>>>> here is a link to throttling branch:
>>>> 	http://github.com/amalysh/kannel/tree/smpp-throttling
>>>> only smpp implemented for now.
>>>
>>> Great, thanks for the link.
>>>
>>> I see that you basically break out when you are over  
>>> throughput[1], I
>>> see your concern now, since the thread for receiving is the same as
>>> the sender, so you just break out to keep processing incoming pdu.
>>> Makes sense, and this indeed breaks my assumption that the smsc
>>> implementations would have a thread for sending and another one for
>>> receiving.
>
> However there's still a problem. In the case of smpp not in  
> transceiver
> mode the io_thread() code that calls send_messages() is basically:
>
> for (;conn != NULL;) {
>   while ((ret = read_pdu(smpp, conn, &len, &pdu)) == 1) { //nothing  
> since we don't read
>   }
>   ...
>   if (transmitter && difftime(time(NULL), smpp->throttling_err_time)  
> > SMPP_THROTTLING_SLEEP_TIME) {
>       smpp->throttling_err_time = 0;
>       send_messages(smpp, conn, &pending_submits);
>   }
> }
>
> So if send_messages() does not sleep and we are over the throughput  
> this
> basically comes down to a tight loop that in transceiver is controlled
> by read_pdu() blocking on the network read.
>
> Have you considered that?
>
> I'm starting to think that we'll need to know 1) if we are over the  
> throughput
> 2) if we are in some kind of transceiver mode or not.
>
>>> Unfortunately this is smsc-dependant, so maybe we could move this to
>>> a more generic api, and make the rule that the SMSCs MUST check that
>>> api  (say...  conn->over_throughput()?) and move the load
>>> setup/increase to the  already existing callbacks?.
>>
>> I think, it's already enough abstracted in load object. Now it's SMSC
>> dependent how to use it.
>> So I don't think we need more api there but I'm open for a patch that
>> would make it easier to implement
>> this in other smsc modules.
>>
>>>
>>> That way it's a bit more generic and we can implement
>>> conn->sleep_for_throughput() for the smsc that need their sender
>>> thread to sleep, or let the others (i.e. smpp) handle it  
>>> accordingly.
>>>
>>> Opinions about this approach?
>>>
>>> [1] I didn't check the load object but I assume it account for
>>> load_increases in the set interval, which would make sense.
>>>
>>>> Thanks,
>>>> Alex
>>>
>>> Thanks your code, made your points a lot more clearer, I hope we can
>>> come up
>>> with a better implementation of throughput for all kannel users.
>
>
>    Damián Viano(Des).