hm.. thats weird i have several smscs in my config named smsc_carriername_mt1 , smsc_carriername_mt2 , ... and i put allowed-smsc-id=smsc_carriername_mt in their config, then submit messages with smsc=smsc_carriername_mt (without numbers) and kannel does load balance between them... or at least so it looks (messages go out from all of them)
On Fri, Mar 19, 2010 at 1:57 PM, Alejandro Guerrieri <[email protected]>wrote: > smsc-id's can't be unique. That would ruin load-balancing for example. > > smsc-admin-id's could be unique though... (imho, they _should_ be unique, > otherwise it's pointless to use it). > > Regards, > > Alex > -- > Alejandro Guerrieri > [email protected] > > > > On 19/03/2010, at 12:51, Konstantin Vayner wrote: > > Actually, now that i'm rereading this conversation again... > > > You have to remember SMSC pointer not only SMSC-name/id and then teach > all routing parts > > to respect it... > > What if kannel gets shut down and then starts up again? > Obviousely, smsc pointers are different... > > I say lets make smsc-id's a must and unique, that'll make things better ;) > > On Thu, Mar 18, 2010 at 11:00 AM, Alexander Malysh <[email protected]>wrote: > >> Hi, >> >> the possibility for endless loop is equal for each part. So this will not >> help... We need real fix... >> >> Thanks, >> Alexander Malysh >> >> Am 17.03.2010 um 18:04 schrieb Michael Zervakis: >> >> > Dear Alex, >> > >> > From my experience endless loops from temporary errors usually occur >> before ever transmitting the first message part. It's a very rare occurence >> to transmit first part and then enter in an endless loop with left parts. A >> partial fix could be to keep two counters in split_parts struct, parts_left >> and parts_len, to make it possible to determine which part we are >> transmitting. So if temp error occurs and we are sending first part we can >> safely put the whole message into resend queue without the drawback of >> sending extra SMS parts to receiver. I know this is not a real fix, but I >> believe it will hanlde most of the endless loop cases. >> > >> > >> > Am 17.12.2009 um 11:28 schrieb Konstantin Vayner: >> > >> > >> > >> > why remembering smsc-id in sms.smsc_id is not enough? >> > >> > >> > due to accepted-smsc in smsc config group and because SMSCs may have the >> same names (or even no names defines)... >> > >> > >> > >> > how does smsbox remember routing when i submit a message with predefined >> smsc id from http (sendsms) ? >> > >> > On Thu, Dec 17, 2009 at 12:10 PM, Alexander Malysh >> > <[email protected]<mailto: >> [email protected]>> wrote: >> > >> > >> > Am 17.12.2009 um 10:43 schrieb Konstantin Vayner: >> > >> > >> > >> > so the best option would be to requeue the part via same smsc, right ? >> > >> > >> > yes, but it's not easy todo. You have to remember SMSC pointer not only >> SMSC-name/id and then teach all routing parts >> > >> > to respect it... >> > >> > >> > >> > cause requeueing all parts may also get extra messages to the handset >> despite it not being able to reconstruct (not to mention the extra money ;) >> ) >> > >> > On Thu, Dec 17, 2009 at 11:33 AM, Alexander Malysh >> > <[email protected]<mailto: >> [email protected]>> wrote: >> > >> > Hi, >> > >> > >> > unfortunately this will not work as expected (the rule is: _all_ parts >> if multipart message have to be send via the same SMSC)... >> > >> > >> > example: >> > >> > >> > SMSC-A -> splits (2 parts) -> 1 part sent OK -> 2 part get >> temp. error -> you put it into global queue for resend -> 2 part sent via >> SMSC-B -> handset rejects it >> > >> > >> > We have only two possibility here: >> > >> > 1) if temp error occurs put the _whole_ message into resend queue and >> resend then _all_ parts (very easy todo) >> > >> > 2) remember smsc which was used for first parts and resend it via the >> same smsc (complicated but save money :) ) >> > >> > >> > Thanks, >> > >> > Alexander Malysh >> > >> > >> > Am 16.12.2009 um 18:17 schrieb Konstantin Vayner: >> > >> > >> > >> > Bug report: http://redmine.kannel.org/issues/show/529 >> > >> > Quote from gw/bb_smscconn.c : >> > >> > static void handle_split(SMSCConn *conn, Msg *msg, long reason) >> > { >> > struct split_parts *split = msg->sms.split_parts; >> > >> > /* >> > * If temporarely failed, try again immediately but only if connection >> active. >> > * Because if connection is not active we will loop for ever here >> consuming 100% CPU >> > * time due to internal queue cleanup in smsc module that call >> bb_smscconn_failed. >> > */ >> > if (reason == SMSCCONN_FAILED_TEMPORARILY && smscconn_status(conn) == >> SMSCCONN_ACTIVE && >> > smscconn_send(conn, msg) == 0) { >> > /* destroy this message because it will be duplicated in smsc >> module */ >> > msg_destroy(msg); >> > return; >> > } >> > >> > (end quote) >> > >> > So, if an smsc is alive and throws temporary error every time you try to >> submit such a message, we enter endless loop of attempting to resend it.... >> > >> > >> > Suggested patch follows (also attached). >> > Sorry its not cvs diff - having firewall issues accessing pserver now so >> i ran diff vs snapshot generated yesterday >> > I will be able to produce a normal cvs diff tomorrow morning if it is >> needed >> > >> > >> > --- kannel-snapshot/gw/bb_smscconn.c 2009-11-15 16:12:28.000000000 >> +0200 >> > +++ gateway-cvs/gw/bb_smscconn.c 2009-12-16 19:47:32.000000000 >> +0200 >> > @@ -203,18 +203,6 @@ >> > struct split_parts *split = msg->sms.split_parts; >> > /* >> > - * If temporarely failed, try again immediately but only if >> connection active. >> > - * Because if connection is not active we will loop for ever here >> consuming 100% CPU >> > - * time due to internal queue cleanup in smsc module that call >> bb_smscconn_failed. >> > - */ >> > - if (reason == SMSCCONN_FAILED_TEMPORARILY && smscconn_status(conn) >> == SMSCCONN_ACTIVE && >> > - smscconn_send(conn, msg) == 0) { >> > - /* destroy this message because it will be duplicated in smsc >> module */ >> > - msg_destroy(msg); >> > - return; >> > - } >> > - - /* >> > * if the reason is not a success and status is still success >> > * then set status of a split to the reason. >> > * Note: reason 'malformed','discarded' or 'rejected' has higher >> priority! >> > @@ -303,7 +291,7 @@ >> > void bb_smscconn_send_failed(SMSCConn *conn, Msg *sms, int reason, >> Octstr *reply) >> > { >> > - if (sms->sms.split_parts != NULL) { >> > + if (reason != SMSCCONN_FAILED_TEMPORARILY && sms->sms.split_parts >> != NULL) { >> > handle_split(conn, sms, reason); >> > octstr_destroy(reply); >> > return; >> > >> > >> > >> > >> > >> > <bb_smscconn.diff> >> > >> > >> > >> > >> > >> > >> > >> >> > >
