Re: Interesting issue with DLRs

Andreas,

How do I do this?

I only have the one smsc configuration, with the tx and rx ports set.  
So as far as I am aware its only on session anyway? If you mean a  
transceiver , they are not supported by the operator.

Regards

Ben
On 21 Oct 2006, at 07:59, Andreas Fink wrote:

> In this case the solution is to use a SINGLE session instead one  
> for receive and one for transmit.
>
> On 20.10.2006, at 21:44, Ben Suffolk wrote:
>
>> Stipe,
>>
>>> 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.
>>
>>
>> I have looked at the relevant logs (attached here as a text file,  
>> with my notes and a lot removed to make it readable with just the  
>> relevant parts in), and it seems to bear out my initial thoughts  
>> that the DLR is coming in on a different thread, and so has the  
>> opportunity to be processed before the response in the tx thread.
>>
>> You will note from the logs that the message responses are  
>> asynchronous to the submissions. Thats because this operator uses  
>> an smpp load balancer in front of the SMSCs so that although you  
>> have only one connection, they share the messages across multiple  
>> SMSCs, and as different SMSCs are under different loads some are  
>> able to respond quicker than others.
>>
>> Regards
>>
>> Ben
>>
>> <smsc.log>
>>
>