question

Upvotes
Accepted
33 1 1 6

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?

elektronelektron-sdkrrteta-apielektron-transport-apirssl
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
Accepted
38.1k 71 35 53

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


1573532507302.png (108.6 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
23k 22 9 14

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?

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
1 1 0 3
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?
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
23k 22 9 14

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
23k 22 9 14

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);
                }
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Click below to post an Idea Post Idea