question

Upvotes
Accepted
nick.zincone avatar image
9.7k ●49 ●38 ●60

RWF version discrepancy and how RFA handles it

I'm trying to gain a better understanding how RFA deals with discrepencies with the version differences of the Reuters Wire Format (RWF) between an RFA application and an ADS. The following output is from an RFA Java application built with 8.0.0.E2.all.rrg. When looking at some general RFA logs, I see this:

Connection[myNamespace::RSSL_nylabats1]: Requested version 14:1, Connected version 14:0


May 05, 2017 3:22:31 PM com.reuters.rfa.internal.connection.rssl.RSSLClientConnection processTransportConnected
INFO: com.reuters.rfa.connection.rssl.myNamespace.RSSL_nylabats1
Connection[myNamespace::RSSL_nylabats1] = (14:0)

I'm making the assumption the 14:1 and 14:0 refer to the RWF versions and that it is of the format: <major ver>:<minor ver>

I can see that my RFA application is using an RWF format of [major:14, minor:1] and that the ADS supports RWF [major:14, minor:0]. I'm also assuming that they are compatible.

Would I expect to see any additional logs if the RWF versions were not compatible?

When looking further, wireshark was used to capture some additional details within an RFA Java application built with 8.0.0.L2.all.rrg. For example, I see this:

RWF Payload Contained in RIPC Socket Transport
    RIPC Message
        Message Length: 32
        Flags: 0x00
        Opcode: 0
        Ripc Version: 12
        Ping Timeout: 60
        Session Flags: 0x00
        Protocol Type: 0
        Major Version: 14
        Minor Version: 1
        Host Name: T66721
        IP Address: 10.5.4.73

And this as a response:

RWF Payload Contained in RIPC Socket Transport
    RIPC Message
        Message Length: 19
        Flags: 0x01
        Opcode: 0x01
        Ripc Version: 12
        Max Msg: 24
        User Size: 0
        Session Flags: 0x03
        Ping Timeout: 30
        Major Version: 14
        Minor Version: 0
        Compression Type: 0
        Compression Level: 0

Above I can see the Major and Minor version as I previously described. What is the Ripc Version: 12 represent?

I ask because later in the wireshark dump, I see this:

RWF Payload Contained in RIPC Socket Transport
    RIPC Message
        Message Length: 67
        Flags: 0x00
        Opcode: 0
        Ripc Version: 14
        Flags: 0x08
        Ping Timeout: 60
        Session Flags: 0x00
        Protocol Type: 0
        Major Version: 14
        Minor Version: 1
        Host Name: T66721
        IP Address: 10.5.4.73
        Component Version: RFA Java Edition 8.0.0.L2.all.rrg

In here there are 2 unexpected things I noticed. The first is that the Ripc Version: 14 for some reason is different than my initial connection. Because I don't really understand what this represents, I'm also not clear as to why it changed from 12 to 14 when I initially connected. This specific connection request didn't succeed and it later performed a successful connection request with Ripc Version: 12. I also noticed there was a new line that contained the Component Version.

I'm unclear as to whether this was expected bahavior and if not, would cause any unexpected behavior later on.

thank you

treprfarfa-apiRWF
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.

2 Answers

Upvotes
Accepted
wasin.w avatar image
11.5k ●16 ●7 ●10

Hi @nick.zincone.1

Basically, when a consumer establishes a connection with a provider with a different RWF version, the lower version is considered the negotiated version for both the consumer and provider on the established connection. The negotiation steps is following

The RFA Java 8 and TREP 3 use the RWF version 14.1. This warning message is generated when the RFA 8 connects the TREP 2.x that uses RWF 14.0 to let the user know that there is a RWF version mismatch, and then the API uses RWF 14.0 as a negotiated version to communicate with TREP 2.x.

Please note that the RWF version 14.1 is backward compatible with version 14.0

The RIPC is the transport communication inside the RWF. Basically, the API manages it for the application and the application does not need to handle it. Do you encounter any issue with it?

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.

nick.zincone avatar image nick.zincone

Thanks Wasin. The application doesn't encounter any issues related to the RIPC version. Just wanted verification on some of the details.

Upvotes
brian.sandri avatar image
478 ●4 ●2 ●3

The RIPC version is the underlying TCP protocol handshake that is used. These are also backward compatible and will downgrade as connection is established. This handshake controls some of the underlying information exchange that may be available at a transport level (e.g. Connected Component versioning, etc).

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.

nick.zincone avatar image nick.zincone

Thanks Brian. I'm still in process of confirming the details related to the wireshark dump I outlined above, but I would expect that when an RFA application starts up, it will attempt to utilize the same RIPC version initially. It seems to make sense that during negotiation is when the downgrade will occur.

Click below to post an Idea Post Idea