RE: smpp reconnect bugfix

Against which version of Kannel this patch was generated ?
Please - before fixing a but, check the CVS to see if it wasn't fixed
already, and it it hasn't - generate your patch against latest CVS.

Also - I don't think that this patch is correct - it will only make the
receiver thread not being able to change the status of the connection if
a transmitter exist. maybe a better approach would be to have two status
variables ?

--
Oded Arbel
m-Wise mobile solutions
[email protected]

+972-9-9581711 (116)
+972-67-340014

::..
'I never met a piece of chocolate I didn't like.'

> -----Original Message-----
> From: Vibhu Mohindra [mailto:[email protected]]
> Sent: Saturday, September 28, 2002 1:30 AM
> To: [email protected]
> Cc: Mohit Narain
> Subject: smpp reconnect bugfix
> 
> 
> Observation:
> 
> If the receiver connection breaks but the transmitter 
> doesn't, then later
> even though the receiver manages to reconnect correctly, the 
> transmitter
> stops sending SMSs. That is, further submit_sms continue to be queued
> instead of being sent.
> 
> Reason:
> 
> The transmitter io_thread is given enough privileges to update
> the status to SMSCCONN_ACTIVE upon successful binding. However the
> receiver thread can only make the status SMSCCONN_ACTIVE_RECV. This
> means that if the receiver socket breaks then the status is
> reduced to SMSCCONN_RECONNECTING. Upon a reconnect it becomes
> SMSCCONN_ACTIVE_RECV. Since the transmitter socket never broke it will
> not need a reconnect and consequently the status will remain only at
> SMSCCONN_ACTIVE_RECV.
> 
> The thread receiving SMSs from the smsbox sees that the status is not
> SMSCCONN_ACTIVE and so (correctly) continues queueing messages.
> 
> Proposed Fix:
> 
> Kannel can treat a broken receiving connection exactly the same as
> a connected receiving connection where the SMSC has no messages for
> it. However it must behave differently when the transmitting 
> connection
> is up from when it is down (send messages vs. queue them). This seems
> to be why transmitter and transceiver are privileged enough to update
> the status to SMSCCONN_ACTIVE, whereas the receiver is not. 
> In the same
> spirit I thought it made sense for only the transmitter (or 
> transceiver)
> thread to reduce the status to SMSCCONN_RECONNECTING upon a 
> socket snap.
> 
> If the receiver socket snaps, the receiver io_thread will go into a
> reconnect anyway. However there is no need for it to set the (shared)
> status variable to SMSCCONN_RECONNECTING, especially since it is not
> itself privileged enough to later restore the status to 
> SMSCCONN_ACTIVE.
> 
> Vibhu
>