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