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

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?

Welcome!

It looks like you're new here. Sign in or register to get started.

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?

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Welcome!

It looks like you're new here. Sign in or register to get started.