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