> 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
