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