Imported from previous forum
Hi,
In case where a single snapshot message spans across more than one MTU/ packet, is there a way of identifying the fragments related to the same snapshot message?
How about having the field LastFragment (893) with the value N (not last message) for the first few fragments and having it set to Y (Last message) in the last fragment of the Snapshot message?
Or else is it better to have 2 fields indicating the total fragment count the snapshot is broken in to and the fragment seq number of the current fragment.
E.g.: two fields x and Y to indicate x of Y fragments.
If not is there already a way in which this can be achieved?
Any suggestions?
Thanks
Maybe not an answer to your question but a couple of thoughts. If one snapshot message spans more than one packet then I assume you do not require the benefits of FAST encoding where the first message in a packet is always complete and savings on the wire start with the second message in each packet.
I am not sure why you would design a single snapshot to be that big if you can avoid it somehow. Each snapshot only carries book data from a single instrument and even a price depth of 50 should be less than 1500 bytes. Or are you sending order depth, i.e. individual orders of an instrument? It might be worth to send only one order per snapshot and take the extra redundancy of root level fields but being able to use FAST. The bytes on the wire will be much less than the message layout suggests.
Recovery also gets more complicated if you cannot get one message into a single network packet.
Hi,
In case where a single snapshot message spans across more than one MTU/
packet, is there a way of identifying the fragments related to the same
snapshot message?How about having the field LastFragment (893) with the value N (not last
message) for the first few fragments and having it set to Y (Last
message) in the last fragment of the Snapshot message?Or else is it better to have 2 fields indicating the total fragment
count the snapshot is broken in to and the fragment seq number of the
current fragment.
E.g.: two fields x and Y to indicate x of Y fragments.If not is there already a way in which this can be achieved? Any
suggestions?Thanks
Maybe not an answer to your question but a couple of thoughts. If one
snapshot message spans more than one packet then I assume you do not
require the benefits of FAST encoding where the first message in a
packet is always complete and savings on the wire start with the second
message in each packet.
A minor correction: When you are using a lossy protocol, the first entry in a repeating subgroup within a message must be complete, but subsequent entries can benefit greatly from FAST encoding. A market data snapshot message that is too large to fit into a single packet will obviously contain many market data entries.
Dale
I am not sure why you would design a single snapshot to be that big if
you can avoid it somehow. Each snapshot only carries book data from a
single instrument and even a price depth of 50 should be less than
1500 bytes. Or are you sending order depth, i.e. individual orders of
an instrument? It might be worth to send only one order per snapshot
and take the extra redundancy of root level fields but being able to
use FAST. The bytes on the wire will be much less than the message
layout suggests.Recovery also gets more complicated if you cannot get one message into a
single network packet.Hi,
In case where a single snapshot message spans across more than one
MTU/ packet, is there a way of identifying the fragments related to
the same snapshot message?How about having the field LastFragment (893) with the value N (not
last message) for the first few fragments and having it set to Y (Last
message) in the last fragment of the Snapshot message?Or else is it better to have 2 fields indicating the total fragment
count the snapshot is broken in to and the fragment seq number of the
current fragment.
E.g.: two fields x and Y to indicate x of Y fragments.If not is there already a way in which this can be achieved? Any
suggestions?Thanks