The message "Accepted for delivery..." is displayed by smsbox AFTER a positive ack from bearerbox. Otherwise it will say "Not routable..." or any other appropriate error message.
== Rene -----Original Message----- From: Alvaro Cornejo [mailto:[email protected]] Sent: Monday, 23 August, 2010 20:43 To: Rene Kluwen Cc: Alexander Malysh; [email protected] Subject: Re: smppbox bulk sms: slow reception from a client I think we are mixing things IMHO opensmppbox should gives back an ACK immediately after receiving a packet that complies to SMPP specs --otherwise return an error--, no matter what finally happens with it. This will be something equivalent to the "0: Accepted... " in kannel. ie message received by kannel (opensmppbox in this case). Even more that from the client point of view, opensmppbox acts as its SMSC. Independently whether opensmppbox has or not a queue to store messages to be forwarded to kannel. If sender needs full/partial delivery status, then that is another story.It should ask for the dlr type he wants, and opensmppbox should request kannel to return it any dlr addresses to it. And I think this is being handled in another thread Regards Alvaro |--------------------------------------------------------------------------- --------------------------------------| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com On Mon, Aug 23, 2010 at 7:23 AM, Rene Kluwen <[email protected]> wrote: > Yes, you are right. I totally agree. > > == Rene > > -----Original Message----- > From: Alexander Malysh [mailto:[email protected]] On Behalf Of > Alexander Malysh > Sent: Monday, 23 August, 2010 10:49 > To: Rene Kluwen > Cc: [email protected] > Subject: Re: smppbox bulk sms: slow reception from a client > > Hi Rene, > > I don't really understand why do you need this patch to get more > performance... > If you will use queues you have also use store or you have to delay acks to > the client. > And as far as I see it will have the same effect if client would use > windowing and you > just forward messages to bearerbox without any queues because you will have > queues > overhead. > > Thanks, > Alexander Malysh > > Am 22.08.2010 um 21:03 schrieb Rene Kluwen: > >> Sorry, forgot to copy the list. >> >> -----Original Message----- >> From: Rene Kluwen [mailto:[email protected]] >> Sent: Sunday, 22 August, 2010 20:53 >> To: 'Hillel Bilman'; 'Davit Mirzoyan'; 'Alvaro Cornejo'; 'Nikos Balkanas'; >> '[email protected]' >> Subject: RE: smppbox bulk sms: slow reception from a client >> >> For the ones who are worried about smppbox performance. Here is something >> that I believe in better than the queue implementation (like in my earlier >> post of today). >> >> At some point in time, I made smppbox wait for a bearerbox ack before >> acknowledging the message back to the ESME and vice versa. In the > following >> patch, I turned that back again. I immediately acknowledge the message, >> irregardless what it's relaying status later is going to be. >> >> If you have problems with smppbox and/or slow performance, this patch > might >> be for you. I made the patch in such a manner that it is easy to make a >> configuration option for this, in a later stage. >> >> Please test. >> >> == Rene >> >> >> -----Original Message----- >> From: Hillel Bilman [mailto:[email protected]] >> Sent: Sunday, 22 August, 2010 18:59 >> To: [email protected] >> Cc: [email protected] >> Subject: RE: smppbox bulk sms: slow reception from a client >> >> Thanks for the update and to Chimit for smppbox in general. >> >> To take up the discussion from the user group, you mentioned a great idea > to >> have another set of queues that smppbox only uses. >> To add to this, it would be great to have the same set of queues where you >> can set priority and range 0-3 is allowed. Then this prevents your > smppbox >> flooding bearer box and also you can far more easily isolate problems from >> smppbox. >> >> Regards >> >> >> >> <smppbox_direct_acks_1.patch> > > > > >
