MRN: Uniqueness and ordering
How unique are guids used for MRN stories? Can they be reused across RICs?
If an MRN story is fragmented, are we guaranteed to receive fragments in order of FRAG_NUM?
Best Answer
-
You might find this related: https://community.developers.refinitiv.com/questions/17412/de-duplicating-mrn-story-messages-received-over-tw.html
From the data we have seen so far, FRAG_NUM increases monotonically, but as mentioned in the linked question, you can get resets in the middle of a FRAG_NUM sequence (so counting can re-start from 0).
If you have access to a dictionary data structure, it's not too difficult to address the case for out of order fragments. I agree it would be nicer for the manual to specify this outright so that we don't have to guess either way.
1
Answers
-
I guess this explains the guid uniqueness:
"A single MRN data item publication is uniquely identified by the combination of RIC, MRN_SRC and GUID."
Now I'm just curious to know whether fragments belonging to the same message will always arrive in order of the FRAG_NUM. Documentation doesn't seem to confirm nor deny this.
0 -
Thanks for this. As long as we know that out of order and duplicate fragments are possible we can cater for this.
This does raise the question, if we can receive 'duplicates' (retransmissions) will the same fragment numbers always have the same boundaries, e.g. if we already have a FRAG_NUM==2, will a duplicate fragment with FRAG_NUM==2 have the same starting and ending position as the previously received fragment in the overall message? I guess it will but it would be nice to have this confirmed.
Thanks
0 -
I would assume so, otherwise the protocol would not be consistent. What you can do is (following sequence applies to ETA, you may have to adapt it to EMA):
i) Keep accumulating fragments until total_size == sum(received_fragments_sizes).
ii) Ignore any repeated fragments (can check this through FRAG_NUM). Or you can simply replace the older copy with the new one.
iii) When total_size == sum(received_fragment_sizes), iterate through the fragments (in FRAG_NUM order) and append the content to a single buffer.
iv) Unzip the buffer content and parse into JSON.
Cheers,
0 -
Thanks. I was thinking of IP where you can receive overlapping fragments (but otherwise don't have explicit fragment numbers). I hope the boundaries remain the same if the sequence resets.
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
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛