Re: Patch to add configurable max retries, and delay between retries for SMPP temporary failed messages.

Hi,

patch could be produced with cvs diff -Nau.

I don't think it's a good idea to implement max retries only for the 
smpp. It's really easy to get it working for all protos if you implement 
it at generic layer bb_smscconn.c.

Thanks,
Alex

Josh McAllister schrieb:
> I have a patch with some changes we had to make to pass Cingular US's
> SMPP integration testing. This is my first time giving a patch back to
> an open source project, so could someone let me know how I should
> produce the diff, and how I should submit it.
>  
> This patch adds:
> max-retries = [num retry attempts]
> and
> retry-delay = [seconds]
> 
> config options for SMPP smsc groups.
> retry-delay is only the minimum delay... it may be slightly longer
> before we actually get around to retrying.
> 
> The default (and only AFAIK) behavior is to immediately retry and keep
> retrying, very ugly.
> 
> Caveat: If your throttle time delay is less than your retry delay,
> delayed messages will be retried before new messages in the event you
> are throttled... The easy fix... make sure retry-delay is >
> throttle-delay by at least 15 - 30 seconds.
> 
> NOTE: I do set defaults for max-retries(10), and retry-delay(30) This
> changes the current behavior... but IMHO the current behavior is not
> sane.
> 
> There's also a couple of sm_resp codes added... these were required by
> Cingular, US. Not sure if they're standardized... they are:
> 
> RX_T_MCFAIL (x45) = Message center reported failure, Cingular says this
> is a Temporary Failure.
> RX_T_STNA (x410) = Service Type not Available, again a Temp failure.
> 
> If I missed some config option(s), that already addresses the temporary
> failure behavior for SMPP SMSCs, then please let me know... otherwise
> this should be a very useful patch.
> 
> Thanks,
> 
> Josh McAllister
> 
> 
> 
> 
> 
>