Yup we have. This is what happens when you send above the throughput allowed by the SMSC you are connecting to for your account.
0x58 is SMPP_ESME_RTHROTTLED
We have also seen SMPP_ESME_RMSGQFUL comming in on a generic_nack_resp.
Our smsc module is modified for this. Basically we have added generic_nack_response pdu handler, which reques the message. I can submit patches if you are interested.
Nisan
At 08:02 AM 12/5/02 +0100, Andreas Fink wrote:
Anyone seen this:
2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU:
2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump:
2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp
2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 = 0x80000000
2002-12-05 06:57:53 [10] DEBUG: command_status: 88 = 0x00000058
2002-12-05 06:57:53 [10] DEBUG: sequence_number: 31 = 0x0000001f
2002-12-05 06:57:53 [10] DEBUG: SMPP PDU dump ends.
2002-12-05 06:57:53 [10] ERROR: SMPP[link5]: Unknown PDU type 0x80000000, ignored.
This happens under high load on a SMPP link to a SMSC.
after that the link is more or less stuck. Only restarting helps dequeuing messages again.
Andreas Fink
Fink Consulting GmbH
---------------------------------------------------------------
Tel: +41-61-6666332 Fax: +41-61-6666331 Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED]
Homepage: http://www.finkconsulting.com
---------------------------------------------------------------
</blockquote></x-html>
