Ok, compile Kannel from CVS (vs-20060509), and deployed it in production
after some basic testing - all seems well so far.
Details:
Kannel bearerbox version `cvs-20060509'. Build `May 30 2006 17:37:39',
compiler `3.2 20020903 (Red Hat Linux 8.0 3.2-7)'. System Linux, release
2.4.20-19.8smp, version #1 SMP Tue Jul 15 15:01:43 EDT 2003, machine
i686. Hostname vesuvius, IP 10.100.123.135. Libxml version 2.6.9. Using
OpenSSL 0.9.6b [engine] 9 Jul 2001. Using native malloc.
However, the 'throughput' problem still exists - here is the
configuration for one of our binds:
# Vodafone SMSC. Free MT services
# This SMPP account is for all new free MT services provisioned through
MPAPS
group = smsc
smsc = smpp
smsc-id = vodafonefrmt
host = 202.81.65.20
port = 3403
transceiver-mode = true
smsc-username = xxx
smsc-password = yyy
system-type = VMA
address-range = 0
source-addr-ton = 3
source-addr-npi = 9
dest-addr-ton = 1
dest-addr-npi = 1
alt-charset="ASCII"
enquire-link-interval = 30
allowed-smsc-id = "vodafonefrmt"
throughput = 13
Upon starting Kannel, I see this in the bearer.log:
2006-05-31 23:41:42 [18565] [0] INFO: Set throughput to 13.000 for smsc
id <vodafonefrmt>
If I send a batch of 100 MTs through Kannel, to that SMSC, they are all
sent at once, which triggers the following response from the SMSC:
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:56:49 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:56:49 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:57:13 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:57:13 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
2006-05-31 23:57:13 [18590] [10] WARNING: SMPP: PDU NULL terminated
string has no NULL.
2006-05-31 23:57:14 [18590] [10] ERROR: SMPP[vodafonefrmt]: SMSC
returned error code 0x00000058 (Throttling error) in response to submit_sm.
...
etc. for the next 5 minutes or so. Each minute, Kannel tries to send the
all the queued MTs at once, and a small number get through before the
throttling condition is triggered, and the SMSC stops accepting MTs.
After about 5 minutes, all hundred MTs did eventually get through, but
this is hardly ideal - in cases of high load, it could take many many
hours for all the messages to trickle through.
So:
- the throughput parameter is not honoured for MTs submitted to Kannel
via HTTP
- the throughput parameter is not honoured for MTs delivered from
Kannel's queue/store
Have I interpreted the situation correctly? Has anyone else encountered
this problem? Let me know if I should provide any other info...
One thing - Vincent's email, with subject '[REQUEST] EMI/UCP +
throttling: Need beta-testers' - this sounds like it might be
applicable, but I'm not 100% sure - what does EMI/UCP mean?
Thanks,
Alexander Malysh wrote:
Hi,
I would advice you to try CVS head version. It contains numerous bug
fixes all over the place. Please try it and report when the problem
persist.
Thanks,
Alex
Giulio Harding schrieb:
Hi, this is my first post to the Kannel Devel mailing list (and I've
only been subscribed for maybe a month or so), so please excuse any
cluelessness on my part...
We're becoming quite reliant on Kannel because of significant problems
with our old SMS gateway, and a new SMS gateway we're trying to
migrate to.
As such, I have a fairly urgent need to diagnose and resolve an issue
that's cropped up a few times, with regards to Kannel's handling of
MTs that are queued to its message store file.
The problem is this:
An SMPP link to a carrier goes down, for one reason or another, and
MTs submitted to Kannel are queued in its store file. When the link
comes back up (responds to bind requests again), *one* MT is
submitted, but the rest of the queued MTs are *not* submitted, despite
the bearer.log indicating (for sets of 10 MTs at a time) "WARNING:
SMPP[optuschmt]: Not ACKED message found, will retransmit.
SENT<90>sec. ago, SEQ<110>, DST<61402276846>" etc. (I've checked this
with Etheral, monitoring traffic to the SMSC's IP address and port -
only one SMPP submit_sm exchange occurs)
Also, all further MTs submitted to Kannel for that SMPP link will
queue, even though the link is up (and responding to bind enquiries).
If I restart Kannel, again, *one* MT will be submitted, and that's it,
and MTs will continue to queue.
The only way to resolve this, so far, is to stop Kannel, move its
store file (and backup) aside, and restart Kannel so it has an empty
store. Subsequent MTs are submitted fine, and don't queue.
I then have to parse the original store file and manually resend those
MTs that were not submitted before.
This is a huge problem when we are experiencing heavy traffic, and it
can sometimes take hours to resolve.
This is with Kannel 1.4.0 running on Redhat 8.0 (let me know if I
should provide extra info, e.g. SMSC connection configuration, log
excerpts etc.)
I am currently trying to replicate this problem on a test setup, but I
wanted to check with people on the mailing list for any advice. Has
anyone else encountered this problem? What are the chances of getting
some help to diagnose & fix it? I (and some colleagues) have passable
C skills, but any tips on where I should start to diagnose the problem
would be greatly appreciated.
Thanks,
--
Giulio Harding
Systems Administrator
m.Net Corporation
Level 13, 99 Gawler Place
Adelaide SA 5000, Australia
Tel: +61 8 8210 2041
Fax: +61 8 8211 9620
Mobile: 0432 876 733
MSN: [EMAIL PROTECTED]
http://www.mnetcorporation.com
