Anders Nygren - 2005-07-22

Hi
Some time ago I argued that enquire_link should propagate all the way up to the application level, so that enquire_link really tests that the application level connection is working, and not just the SMPP connection.

The code recently added in gen_esme_session.erl and gen_esme.erl propagates the enquire_link messages to the gen_esme. But gen:esme:handle_enquire_link/3 does a
    gen_server:cast(ServerRef, {enquire_link, Session, Pdu})
So the gen_esme_session:handle_event({input.........}....) gets a ok reply from the gen_esme and sends an enquire_link_resp independent of if the gen_esme is working or not.

My proposal is to change gen_esme:handle_enquire_link/3 to
handle_enquire_link(.....) ->
    gen_server:call(ServerRef, {enquire_link, Session, Pdu},Timeout).

Add a callback in the gen_esme behaviour handle_enquire_link the application implementing the gen_esme behaviour is expected to reply ok to this callback to show that it is still alive.

gen_esme_session shall not send enquire_link_resp until it has received a reply on the handle_enquire_link callback.

I have looked at how to implement this in gen_esme_session but I have not yet come up with a good way.
What I think I have to do is, in

gen_esme_session:handle_event({input.........}....)  ->
    ...
          CmdId when CmdId == ?COMMAND_ID_ENQUIRE_LINK ->
   cancel_timer(...),
   spawn a new process to run the (SData#state.mod):handle_enquire_link callback to avoid blocking the session.

When the (SData#state.mod):handle_enquire_link callback returns ok send an all_states_event(enquire_link_resp_ok).
When the session reveives the enquire_link_resp_ok event it sends the enquire_link_resp to the peer and starts the enquire_link_timer.

Is that the correct way to do this?

/Anders