When invoking rsslInitChannel and obtaining RSSL_RET_CHAN_INIT_IN_PROGRESS return code, Why or under

salvatore.riccio
salvatore.riccio
in UPA
When invoking rsslInitChannel and obtaining RSSL_RET_CHAN_INIT_IN_PROGRESS return code, Why or under what conditions does the UPA API return a RSSL_IP_FD_CHANGE?
Tagged:

Best Answer

  • Jirapongse
    Jirapongse
    Answer ✓

    @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.

    image

    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.

Answers

  • zoya faberov
    zoya faberov

    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?

  • Anup.Patel
    Anup.Patel
    Zoya,

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

    Is it the ads going down?Is it the ads re-balancing?
  • zoya faberov
    zoya faberov

    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.

  • zoya faberov
    zoya faberov

    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);
                    }

Categories