Am 10.06.2009 um 16:40 schrieb Damian Viano:
On Wed, Jun 10, 2009 at 09:38:41AM +0200, Alexander Malysh wrote:
Hi,
not only this is issue. You want not sleep! Just think about it a
bit.
Sleeping was the current approach so I just followed it. I think the
idea
behind that (and behind the code to ensure the sleeping time is
accomplished) is
that the smsc have different threads for TX(MTs) and RX(MOs) so
making the TX
thread sleep shouldn't be a problem, this might be a false assumption.
false assumption, TX and MX may running in one thread (e.g. SMPP v3.4
transceiver mode).
Hint: you want to process MOs and ACKs without delays...
-1
Could you point me to some code affected by this? And please don't
just tell me
that the way throughput is currently implemented is wrong and
therefore the
patch I made to fix the current implementation is also wrong.
see above..
and yes, current implementation is wrong. and why should we accept fix
for a wrong version instead of
doing it right ?
I'd really appreciate it, since I'm only trying to help by fixing a
problem. If
the current (sleeping) approach is wrong, great, let's talk about it
and find
another way to implement it better.
something like this:
http://github.com/amalysh/kannel/commit/31db912a9e5aecd6d9f038b56d09f408f2c256f9
Thanks,
Alex
P.S. I already posted patch that fixes this issue but not in ideal
way.
SMSC will not sleep but sending
all allowed messages in the time slot at full speed instead of
delaying
each message.
Full speed? I'm not sure I get that point keeping in mind that if
you send for
a 10 sms/s throughput, 20 sms in 1 second and then nothing for
another second,
you still violated the throughput, as you sent 20sms/s.
Thanks for your input on my patch, I appreciate it, and hope you
have time to
further explain your points.
Damián Viano(Des).
