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