MEMO (MEMbers Order)

What is the difference between Replay and Stream modes?

The mode is defined by the configuration of the port and is advertised to the client after login. The current protocol specification provides more in the “Request Modes” section.

Is it possible to have both Replay/Stream behaviors for the same session?

No, a server (i.e. – a session) operates in one mode only per the current specification. Depending on the service being recovered, the recovery server will be in either streaming or replay mode. e.g.: MEMO will always be conducted over “streaming” mode, while MEMOIR multicast feeds will offer a gap recovery “replay” mode server.

Please explain exchange matching engine failover and how it affects my session connectivity.

Order entry sessions do not connect directly to a matching engine, as such a matching engine failure should not affect a customer’s order entry or market data connections. Should a matching engine fail, any orders sent during the failure will be rejected via MEMO. Market data feeds will also continue to operate. 

What if my MEMO Port fails?

Should a MEMO Port fail (e.g.: hardware failure), the MEMX team will take appropriate action to recover the port.  Customer’s will reconnect on the same IP address/port to the recovered MEMO port. Any messages missed messages can be replayed allowing customers to continue from the point of failure. The same would hold true for market data feeds.

Can I start a session with an old identifier?

The start of session message will always send a new and unique session identifier. While the specification does allow a previous session identifier to be sent in the streaming or replay request, MEMX does not currently plan to support the replay of previous sessions. Should the replay of a different/previous session identifier be requested a “Stream Rejected”/”Replay Rejected” message with error code “P” will be transmitted in response.

How many sessions does a MEMO port support?

Most MEMX-TCP servers will accept only one concurrent connection from a client.

Is disconnecting the TCP session equivalent to a graceful logout?

Yes, disconnecting from the TCP server is the accepted procedure for logging out as stated in the current specification: “Once the client no longer wishes to receive messages, the client should initiate a TCP disconnection.”

Should I expect heartbeat messages at regular intervals regardless of other messages on the connection?

No. You should treat the receipt of any message from the server as a heartbeat for the purposes of keeping the connection alive, and the server will not send heartbeats unless no messages have been sent within the heartbeat interval. Per the specification: “Any message counts as a heartbeat for the purposes of keeping a session alive.”

For the provision of CMS symbology, will an appended suffix within tag 55 be rejected?

Yes, MEMX will reject if tag 55 contains both the symbol and the suffix.

Will the exchange reject a new order on the receipt of a duplicate ClOrdID?

Yes

The spec identifies a reason for a cancel reject as duplicate order ID, but not new order reject?

The early preview specification is currently missing several reasons, additional reasons will be provided in the next version.

For Cancel requests the specification states that either OrigClOrdID or OrderID fields must be present. Can both identifiers be present on the order?

Yes, however we will reject the order if the identifiers do not both reference the same order.

Is MassCancelRequest performed across the MPID + optional CancelGroupID?

The mass cancel is performed against the entire firm unless additional restrictions are applied such as side, symbol, and CancelGroupId etc.

Is there any setting to prevent or reject Mass Cancels for a session?

No, the exchange will not reject a mass cancel request based on a session or port setting.

Is ExecID unique for both sides of the same exchange cross?

Yes.

Can we opt out of some server messages e.g. PendingNew/ PendingCancel?

No.

What message is sent back for Self Trade Prevention cancels?

ExecutionReport_Canceled will be sent for orders that were canceled as a result of this check.

What is the default setting for order routing? Does the exchange apply any default behavior if the order doesn’t contain this explicit instruction?

This field is mandatory and there is no default behavior.

Is the OrderID used in the MEMO specifications correlated with the OrderID in the MEMOIR Market Data specifications?

Yes. The MEMO ExecID in an ExecutionReport_New, ExecutionReport_Replaced, and ExecutionReport_Restatement message is correlated with the OrderID in the associated messages in MEMOIR Depth. For example, if an ExecutionReport_New is received, the MEMOIR Depth OrderID is the ExecID of the ExecutionReport_New message. If an ExecutionReport_New followed by an ExecutionReport_Restatement is received, the MEMOIR Depth OrderID is the ExecID of the ExecutionReport_Restatement message.

Do MEMO SBE and FIX protocols have 100% feature parity as far as trading functionality is concerned?

No.  MEMO FIX does not offer the ability to cancel on behalf of a different port nor does it offer the mass cancel functionality. These features are available only via SBE.

What is the max message rate supported for SBE TCP?

There is no fixed maximum messaging rate at the MEMO port (i.e. throttle). In the event that MEMO messages are sent faster than the system can process them TCP flow control will be used to indicate this to clients.

The heartbeat interval is configurable, any guidance regarding the interval range?

Unless clients request otherwise, MEMX will emit heartbeats at 1 second intervals, and time out clients after 5 seconds of inactivity. Many clients will find this sufficient.

What is an RST packet sent in response to invalid client request?

An RST packet is a TCP/IP packet control flag which will close a TCP connection immediately, causing the operating system to free the resources associated with the connection without waiting for additional information from the server-side. See RFC 793 https://tools.ietf.org/html/rfc793

Are all execution reports sequenced?

Yes.

What messages are not sequenced?

All MEMO business layer messages from the client to the MEMX server are not sequenced. All MEMO business layer messages from the MEMX server to the client are sequenced.

MEMOIR Protocol Details

What is expected heartbeat interval to maintain Gap fill and Snapshot TCP connections throughout the day?

Sending heartbeats at a 1 second interval is sufficient, but configurable if necessary.

Are there limitations on number of packets per retransmission request, the timeliness of retrains requests, or the number of retransmission requests per day?

MEMX has yet to define any such limits.  They will be made available in upcoming spec versions/FAQs.

Can you tell me more about the “ReplayRequest”, “ReplayBegin”, “ReplayComplete”, “ReplayAllRequest” messages?

These are MEMX-TCP Session/Framing layer messages and are used as elements in the network stack for most MEMX protocols (i.e. MEMO, MEMOIR). They are covered in the MEMX-TCP document available with the protocol specifications.