TRCC - issue contributing using SSLInserts and Marketfeed - how to remove 0x00 bMarketfeed
Hi - this leads on from this previous query:
In brief, we have an application team using an application coded with RFA6 which is unable to contribute via SSLInserts on RCC (Contributions Channel). They receive a postMsg NAK which complains about containerType RSSL_DT_OPAQUE.
In the previous query we were advised to approach the RTDS team and we have since had the following response back from them:
"Please see our developer's update for this query:
From the ads.dbg, there are several SIPC message dump,
Sipc message Received: Len: 128 HdrLen: 6 Flags: 0 ProtId: 0 FD: 32 Thu Aug 05 12:52:56 2021 MsgLen 128 Flags 0 Opcode 24 HdrLen 5 SSL Insert Request. srvcId: 2 ReqId: 215386792
ItemName: DE000BC0AVW4=BARL DataLen: 97
Data(97):
1c35 1d2e 4445 3030 3042 4330 4156 5734 .5..DE000BC0AVW4
3d42 4152 4c2e 4e61 451f 301e 3638 1f31 =BARL.NaE.0.68.1
3320 4465 6320 3230 3231 1e37 381f 4445 3 Dec 2021.78.DE
3030 3042 4330 4156 5734 1e32 3735 1f31 000BC0AVW4.275.1
3232 2e39 371e 3339 331f 3132 302e 3937 22.97.393.120.97
1e39 3638 1f42 4152 434c 4159 5353 501c .968.BARCLAYSSP.
00 .
The first byte is 0x1c and the last byte is 0x00, which is wrong, the last byte should be 0x1c. <FS> in hex is 0x1c.
When converting SSL insert to RSSL post message, we have to scan the payload to determine if Marketfeed (or not) as SSL inserts do not contain a container type.
To determine if Marketfeed (or not), we look at the first byte and last byte of the payload for the <FS> start and terminator (that’s it) and if <FS> is not in the first and last byte, we assume it’s not Marketfeed and set the container type on the RSSL post message to RSSL_DT_OPAQUE and of course we will not be convert to RWF.
As the last byte is not 0x1c, ADS assumes it is not Marketfeed and sends RSSL_DT_OPAQUE to TRCC which of course it rejects.
So it seems the consumer application is adding an extra byte onto the end of the Marketfeed which is causing this.
Remove the 0x00 and have a try again"
Do you have any advice for our application team about how to remove the 0x00?
Best Answer
-
Looking at some old RFA C++ contributions example source code, I can see the MF buffer is constructed at the application level - i.e. adding each of the components of the message along with the various separators such as FS,GS, RS, US individually.
Therefore, if an additional byte is being added to the buffer - it is most likely an application-level coding error e.g. wrongly sized buffer that is passed to the rfa::sessionLayer::MarketDataContributor:contribute() function.
Another explanation could be that the older version of RFA was wrongly adding the additional byte to the buffer after it was passed to the API via the rfa::sessionLayer::MarketDataContributor:contribute() function. However, given how old RFA 6 is I cannot confirm if there was such a bug.
0
Answers
-
RFA 6 is an end-of-life product.
Please try the latest RFA 7 that supports the SSL protocol.
- RFA C++: https://developers.refinitiv.com/en/api-catalog/refinitiv-real-time/robust-foundation-api-rfa-c--/downloads
- RFA Java: https://developers.refinitiv.com/en/api-catalog/refinitiv-real-time/robust-foundation-api-rfa-java/downloads
It could be a known issue that has been fixed in the latest version of RFA.
Please also refer to the API compatibility matrix for the supported operating systems and compilers
1 -
Thanks but the application team are struggling to meet the deadline of MLIP (Marketlink) being EOL and would like some guidance on how to quickly re-code their existing application to work via RCC. Are you able to elaborate any further on the advice given by the RTDS team on how to go about removing the 0x00 from the Marketfeed messages?0
Categories
- All Categories
- 6 AHS
- 37 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 中文论坛