Hi, It's good (or not) to know that somebody else has the same problem.
I don't agree to you idear at all since I use the Kannel's notification feature (sendsms cgi with dlrmark/dlrurl fields) to makes my Application aware of the failure and than the Application itself takes charge of the resending process. It means if the Application deliver the message successfuly next time, Kannel will improperly resend the obsolete message, when being restarted, based on store-file. Once Kannel notifies the Application that a message wasn't delivered to SMSC (escape %d = 16) it shouldn't keep resending the message. Actually, Kannel doesn't "keep resending" the message, but when it's restarted, for some reasone it reads the failed messages from store-file and resends them again. It's inconsitent in my point of view. I think the solution is: Each DLR successfuly delivered to an Application MUST be removed from store-file. I consider this a bug. Unfortunatelly I don't have resources to assess the source code and try to fix it, but will be pleased to help on testing. Any other opinions? Mauricio -----Original Message----- From: Kaido Karner [mailto:[EMAIL PROTECTED]] Sent: quinta-feira, 1 de agosto de 2002 08:20 To: Mauricio Ramos; [EMAIL PROTECTED] Subject: RE: PROBLEM: Successful failure notification making messages to be resended re > I realized that every time Kannel successfuly notify my Application that > messages hadn't been delivery to SMSC (escape %d = 16) it write a new line > in store-file, so every notification of a message not sent increases the > store-file. > > The actual problem is when I restart Kannel. When it happens, > Kannel resend > all those messages written in store file which in my point of > view shouldn't > happen because my Application looked after those messages when it had > received the original DLR. I have the same problem - if by some reason (network error for example) the message is not sent and is waiting in the storefile. no attempt is made to resend it, before the bearerbox is restarted. imagine this can happen says later - the message is obsolete at this time anyway. so - the good solution would be to try to resend the message if some reasonable time is passed - or even better - when the appropriate smsc connection seems to be alive again. the quick-and-dirty solution would be clearing the storefile at graceful shutdown of the bearerbox - loosing some messages seems a better alternative to me than resending them days later. now I'm start to think that implementation of resending them at some reasonable time (several minutes for example) after failure should not be very big work .. add a thread to poll the store at some interval for messages old enough and trying to re-send them. however, the store should have something to know if the attempt to send a particular message is even performed. this is easily implemented by adding a special message type (send_attempt or something) and adding this to store each time the message just before sending the message. then the polling thread can look the store for messages which have been attempted to send, but don't have ack after some time, and resend them. did I miss something? maybe somebody have appropriate patch already? kaido
