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.
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?
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).