Re: Interesting issue with DLRs

Stipe Tolj <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Organization tolj.org system architecture
Message-ID <[email protected]>
Hi Ben,

Ben Suffolk wrote:

> I had assumed that the deliver_sm would come in on the RX bind, and  the 
> submit_sm_resp as the reply on the TX bind. Are you saying the  same 
> thread handles both these binds? If so is it possible that the  SMSC did 
> in fact deliver the submit_sm_resp fractionally before the  deliver_sm 
> but the thread was processing the RX at the time (say  several 
> deliver_sm PDUs were coming in at the same time - which given  the 
> nature of my app happens a lot as the message flow is pretty  bursty 
> like that) and so got to the deliver_sm before the  submit_sm_resp. 
> However its more than possible that the SMSC could be  to blame.

yep yep, you're right, of course... my fault. The submit_sm_resp is the ACK on 
the TX session and either deliver_sm or data_sm for DLR is handled in a seperate 
thread handling the RX session. Sorry for the hassle.

ok, this leads us under MT (TX session) burst state to the following scenario 
hapenning:

TX session is under load, and RX is pretty unused. Now, the MT is flowing into 
SMSC via TX session in a row with a bunch of others. The TCP line is "used" and 
hence submit_sm_resp is "slower" then the DLR flowing on the "free" RX session.

Makes sense under high-load situations.

> Assuming you used a database to store the DLRs and used the same one  
> for each system it should find them? Or by 2 independent SMPP systems  
> do you not mean 2 bearerbox instances connected to the same SMSC?

In my case it was 1 kannel instance and 1 sendxms instance using the same SMPP 
accounts, and both having RX sessions bound. Then you get DLRs over the RX 
sessions of both for MTs that have been submited by the other instance.

Stipe

-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

tolj.org system architecture      Kannel Software Foundation (KSF)
http://www.tolj.org/              http://www.kannel.org/

mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.