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>
>
>
>
>
>