Am 19.03.2010 um 13:05 schrieb Konstantin Vayner: > 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)
try this setup for e.g. SMPP with the same username/pass and you will get issues with DLRs because DLRs will arrive on every connection. And to the question about shutdown: yes you will lose pointer to SMSC struct and there would be only one possibility to go for sure, retransmit all parts. > > > On Fri, Mar 19, 2010 at 1:57 PM, Alejandro Guerrieri <aguerri...@kannel.org> > 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 > aguerri...@kannel.org > > > > 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 <amal...@kannel.org> >> 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 <amal...@kannel.org >> > <mailto:amal...@kannel.org>> 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 <amal...@kannel.org >> > <mailto:amal...@kannel.org>> 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> >> > >> > >> > >> > >> > >> > >> > >> >> > >
