Re: [Quickfix-developers] fragmentation?

[Alvin W. <AW...@FF...>]

Excerpt from FIX44 vol5:

Fragmentation of Allocation Messages

FIX Allocation messages support fragmentation in a way similar to=20
MassQuote and the List Order messages.  If there are too many entries=20
within a repeating group to fit into one physical message, the entries can=
=20
be continued in subsequent messages by repeating the principal message=20
reference and other required fields, then continuing with the repeating=20
group.  This is achieved by using an optional TotNoAllocs field (giving the=
 total number of AllocAccount details across the entire=20
allocation) that supplements the NoAllocs field (giving the number of Alloc=
Account details in a particular message=20
fragment).  The TotNoAllocs field is repeated with the same value in all fr=
agments of the batch.  For=20
example, an Allocation Instruction with 200 allocation account instances=20
could be fragmented across three messages - the first two containing=20
TotNoAllocs=3D200, NoAllocs=3D80 and the third TotNoAllocs=3D200, NoAllocs=
=3D40.=20
To help the receiver reconstitute the batch the Boolean field LastFragment =
is sent with a "Y" value in the last fragment.
For fragmented allocation events the receiving application must persist=20
state between messages to determine whether all instances of the repeating=
=20
group have been received before acting on the instruction or processing=20
the report.=20
For this to work some key rules must be enforced:
1)      The sender must supply a consistent value for TotNoAllocs in all=20
related fragments and must use the same primary message reference in all=20
fragments of the batch, e.g. AllocID in AllocationInstruction.
2)      The sender must ensure that fragments are transmitted in order=20
without intervening traffic.
3)      The NoAllocs group must reach capacity only in the last fragment,=
=20
and that message must contain LastFragment=3DY.
4)      The receiver must acknowledge every fragment received=20
(AllocationInstructionAck with AllocStatus=3D"received") and never reject a=
=20
non-last fragment; acknowledgment of the final fragment accepts or rejects=
=20
the entire set.

There are a number of design suggestions for implementing fragmentation:
1)      Optional block-level fields supplied in early fragments need not=20
be repeated in subsequent fragments.  If they are repeated and the values=
=20
are different, the receiver may choose to reject (on receiving the last=20
fragment) or to apply the last received value to the event.
2)      If a message supports multiple "Number of" groups, e.g. NoOrders,=
=20
NoExecs, and NoAllocs in AllocationInstruction, the sender may distribute=
=20
the array instances over any and all fragments, as long as the NoAllocs=20
group is not filled before the last fragment.
3)      The receiver must be able to abort collecting an incomplete array=
=20
? either on expiration of a timer or the receipt of an unrelated message=20
from the same counterparty.

FIX Message
<Total number of> field
related <Number of> field
Prinicipal message reference
AllocationInstruction
TotNoAllocs
NoAllocs (78)
AllocID (70)
AllocationReport
TotNoAllocs
NoAllocs (78)
AllocReportID (755)

Maximum message size for fragmentation purposes can be determined by using=
=20
the optional MaxMessageSize field in the Logon message or by mutual=20
agreement between counterparties.






Joerg Thoennes <Joe...@ma...>
02/15/2005 11:32 AM

=20
        To:     Alvin Wang <AW...@FF...>
        cc:     qui...@li...
        bcc:=20
        Subject:        Re: [Quickfix-developers] fragmentation?


Hi Alvin,

> How does quickfix handle fragmentation? Do I have to do it myself? Or=20
> quickfix will decide and handle for me? Thanks!

What do you mean? If a socket read returns an incomplete FIX message, and=
=20
the next socket=20
read returns the next part and whether QF handles this?

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen



**********************************************************************
This e-mail message is intended solely for the use of the addressee. The me=
ssage
 may contain information that is privileged and confidential.  Disclosure to
anyone other than the intended recipient is prohibited. If you are not the
intended recipient, please do not disseminate, distribute or copy this
communication, by e-mail or otherwise. Instead, please notify us immediatel=
y by
return e-mail (including the original message with your reply) and then del=
ete
and discard all copies of the message.
We have taken precautions to minimize the risk of transmitting software vir=
uses
 but nevertheless advise you to carry out your own virus checks on any
attachment to  this  message.  We  accept  no  liability  for any loss or d=
amage
 caused by software viruses.
**********************************************************************