Did I get this right: TCP not SMPP connections are left open?
Well, anyway, on both protocols this can happen anytime to anyone with
misconfigured or defect routers or whatever, that should be no problem
to any SMSC or currently available TCP stack... that's why the good
and awesome god OSI invented timeouts ;-)
I administrate a a SMSC and a couple of VSMSCs with some hundred
clients connected to them. There are always some not connected or the
connection has broken down without any TCP FIN or SMPP UNBIND. The
connection hangs around in an undefined state for some seconds and
returns to Listen/Disconnected and awaits a new connection.
I really don't get the problem...
But maybe it would be very helpful if you have a bearerbox.log from
such an event.
Regards
Falko
Am 17.02.2009 um 17:33 schrieb Manuel Fernando Aller:
Stipe Tolj wrote:
Manuel Fernando Aller schrieb:
First of all, I don't think it was problem of kannel, but
searching in
the source code I can't find the specific code where kannel closes
connection whith the smsc after sending an sms.
As you can imagine, I'm not a c++ developer :-P
you don't have to. Kannel itself is C with POSIX.1 threads
(pthreads),
so no object orientation at all :p
You've catched me again, I'm not a C developer :-S
I agree with Falko, we need more details. In fact the list would need
to review a snippet of your bearerbox.log to verify what is going on
exactly at the time you have experienced the connection misbehavior.
When we connect to this new operator, we configure Kannel as usual.
Couple of days later, operator is saying that we are leaving open
connections with the SMSC.
I then tried to understand why this happens (with my limited knowledge
of smpp protocol), And I figure out that 'kannel opens an maintains
ONE
and ONLY connection with the SMSC, so I don't know where or when the
connections are left open', as the operator is saying that the only
content aggregator with this problem is us...
Another possibility is the so-called "silent TCP teardrop" effect,
which means: a router node in the middle of the IP connection route
drops the connected "silently". Which means both TCP communication
endpoints still think the connection is valid, but the router has
"cut
it in the middle", without signaling the TCP connect dropping to any
of the endpoints.
This was my first feeling to this situation.
Thanks!
--
Manuel Fernando Aller
