Re: Kannel 1.4.2 out

Hi,

Sorry for budding in, but this is very interesting conversation and couldn't 
resist.

I imagine that in this case you don't get SIGPIPE from trying to write to a 
closed socket. But if you check the bytes written you should be getting an 
error. Alarms may be needed because i smell timeouts on the socket. This 
could provide for a rollback procedure to reclaim the message and reset the 
state to offline. Of course this will be only a quick workaround untilI 
states are fixed, since I anticipate that the receiver will reset it to 
online, and transmitter offline again.

Is this something feasible for 1.4.2?
Nikos
----- Original Message ----- 
From: "Stipe Tolj" <[email protected]>
Cc: <[email protected]>
Sent: Saturday, January 10, 2009 7:18 PM
Subject: Re: Kannel 1.4.2 out


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