Under what conditions should I recall rsslConnect and/or rsslInitChannel for an RSSL Consumer in ...

bneway

...the event of disconnection?

Hi, I am trying to flush out disconnect handling for an RSSL Consumer connecting to a UPA server and I have some questions. The connection type this question is relevant to is RSSL_CONN_TYPE_SOCKET. I am first wondering if there are any general guidelines on usage of rsslConnect and rsslInitChannel in the event of failure to connect or disconnection. I also have some specific questions regarding the proper course of action to take in various scenarios.

• Say the first call to rsslConnect returns a NULL pointer. I assume in this case the only sensible course of action is to wait a retry period and attempt the call again later.
• Say a connection is established with the UPA server, the logon is successful, and messages are being exchanged. Later, a call to rsslRead or rsslWrite fails and inspecting the channel state reveals the channel state is RSSL_CH_STATE_CLOSED. There are a few courses of action that I see as being likely, but am unsure which, if any, are the right one:
  • Call rsslInitChannel until the connection is reestablished and the channel state is RSSL_CH_STATE_ACTIVE. I suppose this case begs the question, do I need to logon again?
  • Call rsslConnect again, followed by calls to rsslInitChannel
  • Completely tear down the connection with rsslCloseChannel and then completely start over

Thank you very much for your time

Jirapongse

@bneway

Thank you for reaching out to us.

If the channel's state is RSSL_CH_STATE_CLOSED, the application needs to close the channel, and then call rsslConnect again followed by rsslInitiChannel until the channel is active.

If the rsslConnect method returns NULL, the application should get an additional information in the RsslError structure.

You can refer to the Consumer example in the package regarding how to handle the channel's states.