Re: Kannel 1.4.2 out

I can confirm this behavior from tests made back on 2004, when we were  
being certified by a carrier to connect to them. I don't know if  
anything changed since then on the code, it seems like it didn't.

When we used a single TX/RX link, disconnecting half of it wouldn't  
drop the other half. Alex suggested me to use two independent links  
and that solved the problem.

Regards,
--
Alejandro Guerrieri
[email protected]

El 10/01/2009, a las 18:18, Stipe Tolj escribió:

> Alexander Malysh schrieb:
>>
>> As far as I know it only happens on SMPP connections with receiver  
>> and
>> sender thread (not transceiver). Is it correct?
>> If yes, then we need to investigate this bug first or disable 2  
>> Threads
>> (sender and receiver) and force users to use 2 SMPP connection groups
>> (one for receiver and one for sender).
>
> yep, I can confirm this as seen on some production (high load)  
> systems.
>
> The effect can be described as following:
>
> - A SMPP connection that uses 'port' and 'receive-port' in the smsc  
> group.
> - Which means we have 1 TCP connection for the transmitter session,  
> and 1 TCP
> connection for the receiver session.
> - Due to architecture design, a "smsc" can have only 1 state.  
> Normally this
> would be "online" internally, so the abstraction layer of bearerbox  
> will
> consider in it's routing decision this as a valid route.
> - Now, the magic part: We get a so called "silent TCP teardrop",  
> which means the
> TCP connections are "semantically disconnected" by a middle router,  
> but the TCP
> end-points (server, client) don't get a corresponding TCP drop  
> packet. In this
> state we (Kannel) "believes" we're still connected. If we use  
> enquire_link PDUs
> to ensure we "are" connected, we will notice we're not and drop the  
> TCP
> connections, trying to re-establish the connection.
> - The "fun" thing is: if the TCP teardrop happens only for the  
> transmitter
> session, the receiver session will still keep getting  
> enquire_link_resp PDUs
> back from the SMSC side and keep the overall module state in  
> "online", and hence
> the transmitter part is NOT re-establishing the connection.
> - The result: we end up in a transmitter session that seems "online"  
> from the
> perspective of the abstractive bearerbox layer, so it WILL route MTs  
> this way,
> and we keep pushing them into the "lost sink".
>
> What we need to check is the state handling here.
>
> @Arne: is this pretty much the behavior you have also being faced  
> with?
>
> 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
> -------------------------------------------------------------------
>