Imported from previous forum
Allowing the client application, or exchange (for example) to specify multiple orders or multiple execution reports within a single message / data packet.
For example, if an aggressive 10 lot order matches against 10, 1 lot orders which are already resting in the book, why send 10 execution reports (a large proportion of which is duplicated information), when you could send one message containing all the data to reduce bandwidth and improve performance.
just to understand you proposal more in detail; would you be OK with a message encoding that would de-duplicate (remove) the repeated info before sending and re-insert it when the message is received at the other end? Or, do you think that this would still carry too much processing overhead at the receiving end?
Allowing the client application, or exchange (for example) to specify multiple orders or multiple execution reports within a single message / data packet.
For example, if an aggressive 10 lot order matches against 10, 1 lot orders which are already resting in the book, why send 10 execution reports (a large proportion of which is duplicated information), when you could send one message containing all the data to reduce bandwidth and improve performance.
In general quite happy with what you describe being part of the protocol layer - works well in FAST…
My proposal was more along the lines of reducing the number of messages that are being sent by expanding the business level message to allow multiple related execution reports within a single message encoding. That way the duplicate info would not need to be dealt with by the protocol as it would not have been present in the message at the business level.
just to understand you proposal more in detail; would you be OK with a message encoding that would de-duplicate (remove) the repeated info before sending and re-insert it when the message is received at the other end? Or, do you think that this would still carry too much processing overhead at the receiving end?
Allowing the client application, or exchange (for example) to specify multiple orders or multiple execution reports within a single message / data packet.
For example, if an aggressive 10 lot order matches against 10, 1 lot orders which are already resting in the book, why send 10 execution reports (a large proportion of which is duplicated information), when you could send one message containing all the data to reduce bandwidth and improve performance.
This is quite interesting if the exchange manage the “bundling” during the matching. Otherwise, if a software layer in the middle needs to package multi messages together it may be expensive and slow.
If my memory is correct, the old paris exchange protocol (MMTP) used to package ack+fully filled in a single message for “at best” orders for example…
This is efficient for the matching engine and efficient for the receiving end.
In general quite happy with what you describe being part of the protocol layer - works well in FAST…
My proposal was more along the lines of reducing the number of messages that are being sent by expanding the business level message to allow multiple related execution reports within a single message encoding. That way the duplicate info would not need to be dealt with by the protocol as it would not have been present in the message at the business level.
just to understand you proposal more in detail; would you be OK with a message encoding that would de-duplicate (remove) the repeated info before sending and re-insert it when the message is received at the other end? Or, do you think that this would still carry too much processing overhead at the receiving end?
Allowing the client application, or exchange (for example) to specify multiple orders or multiple execution reports within a single message / data packet.
For example, if an aggressive 10 lot order matches against 10, 1 lot orders which are already resting in the book, why send 10 execution reports (a large proportion of which is duplicated information), when you could send one message containing all the data to reduce bandwidth and improve performance.
Yes, match engines may generate multiple execution reports from a single event, e.g. one large order trades with multiple counter parties at different prices. There’s no question that it would be more efficient to deliver a bundle of execution reports to an end point as opposed to routing them individually. Not only would the work to encode duplicate party identifiers be reduced, but the routing process would be performed once instead of multiple times.
In our network tests we have found that message size is often less important for performance than the number of packets transmitted. In the case of bundling execution reports, a message would grow somewhat to accomodate multiple quantities and prices, but the message should still fit within a single packet assuming encoding is very efficient. Therefore, from a network perspective, latency would be lower to route and deliver that packet as opposed to individual messages.
This is quite interesting if the exchange manage the “bundling” during the matching. Otherwise, if a software layer in the middle needs to package multi messages together it may be expensive and slow.
If my memory is correct, the old paris exchange protocol (MMTP) used to package ack+fully filled in a single message for “at best” orders for example…
This is efficient for the matching engine and efficient for the receiving end.
In general quite happy with what you describe being part of the protocol layer - works well in FAST…
My proposal was more along the lines of reducing the number of messages that are being sent by expanding the business level message to allow multiple related execution reports within a single message encoding. That way the duplicate info would not need to be dealt with by the protocol as it would not have been present in the message at the business level.
just to understand you proposal more in detail; would you be OK with a message encoding that would de-duplicate (remove) the repeated info before sending and re-insert it when the message is received at the other end? Or, do you think that this would still carry too much processing overhead at the receiving end?
Allowing the client application, or exchange (for example) to specify multiple orders or multiple execution reports within a single message / data packet.
For example, if an aggressive 10 lot order matches against 10, 1 lot orders which are already resting in the book, why send 10 execution reports (a large proportion of which is duplicated information), when you could send one message containing all the data to reduce bandwidth and improve performance.
This is covered in FIX since 5.0 SP1 with the addition to the Execution Report. This has been made even more flexible with the new which is part of the ISE Order Handling proposal (currently in puiblic review until Jan 28).
I consider this problem to be solved. It was also extremely important from another point of view, i.e. to be able to align the FIX transaction model with the one from the matching engine to avoid the user seeing intermediate states that are unknown to the matching engine because the multiple executions were atomic for it (single transaction).
Allowing the client application, or exchange (for example) to specify multiple orders or multiple execution reports within a single message / data packet.
For example, if an aggressive 10 lot order matches against 10, 1 lot orders which are already resting in the book, why send 10 execution reports (a large proportion of which is duplicated information), when you could send one message containing all the data to reduce bandwidth and improve performance.