[This message was posted by Dale Wilson of Object Computing, Inc 
<[email protected]> to the "General Q/A" discussion forum at 
http://fixprotocol.org/discuss/22. You can reply to it on-line at 
http://fixprotocol.org/discuss/read/247ebdd5 - PLEASE DO NOT REPLY BY MAIL.]

> 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


[You can unsubscribe from this discussion group by sending a message to 
mailto:[email protected]]

--

You received this message because you are subscribed to the Google Groups 
"Financial Information eXchange" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/fix-protocol?hl=en.


Reply via email to