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
Best Answer
-
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 followingThe 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.0The 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?
0
Answers
-
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).
0 -
Thanks Wasin. The application doesn't encounter any issues related to the RIPC version. Just wanted verification on some of the details.
0 -
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.
0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛