Currently it'll continue to double the wait time with no upper limit. since I assume that eventually the SMPP server will agree to send a message w/o responding with a throttling error, and the double type can hold enough data to represent time length much longer then a year ( ;-> ) then I don't think it's a problem.
-- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. When I was 16, I thought there was no hope for my father. By the time I was 20, he had made great improvement. > -----Original Message----- > From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 27, 2002 4:06 PM > To: Oded Arbel; Damjan; [EMAIL PROTECTED] > Subject: RE: [PATCH] Kannel resending old unsuccessful > messges after a box restart.BUG? > > > Hi Oded, > > A backoff alghorithm would be nice! It sounds like Postifx MTA. > > But, is there a limit or Kannel would be backing off until forever? > > Regards. > > > -----Original Message----- > > From: Oded Arbel [mailto:[EMAIL PROTECTED]] > > Sent: domingo, 25 de agosto de 2002 14:58 > > To: Oded Arbel; Damjan; [EMAIL PROTECTED] > > Subject: [PATCH] Kannel resending old unsuccessful messges > after a box > > restart.BUG? > > > > > > Hi list. > > > > Attached is a patch to introduce configurable throttling > > delay with backoff. the patch adds another configuration > > option: 'throttling-delay' that is used as the base delay for > > a simple backoff mechanism that will simply double the last > > sleep time and sleep again, if it after sleeping and sending > > it received another throttling error. > > > > Warning - this patch is _not_ tested ! it simply compiles. I > > would like to have comments on the code, the solution methods > > and the new configuration option name. testing would be nice > > too :-) I'll try to find time to upload the changes to a test > > platform tommorow. > > > > -- > > Oded Arbel > > m-Wise mobile solutions > > [EMAIL PROTECTED] > > > > +972-9-9581711 (116) > > +972-67-340014 > > > > ::.. > > In shallow waters, shrimps make fools of dragons. > > -- Chinese Proverb > > > > > > > -----Original Message----- > > > From: Oded Arbel > > > > > > >>Current CVS version does handle 'Throttling Error' properly > > > by stoping > > > >>to send messages for a predetrmind time - 15 seconds currently. > > > >> > > > >> > > > > > > > >Thats too much, I'm using my own scripts with a perl SMPP driver, > > > >usually I can send some 4 messages as fast as I can send them, > > > >and then I get the "Throttling Error", I then wait some 0.8 > > > >seconds and then continue to send. Actually it depends of the > > > >settings your SMPP provider has set-up for your connection. > > > > > > > > > > > Currently it's set as a compile time option, which you can > > > change - 15 > > > seconds is what O2 required of us in their credentials > tests. but I > > > agree it's not the best course. Here at m-Wise we usually do > > > that, since > > > most time we don't think about other people's needs as much as we > > > should, as Andreas Fink pointed out, and we usually put in > > > new features > > > with a compile time option, thinking - "If we ever find a > > > provider that > > > requires a different setting - we'll add a configuration > > > option, as it's > > > simple enough". I assure you that it is pure laziness and not > > > because we > > > are bad people :-) > > > > > > If the developers have no objections, I'll implement a run-time > > > configuration option which will default to the compile > time option > > > (currently 15 seconds), first thing sunday morn. alternativly > > > - do you > > > think its possible/needed/interesting implementing some kind of > > > exponential backoff mechanism that will start at a small > delay and > > > increase it as long as it gets consecutive 'Throttling Errors' ? > > >
