When invoking rsslInitChannel and obtaining RSSL_RET_CHAN_INIT_IN_PROGRESS return code, Why or un...

Hello @salvatore.riccio

Please see the answer to the following question, very similar,

Please let us know if you are encountering RSSL_IP_FD_CHANGE

under the same conditions, and if the suggestion helps you proceed?

response from previous post says that there's no cleanup, but what client is asking WHAT CAUSES THIS PROBLEM?

Hello @Anup.Patel, @salvatore.riccio,

The referenced thread contains the advice, what is recommended to do upon receipt of RSSL_IP_FD_CHANGE, to unregister interest, to remove from notifier, and not to close the connection. This is not a common condition, but if in receipt of it, it's important to know how to handle it.

This is not a pbm, if I understand you, not a failure, not unrecoverable error.

It means that on receipt, there is no guarantee of the integrity, and the recommended handling on consumer is described.

Hello @Anup.Patel @salvatore.riccio,

Optionally, review further info from UPA Developer Guide by searching for

"RSSL_IP_FD_CHANGE".

Section 10.5.2 explains what happens and section 10.5.5 shows how to unregister:

if (inProgInfo.flags & RSSL_IP_FD_CHANGE)
                {
                    /* File descriptor has changed, unregister old and register new */
                    FD_CLR(inProgInfo.oldSocket, &readfds);
                    FD_CLR(inProgInfo.oldSocket, &writefds);
                    FD_CLR(inProgInfo.oldSocket, &exceptionfds);
                    /* newSocket should equal pChnl->socketId */
                    FD_SET(inProgInfo.newSocket, &readfds);
                    FD_SET(inProgInfo.newSocket, &writefds);
                    FD_SET(inProgInfo.newSocket, &exceptionfds);
                }

@salvatore.riccio

It can happen when the API is negotiating the version used by the channel.

For example, I got RSSL_IP_FD_CHANGE when running the ETA consumer from ESDK 1.3.1.L1 to connect to the UPA Provider 7.6 or RFA Provider 7.6. ESDK 1.3.1.L1 is newer than UPA Provider 7.6 and RFA Provider 7.6.

The result from Wireshark indicates that there are disconnection and reconnection before the channel is active.

I assume that first, the ETA consumer from ESDK 1.3.1.L1 is trying to connect to the Provider with the new version that isn't supported by the Provider 7.6. Then, the provider has rejected the connection. Next, the ETA consumer is trying to reconnect to the provider by lowering its version and at the second attempt, it can connect to the provider with this version.

All of these are handled internally in ETA and the application receives RSSL_IP_FD_CHANGE because of this disconnection and reconnection.