Re: 1 bug and some queries with SMPP driver

> Should the SMPP driver treat message queue full errors in a similar manner
> to throttling errors
> as I think some SMSC operators request this behaviour. And it makes sense
to
> retry a message that
> receives a message queue full error.

I haven't found any exact documentation from either Logica or any of our
SMSCs on how to cope with the Message queue full error so I would expect
that the current 'back off for a while and try again in a short time'
approach will work, however it's not that elegant.

Instead, could we not send a Generic Nack PDU every x amount of
seconds/milliseconds until the error is cleared and we get a PDU back with 0
rather than 14? This way it's potentially significantly neater and delivery
can resume potentially quicker.

For the throttling code I've wanted to write some auto-speed controlling
code that will self regulate the speed of the message sending to avoid
getting I/F Throttled Errors, rather than the current workable but not
beautiful approach.

Basically if you could track the amount of 58 I/F errors you get over a
certain period and then divide your messaging speed to reduce the speed down
then the system could auto regulate itself. Not that would be nice!

> When a message is sent requesting a submission report, why does the SMPP
> driver save the
> message to the store if the response is successful and not save the
message
> if the
> response is unsuccessful. Surely the behaviour should be the same
regardless
> of
> failed or succeeded. It also seems to be inefficient if only requesting
> submission reports
> and not delivery reports!

Would make sense to store all messages submitted regardless of delivery
outcome. Agreed.

> Within the SMPP driver there is the following line for throttling
messages:
>
<deleted>
> condition evaluation, I would suggest that this would be easier to
> understand if it was extracted out of
> the if statement.

+1 from me.

Alex
Skywire