System Interface Specifications For Arrowhead

Confidential
Reference Translation
System Interface Specifications for
ESP (Exchange Standard Protocol)
Version 4.0
Released September 2015
Applied September 2015
Tokyo Stock Exchange, Inc.

System Interface Specifications for arrowhead - ESP (Exchange Standard Protocol)
Terms and Conditions of Use
Prior to using these interface specifications, users are required to read and agree to the terms and conditions described below.
Scope of Use
These interface specifications shall be disclosed only to 1. trading participants of Tokyo Stock Exchange, Inc. (hereinafter referred to as "TSE") and 2. any
person or legal entity who has entered into a disclosure agreement with TSE (hereinafter 1. and 2. are referred to as "user").
Copyright, etc.
All rights, including copyright for various information in these interface specifications (hereinafter referred to as "technical information, etc.") are vested in
TSE.
Prohibitions
Whether with or without consideration, in whatever form or media, including but not limited to a license, transfer, resale or lease, these interface
specifications or any part of it including but not limited to technical information, etc. herein must not be provided to any third parties or published.
Disclaimer
In no event shall TSE be liable for any damage or loss arising directly or indirectly from the use or inability to use of information due to errors, omission,
or missing, etc. of information in this document.
TSE accepts no responsibility or liability for damage or loss incurred by the users or customers of the users, etc. arising from connecting their systems to
the TSE trading system according to information provided in this document or arising in connection with the use of this document unless due to intentional
act or gross negligence of TSE.
In addition, TSE accepts no liability for damage or loss of profit incurred by the users or customers of the users, etc. arising from any special circumstances
irrespective of whether or not TSE has foreseen such circumstances.
The right to claim compensation for damage or loss shall be extinguished unless exercised within 12 months from the date such damage or loss occurs.
Breaches
In the event of any breach of terms or conditions described herein, users shall accept instructions of TSE without dissent.
Miscellaneous
TSE does not warrant, whether express or implied, that the content of these interface specifications is error-free.
i
This English version is not an official translation of the original Japanese document. In cases where any differences occur between the English version and the original Japanese version, the Japanese version shall prevail.
Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

Change History
No. Created/Modified Version Page Summary of Change
1 July 2007 1.0 - Issued.
3.5.1
"1. Reject Message (resend flag set to "no"), 2. Logout Response Message (resend flag set to "no"), and 3. Messages
2 January 2009 1.3 23 to be sent to the Virtual Server in response to a resend request"=>"1. Reject Message (resend flag set to "no"), 2.
Logout Response Message (resend flag set to "no"), 3. Logout Request Message (resend flag set to "no"), and 4.
Messages to be sent to the Virtual Server in response to a resend request"
3.8.3
3 January 2009 1.3 88 "The Virtual Server has to notify the Exchange Trading System of the ARMSN immediately"=>"The Virtual Server
has to update the ARMSN immediately and notify the Exchange Trading System of the updated ARMSN"
3.10.2
"If the receiver encounters the "Cases" below, it does not send any message to the sender and immediately releases
4 January 2009 1.3 102
the TCP connection and the ESP link"=>"If the receiver encounters the "Cases" below, it discards such message
without sending any Message to the sender and immediately releases the TCP connection and the ESP link"
Table4.2-A
5 January 2009 1.3 109 A value in the table 4.2-A has been changed from “Yes" to "No" as Logout Response Messages cannot be sent from
the Virtual Servers in the Upstream Direction.
Table 4.4.1-A
The following Reject Reason Codes have been added.
No.8 “0008:Incorrect ARMSN”
6 January 2009 1.3 114
No.9 “0009:Incorrect SAMSN”
No.10 “0010:Incorrect Message Length”
No.11 “0011:Incorrect Number of Data Transaction”
ii


No.12 “0012:Incorrect Skip Message Sequence Number”
No.13 0013:Incorrect Format
Table 4.4.2-A
7 January 2009 1.3 115 The following Logout Reason Code has been deleted.
No.5 “0104: Time Out (Logout Response Timer)”
Table 4.4.2-A
8 January 2009 1.3 116 The following Logout Reason Code has been added.
No.11 “0199:System Error”
The following description has been added.
(*) In order to re-establish an ESP link, clients establish a TCP connection and perform a Login process at least
9 July 2009 1.5 20 10 seconds after the release of last established ESP link. If the client attempts to establish a TCP connection
and perform a Login process immediately after the established ESP link or connection is released, it will be
handled as an incorrect Login process, and the ESP link will not be established
The following description has been added.
(*) In order for the Exchange Trading System to respond to a resend request, a predetermined number of messages
10 July 2009 1.5 60
will be retained beginning with the last sent Message. In the case where the number of messages for retention is
exceeded, Messages falling outside the range for retention will be handled as outside the range of resend operation.
Figure 3.7.2-d Resend in Exchange Trading System when Virtual Server specifies Resend Start Sequence Number
11 July 2009 1.5 63
Outside Range of Resend Operations has been added.
12 December 2009 2.0 - No changes were made to Ver. 1.5. Only the version number was changed to align with other interface
specifications.
13 August 2010 2.1 - No changes were made to Ver. 2.0. Only the version number was changed to align with other interface
specifications.
14 November 2010 2.11 - No changes were made to Ver. 2.1. Only the version number was changed to align with other interface
iii


specifications.
15 April 2011 2.2 ⅴ Item 4 "Virtual Server (Copy Notice)" has been added.
16 April 2011 2.2 ⅷ "System Interface Specifications for arrowhead - Operation (Copy Notice)" and "System Interface Specifications for
arrowhead - Data Format (Copy Notice)" have been added to "About What These Specifications Cover in a Series of
Documents".
17 April 2011 2.2 7 "Notice Sequence Number", which is a sequence number of copy notice operations, has been added to Table 3.2-A
in 3.2 (1).
18 April 2011 2.2 8 Descriptions related to a Virtual Server (Copy Notice) have been added to 3.2(2).
19 April 2011 2.2 20 Descriptions related to a Virtual Server (Copy Notice) have been added to 3.4.3(8).
20 April 2011 2.2 76 Descriptions related to a Virtual Server (Copy Notice) have been added to Table 3.8.3-A in 3.8.3.
21 April 2011 2.2 98 Descriptions related to a Virtual Server (Copy Notice) have been added to 4.1.1.
22 April 2011 2.2 100 Descriptions related to a Virtual Server (Copy Notice) have been added to 4.1.4.
23 April 2011 2.2 102 Descriptions related to copy notice operations have been added to Table 4.2-A in 4.2.
24 November 2011 2.3 - Not applicable
25 April 2012 2.4 - No changes were made to Ver. 2.2. Only the version number was changed to align with other interface
specifications.
26 May 2012 2.5 112 4.1.3 No.12 “Transmission Time”
Expression of Transmission Time has been changed from accuracy of 100 milliseconds to 1 millisecond.
specifications.
28 July 2013 2.7 - No changes were made to Ver. 2.6. Only the version number was changed to align with other interface
specifications.
29 October 2013 3.0 111 4.1.3 No.12 “Transmission Time” No.13 Reserved
“Expression of Transmission Time” has been changed from 1millisecond to 100microsecond.
iv


“Reserved” has been changed from “4 bytes” to “1 byte”.
30 October 2013 3.0 - “Link Control Parameters”
Each timer set values have been changed.
31 June 2014 3.1 4 In Section 2.1, the description, “IP addresses for each host machine (Virtual Server) in the Participant Side LAN
located directly below the router and the IP addresses used in the Exchange Trading System to which the
Trading Participant connects will also be assigned by the Exchange,” was changed to “IP addresses for each
host machine (Virtual Server) in the Participant Side LAN located directly below the router will be designated
by the Trading Participant or Exchange on the application for the Virtual Servers, whereas the IP addresses
used in the Exchange Trading System to which the Trading Participant connects will be assigned by the
Exchange”.
32 June 2014 3.1 5 In Section 2.2, the description, “The Exchange Trading System uses the IP address of the Virtual Server machine
and a port number to uniquely identify a Virtual Server,” was changed to “The Exchange Trading System uses
the IP address of the Virtual Server machine, a port number and the Virtual Server Number specified in the
Login Request Message to uniquely identify a Virtual Server.”“
33 June 2014 3.1 5 In Section 2.2, the description, “Therefore, a Trading Participant must use the port numbers as designated by the
Exchange,” was deleted.
34 June 2014 3.1 23 In Section 3.4.3 (8), the description “at least 10 seconds” was changed to “at least one (1) second.”
specifications.
36 January 2015 3.21 - No changes were made to Ver. 3.2. Only the version number was changed to align with other interface
specifications.
37 September 2015 4.0 - No changes were made to Ver. 3.21. Only the version number was changed due to renewal of arrowhead.
v

Contents
1. Overview .................................................................................................. 1 3.6.3. Exceptions ................................................................................. 48

1.1. System Overview ................................................................................ 1 3.7. Control of Message Recovery ............................................................ 50
1.2. System Components ............................................................................ 2 3.7.1. Basic Procedures ........................................................................ 50
1.3. Scope of the Specification .................................................................... 2 3.7.2. Case-by-Case Explanations ......................................................... 54
1.4. Relationship between Operation Specifications and ESP Specification .... 3 3.7.3. Exceptions ................................................................................. 78
2. TCP Connection ........................................................................................ 4 3.8. Operation Message Transmission Procedures ...................................... 81
2.1. IP Address .......................................................................................... 4 3.8.1. Operation Message Transmission Procedures - Scope of Application
2.2. Port Number ....................................................................................... 5 .............................................................................................................. 81
2.3. Establishment and Release of a TCP connection .................................... 5 3.8.2. Operation Message Transmission Procedures - Overview .............. 82
3. Link Control ............................................................................................. 6 3.8.3. Basic Procedures ........................................................................ 86
3.1. Link Control Overview ........................................................................ 6 3.8.4. Case-by-Case Explanations ......................................................... 90
3.2. Relationship between Message Sequence Numbers and a Link ............... 8 3.8.5. Exceptions ................................................................................. 92
3.3. Relationship between a TCP connection and an ESP Link .................... 10 3.9. Heartbeat Process .............................................................................. 97
3.4. Link Establishment ............................................................................ 12 3.9.1. Basic Procedures ........................................................................ 97
3.4.1. Basic Procedures ......................................................................... 12 3.9.2. Case-by-Case Explanations ......................................................... 98
3.4.2. Case-by-Case Explanations .......................................................... 13 3.9.3. Exceptions ................................................................................. 99
3.4.3. Exceptions .................................................................................. 16 3.10. Link Reject ................................................................................... 101
3.5. Link Release ..................................................................................... 24 3.10.1. Before Establishing an ESP Link .............................................. 101
3.5.1. Basic Procedures ......................................................................... 24 3.10.2. ESP Link Established State ...................................................... 101
3.5.2. Case-by-Case Explanations .......................................................... 26 3.10.3. During Releasing ESP Link ..................................................... 104
3.5.3. Exceptions .................................................................................. 29 3.11. Link Control Parameters ................................................................ 105
3.6. Send/Receive Control of Messages ..................................................... 39 4. Message ............................................................................................... 108
3.6.1. Basic Procedures ......................................................................... 39 4.1. Message Format .............................................................................. 108
3.6.2. Case-by-Case Explanations .......................................................... 41 4.1.1. Message Basic Format .............................................................. 108
vi

4.1.2. Data Format.............................................................................. 108 4.3.6. Logout Response Message ......................................................... 115
4.1.3. Message Header Data Format .................................................... 109 4.3.7. Heartbeat Message .................................................................... 116
4.1.4. Data Format - Data Area ............................................................ 110 4.3.8. Resend Request Message ........................................................... 116
4.2. List of Link Control Messages .......................................................... 111 4.3.9. Skip Message ........................................................................... 117
4.3. Link Control Message Data Format .................................................. 113 4.3.10. Reject Message ....................................................................... 117
4.3.1. Login Request Message ............................................................. 113 4.4. List of Reason Codes ....................................................................... 118
4.3.2. Login Response Message ........................................................... 113 4.4.1. Reject Reason Code .................................................................. 118
4.3.3. Pre-Logout Request Message ..................................................... 114 4.4.2. Logout Reason Code ................................................................. 119
4.3.4. Pre-Logout Response Message ................................................... 114
4.3.5. Logout Request Message ........................................................... 115
vii

Introduction
A number of terms used throughout these specifications are defined below.

Refer to "3. Link Control" about how to use each Message. For the format, refer to each corresponding section in "4. Message."
No. Term Description Where to read for details?

This term collectively represents Virtual Servers, i.e. Virtual Server
1 Virtual Server "1 Overview"
(Order/Notice), Virtual Server (Query) and Virtual Server (Drop Copy).
This term represents a Virtual Server that can be used to connect to the
Exchange Trading System to enable, for example, entries of orders or receipt
2 Virtual Server (Order/Notice) "1 Overview"
of notices. A basic unit to send/receive Messages to/from the Exchange
Trading System.
This term represents a Virtual Server that can be used to connect to the
Exchange Trading System to enable, for example, queries and views of own
3 Virtual Server (Query) "1 Overview"
order statuses or Order Book Status statuses. A basic unit to send/receive
Messages to/from the Exchange Trading System.
This term represents a Virtual Server that connects the Exchange Trading
System and receives a copy of a notice created by a Virtual Server
4 Virtual Server (Drop Copy) "1 Overview"
(Order/Notice). A basic unit to send/receive Messages to/from the Exchange
Trading System.
This term collectively represents procedures to establish an ESP link including
5 Login Process "3.4 Link Establishment"
an Exchange of Login Messages.
This term collectively represents Login Messages, i.e. Login Request Message
6 Login Message "3.4 Link Establishment"
and Login Response Message.
viii


This term collectively represents procedures to release an ESP link including
7 Logout Process "3.5 Link Release"
an Exchange of Logout Messages.
This term collectively represents Logout Messages, i.e. Pre-Logout Request
8 Logout Message Message, Pre-Logout Response Message, Logout Request Message and "3.5 Link Release"
Logout Response Message.
This term represents an orderly flow of Messages controlled via a
bidirectional and consecutive Message Sequence Number mechanism that is
9 ESP Link ⅴ "3.1 Link Control Overview"
implemented between Virtual Servers and the Exchange Trading System.
ESP stands for Exchange Standard Protocol.
Those sequence numbers that must be set for any and all incoming and "3.2 Relationship between Message Sequence
10 Message Sequence Number (MSN)
outgoing Messages (unique sequential numbers in increments of '1'). Numbers and a Link"
"3.6 Send/Receive Control of Messages"
11 Expected Sequence Number A Message Sequence Number that a Message receiver expects to receive next.
3.6.1 Basic Procedures (2) Receiver
This term means a resending of Messages from a sender upon request of a
receiver. Note that "Resend" in these specifications is one thing, and
12 Resend "3.7 Control of Message Recovery"
"Administrative Instruction (retransmission)" in the "System Interface
Specifications for arrowhead - Operation (Order/Notice)" is another.
13 Resend Process This term collectively represents procedures to recover Messages. "3.7 Control of Message Recovery"
When a receiver detects any missing Message, it requests a resend to the "3.7 Control of Message Recovery"
14 Resend Request
sender to recover the message gap. 3.7.1 Basic Procedures
When a Message receiver sends a resend request to a Message sender, this
Resend Start Message Sequence number must be set in the Resend Request Message, i.e. a Message Sequence "3.7 Control of Message Recovery"
15
Number Number that the receiver expects to receive after the last successfully received 3.7.1 Basic Procedures
Message.
ix


"3.7 Control of Message Recovery"
3.7.2 Case-by-Case Explanations
This term means those Messages that are received after the Message that
16 Subsequent Message (1) Subsequent Message Processing by
caused the message gap up until the receiver receives resend Messages.
Receiver after Sending Resend
Request
When we use the term "resend Message" it represents all the Messages resent
with the resend flag set to "yes" starting from the one that has the resend start "3.7 Control of Message Recovery"
17 Resend Message
Message Sequence Number specified in the Resend Request Message and 3.7.1 Basic Procedures
those subsequent resent Messages.
When we use this term, it represents Messages that have already been sent
18 Already Sent Message before a sender stops sending new Messages upon receipt of a Resend Request
3.7.1 Basic Procedures
Message from a receiver.
Resend Flag can only be set for those Messages that are resent by a sender in "3.7 Control of Message Recovery"
19 Resend Flag
response to a Resend Request Message from a receiver. 3.7.1 Basic Procedures
To be resent or not to be resent depends on the type of the Message to be "3.7 Control of Message Recovery"
20 Resend Target resent and the range of resend operation. For Messages not to be resent, 3.7.2 Case-by-Case Explanations
whether a replacement is required, possible or not possible is defined. (2) Non-resend Message Exist in Resend
This term is used to determine the range (within or without) of a resend
operation based on the Already Received Message Sequence Number
21 Range of Resend Operation 3.7.2 Case-by-Case Explanations
(ARMSN) that a receiver notifies a sender. The purpose is to limit the range
(2) Non-resend Message Exist in Resend
a sender has to retain Messages to prepare for a resend request from a receiver.
x


This information is issued from the Exchange Trading System to Virtual
Sending Allowed Message Sequence Servers. This shows the range of Message Sequence Numbers that a Virtual "3.8.2 Operation Message Transmission
22
Number (SAMSN) Server can use for a series of outgoing Messages. Thus a Virtual Server is Procedures - Overview"
not able to send Messages by setting sequence numbers out of this range.
This information is Exchanged between the Exchange Trading System and
Already Received Message Sequence each Virtual Server. This represents the number that each side recognizes as "3.8.2 Operation Message Transmission
23
Number (ARMSN) "already received" and will be used to determine the range of a resend Procedures - Overview"
operation.
xi

About What These Specifications Cover in a Series of Documents
These specifications are a part of a series of system documents as shown below.
System Interface Specifications for arrowhead
ESP (Exchange Standard Protocol) Specifications
Operation (Order/Notice) Specifications Data Format (Order/Notice)
Operation (Query) Specifications Data Format (Query)
Operation (Drop Copy) Specifications Data Format (Drop Copy)

業務（コピー通知）編
This document is shown in gray.
xii

1. Overview
This chapter describes overview of the system and scope of the specifications.
1.1. System Overview
The Exchange Trading System and a Trading Participant system are connected via the network to enable efficient trading operations.
The Exchange Trading System consists of two processing components; 1. operation processor to address trading and query operations and 2. front processor to address
connectivity with Virtual Servers and Message relaying as an FEP to the operation processor.
A Trading Participant connects to the Exchange Trading System with a router or other equipment and implements functionalities as defined in these specifications into a
Virtual Server to achieve various trading operations such as placing orders, querying order statuses and receiving execution, etc. See the following connection diagram.
<Trading Participant> <Exchange>

<Network>
Virtual Server Exchange Trading System
Front Operation
Processor Processor
Order Entries, Queries, etc.
Acceptance Notices, Execution Completion Notice, Own Order Statuses, etc.
Figure 1.1 - a System Connection Diagram
1

1.2. System Components
The system consists of the following main components.

(1) Exchange Trading System
Operation processors address trading and query operations. There are multiple operation processors. Front processors, implemented between operation processors
and Virtual Servers, receive Messages such as orders, etc. from Virtual Servers and perform required validation processes, then distribute those Messages to operation
processors. Similarly, front processors receive Messages such as notices, etc. from operation processors and perform required validation processes, then distribute
them to each Virtual Server.
(2) Virtual Server
A Virtual Server is a basic unit to send/receive Messages to/from the Exchange Trading System. There are three types of Virtual Servers; Virtual Server
(Order/Notice), Virtual Server (Query) and Virtual Server (Drop Copy). *
・ Virtual Server (Order/Notice) connects to the Exchange Trading System to enter orders, etc. and receive notices, etc.
・ Virtual Server (Query) connects to the Exchange Trading System to enter queries for obtaining own order statuses, etc. and receive query responses.
・ Virtual Server (Drop Copy) connects to the Exchange Trading System to receive a copy of a notice created by a Virtual Server (Order/Notice).
A Trading Participant can handle both equities trading and CBs trading with a single Virtual Server (Order/Notice). However, it is not possible for a Trading
Participant to handle trading operations (Order/Notice), query operations (Query) and Drop Copy reception operations (Drop Copy) on a single Virtual Server.
* Note that we do not expressly mention the types of Virtual Server Order/Notice, Query, or Drop Copy, in these specifications. Thus, if we simply mention
"Virtual Server" it means that the topic is common for the three types of Virtual Servers.
1.3. Scope of the Specifications
This document only covers interfacing specifications between Virtual Servers and the Exchange Trading System as a part of intersystem connections. Any other
Messages that do not appear in these specifications are not acceptable within the intersystem connection.
2

1.4. Relationship between Operation Specifications and ESP Specifications
The Exchange Standard Protocol (hereinafter referred to as "ESP") described in these specifications, implemented in the middle of the operation layer (for
sending/receiving operation Messages) and the TCP layer, is a transmission control protocol to ensure an orderly and accurate messaging.

Operation Protocol
arrowhead - Operations
Administration&Operation Link/Query Link
ESP System Interface Specifications for

arrowhead - ESP
ESP Link
TCP
TCP connection
3

2. TCP Connection
This chapter describes the TCP connection between Virtual Servers and the Exchange Trading System.
2.1. IP Address
The WAN side IP address for Participant Side router and the IP address for Participant Side LAN located directly below the router will be assigned by the Exchange. IP
addresses for each host machine (Virtual Server) in the Participant Side LAN located directly below the router will be designated by the Trading Participant or Exchange on
the application for the Virtual Servers, whereas the IP addresses used in the Exchange Trading System to which the Trading Participant connects will be assigned by the
Exchange. These are local IP addresses uniquely assigned by the Exchange. Therefore, when a Trading Participant installs Virtual Servers within its local IP network, it is
recommended to take special care to prevent a duplication of IP addresses.
4

2.2. Port Number
A single TCP connection is used between a Virtual Server and the Exchange Trading System. A Trading Participant can install and run multiple Virtual Servers in a
single server machine but each Virtual Server must have a unique TCP port number. Also, a Trading Participant can install a Virtual Server (Order/Notice), a Virtual Server
(Query), and a Virtual Server (Drop Copy) in a single server machine. The Exchange Trading System uses the IP address of the Virtual Server machine, a port number and
the Virtual Server Number specified in the Login Request Message to uniquely identify a Virtual Server. In other words, a Trading Participant cannot connect to the
Exchange Trading System using an IP address and a port number not the ones designated by the Exchange. The following diagram shows how IP addresses and port
numbers are assigned.
<Trading Participant> <Exchange>
Server Machine Exchange Trading

System
Virtual Server TCP connection
(Order/Notice)
Router Router
(Participant (Exchange Side)
SideTrading
Participant)
Virtual Server TCP connection
(Query)
: IP address
Figure 2.2 - a IP Addresses and Port Numbers : Port Number
2.3. Establishment and Release of a TCP connection
A TCP connection establishment request will always be made from a Virtual Server to the Exchange Trading System. A TCP connection release request will typically be
made from a Virtual Server. However, it sometimes will be made from the Exchange Trading System when the Operation ends. Additionally, release of the connection
may be requested by the Exchange Trading System if a system failure or exception occurs. Note that the TCP connection will in principle be released via FIN connection
termination procedures. Refer to "3. Link Control" for details on when to establish/release a TCP connection.
5

3. Link Control
This chapter describes the link control mechanism implemented between Virtual Servers and the Exchange Trading System.
3.1. Link Control Overview
An ESP link is defined as an orderly flow of Messages controlled via a bidirectional and consecutive Message Sequence Number mechanism that is implemented between
Virtual Servers and the Exchange Trading System. The following diagram shows the overview of an ESP link.
6

<Virtual Server> <Exchange Trading System>
ESP Link Established Login Process Mes. Seq. No. "init val = 1"
Keep Alive Heartbeat Process
Message Gap Occur Mes. Recovery Process
Send/Receive Message Send/Receive Message
ESP Link Released Logout Process Mes. Seq. No. "reset"
ESP Link Re-established Login Process Mes. Seq. No. "init val = 1"
* dotted line only represents event timing.
Figure 3.1 - a Overview of ESP Link
7

3.2. Relationship between Message Sequence Numbers and a Link
(1) Message Sequence Number

Message Sequence Numbers must be set for any and all incoming and outgoing Messages (unique sequential numbers in increments of '1'). Message Sequence
Numbers are separately maintained for Upstream Messages and Downstream Messages. Upstream Message Sequence Numbers are assigned by a Virtual Server
and set to the Messages to be sent from a Virtual Server to the Exchange Trading System. Downstream Message Sequence Numbers are assigned by the Exchange
Trading System and set to the Messages to be sent from the Exchange Trading System to a Virtual Server.
Note that "Message Sequence Numbers" for the link controls is one thing, and "sequence numbers and other numbers" for the operations is another. Refer to the
following table for the details. (The following numbers are used for the operations.)
Table 3.2 - A List of Sequence Numbers and Other Numbers

Category Sequence Numbers and Other Numbers Description
Order Entry Sequence Number
Acceptance-related Notice Sequence Number
Execution-related Notice Sequence Number Refer to "System Interface Specifications for arrowhead -
Trading Operation
Order Acceptance Number Operation (Order/Notice)."
Execution Notice Number
Notice Creation Number per Issue
Refer to "System Interface Specifications for arrowhead -
Query Operation (none)
Operation (Query)."
Refer to "System Interface Specifications for arrowhead -
Drop Copy Operation Notice Sequence Number
Operation (Drop Copy)"
Sequence numbers used to control a link. Assigned to any
Link Controls Message Sequence Number
and all incoming and outgoing Messages.
8

(2) ESP Link

An ESP link consists of two independent routes; an Upstream flow controlled via an Upstream Message Sequence Number mechanism and a Downstream flow
controlled via a Downstream Message Sequence Number mechanism. A single ESP link is implemented between a Virtual Server and the Exchange Trading
System. In other words, a single Virtual Server cannot use multiple ESP links. If, however, multiple Virtual Servers are set up in a single server machine, it is
possible to establish an ESP link for each of those Virtual Servers.
ESP Link
"N": Upstream Mes. Seq. No.
Upstream "M": Downstream Mes. Seq. No.

Assign Mes. Seq. No. 2+N 1+N N
Downstream
M M+1 M+2 Assign Mes. Seq. No.
Figure 3.2 - a ESP Link
An ESP link must always be established by exchanging Login Messages; an Upstream Message and a Downstream Message, each has a Message Sequence
Number of '1', and released by exchanging Logout Messages. It is not allowed to send a Login Message if an ESP link has already been established. Also, if the
value of the Message Sequence Number does not equal to '1', such Login Message will be denied. An ESP link is also established by exchanging Login Messages
in association with an establishment of a TCP connection and released by releasing the TCP connection in association with an exchanging of Logout Messages.
When an ESP link has already been established, such state is described as follows.
- By checking the inbound and outbound sequence numbers, an orderly messaging has been maintained over the ESP link.
- The sent Messages has been retained to prepare for a resend request. Note that sent Messages will be retained as per description in "3.7 Control of
Message Recovery."
Thus, if an ESP link has already been established, an orderly, consecutive and bidirectional messaging between a Virtual Server and the Exchange Trading System
9

is guaranteed. A Logout process that involves an Exchange of Logout Messages enables a Virtual Server and the Exchange Trading System to first confirm that no
message gap exists and then release the ESP link.
If an ESP link between a Virtual Server and the Exchange Trading System was released without normally performing a Logout process due to an exception, it is
possible to assure continuity of operations by performing failure recovery procedures specified in the "System Interface Specifications for arrowhead - Operation
(Order/Notice)" and "System Interface Specifications for arrowhead - Operation (Drop Copy)". A normal Logout process is defined as a process to first confirm
that no message gap exists and then release the ESP link.
For the relationship between a TCP connection and an ESP link, refer to "3.3 Relationship between a TCP connection and an ESP Link."
The following diagram shows how the Message Sequence Numbers are controlled with regard to the establishment and release of an ESP link.
ESP Link (messaging) ESP Link (messaging)
Establishment Release Establishment Release
Mes. Seq. Nums and Sent Messages are Maintained Mes. Seq. Nums and Sent Messages are Maintained
(Mes. Seq. No. continue) (Mes. Seq. No. reset) (Mes. Seq. No. continue)
Mes. Seq. No. = '1' Mes. Seq. No. = '1'
A day's Operation
Figure 3.2 - b Establishment and Release of an ESP Link and Message Sequence Numbers
3.3. Relationship between a TCP connection and an ESP Link
When an ESP link has been established, the TCP connection and the ESP link are in a one-to-one relationship. Therefore, it is not possible to establish multiple ESP links
within a single TCP connection. It is also not possible for a single ESP link to be established over multiple TCP connections. The following diagram shows the
relationship between a TCP connection and an ESP link.
10


TCP connection Established
ESP Link Established Login Process
<TCP connection> <TCP connection>
ESP Link Released Logout Process

TCP connection Released
<TCP connection>

<TCP connection>

Figure 3.3 - a Relationship between a TCP connection and an ESP Link
11

3.4. Link Establishment
By successfully completing a Login process, a Virtual Server and the Exchange Trading System can establish an ESP link. Note that the Message Sequence Number
must be '1' for each of the Login Messages.
3.4.1. Basic Procedures
A Login process can be started only from a Virtual Server according to the following steps.
・ A Virtual Server establishes a TCP connection with the Exchange Trading System (once a TCP connection has been established, the Virtual Server must
immediately send a Login Request Message).
・ The Virtual Server sends a Login Request Message (Message seq. no. = '1') to the Exchange Trading System.
・ The Exchange Trading System receives the Login Request Message.
・ The Exchange Trading System validates the received Login Request Message.
・ If the Exchange Trading System regards the Login Request Message as valid, it sends a Login Response Message (Message seq. no. = '1') to the Virtual Server.
・ The Virtual Server receives the Login Response Message.
・ If the Virtual Server regards the Login Response Message as valid, the Login process ends and an ESP link is established.
Once the Login process has been successfully completed and an ESP link has been established, the Virtual Server and the Exchange Trading System are able to send
and receive Messages.
12

Login Request Message

Validation "OK"
Login Response Message
ESP Link Established
Figure 3.4.1 - a Login Process (Basic Procedures)
During a Login process, the following sending operations are prohibited. A Virtual Server cannot;
・ Send any Messages before sending a Login Request Message in a Login process.
・ Send a Login Request Message which has a value other than '1' in the Message Sequence Number field or the resend flag is set to "yes."
・ Send any Messages after sending a Login Request Message up until it receives a Login Response Message from the Exchange Trading System and an ESP
link is established.
・ Send a Login Request Message if an ESP link has already been established.
During a Login process, the following sending operation is prohibited. The Exchange Trading System cannot;
・ Send any Messages before sending a Login Response Message in a Login process.
・ Send a Login Response Message which has a value other than '1' in the Message Sequence Number field or the resend flag is set to "yes."
3.4.2. Case-by-Case Explanations
A Virtual Server and the Exchange Trading System perform a Login process according to the procedures described in the tables below by checking the type, Message
Sequence Number and resend flag of the Messages received during the link establishment process.
Note that the words "during the link establishment process" represents the periods, for Virtual Servers; from the establishment of a TCP connection to the receipt of a
successful Login Response Message, and for the Exchange Trading System; from the establishment of a TCP connection to the sending of a Login Response Message to
13

the Virtual Server.

Table 3.4.2 - A How a Virtual Server Processes Incoming Messages
Incoming Message
Procedure
Message Type Message Sequence Number Resend Flag
This is a normal Login Response Message. Proceed with the Login process. If a
No Login Request Message is not sent out yet, however, perform the procedure for
Message Sequence Number = '1'
Login Response "Other Messages" below.
Message Yes This is not a normal Login Response Message. Perform the steps described in
"3.4.3. Exceptions, (6) Defect in Login Response "to end the Login process
Message Sequence Number ≠ '1' Regardless of this.
abnormally.
Other Messages (other This is not a normal Login procedure. Perform the steps described in "3.4.3.
than Login Response Regardless of this. Regardless of this. Exceptions, (5) Receipt of Other Message (other than Login Response Message)" to
Message) end the Login process abnormally.
Table 3.4.2 - B How the Exchange Trading System Processes Incoming Messages
Incoming Message
Procedure
No This is a normal Login Request Message. Proceed with the Login process.
Message Sequence Number = '1'
Yes This is not a normal Login Request Message. Perform the steps described in
"3.4.3. Exceptions, (3) Defect in Login Request "to end the Login process
Message Sequence Number ≠ '1' Regardless of this.
abnormally.
Other Messages (other This is not a normal Login procedure. Perform the steps described in "3.4.3.
than Login Request Regardless of this. Regardless of this. Exceptions, (1) Receipt of Other Message (other than Login Request Message)" to
Message) end the Login process abnormally.
(1) Establishment of an ESP Link

When establishing an ESP link, a Virtual Server can start a Login process by sending a Login Request Message setting '1' to the Message seq. no. field.
14

(2) Re-establishment of an ESP Link

In the following case, a Virtual Server can re-establish an ESP link by sending a Login Request Message setting '1' to the Message Sequence Number field to
start a Login process.
・ If the last established ESP link has been released via a Logout process that involves an Exchange of Pre-Logout Messages and confirming that no
message gap has been detected.
If the last established ESP link during the same business day has been released without confirming that no message gap exists via a Logout process, refer to
"3.4.3. Exceptions, (8) The Case that Last Established ESP Link has been Released without Confirming that no Message Gap Exists via a Logout Process."
15

3.4.3. Exceptions
(1) Receipt of Other Message (other than Login Request Message)

The Exchange Trading System, if the first Message received from a Virtual Server after establishing a TCP connection is not a Login Request Message,
performs the following steps to end the Login process abnormally.
・ The Exchange Trading System receives a Message from a Virtual Server and that is not a normal Login Request Message (regardless of the
Message Sequence Number and the resend flag).
・ The Exchange Trading System discards the received Message (the expected sequence number remains unchanged).
・ The Exchange Trading System does not send any Message to the Virtual Server and releases the TCP connection that has been in established state
with the Virtual Server.
Other than Login Request Message
Figure 3.4.3 - a Receipt of Other Message (other than Login Request Message)
16

(2) Delay in Receiving Login Request Message

The Exchange Trading System, if it does not receive a Login Request Message from a Virtual Server in a given period of time (hereinafter referred to as
"Login Request Timer") after establishing a TCP connection, performs the following steps to end the Login process abnormally. For details on the Login
Request Timer, refer to "3.11. Link Control Parameters."
・ The Exchange Trading System does not receive any Login Request Message from a Virtual Server, until a given period of time specified for the
Login Request Timer elapses after establishing a TCP connection.
Timeout
Figure 3.4.3 - b Delay in Receiving Login Request Message
17

(3) Defect in Login Request Message

The Exchange Trading System validates the Login Request Message received from a Virtual Server. If any defect is found in the Message, it performs
the following steps to end the Login process abnormally. The defects include, for example; the Message Sequence Number is not '1', or the resend flag is
set to "yes", etc.
・ The Exchange Trading System receives an Incorrect Login Request Message from a Virtual Server.

Validation "NG"
Figure 3.4.3 - c Defect in Login Request Message
18

(4) Delay in Receiving Login Response Message

A Virtual Server, if it does not receive a Login Response Message from the Exchange Trading System in a given period of time (hereinafter referred to as
"Login Response Timer") after sending a Login Request Message to the Exchange Trading System, performs the following steps to end the Login process
abnormally. For details on the Login Response Timer, refer to "3.11. Link Control Parameters."
・ A Virtual Server does not receive any Login Response Message from the Exchange Trading System, until a given period of time specified for the
Login Response Timer elapses after sending a Login Request Message to the Exchange Trading System.
・ The Virtual Server does not send any Message to the Exchange Trading System and releases the TCP connection that has been in established state
with the Exchange Trading System.
Timeout
Figure 3.4.3 - d Delay in Receiving Login Response Message
19

(5) Receipt of Other Message (other than Login Response Message)

A Virtual Server, if the first Message received from the Exchange Trading System after sending a Login Request Message to the Exchange Trading
System is not a Login Response Message, performs the following steps to end the Login process abnormally. A Virtual Server also performs the following
steps to end the Login process abnormally if it receives any Message before sending a Login Request Message to the Exchange Trading System.
・ A Virtual Server receives a Message from the Exchange Trading System and that is not a normal Login Response Message (regardless of the
Message Sequence Number and the resend flag).
・ The Virtual Server discards the received Message (the expected sequence number remains unchanged).
Other than Login Response Message
Figure 3.4.3 - e Receipt of Other Message (other than Login Response Message)
20

(6) Defect in Login Response Message

A Virtual Server validates the Login Response Message received from the Exchange Trading System. If any defect is found in the Message, the Virtual
Server performs the following steps to end the Login process abnormally. The defects include, for example; the Message Sequence Number is not '1', or
the resend flag is set to "yes", etc.
・ A Virtual Server receives an Incorrect Login Response Message from the Exchange Trading System.

Validation "OK"
Figure 3.4.3 - f Defect in Login Response Message
21

(7) Receipt of Login Request/Response Message in an ESP Link Established State

The following steps are for cases that the Exchange Trading System or a Virtual Server receives a Login Request/Response Message in the state that an
ESP link has been established.
・ The Exchange Trading System receives a Login Request/Response Message from a Virtual Server.
・ The Exchange Trading System sends a Reject Message for the Login Request/Response Message to the Virtual Server.
・ The Exchange Trading System proceeds to the next Message.
If it is the case where a Virtual Server receives a Login Request/Response Message in the state that an ESP link has been established, replace "Exchange
Trading System" with "Virtual Server" in the explanation above, and vice versa.
ESP Link Established State
Reject Message
ESP Link Established State
Figure 3.4.3 - g Receipt of Login Request Message in an ESP Link Established
(8) The Case that Last Established ESP Link has been Released withoutState
Confirming that no Message Gap Exists via a Logout Process
If the last established ESP link during the same business day has been released without confirming that no message gap exists via a Logout process, there
is a possibility that a Message gap has occurred. Thus the Virtual Server (Order/Notice), after establishing(*) a new ESP link by performing another Login
process, must confirm that no Message gap exists for order or notice by using an appropriate administrative instruction and get the missing Messages if
necessary.
Refer to "System Interface Specifications for arrowhead - Operation (Order/Notice)" for details on administrative instruction functionalities.
The Virtual Server (Drop Copy), after establishing a new ESP link by performing another Login process, must start operations by sending an Operation
Start Request Message for which Already Received Notice Sequence Number is set. Refer to “System Interface Specifications for arrowhead – Operation
22

(Drop Copy)” for details.

Note, however, that if an ESP link for a Virtual Server (Query) is released, queries and the results will not be taken over to the next ESP link. Refer to
"System Interface Specifications for arrowhead - Operation (Query)" for details.
(*) In order to re-establish an ESP link, clients establish a TCP connection and perform a Login process at least one (1) second after the release of last
established ESP link. If the client attempts to establish a TCP connection and perform a Login process immediately after the established ESP link or
connection is released, it will be handled as an incorrect Login process, and the ESP link will not be established.
23

3.5. Link Release
By successfully completing a Logout process, a Virtual Server and the Exchange Trading System can release an ESP link.
A Logout process must be started from a Virtual Server. The following steps must first be completed to make sure no message gap exists and then the ESP link is
released.
・ The Virtual Server sends a Pre-Logout Request Message to the Exchange Trading System.
・ The Exchange Trading System receives the Pre-Logout Request Message from the Virtual Server.
・ The Exchange Trading System validates the Message Sequence Number of the received Pre-Logout Request Message to check if no message gap
exists.
・ The Exchange Trading System, if no message gap has been detected, sends a Pre-Logout Response Message to the Virtual Server.
・ The Virtual Server receives the Pre-Logout Response Message from the Exchange Trading System.
・ The Virtual Server validates the Message Sequence Number of the received Pre-Logout Response Message to check if no message gap exists.
・ The Virtual Server, if no message gap has been detected, sends a Logout Request Message to the Exchange Trading System.
・ The Exchange Trading System receives the Logout Request Message from the Virtual Server.
・ The Exchange Trading System sends a Logout Response Message to the Virtual Server.
・ The Virtual Server receives the Logout Response Message from the Exchange Trading System.
・ The Virtual Server releases the TCP connection that has been in established state with the Exchange Trading System and then releases the ESP link
(upon receipt of a Logout Response Message from the Exchange Trading System, a Virtual Server must immediately release the TCP connection).
Once the Logout process is successfully completed and the ESP link is released, the Virtual Server and the Exchange Trading System will no longer be able to send
and receive Messages.
24

Pre-Logout Request Message

no Message gap exists
Pre-Logout Response Message
no Message gap exists
Logout Request Message
Logout Response Message
ESP Link Released
Figure 3.5.1 - a Logout Process
During the Logout process, the following sending operation is prohibited. A Virtual Server can not;
・ Send any other Messages after sending a Pre-Logout Request Message except, 1. Reject Message (resend flag set to "no"), 2. Logout Request Message
(resend flag set to "no"), 3. Resend Request Message (resend flag set to "no"), 4. Heartbeat Message, and 5. Messages to be sent to the Exchange Trading
System in response to a resend request.
・ Send any Messages after sending a Logout Request Message.
During the Logout process, the following sending operation is prohibited. The Exchange Trading System cannot;
・ Send any other Messages after sending a Pre-Logout Response Message except, 1. Reject Message (resend flag set to "no"), 2. Logout Response Message
(resend flag set to "no"), 3. Logout Request Message (resend flag set to "no"), and 4. Messages to be sent to the Virtual Server in response to a resend
request.
・ Send any Messages after sending a Logout Response Message.
25

A Virtual Server and the Exchange Trading System perform a Logout process according to the procedures described in the tables below by checking the type,
Message Sequence Number and resend flag of the Messages received during the link release process. Note that the words "during the link release process" represents
the periods, for Virtual Servers; from the receipt of a Pre-Logout Response Message to the release of the TCP connection, and for the Exchange Trading System; from
the receipt of a Pre-Logout Request Message to the release of the TCP connection.
However, if the Logout process is based on a link reject, the periods are, for each of the Virtual Server and the Exchange Trading System; from the sending of a
Logout Request Message to the release of the TCP connection, and for the counterpart; from the receipt of a Logout Request Message to the release of the TCP
connection. For details on link reject, refer to "3.10. Link Reject."
Table 3.5.2 - A How a Virtual Server Processes Incoming Messages

Incoming Message
Procedure
Logout Response Message Regardless of this. Regardless of this. This is a normal Logout Response Message. Proceed with the Logout process.
This is not a normal procedure. Perform the steps described in "3.5.3.
Other Messages (other than
Regardless of this. Regardless of this. Exceptions, (6) Virtual Server Receives incorrect Message after Receiving
Logout Response Message)
Pre-Logout Response ."
26

Table 3.5.2 - B How the Exchange Trading System Processes Incoming Messages
(from the receipt of a Pre-Logout Request Message to the receipt of a Logout Request Message)
Incoming Message
Procedure
Expected Sequence Number No This is not a normal Message. Perform the steps described in "3.5.3. Exceptions,
> Received Message (3) Exchange Trading System Receives Incorrect Message 1 after Receiving
Yes
Sequence Number Pre-Logout Request ."
Perform a resend process according to the steps described in "3.7. Control of
Message Recovery" and proceed with the Logout process. Note that if this Message
causes a message gap, the receiver must not request a resend. Also, if the received
Resend Request Message No
Expected Sequence Number Resend Request Message includes any defect, such Message is not normal. Thus,
≦ Received Message perform the steps described in "3.5.3. Exceptions, (3) Exchange Trading System
Sequence Number Receives Incorrect Message 1 after Receiving Pre-Logout Request ."
This is not a normal Message. Perform the steps described in "3.5.3. Exceptions,
Yes (3) Exchange Trading System Receives Incorrect Message 1 after Receiving
Pre-Logout Request ."
Expected Sequence Number No This is not a normal Message. Perform the steps described in "3.5.3. Exceptions,
> Received Message (3) Exchange Trading System Receives Incorrect Message 1 after Receiving
Yes
Sequence Number Pre-Logout Request ."
Logout Request Message No This is a normal Logout Request Message. Proceed with the Logout process.
Expected Sequence Number
≦ Received Message
Yes (3) Exchange Trading System Receives Incorrect Message 1 after Receiving
Sequence Number
27

Incoming Message
Procedure
Other Messages Regardless of this. Regardless of this. (4) Exchange Trading System Receives Incorrect Message 2 after Receiving
Table 3.5.2 - C How the Exchange Trading System Processes Incoming Messages (after receiving a Logout Request Message)
Incoming Message
Procedure
This is not a normal Message. Perform the steps described in "3.5.3.
All Messages Regardless of this. Regardless of this. Exceptions, (9) Exchange Trading System Receives Incorrect Message after
Receiving Logout Request ."
(1) Logout Process Triggered by a Virtual Server

No special instructions.
(2) Logout Process Based on a Link Reject
If the ESP link is released due to a case described in "3.10. Link Reject, 3.10.2. ESP Link Established State, (3) Critical Error," perform the procedures
described therein, not the ones for Logout process.
28

3.5.3. Exceptions
(1) Virtual Server Receives Resend Request Message from Exchange Trading System after Sending Pre-Logout Request Message
If the Virtual Server, during the period after sending a Pre-Logout Request Message to the Exchange Trading System up until it receives a Pre-Logout
Response Message from the Exchange Trading System, receives a Resend Request Message from the Exchange Trading System, it performs the steps
described in "3.7. Control of Message Recovery, 3.7.1. Basic Procedures."
(2) Exchange Trading System Detects Message Gap while Validating Pre-Logout Request Message
The Exchange Trading System receives a Pre-Logout Request Message from a Virtual Server. It validates the Message Sequence Number and detects a
message gap. In this case, for the steps to follow, refer to "3.7. Control of Message Recovery, 3.7.2. Case-by-Case Explanations, (7) Exchange Trading
System Detects Message Gap while Validating Pre-Logout Request ."
(3) Exchange Trading System Receives Incorrect Message 1 after Receiving Pre-Logout Request Message
If the Exchange Trading System, during the period after receiving a Pre-Logout Request Message from the Virtual Server up until it receives a Logout
Request Message from the Virtual Server, receives a Resend Request Message (resend flag set to "no") that has a duplicate in Message Sequence Number, or
an incorrect Resend Request Message (resend flag set to "no"), or a Resend Request Message (resend flag set to "yes"), or a Logout Request Message
(resend flag set to "yes"), then it proceeds with the Logout process according to the following steps.
・ The Exchange Trading System receives an Incorrect Message from the Virtual Server.
・ The Exchange Trading System sends a Reject Message to the Virtual Server.
・ The Exchange Trading System handles the next Message received from the Virtual Server.
Note that if the Resend Start Message Sequence Number is greater than the Already Sent Message Sequence Number, such Message is called an
"Incorrect Resend Request Message."
(4) Exchange Trading System Receives Incorrect Message 2 after Receiving Pre-Logout Request Message
If the Exchange Trading System, during the period after receiving a Pre-Logout Request Message from the Virtual Server up until it receives a Logout
Request Message from the Virtual Server, receives a valid Resend Request Message (resend flag set to "no"), or a Logout Request Message (resend flag set
to "no"), or other Messages except those which are described in "(3) Exchange Trading System Receives Incorrect Message 1 after Receiving Pre-Logout
Request " above, then it proceeds with the Logout process according to the following steps.
29

・ The Exchange Trading System does not send any Message to the Virtual Server and proceeds to the next Message.
(5) Virtual Server Detects Message Gap while Validating Pre-Logout Response Message
The Virtual Server receives a Pre-Logout Response Message from the Exchange Trading System. It validates the Message Sequence Number and
detects a message gap. In this case, for the steps to follow, refer to "3.7. Control of Message Recovery, 3.7.2. Case-by-Case Explanations, (8) Virtual
Server Detects Message Gap while Validating Pre-Logout Response ."
(6) Virtual Server Receives incorrect Message after Receiving Pre-Logout Response Message
If the Virtual Server, after receiving a Pre-Logout Response Message from the Exchange Trading System, receives a Message that is not a Logout
Response Message (regardless of the Message Sequence Number and the resend flag), then it proceeds with the Logout process according to the following
steps.
・ The Virtual Server receives an Incorrect Message from the Exchange Trading System.
・ The Virtual Server does not send any Message to the Exchange Trading System and proceeds with the Logout process.
30

(7) Delay in Receiving Pre-Logout Response Message

The Virtual Server, if it does not receive a Pre-Logout Response Message from the Exchange Trading System in a given period of time (hereinafter
referred to as "Pre-Logout Response Timer") after sending a Pre-Logout Request Message to the Exchange Trading System, performs the following steps to
complete the Logout process. For details on the Pre-Logout Response Timer, refer to "3.11. Link Control Parameters."
・ The Virtual Server sends a Pre-Logout Request Message to the Exchange Trading System.
・ The Virtual Server, even though a given period of time specified for the Pre-Logout Response Timer elapses after sending the Pre-Logout Request
Message, does not receive a Pre-Logout Response Message from the Exchange Trading System. In this case, it sends a Logout Request Message
to the Exchange Trading System.
・ The Virtual Server immediately releases the TCP connection without waiting for the response Message.
Timeout
ESP Link Released
Figure 3.5.3 - a Delay in Receiving Pre-Logout Response Message
31

(8) Exchange Trading System Detects Message Gap while Validating Logout Request Message
The Exchange Trading System validates the Message Sequence Number of the received Logout Request Message and detects a message gap. In this
case, it will not perform any recovery process and proceed with the Logout process.
・ The Exchange Trading System receives a Logout Request Message from the Virtual Server.
・ The Exchange Trading System validates the Message Sequence Number of the received Logout Request Message and a gap is detected.
・ The Exchange Trading System will not perform any recovery process and sends a Logout Response Message to the Virtual Server to proceed with
the Logout process.
Expected Seq. No. Admin

Pre-Logout Request Msg (Seq. No. = N) N
N+1
Message (Seq. No. = N + 1)
Pre-Logout Response Msg (Seq. No. = M)
Logout Request Msg (Seq. No. = N + 2)

Message Gap Detected Incorrect Sequence
Logout Response Msg (Seq. No. = M + 1)
ESP Link Released
Figure 3.5.3 - b Message Gap Detected while Validating Logout Request Message
32

(9) Exchange Trading System Receives Incorrect Message after Receiving Logout Request Message
If the Exchange Trading System, after receiving a Logout Request Message from the Virtual Server, receives a Message (regardless of the Message
Sequence Number and the resend flag), then it proceeds with the Logout process according to the following steps.
・ The Exchange Trading System does not send any Message to the Virtual Server and proceed with the next process.
(10) Delay in Receiving Logout Request Message
The Exchange Trading System, if it does not receive a Logout Request Message from the Virtual Server in a given period of time (hereinafter referred to
as "Logout Request Timer") after sending a Pre-Logout Response Message to the Virtual Server, performs the following steps to complete the Logout
process. For details on the Logout Request Timer, refer to "3.11. Link Control Parameters."
・ The Exchange Trading System receives a Pre-Logout Request Message from the Virtual Server.
・ The Exchange Trading System sends a Pre-Logout Response Message to the Virtual Server.
・ The Exchange Trading System, even though a given period of time specified for the Logout Request Timer elapses after sending a Pre-Logout
Response Message, does not receive a Logout Request Message from the Virtual Server. In this case, it sends a Logout Request Message to the
Virtual Server.
・ The Exchange Trading System immediately releases the TCP connection without waiting for the response Message.
33

Logout Request Msg

Timeout
ESP Link Released
Figure 3.5.3 - c Delay in Receiving Logout Request Message
(11) Virtual Server Detects message gap while Validating Logout Response Message
The Virtual Server validates the Message Sequence Number of the received Logout Response Message and detects a Message gap. In this case, it will
not perform any recovery process and proceed with the Logout process.
・ The Virtual Server receives a Logout Response Message from the Exchange Trading System.
・ The Virtual Server validates the Message Sequence Number of the received Logout Response Message and a gap is detected.
・ The Virtual Server will not perform any recovery process and release the TCP connection to complete the Logout process.
34


Pre-Logout Request Msg (Seq. No. = N)
M Pre-Logout Response Msg (Seq. No. = M)

M+1
Ｍ＋１
Message (Seq. No. = M + 1)
Logout Request Msg (Seq. No. = N + 1)
Logout Response Msg (Seq. No. = M + 2)

Incorrect Sequence Message Gap Detected
ESP Link Released
Figure 3.5.3 - d Message Gap Detected while Validating Logout Response Message
35

(12) Delay in Receiving Logout Response Message

The Virtual Server, if it does not receive a Logout Response Message from the Exchange Trading System in a given period of time (hereinafter referred to
as "Logout Response Timer") after sending a Logout Request Message to the Exchange Trading System, performs the following steps to complete the
Logout process. For details on the Logout Response Timer, refer to "3.11. Link Control Parameters."
・ The Virtual Server sends a Logout Request Message to the Exchange Trading System.
・ The Virtual Server, if it does not receive a Logout Response Message from the Exchange Trading System in a given period of time (Logout
Response Timer) after sending a Logout Request Message to the Exchange Trading System, immediately releases the TCP connection without
waiting for the response Message.
Logout Response Msg

Timeout
ESP Link Released

Figure 3.5.3 - e Delay in Receiving Logout Response Message
36

(13) Delay in Releasing TCP connection

The Exchange Trading System, if the Virtual Server does not release the TCP connection in a given period of time (hereinafter referred to as "Connection
Release Timer") after sending a Logout Response Message to the Virtual Server, performs the following steps to complete the Logout process. For details
on the Connection Release Timer, refer to "3.11. Link Control Parameters."
・ The Exchange Trading System sends a Logout Response Message to the Virtual Server.
・ The Exchange Trading System, if the Virtual Server does not release the TCP connection in a given period of time (Connection Release Timer)
after sending a Logout Response Message to the Virtual Server, immediately releases the TCP connection without waiting for the release from the
Virtual Server.
ESP Link Released

Timeout
Figure 3.5.3 - f Delay in Releasing TCP connection
37

(14) Instructions from Upper Layer

The Exchange Trading System sometimes releases the ESP link by instruction of the upper layer. About the triggers of the ESP link release instructions
from the upper layer, refer to "System Interface Specifications for arrowhead - Operation (Order/Notice)" , "System Interface Specifications for arrowhead -
Operation (Query) " and "System Interface Specifications for arrowhead - Operation (Drop Copy)"
・ The Exchange Trading System sends a Logout Request Message to the Virtual Server.
・ The Exchange Trading System releases the TCP connection without waiting for the Logout Response Message from the Virtual Server.

ESP Link Established

Instructions from Upper Layer
ESP Link Released
Figure 3.5.3 - g Instructions from Upper Layer
38

3.6. Send/Receive Control of Messages
Every Message sent/received between a Virtual Server and the Exchange Trading System including Message for Login/Logout processes has a Message Sequence Number
(unique sequential numbers in increments of '1'). These numbers enable orderly Message transmissions without any duplications or gaps.
(1) Sender
On both Virtual Server side and the Exchange Trading System side, Message Sequence Numbers must be separately maintained and set for every
outgoing Message. Note that the value of the Message Sequence Number must be '1' for the link establishment process.
・ The Message sender sets an appropriate value to the Message Sequence Number field of the Message and sends it to the receiver.
・ The sender must maintain the Message Sequence Number to assure the continuity of the numbers to be assigned to the subsequent Messages.
・ The sender also has to retain the sent Messages along with the Message Sequence Numbers to prepare for a resend request from a receiver.
Regarding the range of Messages and Message Sequence Numbers a sender has to retain, refer to "3.7. Control of Message Recovery."
(2) Receiver
On both Virtual Server side and the Exchange Trading System side, expected sequence numbers (i.e. the Message Sequence Number that the receiver
expects to receive next) must be separately maintained to validate the Message Sequence Number in every incoming Message. Note that the value of the
expected sequence number must be '1' for the link establishment process.
・ Every time the receiver receives a Message from the sender, it must check if the Message Sequence Number in the Message is the same number as
the expected sequence number to validate the continuity, i.e. no duplication or gap in the Messages.
・ The receiver, once it confirms that no duplication or gap has been found in the Message, must update the expected sequence number to prepare for
the next Message Sequence Number validation process.
For cases where the receiver detects any duplication or gap in the Message Sequence Numbers, refer to "3.6.3. Exceptions."
39


This figure shows an Upstream Message case where a Virtual Server is the sender and the Exchange Trading
System is the receiver. Thus, for a Downstream Message case, replace "Exchange Trading System" with
"Virtual Server" and vice versa.
Msg. Seq. No. Admin Expected Seq. No. Admin
N-1 N
Message (Seq. No. = N)
Update Update
N N+1
Update Update
N+1 N+2
Update Update
N+2 N+3
Update Update
Figure 3.6.1 - a Send/Receive Messages (Basic Procedures)
40

A Virtual Server and the Exchange Trading System process all incoming Messages according to the procedures described in the tables below by checking the type,
Message Sequence Number and resend flag.
Table 3.6.2 - A How the Incoming Messages are Processed (Virtual Servers and the Exchange Trading System)
Incoming Message
State Procedure
Message Type Msg. Seq. No. Resend Flag
During Link Establishment Process Follow the steps described in "3.4. Link Establishment."
Login Request Message Regardless of this. Regardless of this.
This is not a Normal Message. Perform the steps described in
Login Response Message Regardless of this. Regardless of this.
"3.6.3. Exceptions, (1) Receipt of Incorrect Message."
Expected Sequence Number > No
Link Received Message Sequence Discard the received Message (the expected sequence number
Yes
Established Number remains unchanged) and proceed to the next Message.
State (*), This is not a normal Message. Perform the steps described in
Expected Sequence Number = No
other than "3.6.3. Exceptions, (1) Receipt of Incorrect Message."
Received Message Sequence
subsequent Process this Message normally and then handle the next
Skip Message Number Yes
Messages Message.
(*2) This is not a normal Message. Perform the steps described in
No
（ Expected Sequence Number < "3.6.3. Exceptions, (1) Receipt of Incorrect Message."
Received Message Sequence This is the case where a message gap is detected in validating the
Number Yes received Message. Perform the steps described in "3.7. Control
of Message Recovery."
(continued on the next page)
41

(from the previous page)

Incoming Message
State Procedure
This is not a normal Message. Perform the steps described in
Yes "3.6.3. Exceptions, (1) Receipt of ."
Number
Process this Message normally and then handle the next
Expected Sequence Number = No
Message.
Heartbeat Message This is not a normal Message. Perform the steps described in
Number Yes
Resend Request Message "3.6.3. Exceptions, (1) Receipt of ."
Link This is the case where a message gap is detected in validating
Established Expected Sequence Number < No the received Message. Perform the steps described in "3.7.
State (*), Received Message Sequence Control of Message Recovery."
other than Number This is not a normal Message. Perform the steps described in
Yes
subsequent "3.6.3. Exceptions, (1) Receipt of ."
Messages This is not a normal Message. Perform the steps described in
(*2) "3.6.3. Exceptions, (1) Receipt of ."
Discard the received Message (the expected sequence number
Number Yes
remains unchanged) and proceed to the next Message.
Operation Messages Expected Sequence Number =
Process this Message normally and then handle the next
Reject Message Received Message Sequence Regardless of this.
Message.
Number
Expected Sequence Number < This is the case where a message gap is detected in validating
Received Message Sequence Regardless of this. the received Message. Perform the steps described in "3.7.
Number Control of Message Recovery."
42

Incoming Message
State Procedure
Number
Expected Sequence Number ≦ This is a normal Logout Request Message. Perform the steps
No
Received Message Sequence described in "3.5. Link Release."
Number Yes
Logout Response
Regardless of this. Regardless of this. "3.6.3. Exceptions, (1) Receipt of ."
Message
Perform the steps described in "3.7. Control of Message
Link Established State, Subsequent Messages
Recovery."
During Link Release Process Perform the steps described in "3.5. Link Release."
* Note that "Link Established State" includes up until:

・ A Virtual Server receives a Pre-Logout Response Message (expected sequence number = Message Sequence Number, resend flag set to "no") from
the Exchange Trading System. However, if a message gap is detected while validating the received Pre-Logout Response Message, then up until a
Pre-Logout Response Message (expected sequence number = Message Sequence Number, resend flag set to "yes") is received.
・ The Exchange Trading System receives a Pre-Logout Request Message (expected sequence number = Message Sequence Number, resend flag set
to "no") from a Virtual Server. However, if a message gap is detected while validating the received Pre-Logout Request Message, then up until a
Pre-Logout Request Message (expected sequence number = Message Sequence Number, resend flag set to "yes") is received.
*2 "Subsequent Messages" means those Messages that are received after sending a Resend Request Message up until the receiver receives resend Messages.
For details, refer to "3.7. Control of Message Recovery."
43

Table 3.6.2 - B How a Virtual Server Processes Incoming Messages

Incoming Message
State Procedure
Regardless of
Pre-Logout Request Message Regardless of this.
this.
Pre-Logout Response
Message (before sending Regardless of
Regardless of this. "3.6.3. Exceptions, (1) Receipt of ."
Link Pre-Logout Request this.
Established Message)
State, other Expected Sequence Number > No
than Received Message Sequence Discard the received Message (the expected sequence number
Yes
subsequent Number remains unchanged) and proceed to the next Message.
Pre-Logout Response
Messages Expected Sequence Number =
Message (after sending Regardless of This is a normal Pre-Logout Response Message. Perform the
Pre-Logout Request this. steps described in "3.5. Link Release."
Number
Message)
Regardless of
Received Message Sequence the received Message. Perform the steps described in "3.7.
this.
Number Control of Message Recovery" to recover the gap.
Table 3.6.2 - C How the Exchange Trading System Processes Incoming Messages
Incoming Message
State Procedure
Link Expected Sequence Number > This is not a normal Message. Perform the steps described in
Pre-Logout Request Message No
Established Received Message Sequence "3.6.3. Exceptions, (1) Receipt of ."
44

Incoming Message
State Procedure
State, other Number Discard the received Message (the expected sequence number
Yes
than remains unchanged) and proceed to the next Message.
subsequent Expected Sequence Number =
Regardless of This is a normal Pre-Logout Request Message. Perform the
Messages Received Message Sequence
this. steps described in "3.5. Link Release."
Number
Regardless of
Received Message Sequence the received Message. Perform the steps described in "3.7.
this.
Number Control of Message Recovery" to recover the gap.
Regardless of This is not a normal Message. Perform the steps described in
Pre-Logout Response Message Regardless of this.
this. "3.6.3. Exceptions, (1) Receipt of ."
45


During Link Establishment
During Link Establishment Login Request Message Process
Process
Link Established State
other than subsequent
Messages
Message (*)
Link Established State, Resend Request Message Link Established State,

other than subsequent Messages subsequent Messages
Resend Message (*2)
Link Established State
other than subsequent
Pre-Logout Request Message Messages
Logout Request Message During Link Release
During Link Release Process
Process Logout Response Message
(*) Any Message that triggers a Resend Request Message.

(*2) Message Sequence Number = Resend Start Message Sequence Number and resend flag set to "yes."
Figure 3.6.2 - a Concept of "State"
46

(1) Sender
On both Virtual Server side and the Exchange Trading System side, Message Sequence Numbers (unique sequential numbers in increments of '1') must be
separately set for every outgoing Message. However, this will not be applied for the following case.
・ When the sender, in response to a resend request from the receiver, resend "Already Sent Message(s)" to the receiver.
If a receiver detects a message gap in its Message Sequence Number validation process, a resend request will be made to the sender. In response to this
resend request, the sender will resend "Already Sent Message(s)" to the receiver setting the resend flag to "yes." This resend operation by a sender
corresponds to the above case.
(2) Receiver
On both Virtual Server side and the Exchange Trading System side, Message Sequence Numbers must separately be validated. If a duplicate is found, it
is regarded as an exception. However, this will not be applied for the following case.
・ When the receiver receives Message(s) from the sender with the resend flag set to "yes."
47

3.6.3. Exceptions
(1) Receipt of Incorrect Message

When receiving an Incorrect Message (including duplicate cases in Message Sequence Numbers), a Virtual Server or the Exchange Trading System
performs the following steps.
・ The receiver receives an Incorrect Message from the sender
・ The receiver discards the received Message (the expected sequence number remains unchanged).
・ The receiver sends a Reject Message to the sender.
・ The receiver proceeds to the next Message received from the sender.

Incorrect Message
This figure assumes that the Virtual
Server is the sender and the Exchange
Reject Message Receive an Incorrect
Trading System is the receiver.
Message
ESP Link Continues
Figure 3.6.3 - a Receipt of Incorrect Message
48

This figure assumes that the Virtual Expected Seq. No. Admin
Trading System is the receiver. N+2
Update

N+3
Reject Message Detects a Duplicate of

Msg. Seq. No.
ESP Link Continues
Figure 3.6.3 - b Receipt of Incorrect Message (Duplicate of Message Sequence Number)
(2) Message Gap

As a result of performing a Message Sequence Number validation process, either a Virtual Server or the Exchange Trading System may detect a message
gap. For the steps to perform, refer to "3.7. Control of Message Recovery."
49

3.7. Control of Message Recovery
On both Virtual Server side and the Exchange Trading System side, Message Sequence Numbers (unique sequential numbers in increments of '1') must be set for every
outgoing Message. These numbers must always be validated by the receiving side to enable orderly Message transmissions without any duplications or gaps. If the
receiving side detects a gap in the validation process, it will be recovered by performing the steps below.
On both Virtual Server side and the Exchange Trading System side, Message Sequence Numbers in all incoming Messages are validated. If the receiving side
detects any missing Message, it must immediately request a resend to the sender to recover the message gap. Upon receipt of a resend request, the sender of the
missing Message must resend the requested Message(s) before sending new Messages.
Note: We are going to use the term "resend" to avoid confusion between "resend operation in the link control" and "Administrative Instruction (retransmission) in the
System Interface Specifications for arrowhead - Operation (Order/Notice)."
・ The Exchange Trading System performs a Message Sequence Number validation process and a gap is detected in the Messages received from a
Virtual Server.
・ The Exchange Trading System discards the received Message that caused the message gap (the expected sequence number remains unchanged).
The discarded Message is to be received from the Virtual Server via a resend operation.
・ The Exchange Trading System sends a Resend Request Message to the Virtual Server. In this resend request, the Exchange Trading System sets
the Message Sequence Number of the Message that it expects to receive after the last successfully received Message (hereinafter referred to as
"resend start Message Sequence Number").
・ The Virtual Server receives the Resend Request Message from the Exchange Trading System.
・ The Virtual Server stops sending new Messages.
・ The Virtual Server resends Messages to the Exchange Trading System starting from the one that has the resend start Message Sequence Number
specified in the Resend Request Message to the last one that the Virtual Server recognizes as "already sent." Note that the Message Sequence
Numbers of those resend Messages must be the original sequence numbers and the resend flags must also be set to "yes" (i.e. no renumbering
allowed).
・ The Virtual Server resumes its sending operation (new Messages) after completing the resend operation.
50

・ The Exchange Trading System receives the resend Messages from the Virtual Server to recover the message gap.
When we use the term "resend Message" it represents all the resent Messages with the resend flags set to "yes" starting from the one that has the resend start Message
Sequence Number specified in a Resend Request Message and those subsequent resent Messages. However, if any gap raises in the resend Messages, all subsequent
resent Messages will not be regarded as "resend Messages" because the continuity in the Message Sequence Numbers has been broken.
The resend flag can only be set for those Messages that are resent in response to a Resend Request Message, i.e. it is not possible to set the flag for other types of
Messages.
It depends on the status managed by a Virtual Server to stop and resume sending new Messages, in other words, it does not depend on the receive status on the
Exchange Trading System side. Messages that have "already been sent" status represents those Messages sent before a Virtual Server stops sending new Messages
upon receipt of a Resend Request Message from the Exchange Trading System. If it is the case where a Virtual Server detects a message gap, replace "Virtual Server"
with "Exchange Trading System" in the explanation above, and vice versa.
51


Message (1)
Already Sent
Messages Message (2) Resend Request Message
Message (Seq. No. = N + 3) (resend start Message Sequence Number = N + 1)
Message (3)
stops sending
new Messages Message (4)
Message (5) (resend flag "yes")
This figure represents the case where
Resend "Already Sent (resend flag "yes")
the Exchange Trading System detects a
Messages" Message (Seq. No. = N + 3)
Message gap. If it is the case where a
(resend flag "yes")
Virtual Server detects a Message gap,
replace "Virtual Server" with
New Messages "Exchange Trading System" in this
figure, and vice versa.
Figure 3.7.1-a Switching Between New Messages and Already Sent Messages
52


This figure represents the case where the Exchange
Trading System detects a Message gap. If it is the
case where the Virtual Server detects a Message Message (Seq. No. = N) N
gap, replace "Exchange Trading System" with N+1
"Virtual Server" in this figure, and vice versa. Message (Seq. No. = N + 1)

Already Sent Message

Message Gap Detected Discard Message
(Expected Seq. No. Remains
Resend Request Msg. (Seq. No. = M) Unchanged)

Stop Sending New Msg. Resend Request Receive Resend Request Send
(Resend Start Msg. Seq. No. = N + 1)
Resend Start
(resend flag "yes") N+2
Resend Messages - from "N + 1" Message (Seq. No. = N + 2)
Message to the last the sender thinks as
"already sent." (resend flag "yes") N+3
Resend End
Resume Sending New Msg

Message (Seq. No. = N + 4) Message Gap Recovered
N+5
Figure 3.7.1 - b Control of Message Recovery (Basic Procedures)
53

The receiver, as for the "Subsequent Message" i.e. Messages received after the Message that caused the message gap up until the Message which has the resend start
Message Sequence Number specified in the Resend Request Message (resend flag set to "yes"), performs the steps described in the tables below according to the type of
Message and how the Message Sequence Number and the resend flag are set.
The following figure shows what "Subsequent Messages" are.
54

[Normal Case] [Message Gap Case 1] [Message Gap Case 2] [Message Gap Case 3]
No Message gap involved. A Message gap is detected, A Message gap is detected, and then A Message gap is detected and resend
and then recovered by sending another gap is detected in the resend Messages are sent to recover the gap, and
a resend request. Messages to recover the first gap. then another gap is detected in the first
2nd resend request is sent resend Message. In this case, the second
immediately after the 2nd gap is resend request is triggered by a timer
Msg. Seq. No. detected. (re-resend request), not by the second gap.
1 1 1 1
5 5 5 5
6 6 6 6
Msg Gap Msg Gap Msg Gap
10 10 10 10
11 11 後続電文 11 後続電文 11 後続電文
Subseq. Msg Subseq. Msg Subseq. Msg
15 15 15 15
16 6 後続電文 6 後続電文 6 後続電文
Resend Msg
20 10 Resend Msg 10 10
21 11 11 11
Subseq. Msg
後続電文
25 15 15
Subseq. Msg 15
16 16 16
20 20
後続電文 20
21 11 6
25 15 10
New Msg 16
Resend Msg 11
Resend Msg
20 15
Msg Gap 21 16
25 20
Subseq. Msg 21
後続電文 : a resend request is sent 25
Resend Msg
後続電文
Figure 3.7.2 - a Subsequent Messages
55

Table 3.7.2 - A How the Incoming Messages are Processed (Virtual Servers and the Exchange Trading System)
Incoming Message
State Procedure
Login Request Message Regardless of this. Regardless of this.
Login Response Message Regardless of this. Regardless of this.
"3.7.3. Exceptions, (2) Receipt of ."
Received Message Sequence Discard the received Message (the expected sequence number
Yes
Number remains unchanged) and proceed to the next Message.
No
Expected Sequence Number =
This is a normal Skip Message. Process the Message and
Link Skip Message proceed to the next Message. Note that the next Message is
Number Yes
Established processed according to, not this table but the procedures
State, described in "3.6. Send/Receive Control of Messages."
subsequent This is not a normal Message. Perform the steps described in
Expected Sequence Number < No
Messages "3.7.3. Exceptions, (2) Receipt of ."
Number Yes
Heartbeat Message Number
Resend Request Message Expected Sequence Number Process this Message normally and then handle the next
≦ Received Message No Message. Note that the expected sequence number must not be
Sequence Number updated.
56

Incoming Message
State Procedure
Yes
57

Incoming Message
State Procedure
Expected Sequence Number > This is not a normal Message. Perform the steps described in
No
Received Message Sequence "3.7.3. Exceptions, (2) Receipt of ."
Number Yes Discard the received Message (the expected sequence number
No remains unchanged) and proceed to the next Message.
Expected Sequence Number = This is a normal Message. Process the Message and proceed
Operation Messages
Received Message Sequence to the next Message. Note that the next Message is processed
Reject Message Yes
Number according to, not this table but the procedures described in "3.6.
Link Send/Receive Control of Messages."
Established Expected Sequence Number < No
State, Received Message Sequence
Yes remains unchanged) and proceed to the next Message.
subsequent Number
Messages Expected Sequence Number > No
Number
Expected Sequence Number Discard the received Message (the expected sequence number
No
≦ Received Message remains unchanged) and proceed to the next Message.
Sequence Number Yes
Logout Response
Regardless of this. Regardless of this. "3.7.3. Exceptions, (2) Receipt of ."
Message
58

Table 3.7.2 - B How a Virtual Server Processes Incoming Messages

Incoming Message
State Procedure
Link Pre-Logout Request Message Regardless of this. Regardless of this.
Established
Pre-Logout Response Message This is not a normal Message. Perform the steps described
State,
(before sending Pre-Logout Regardless of this. Regardless of this. in "3.7.3. Exceptions, (2) Receipt of ."
subsequent
Request Message)
Messages
Expected Sequence Number > This is not a normal Message. Perform the steps described
No
Received Message Sequence in "3.7.3. Exceptions, (2) Receipt of ."
Number Yes Discard the received Message (the expected sequence
Link
number remains unchanged) and proceed to the next
Established Pre-Logout Response Message Expected Sequence Number = No
Message.
State, (after sending Pre-Logout Received Message Sequence
This is a normal Pre-Logout Response Message. Perform
subsequent Request Message) Number Yes
the steps described in "3.5. Link Release."
Messages
Expected Sequence Number < Discard the received Message (the expected sequence
Received Message Sequence Regardless of this. number remains unchanged) and proceed to the next
Number Message.
59

Table 3.7.2 - C How the Exchange Trading System Processes Incoming Messages
Incoming Message
State Procedure
Expected Sequence Number > This is not a normal Message. Perform the steps described in
No
Received Message Sequence "3.7.3. Exceptions, (2) Receipt of ."
Number Yes Discard the received Message (the expected sequence number
Link Expected Sequence Number = No remains unchanged) and proceed to the next Message.
Established Pre-Logout Request Message Received Message Sequence This is a normal Pre-Logout Request Message. Perform the
Yes
State, Number steps described in "3.5. Link Release."
subsequent Expected Sequence Number <
Messages Received Message Sequence Regardless of this.
Number
Pre-Logout Response Message Regardless of this. Regardless of this.
60

(1) Subsequent Message Processing by Receiver after Sending Resend Request Message
The receiver, as for the subsequent Messages received up until it receives resend Messages, performs the steps according to the tables above.
61


case where the Virtual Server detects a Message Message (Seq. No. = N) N
gap, replace "Exchange Trading System" with N+1
"Virtual Server" in this figure, and vice versa. Message (Seq. No. = N + 1)
Message (Seq. No. = N + 2) Discard Message

Message Gap Detected (Expected Seq. No.
The trigger sequences for the Remains Unchanged)
"Resend Request Message (Seq. Message (Seq. No. = N + 3)
No. = N + 4)" is omitted. Resend Request Send
Discard Message
Resend Request Message (Seq. No. = N + 4) (Expected Seq. No.
(Resend Start Msg. Seq. No. = M - 1) Remains Unchanged)
Resend Request Message (Seq. No. = M) Resend Request Receive Process Message
(Expected Seq. No.
(Resend Start Msg. Seq. No. = N + 1) Remains Unchanged)
Stop Sending New Msg. Resend Request Receive

Message (Seq. No. = M - 1)
Resend Start
(resend flag "yes")
Skip Message (Seq. No. = M)

Resend End
(resend flag "yes")

Resend Start
Skip Message (Seq. No. = N + 4)

Resend End

Resume Sending New Msg Message Gap Recovered
N+6
Figure 3.7.2 - b Subsequent Message Processing

62 by Receiver after Sending Resend Request Message

(2) Non-resend Message Exist in Resend Messages

When the sender sends resend Messages to the receiver based on the receiver's resend request, if any non-resend Message is included in the Messages
from the one that has the resend start Message Sequence Number to the last one that the sender recognizes as "already sent," the sender sends a Skip
Message (resend flag set to "yes") instead to the receiver as follows.
・ The Virtual Server sends a Skip Message (resend flag set to "yes") in place of the non-resend Message to the Exchange Trading System.
・ The Virtual Server sets the Message Sequence Number of the non-resend Message to the Message Sequence Number field of the Skip Message
(resend flag set to "yes").
・ In the case where a series of non-resend Messages exists, the Virtual Server sets the Message Sequence Number of the first non-resend Message to
the Message Sequence Number field of the Skip Message (resend flag set to "yes"). While, to the Skip Message Sequence Number field of the
Skip Message (resend flag set to "yes"), the Virtual Server sets the Message Sequence Number of the last non-resend Message.
・ Upon receipt of a Skip Message (resend flag set to "yes") from the Virtual Server, the Exchange Trading System recognizes such non-resend
Message(s) and updates the expected sequence number.
To be resent or not to be resent depends on the type of the Message and the range of resend operation.
The receiver notifies the sender of the Already Received Message Sequence Number (ARMSN) and the range of resend operation must always fall after
this number(*). For details on the ARMSN, refer to "3.8. Operation Message Transmission Procedures."
As described in "3.6. Send/Receive Control of Messages" ("the sender also has to retain the sent Messages along with the Message Sequence Numbers to
prepare for a resend request from a receiver"), the range of resend operation is used for the purposes of limiting the range of Messages a sender has to retain.
When a Skip Message is used as a response to a Resend Request, the resend flag must always be set to "yes" to explicitly indicate that it is a resend
Message. Also, duplicate of Message Sequence Number must be avoided. Note that it is not possible to use a Skip Message (resend flag set to "no") in a
situation that does not involve a resend operation.
It is also not possible to set the resend flag to "yes" for Login, Heartbeat, Resend and Logout Messages.
If it is the case where a Virtual Server detects a message gap, replace "Virtual Server" with "Exchange Trading System" in the explanation above, and vice
versa.
(*) In order for the Exchange Trading System to respond to a resend request, a predetermined number of messages will be retained beginning with the last
sent Message. In the case where the number of messages for retention is exceeded, Messages falling outside the range for retention will be handled as outside
the range of resend operation.
63

Table 3.7.2 - D Resend and Non-resend Messages

Category Message Type Range of Resend Operation (*1) Resend Target Can be replaced with
a Skip Message?
all Messages within resend operation Yes No
Operation
all Messages out of resend operation No (*2) Yes
Reject Message, Pre-Logout Messages within resend operation Yes No
Reject Message, Pre-Logout Messages out of resend operation No (*2) Yes
Link Control Login Message, Heartbeat Message,
within resend operation
Resend Message, Skip Message, Logout No Mandatory
out of resend operation
Message
(*1) "Out of resend operation" does not mean that those Messages must always be treated as "Non-resend" Messages. It means
that those Messages may be treated "out of resend operation."
(*2) If a receiver receives those Messages indicated as "Resend Target = No," such Messages will be treated in the same way as
normal Messages.
64


case where the Virtual Server detects a Message gap, Message (Seq. No. = N) N
replace "Exchange Trading System" with "Virtual N+1
Server" in this figure, and vice versa. Message (Seq. No. = N + 1)
Non-resend Messages

Resend Request Message (Seq. No. = M)


Resend Start
Resend Messages - from "N + 1"
Message to the last the sender
thinks as "already sent." (resend flag set to "yes" and Skip Msg. Seq. No. = N + 3) N+4

Resend End

N+7
Figure 3.7.2 - c Non-resend Message Exist in Resend Messages
65

＜Virtual Server＞＜Exchange Trading System＞
Retained Msg
for Resend
M+1
*In case where number of retained messages for
M+2
resend operation is “3”
M+3
Message (Seq. No. = M + 4) Store Sent Msg No. of Msg for

Retention Exceeded
Discard oldest Sent Message from Delete Retained Msg M+1

Retained Messages for Resend (Seq. M+2
No. = M + 1), and retain Sent Message M+3
(Seq. No. = M + 4.) Store Sent Msg M+4
Resend Request Send Resend Request Message (Seq. No,.= N) Resend Request Receive
(Resend Start Msg. Seq. No. = M + 1)
Resend Start
Skip Message (Seq. No. = M + 1) Replace with Skip Msg M+1
(resend flag “yes”, skip Msg Seq. No. = 00000000)
M+2
Message (Seq. No. = M + 2) Resend Send Seq. No. (M+1) is out of
M+3
(resend flag "yes") range of Resend operations. The
M+4
Message (Seq. No. = M + 3) Message is not resent but instead
(resend flag "yes") replaced with Skip Message and resent.
Message (Seq. No. = M + 4) Resend End

(resend flag "yes")
66
Figure 3.7.2-d Resend in Exchange Trading System when Virtual Server specifies Resend Start Sequence Number Outside Range of Resend Operations

(3) Receipt of Another Resend Request while Sender is Sending Resend Messages
If the sender receives another resend request from the receiver while sending resend Messages, the sender performs the following steps. These steps are
applied for the cases described below.
・ The Virtual Server sends resend Messages in response to the Resend Request Message (i) from the Exchange Trading System.
・ The Virtual Server receives another Resend Request Message (ii) from the Exchange Trading System while resending Messages.
・ The Virtual Server stops resending for the first request, i.e. Resend Request Message (i).
・ The Virtual Server starts resending for the second request, i.e. Resend Request Message (ii).
Cases:
・ When the second request from the receiver and the Message resending from the sender cross.
・ When the receiver detects a message gap in the resend Messages and makes another resend request.
Note that if it is the case where the Exchange Trading System receives another resend request from the Virtual Server while sending resend Messages,
replace "Virtual Server" with "Exchange Trading System" in the explanation above, and vice versa.
67

(4) Receiver Repeats Resend Requests

If the receiver does not receive any resend Message from the sender in a given period of time (hereinafter referred to as "Re-resend Request Timer") after
sending a Resend Request Message to the sender, there is a possibility that the Resend Request Message or the resend Message has been lost. In this case,
the receiver repeats resend requests for a certain number of times (hereinafter referred to as "Number of Times of Re-resend Request") according to the
following steps. For details on the Re-resend Request Timer and Number of Times of Re-resend Request, refer to "3.11. Link Control Parameters."
・ The Exchange Trading System sends a Resend Request Message to the Virtual Server.
・ The Exchange Trading System, if it does not receive any resend Message from the Virtual Server in a given period of time (Re-resend Request
Timer) after sending a Resend Request Message to the Virtual Server, sends a Resend Request Message again (and again). Note that the Message
Sequence Numbers of the repeated Resend Request Messages must be updated.
・ And, if the Exchange Trading System does not receive any resend Message from the Virtual Server in a given period of time (Re-resend Request
Timer), it repeats resend requests for a certain number of times specified by the "Number of Times of Re-resend Request."
versa.
68


case where the Virtual Server detects a Message
gap, replace "Exchange Trading System" with
"Virtual Server" in this figure, and vice versa.
Message Gap Detected
Resend Request Msg. (Seq. No. = M)

Resend Request Send
Timeout
Resend Request Msg. (Seq. No. = M + 1)
Resend Request Send
<< skip the rest...>>
Figure 3.7.2 - d Receiver Repeats Resend Requests
69

(5) Message Gap Detected while Validating Heartbeat Message

The receiver validates the Message Sequence Number in a Heartbeat Message received from the sender. If a gap is detected, it must perform the
following steps to recover the message gap.
・ The Exchange Trading System receives a Heartbeat Message from a Virtual Server.
・ The Exchange Trading System validates the Message Sequence Number in the Heartbeat Message and a gap is detected.
・ The Exchange Trading System discards the received Heartbeat Message (the expected sequence number remains unchanged).
・ The Exchange Trading System sends a Resend Request Message to the Virtual Server to recover the Message gap.
If it is the case where a Virtual Server detects a Message gap, replace "Virtual Server" with "Exchange Trading System" in the explanation above, and
vice versa.
70


case where the Virtual Server detects a Message gap, Message (Seq. No. = N) N
replace "Exchange Trading System" with "Virtual N+1
Server" in this figure, and vice versa. Message (Seq. No. = N + 1)
Heartbeat Message (Seq. No. = N + 3)

Resend Request Msg. (Seq. No. = M)

Resend Start


Resend End
(resend flag "yes", Skip Message) N+4

N+5
Figure 3.7.2 - e Message Gap Detected while Validating Heartbeat Message
71

(6) Message Gap Detected while Validating Resend Request Message

The sender validates the Message Sequence Number in a Resend Request Message received from the receiver. If a gap is detected, it must perform the
following steps to recover the message gap.
・ The Virtual Server receives a Resend Request Message from the Exchange Trading System.
・ The Virtual Server validates the Message Sequence Number in the Resend Request Message received from the Exchange Trading System and a gap
is detected.
・ The Virtual Server sends all resend Messages in response to the resend request from the Exchange Trading System.
・ The Virtual Server discards the received Resend Request Message (the expected sequence number remains unchanged).
・ The Virtual Server sends a Resend Request Message to the Exchange Trading System to recover the message gap.
Note that the Virtual Server must first send all resend Messages in response to the resend request from the Exchange Trading System, and then send a
Resend Request Message to the Exchange Trading System to recover the message gap.
versa.
72


This figure represents the case where the Virtual Server detects a Message gap in validating a Resend
Expected Seq. No. Admin Request Message. If it is the case where the Exchange Trading System detects a Message gap in validating Expected Seq. No. Admin
a Resend Request Message, replace "Exchange Trading System" with "Virtual Server" in this figure, and vice
versa. N
N+1
M Message (Seq. No. = M)
M+1

Resend Request Message (Seq. No. = M + 2)

Message Gap Detected Resend Request Receive Resend Request Send
Resend Start
Resend End
Resend Request Message (Seq. No. = N + 3)

Resend Request Send Message Gap Recovered Resend Request Receive
N+4
Resend Start
M+2 (resend flag "yes")
Skip Message (Seq. No. = M + 2) Resend End
Message Gap Recovered Message (Seq. No. = M + 3)
Figure 3.7.2 - f Message Gap Detected while Validating Resend Request Message
73

(7) Exchange Trading System Detects Message Gap while Validating Pre-Logout Request Message
The Exchange Trading System validates the Message Sequence Number in a Pre-Logout Request Message received from the Virtual Server. If a gap is
detected, it must perform the following steps to recover the message gap.
・ The Exchange Trading System receives a Pre-Logout Request Message from the Virtual Server.
・ The Exchange Trading System validates the Message Sequence Number of the received Pre-Logout Request Message and a gap is detected.
・ The Exchange Trading System discards the received Pre-Logout Request Message (the expected sequence number remains unchanged).
・ The Exchange Trading System sends a Resend Request Message to the Virtual Server to recover the message gap.
・ The Exchange Trading System receives a Pre-Logout Request Message from the Virtual Server as a resend Message (resend flag set to "yes").
・ The Exchange Trading System sends a Pre-Logout Response Message to the Virtual Server to proceed with the Logout process.
Note that the Exchange Trading System sends the Pre-Logout Response Message in response to the resend Message from the Virtual Server, that is, to the
Pre-Logout Request Message (resend flag set to "yes"), not to the Pre-Logout Request Message that caused the gap.
74


Message (Seq. No. = N) N
N +1
Pre-Logout Request Message (Seq. No. = N + 2)


Resend Request Receive Resend Request Send
Resend Start
(resend flag "yes") N +2
Pre-Logout Request Message (Seq. No. = N + 2)

Resend End Pre-Logout Request Receive
(resend flag "yes")
N +3
Pre-Logout Response Message (Seq. No. = M + 1)
Pre-Logout Response Send
Logout Request Message (Seq. No. = N + 3)

Message Gap Recovered
N +4
Logout Response Message (Seq. No. = M + 2)
ESP Link Released

Figure 3.7.2 - g Message Gap Detected while Validating Pre-Logout Request Message
75

(8) Virtual Server Detects Message Gap while Validating Pre-Logout Response Message
The Virtual Server validates the Message Sequence Number in the Pre-Logout Response Message received from the Exchange Trading System. If a gap
is detected, it must perform the following steps to recover the message gap.
・ The Virtual Server receives a Pre-Logout Response Message from the Exchange Trading System.
・ The Virtual Server validates the Message Sequence Number of the received Pre-Logout Response Message and a gap is detected.
・ The Virtual Server discards the Pre-Logout Response Message (the expected sequence number remains unchanged).
・ The Virtual Server sends a Resend Request Message to the Exchange Trading System to recover the message gap.
・ The Virtual Server receives a Pre-Logout Response Message from the Exchange Trading System as a resend Message (resend flag set to "yes").
・ The Virtual Server sends a Logout Request Message to the Exchange Trading System to proceed with the Logout process.
Note that the Virtual Server sends the Logout Request Message in response to the resend Message from the Exchange Trading System, that is, to the
Pre-Logout Response Message (resend flag set to "yes"), not to the Pre-Logout Response Message that caused the gap.
76


M Message (Seq. No. = M)
M+1
Pre-Logout Request Message (Seq. No. = N)
Pre-Logout Response Msg. (Seq. No. = M + 2)

Resend Request Message (Seq. No. = N + 1)

Resend Request Send Resend Request Receive

Resend Start
Pre-Logout Response Receive

Pre-Logout Response Msg. (Seq. No. = M + 2)
Resend End
(resend flag "yes")
M+3
Logout Request Message (Seq. No. = N + 2)
Logout Request Send
Logout Response Message (Seq. No. = M + 3)

Message Gap Recovered
M+4
ESP Link Released
Figure 3.7.2 - h Message Gap Detected while Validating Pre-Logout Response Message
77

3.7.3. Exceptions
(1) Receiver Repeated Requests for Number of Times of Re-resend Request

In case that the receiver does not receive any resend Message from the sender in a given period of time (Re-resend Request Timer) after sending a Resend
Request Message to the sender, it will repeat resend requests for a certain number of times (Number of Times of Re-resend Request). If, despite this, the
receiver cannot receive any resend Message from the sender, it will release the ESP link according to the following steps. For details on the Re-resend
Request Timer and Number of Times of Re-resend Request, refer to "3.11. Link Control Parameters."
・ The Exchange Trading System sends a Resend Request Message to the Virtual Server.
・ The Exchange Trading System, if it does not receive any resend Message from the Virtual Server in a given period of time (Re-resend Request
Timer) after sending a Resend Request Message to the Virtual Server, sends a Resend Request Message again. Note that the Message Sequence
Number of the repeated Resend Request Message must be updated.
・ And, if the Exchange Trading System does not receive any resend Message from the Virtual Server in a given period of time (Re-resend Request
Timer), it repeats resend requests for a certain number of times specified by the "Number of Times of Re-resend Request."
・ After this, if the Exchange Trading System does not receive any resend Message from the Virtual Server in a given period of time (Re-resend
Request Timer), it sends a Logout Request Message to the Virtual Server to immediately release the TCP connection.
versa.
78


case where the Virtual Server detects a Message
gap, replace "Exchange Trading System" with
"Virtual Server" in this figure, and vice versa.

Resend Request Send
Time Out
This figure assumes that the "Number of Resend Request Message (Seq. No. = M + 1)
Resend Request Send
Times of Re-resend Request" is set to '1'. (Resend Start Msg. Seq. No. = N + 1)
time elapsed and it reaches
number of times
Logout Request Message (Seq. No. = M + 2)
Logout Request Send
ESP Link Released
Figure 3.7.3 - a Receiver Repeated Requests for Number of Times of Re-resend Request
79


When an Incorrect Message is received, the Exchange Trading System and each Virtual Server process it according to the following steps.
・ The receiver receives an Incorrect Message from the sender.
・ The receiver discards the received Message (the expected sequence number remains unchanged).
・ The receiver proceeds to the next Message received from the sender.

Incorrect Message
Server is the sender and the Exchange Incorrect Message Receive
Reject Message
Trading System is the receiver.
ESP Link Continues
Figure 3.7.3 - b Receipt of Incorrect Message
This figure assumes that the Virtual Expected Seq. No. Admin
Trading System is the receiver. N+2
Update

N+3
Reject Message
Detects Duplicate of Msg.
Seq. No.
ESP Link Continues
Figure 3.7.3 - c Receipt of Incorrect Message (Duplicate of Message Sequence Number)
80

3.8. Operation Message Transmission Procedures
When a Virtual Server sends any operation Message to the Exchange Trading System, it must follow the steps described in this section. This section also shows how the
Exchange Trading System and each Virtual Server Exchange the Already Received Message Sequence Number (ARMSN) each other.
3.8.1. Operation Message Transmission Procedures - Scope of Application
The procedures will be applied to, among various Messages sent/received based on the link control mechanism described in "3. Link Control," the operation
Messages sent from a Virtual Server. Note that the procedures described below will not be applied to the Link Control Messages used for the purposes of link control
(refer to "4.2. List of Link Control Messages").
Operation Message ESP Link

Transmission
Procedures
New Order, Modification Order, Cancel
Order and Administrative Instruction, etc. Upstream
Acceptance Notice, Execution Notice, Market

Downstream Administration and Warning Information, etc.
Login process, Logout process, Send/Receive Control of Message,

Control of Message Recovery, Heartbeat Process
Figure 3.8.1 - a Operation Message Transmission Procedures - Scope of Application
81

3.8.2. Operation Message Transmission Procedures - Overview
There are two types of different transmission procedures per direction between Virtual Servers and the Exchange Trading System as follows.
・ Upstream Operation Message Transmission Procedures (UOMTP): this is for operation Messages from a Virtual Server to the Exchange Trading
System.
・ Downstream Operation Message Transmission Procedures (DOMTP): this is for operation Messages from the Exchange Trading System to a
Virtual Server.
The UOMTP is based on the following information that the Exchange Trading System notifies the Virtual Server.
・ The range of Message Sequence Numbers that the Virtual Server can use for a series of outgoing Messages (Sending Allowed Message Sequence
Number: SAMSN).
・ The Message Sequence Number that the Exchange Trading System recognizes as "already received from the Virtual Server" (Already Received
Message Sequence Number: ARMSN).
A Virtual Server is not able to send Messages by setting sequence numbers out of the range of SAMSN. The concept of UOMTP is shown in the first diagram
below.
The DOMTP is based on the following information that the Virtual Server notifies the Exchange Trading System.
・ The Message Sequence Number that the Virtual Server recognizes as "already received from the Exchange Trading System" (ARMSN).
Note that there is no concept of using SAMSN for the Downstream Message procedures (DOMTP), unlike procedures for the Upstream Messages (UOMTP). The
concept of DOMTP is shown in the second diagram below.
We assume that each of Operation Message Transmission Procedures described in this section is a kind of function that the Exchange Trading System utilizes to
secure the system's stability by maintaining the SAMSN mechanism in the following situations.
・ If an abnormal case, for example where the number of operation Messages from a Virtual Server goes far beyond the expected bounds and such
situation greatly influences the system or the market, occurs and the Exchange Trading System has to respond to such cases to assure the security
and the reliability as a market infrastructure using, for example, a kind of Message flow control mechanism.
82


<Image 1: Sending Allowed Message Sequence Number (SAMSN) not yet obtained from the Exchange Trading System>
The Virtual Server can not send any operation Message The Exchange Trading System sends the SAMSN to
until it gets the SAMSN from the Exchange Trading SAMSN the Virtual Server.
System.
<Image 2: SAMSN has been obtained from the Exchange Trading System>
SAMSN
SAMSN
The Virtual Server can start sending operation

Messages once it gets the SAMSN from the Exchange
Trading System.
<Image 3: Sending Operation Messages to the Exchange Trading System> (received operation Message)
operation operation
SAMSN Message Message
essage 業
務電文
Sequence Numbers
SAMSN
The Virtual Server can send a series of operation The Exchange Trading System accordingly sends a
Messages until it reaches the SAMSN. new SAMSN to the Virtual Server.

83


<Image 4: A new SAMSN has been obtained from the Exchange Trading System>
(received operation Message)
New SAMSN
Sending Allowed operation
Message Increases Message
SAMSN
After obtaining a new SAMSN from the Exchange

Trading System, the range of Sending Allowed
Message Sequence Number expands.
<Image 5: Stop Sending Operation Messages to the Exchange Trading System>

(received operation Message)
<< stop sending state >>
SAMSN operation
Message
Sequence Numbers operation
Message
SAMSN
The Virtual Server, if it reaches the allowed Message The Exchange Trading System accordingly sends a
Sequence Number, can not send new operation new SAMSN to the Virtual Server.
Messages.
* The Exchange Trading System also notifies the Virtual Server of the Already Received Message Sequence
Number (ARMSN) along with the SAMSN, but the sequence is not shown in this figure.
Figure 3.8.2 - a Concept of Upstream Operation Message Transmission Procedures (UOMTP)
84

The Virtual Server sends the Already Received

Message Sequence Number (ARMSN) to the
ARMSN
Exchange Trading System.
Message Message Message Message
Figure 3.8.2 - b Concept of Downstream Operation Message Transmission Procedures (DOMTP)
85

 UOMTP: Upstream Operation Message Transmission Procedures

When a Virtual Server sends any operation Message to the Exchange Trading System, each side must perform the steps as described below.
i. Virtual Server
・ The Virtual Server cannot send any operation Message until it gets the SAMSN from the Exchange Trading System at the beginning of the day.
・ The Virtual Server receives the SAMSN from the Exchange Trading System.
・ The Virtual Server can send a series of Messages until it reaches the allowed Message Sequence Number.
・ If the Virtual Server receives a new SAMSN from the Exchange Trading System, then it extends the range the Virtual Server can send a series of
Messages.
・ The Virtual Server, if it reaches the allowed Message Sequence Number without receiving a new SAMSN from the Exchange Trading System,
then it stops sending new operation Messages.
Table 3.8.3 - A Range of Stop Sending
Category Message Type Stop Sending Remarks
For details on each Message, refer to "System Interface Specifications
for arrowhead - Operation (Order/Notice)", "System Interface
Operation all Messages Yes
Specifications for arrowhead - Operation (Query)" and "System
Interface Specifications for arrowhead - Operation (Drop Copy)".
Login Request/Response Message, Pre-Logout Request/Response
Link Control all Messages No Message, Logout Request/Response Message, Heartbeat Message,
Resend Request Message, Skip Message and Reject Message
The Virtual Server also receives the ARMSN from the Exchange Trading System. For details on the ARMSN, refer to "3.7. Control of Message
Recovery."
86

ii. Exchange Trading System

・ The Exchange Trading System immediately notifies the Virtual Server of the SAMSN at the beginning of the day. Note that the value of the
SAMSN is variable.
・ After sending the first notification, the Exchange Trading System accordingly notifies the Virtual Server of a new SAMSN. However, the new
SAMSN may be the same as the last notified SAMSN.
・ When the Exchange Trading System notifies the Virtual Server of the SAMSN, it sets the number in any Downstream Message to the Virtual
Server. Therefore, the SAMSN will sometimes be set in a link control Message such as a Heartbeat Message if the Exchange Trading System
has no operation Message to send to the Virtual Server.
・ The value of the new SAMSN must be equal to or greater than the last notified value (either continuously incremented values or discontinuous
greater values), i.e. no lesser values allowed. Whenever the Exchange Trading System has any Message to send to the Virtual Server, it always
set the SAMSN to the corresponding field of such Message.
The Exchange Trading System also immediately notifies the Virtual Server of the ARMSN along with the SAMSN. The value of the ARMSN must
be equal to or greater than the last notified value (either continuously incremented values or discontinuous greater values), i.e. no lesser values allowed.
Whenever the Exchange Trading System has any Message to send to the Virtual Server, it always set the ARMSN to the corresponding field of such
Message.
The diagram below shows how a Virtual Server sends operation Messages within the range of the notified SAMSN. For a diagram that shows how a
Virtual Server reaches the SAMSN, refer to "3.8.4. Case-by-Case Explanations."
87

<1. The Virtual Server has not yet obtained the Sending Allowed Message Sequence Number (SAMSN).>
Message Sequence Number (MSN)
1
<< The Virtual Server can not send any This shows the situation where the Virtual Server has
10 operation Message. >> not yet obtained the SAMSN (i.e. it can not send any
operation Message).
20
<2. The Virtual Server has obtained the SAMSN.>

MSN This shows the situation where the Virtual Server has
obtained the SAMSN (= '20').
1
Therefore, the Virtual Server can send operation
10 Messages until the Message Sequence Number (MSN)
SAMSN = '20'
20 reaches '20'.
<3. The Virtual Server has sent ten operation Messages (MSN = '10').>
MSN
This shows the situation where the Virtual Server has
1 MSN = '1' sent ten operation Messages (MSN = '10').
10 MSN = '10'
This means that the Virtual Server still can send ten
20 Messages.
88


<4. The Virtual Server has obtained new SAMSN (= '30').>

MSN
1 MSN = '1' This shows the situation where the Virtual Server has
MSN = '10'
obtained new SAMSN (= '30') from the
10 Exchange Trading System after sending ten
20 operation Messages (MSN = '10').
30 SAMSN = '30' The Virtual Server changes the allowed MSN range
Update
from '20' to '30'
40
<5. The Virtual Server has sent twenty operation Messages (MSN = '20') and obtained new SAMSN (= '40').>
MSN
1 obtained new SAMSN (= '40') from the
10 MSN = '10' Exchange Trading System after sending twenty
operation Messages (MSN = '20').
20 MSN = '20'
The Virtual Server changes the allowed MSN range
30 from '30' to '40'
40 SAMSN = '40'
Update
: a series of Messages can be sent
50
: already sent
: SAMSN
Figure 3.8.3 - a Operation Message Transmission Procedures (Basic Procedures for Upstream Flow)
89

 DOMTP: Downstream Operation Message Transmission Procedures

When the Exchange Trading System sends any operation Message to a Virtual Server, each side must perform the steps as described below.
 Virtual Server
The Virtual Server has to update the ARMSN immediately and notify the Exchange Trading System of the updated ARMSN, but it does not notify
the SAMSN as used in the UOMTP.
The value of the ARMSN must be equal to or greater than the last notified value (either continuously incremented values or discontinuous greater
values), i.e. no lesser values allowed. Whenever the Virtual Server has any Message to send to the Exchange Trading System, it always set the
ARMSN to the corresponding field of such Message.
 Exchange Trading System
Note that when the Exchange Trading System sends operation Messages according to the Downstream Message procedures, there is no concept of
using SAMSN, unlike procedures for the Upstream Messages.
For details on the ARMSN that a Virtual Server notifies the Exchange Trading System, refer to "3.7. Control of Message Recovery."
(1) Case-by-Case Explanations for UOMTP

i. Virtual Server Reaches the Sending Allowed Message Sequence Number (SAMSN)
The diagram below shows how a Virtual Server reaches the allowed Message Sequence Number.
90

<1. The Virtual Server is continuously sending Messages.>

Message Sequence Number (MSN) << earlier part omitted >>
101 MSN = '101'
sent some Messages and the MSN reaches '110'.
120
130
<2. The Virtual Server has used all allowed Message Sequence Numbers (i.e. it reaches SAMSN) and stops sending Messages.>
MSN This shows the situation where the Virtual Server has
<< earlier part omitted >> sent Messages up until the MSN reaches '120' and
101 stops sending.
110 At this stage, the Virtual Server has not received a
MSN = '120' new SAMSN from the Exchange Trading System and
120 Stop Sending
it stops sending operation Messages because the MSN
130 reaches the current SAMSN.
<3. The Virtual Server resumes sending.>

MSN This shows the situation where the "stop sending"
<< earlier part omitted >> Virtual Server receives a new SAMSN (= '130') from
101 the Exchange Trading System.
The Virtual Server changes the allowed MSN range
110 from '120' to '130'
120 The Virtual Server then resumes sending.
130 Resume Sending

Update
SAMSN = '130' : a series of Messages can be sent
140
: already sent
: SAMSN
Figure 3.8.4 - a A UOMTP Scenario

91 (how a Virtual Server reaches the SAMSN)

ii. Transmission of Link Control Message

A Virtual Server, even though it stops sending new operation Messages (i.e. it reaches the allowed Message Sequence Number), can still send link
control Messages because such Messages are not "stop sending" target.
iii. Receipt of Link Control Message

Even though the Exchange Trading System receives a Message that has a greater Message Sequence Number than the last notified SAMSN, if such
Message is a link control Message, it has to be normally processed because link control Messages are not "stop sending" target.
(2) Case-by-Case Explanations for DOMTP

None.
3.8.5. Exceptions
(1) Exceptions for UOMTP

i. Receipt of Operation Message (MSN is Greater than the Last Notified SAMSN)
The Exchange Trading System performs the following steps when it receives an operation Message that has a greater Message Sequence Number than
the last notified Sending Allowed Message Sequence Number (SAMSN).
・ The Exchange Trading System receives a Message from a Virtual Server and the Message's MSN is greater than the SAMSN it has notified of the
Virtual Server last.
・ The Exchange Trading System regards the Message as an Incorrect Message. The acceptance process is not performed but the expected
sequence number is updated. The Exchange Trading System sends a Reject Message to the Virtual Server and then proceeds with the next
Message. Refer to "3.10 Link Reject, 3.10.2. ESP Link Established State, (1) Operation Message Transmission Procedures Reject."
・ Note that if such Incorrect Message (the MSN is greater than the last notified SAMSN) comes in repeatedly and the Exchange Trading System has
to send Reject Messages to the Virtual Server more than once, perform the steps described in "3.10 Link Reject, 3.10.2. ESP Link Established
State, (3) Critical Error."
92

<1. The Virtual Server has used all allowed Message Sequence Numbers (i.e. it reaches SAMSN) and stops sending Messages.>
<< earlier part omitted >>
Message Sequence Number (MSN) SAMSN = '120'

101 sent Messages up until the MSN reaches '120' (=
current SAMSN).
110 MSN = '110'
120 Stop Sending MSN = '120' The Virtual Server stops sending Messages.
130
<2. The Virtual Server has sent a Message by setting a MSN that is greater than the current SAMSN.>
<< earlier part omitted >>
This shows the situation where the Virtual Server,
MSN although it stops sending, has sent a Message by
SAMSN = '120' setting a MSN (= '121') that is greater than the current
101 SAMSN (= '120').
110
The Exchange Trading System rejects this Message
120 Stop Sending MSN = '121' because the MSN of the received Message (='121') is
greater than the current SAMSN (= '120').
130 Reject Message
140 : a series of Messages can be sent
: already sent
: SAMSN
Figure 3.8.5 - a Receipt of Operation Message (MSN is Greater than the Last Notified SAMSN)
93

ii. Receipt of Lesser SAMSN

A Virtual Server, when it is notified of an Incorrect SAMSN from the Exchange Trading System, performs the following steps.
・ A Virtual Server receives an Incorrect SAMSN from the Exchange Trading System.
・ The Virtual Server does not update any information using the Incorrect SAMSN.
・ The Virtual Server expects the next SAMSN set in the next Message.
94

<1. The Virtual Server is continuously sending operation Messages.>

Message Sequence Number (MSN) << earlier part omitted >>
sent Messages up until the MSN reaches '110'.
110 MSN = '110'
The Virtual Server can send operation Messages until
120 the MSN reaches '120'.
130
<2. The Virtual Server has received an invalid SAMSN.>

MSN << earlier part omitted >>
101 received an invalid SAMSN (= '115') from the
Exchange Trading System.
110
120 SAMSN is not updated. The Virtual Server does not update the SAMSN
because the value is invalid.
130 Invalid SAMSN (= '115')
<3. The Virtual Server has obtained a new SAMSN (= '130').>

MSN << earlier part omitted >> This shows the situation where the Virtual Server has
received a valid SAMSN (= '130') from the Exchange
101 Trading System.
110 The Virtual Server updates the SAMSN.
120
: a series of Messages can be sent
130
Valid SAMSN (= '130') : already sent
: SAMSN
Figure 3.8.5 - b Receipt of Lesser Sending Allowed Message Sequence Number
95

iii. Receipt of Lesser ARMSN

The Exchange Trading System performs the following steps when it is notified of an Incorrect ARMSN (Already Received Message Sequence
Number) from a Virtual Server.
・ The Exchange Trading System receives an Incorrect ARMSN from a Virtual Server.
・ The Exchange Trading System does not perform any process based on the Incorrect ARMSN.
・ The Exchange Trading System expects the next ARMSN set in the next Message.
iv. Receipt of Not-Yet-Used ARMSN

The Exchange Trading System performs the following steps when it is notified of an Incorrect ARMSN from a Virtual Server.
・ The Exchange Trading System receives an Incorrect ARMSN from a Virtual Server.
・ The Exchange Trading System does not perform any process based on the Incorrect ARMSN.
・ The Exchange Trading System expects the next ARMSN set in the next Message.
(2) Exceptions for DOMTP

i. Receipt of Lesser ARMSN
A Virtual Server performs the following steps when it is notified of an Incorrect ARMSN from the Exchange Trading System.
・ The Virtual Server receives an Incorrect ARMSN from the Exchange Trading System.
・ The Virtual Server does not perform any process based on the Incorrect ARMSN.
・ The Virtual Server expects the next ARMSN set in the next Message.
ii. Receipt of unsent status ARMSN

A Virtual Server performs the following steps when it is notified of an Incorrect ARMSN from the Exchange Trading System.
・ The Virtual Server receives an Incorrect ARMSN from the Exchange Trading System.
・ The Virtual Server does not perform any process based on the Incorrect ARMSN.
・ The Virtual Server expects the next ARMSN set in the next Message.
96

3.9. Heartbeat Process
A Virtual Server and the Exchange Trading System monitors each other's system status by checking the intervals of Messages received from the counterpart.
(1) Sender
The sender, a Virtual Server or the Exchange Trading System, if it has no Message to send for a given period of time (hereinafter referred to as "Heartbeat
Transmission Timer"), sends a Heartbeat Message to the receiver to let the receiver know that the sender is "alive." Note, however, that the Exchange
Trading System may send a Heartbeat Message regardless of the Heartbeat Transmission Timer for the purposes of immediately notifying a Virtual Server of
a Sending Allowed Message Sequence Number (SAMSN). For details on the Heartbeat Transmission Timer, refer to "3.11. Link Control Parameters."
(2) Receiver
The receiver, a Virtual Server or the Exchange Trading System, monitors if the sender is "alive" by monitoring whether it receives a Message in a given
period of time (hereinafter referred to as "Heartbeat Receipt Timer"). For details on the Heartbeat Receipt Timer, refer to "3.11. Link Control Parameters."
97


This figure shows an Upstream Message case where a Virtual Server is the sender and the
Exchange Trading System is the receiver. Thus, for a Downstream Message case, replace
"Exchange Trading System" with "Virtual Server" and vice versa.
Interval Admin. Interval Monitoring
Message (operation msg., etc.)
time reset
a given period of time
Timeout Heartbeat Message 一定時間 Msg comes in within the time.
time reset
time reset
Timeout
a given period of time
time reset Msg comes in within the time.
Heartbeat Message
time reset
Figure 3.9.1 - a Heartbeat Process (Basic Procedures)
In the heartbeat process, a Virtual Server becomes the sender of Heartbeat Messages for the upward stream and the Exchange Trading System becomes the sender of
Heartbeat Messages for the downward stream to monitor each other. Note that the heartbeat mechanism is not a request-response type process.
None.
98

3.9.3. Exceptions
(1) Timeout
The receiver, a Virtual Server or the Exchange Trading System, if it receives no Message after a given period of time (Heartbeat Receipt Timer) elapses,
thinks that any trouble occurred in the sender's system and releases the ESP link according to the following steps.
・ The receiver does not receive any Heartbeat Message and a given period of time (Heartbeat Receipt Timer) elapses.
・ The receiver sends a Logout Request Message to the sender.
・ The receiver releases the TCP connection without waiting for the Logout Response Message from the sender.

This figure shows an Upstream Message case where a Virtual Server is the sender and the
Exchange Trading System is the receiver. Thus, for a Downstream Message case, replace
"Exchange Trading System" with "Virtual Server" and vice versa.
Interval Admin. Interval Monitoring
Message (operation msg., etc.)
time reset
Timeout Heartbeat Message

time reset a given period of time
Timeout Heartbeat Message

time reset ～

Timeout
ESP Link Released
Figure 3.9.3 - a Exceptions (Timeout)
99

(2) ESP Link Re-establishment after a Timeout

If a Virtual Server or the Exchange Trading System re-establishes an ESP link after the previous link was released due to a timeout (time elapsed), refer to
the steps described in "3.4. Link Establishment, 3.4.3. Exceptions, (8) The Case that Last Established ESP Link has been Released without Confirming that
no Message Gap Exists via a Logout Process."
(3) Message Gap Detected while Validating Heartbeat Message

If a Virtual Server or the Exchange Trading System detects a Message gap while validating the Message Sequence Number of the received Heartbeat
Message, for the steps to perform, refer to "3.7. Control of Message Recovery, 3.7.2. Case-by-Case Explanations, (5) Message Gap Detected while
Validating ."
100

3.10. Link Reject
If a Virtual Server or the Exchange Trading System receives a highly abnormal Message or encounters a serious event before establishing an ESP link or in an ESP link
established state, it performs the following steps.
3.10.1. Before Establishing an ESP Link
If a Virtual Server or the Exchange Trading System receives a highly abnormal Message or encounters a serious event before establishing an ESP link, follow the
steps described in "3.4. Link Establishment."
3.10.2. ESP Link Established State
If a Virtual Server or the Exchange Trading System encounters the "Cases" below in an ESP link established state, it performs the following steps.
Note that for exceptions described in "3.6. Send/Receive Control of Messages," "3.7. Control of Message Recovery" and "3.9. Heartbeat Process," refer to each
respective procedures.
(1) Operation Message Transmission Procedures Reject
The Exchange Trading System performs the following steps when it encounters one of the "Cases" below.
・ If the Exchange Trading System receives the Message described in the "Cases" below, it does not process the Message (but the expected sequence
number is updated).
・ The Exchange Trading System sends a Reject Message to the sender.
・ The Exchange Trading System retains the ESP link and proceeds to the next Message.
Cases:
・ Receives an operation Message that has a greater Message Sequence Number than the last notified SAMSN with regard to the Upstream
Operation Message Transmission Procedures (UOMTP).
Note that the Exchange Trading System updates the expected sequence number when it encounters this case. For details on the Operation Message
Transmission Procedures and the SAMSN, refer to "3.8. Operation Message Transmission Procedures."
101


A Virtual Server or the Exchange Trading System performs the following steps when it encounters one of the "Cases" below.
・ If either receives the Message described in the "Cases" below, it discards such Message (the expected sequence number remains unchanged).
・ The receiver retains the ESP link and proceeds to the next Message.
Cases:
・ Receives a Message that has an Incorrect Message header. Note, however, that this does not include Messages that have an Incorrect
Message length.

Server is the sender and the
Incorrect Message
Exchange Trading System is the
receiver. If it is the case where the
Reject Message Incorrect Message Receive
Virtual Server is the receiver, replace
"Virtual Server" with "Exchange
Trading System" in this figure, and
vice versa. ESP Link Continues
Figure 3.10.2 - a Receipt of Incorrect Message
102

(3) Critical Error

・ If the receiver encounters one of the "Cases" below, the receiver sends a Logout Request Message to the sender.
・ The receiver immediately releases the TCP connection and the ESP link without waiting for the Logout Response Message from the sender.
Note that if the sender detects a gap in the received Logout Request Message, it cannot perform a gap recovery process.
Cases:
・ Receives a Message and the length of the Message header is invalid.
・ Repeats resend requests according to the "Re-resend Request Timer." (For details on the number of repetition, refer to "3.11. Link
Control Parameters.")
・ Receives the same Message (resend flag set to "yes") repeatedly. (For details on the number of repetition, refer to "3.11. Link Control
Parameters.")
・ Receives Incorrect Messages and sends Reject Messages repeatedly. (For details on the number of repetition, refer to "3.11. Link Control
Parameters.")

Trading System is the receiver. If it Critical Error !!
is the case where the Virtual Server is
the receiver, replace "Virtual Server" ESP Link Released
with "Exchange Trading System" in
this figure, and vice versa. TCP connection Released
Figure 3.10.2 - b Critical Error
103

(4) Message Sequence Number Reaches Upper Limit

・ If the receiver encounters the "Cases" below, it discards such message without sending any Message to the sender and immediately releases the
TCP connection and the ESP link.
Cases:
・ Receives a Message and the value of the Message Sequence Number is '99999999'.

Server is the sender and the
Message (Seq. No. = '99999999')
Exchange Trading System is the
receiver. If it is the case where the
TCP connection Released MSN Reaches Upper Limit
Virtual Server is the receiver, replace
"Virtual Server" with "Exchange
Trading System" in this figure, and
vice versa. ESP Link Released
Figure 3.10.2 - c Message Sequence Number Reaches Upper Limit
3.10.3. During Releasing ESP Link
If a Virtual Server or the Exchange Trading System receives a highly abnormal Message or encounters a serious event while releasing the ESP link, follow the steps
described in "3.5. Link Release."
104

3.11. Link Control Parameters
The tables below show the parameters a Virtual Server and the Exchange Trading System use to control a link. Note that all parameters will be stopped or cleared at the
time the TCP connection is released. Specific setting values will be determined separately.
Table 3.11 - A Link Control Parameters (timers)

Monitored by:
Category Link Control Parameter Description Timer starts when: Timer stops when:
VS ETS
Time from when the TCP connection is established by the
A TCP connection is A Login Request
Login Request Timer (T1) Virtual Server till when the Exchange Trading System receives
established. Message is received.
○
Link a Login Request Message from the Virtual Server.
Establishment Time from when the Virtual Server sends a Login Request
A Login Request A Login Response
Login Response Timer (T2) Message till when it receives a Login Response Message from
Message is sent. Message is received.
○
the Exchange Trading System.
Time from when the Virtual Server sends a Pre-Logout Request

Pre-Logout Response Timer A Pre-Logout Request A Pre-Logout Response
(T3)
Message till when it receives a Pre-Logout Response Message.
Message is sent. Message is received.
○
Note that this does not include time for resend process.
Time from when the Exchange Trading System sends a

Pre-Logout Response Message till when it receives a Logout A Pre-Logout Response A Logout Request
Link Release
Logout Request Timer (T4)
Request Message. Note that this does not include time for Message is sent. Message is received.
○
resend process.
Time from when a Logout Request Message is sent till when a A Logout Request A Logout Response
Logout Response Timer (T5)
Logout Response Message is received. Message is sent. Message is received.
○
Connection Release Timer Time from when a Logout Response Message is sent till when A Logout response is The TCP connection is
(T6) the TCP connection is released. sent. released.
○
105


Monitored by:
Category Link Control Parameter Description Timer starts when: Timer stops when:
VS ETS
Time from when a Resend Request
Control of
Message is sent till when the sender
Message Re-resend Request Timer (T9)
starts receiving the resend
A Resend Request Message is sent. The first resend Message is received. ○ ○
Recovery
Messages.
[Virtual Server]
[Virtual Server]
A Pre-Logout Response Message is
A Login Response Message is
When the sender has no Message to received.
received.
send, this timer measures time from [Exchange Trading System]
Heartbeat Transmission Timer [Exchange Trading System]
(T7)
when the sender sent the last
A Login Response Message is sent.
A Pre-Logout Response Message is ○ ○
Message till when it sends a sent.
[VS and ETS, afterward]
Heartbeat Message. [VS and ETS]
The timer starts again when a
A Logout Request Message is sent.
Message is sent.
A Logout Response Message is sent.
Heartbeat
[Virtual Server]
[Virtual Server]
A Pre-Logout Response Message is
A Login Response Message is
received.
received.
[Exchange Trading System]
Time in which the receiver monitors [Exchange Trading System]
Heartbeat Receipt Timer (T8)
the sender (if it is "alive"). A Login Response Message is sent.
A Pre-Logout Response Message is ○ ○
sent.
[VS and ETS, afterward]
[VS and ETS]
The timer starts again when a
A Logout Request Message is received.
Message is received.
A Logout Response Message is sent.
VS: Virtual Server ETS: Exchange Trading System

106

Table 3.11 - B Link Control Parameters (Number of Times)

Number of Times Number of Times Monitored by:
Category Link Control Parameter Description
count starts when: cleared when: VS ETS
Control of Number of Times of resend requests repetition
Number of Times of Re-resend A Resend Request Message
Message
Request (C1)
that is made based on the "Re-resend Request
is sent.
A resend Message is received. ○ ○
Recovery Timer."
Number of times to send a Reject Message in A Message which does not

Number of Times of Reject Message
(C2)
response to an Incorrect Message when such A Reject Message is sent. cause a Reject Message is ○ ○
Message comes in consecutively. received.
A Message (resend flag set to

Link Reject
"no") comes in.
Number of Times Same Message Number of times to receive the same Message A Message (resend flag set
Repeatedly Received (C3) (resend flag set to "yes") repeatedly. to "yes") comes in.
A Message (resend flag set to ○ ○
"yes") comes in with a
different MSN.
VS: Virtual Server ETS: Exchange Trading System
107

4. Message
4.1. Message Format
4.1.1. Message Basic Format
A Message sent/received between a Virtual Server and the Exchange Trading System consists of a Message header and a data area. The Message header is common
for all Messages. The data area, however, contains various data depending on the type of the Message and differs even between the same Message types depending on
the data classification. Refer to "System Interface Specifications for arrowhead - Operation (Order/Notice)", "System Interface Specifications for arrowhead -
Operation (Query)" and "System Interface Specifications for arrowhead - Operation (Drop Copy)" for details on the data classification.
Message Header Data Area
(* Protocol header, etc. for layers below the transport layer are omitted.)
Figure 4.1.1 - a Message Basic Format
4.1.2. Data Format
A Virtual Server and the Exchange Trading System use the following data format for the link control.
Table 4.1.2 - A Data Format
Notation of Character Code Character Set
Attribute
The character set is JIS8 for single-byte characters and Shifted JIS for double-byte characters. Note that double-byte
C Represents character set. characters (Shifted JIS) may not be used for the Message headers of link control Messages and other Messages.
* All message fields that can use alphabet characters from 'A' to 'Z' and from 'a' to 'z' are case sensitive.
108

4.1.3. Message Header Data Format
The following table shows the data format of the Message header used for the Messages sent/received between a Virtual Server and the Exchange Trading System.
Table 4.1.3 - A Data Format - Message Header
No. Field Name Bytes Attr. Description
Set the length of the Message excluding the "Message Length" field itself. Right-align the Message
1 Message Length 5 C
length, suppressing zeros.
2 Message Type 2 C Set the type of the Message. Refer to "4.2. List of Link Control Messages."
3 Message Sequence Number 8 C Set the Message Sequence Number. (*) Right-align the Message Sequence Number, suppressing zeros.
Set this flag to "yes" for resend Messages for recovery purposes. Set the field as below.
4 Resend Flag 1 C '0': no
'1': yes
For Upstream Messages, set the Participant Code of the sender.
For Downstream Messages, set the Exchange Participant Code of the destination.
5 Participant Code 5 C
Always use the Securities Company Standard Code defined by the Securities Identification Code
Committee (SICC).
For Upstream Messages, set the Virtual Server number of the sender.
6 Virtual Server No. 6 C For Downstream Messages, set the Virtual Server number of the destination.
Set using single-byte alphanumeric characters from ‘0’ to ’9’, from ’A’ to ’Z’, and from ’a’ to ’z’.
Already Received Message Set the Message Sequence Number recognized as "already received." Right-align the ARMSN,
7 8 C
Sequence Number (ARMSN) suppressing zeros.
Set the Sending Allowed Message Sequence Number (SAMSN) the Exchange Trading System notifies
Sending Allowed Message
8 8 C the Virtual Server. Right-align the SAMSN, suppressing zeros.
Sequence Number (SAMSN)
Set all zeros for Upstream Messages (this field is not used for Upstream Messages).
109


9 Data Area Length 5 C Set the length of the data area. Right-align the data area length, suppressing zeros.
10 Number of Data Transaction 3 C Set the number of data transaction in the data area. Set '△△1'.
11 Transmission Date 8 C Set the transmission date (system date) on which the Message is sent in "YYYYMMDD" format.
Set the transmission time (system time) at which the Message is sent in "HHMMSSTTTTTT" or
12 Transmission Time 12 C "HHMMSSTTT△△△" format.
For Downstream Message is sent in "HHMMSSTTTT00" format (the last two digits are always '00').
13 Reserved 1 C Set space.
(*) Refer to "3.10. Link Reject" for the case the Message Sequence Number reaches upper limit ('99999999').
4.1.4. Data Format - Data Area
For the data format of the data area used for the Messages sent/received between a Virtual Server and the Exchange Trading System, refer to "4.3. Link Control
Message Data Format" for link control Messages and refer to "System Interface Specifications for arrowhead - Data Format (Order/Notice)", "System Interface
Specifications for arrowhead - Data Format (Query)" and "System Interface Specifications for arrowhead - Data Format (Drop Copy)" for operation Messages.
110

4.2. List of Link Control Messages
The following table shows the link control Messages used between a Virtual Server and the Exchange Trading System.
Table 4.2 - A List of Link Control Messages
Able to send?
Category Message Name Direction Message Type
Login Request Message Up 01 Yes No
Login Response Message Down 11 No Yes
Pre-Logout Request Message Up 02 Yes No
Pre-Logout Response Message Down 12 No Yes
Up 03 Yes No
Down 13 No Yes
Up 04 No No
Down 14 No Yes
Link Control Message
Up 05 Yes No
Heartbeat Message
Down 15 No Yes
Up 06 Yes No
Resend Request Message
Down 16 No Yes
Up 07 Yes No
Skip Message
Down 17 No Yes
Up 08 Yes No
Reject Message
Down 18 No Yes
111


Able to send?
Category Message Name Direction Message Type
Up 40 Yes No
Operation Message
Operation Message Down 50 No Yes
(Order/Notice) Up 80 Yes No
Administrative Message
Down 90 No Yes
Up 41 Yes No
Operation Message
Operation Message Down 51 No Yes
(Query) Up 81 Yes No
Administrative Message
Down 91 No Yes
Up 42 Yes No
Operation Message Operation Message
Down 52 No Yes
(Operation – Drop
Up 82 Yes No
Copy) Administrative Message
Down 92 No Yes
112

4.3. Link Control Message Data Format
4.3.1. Login Request Message
Table 4.3.1 - A Data Format - Login Request Message

1 Message Header 72 C Set the Message header.
Data Area
2 Reserved 16 C Set spaces.
4.3.2. Login Response Message
Table 4.3.2 - A Data Format - Login Response Message

Data Area
113

4.3.3. Pre-Logout Request Message
Table 4.3.3 - A Data Format - Pre-Logout Request Message

1 Message Header
Data Area 72 C Set the Message header.
4.3.4. Pre-Logout Response Message
Table 4.3.4 - A Data Format - Pre-Logout Response Message

Data Area
114

4.3.5. Logout Request Message
Table 4.3.5 - A Data Format - Logout Request Message

The Logout Reason Code is set.
2 Logout Reason Code 4 C
Data Area
Refer to "4.4.2. Logout Reason Code."
4.3.6. Logout Response Message
Table 4.3.6 - A Data Format - Logout Response Message

Data Area
115

4.3.7. Heartbeat Message
Table 4.3.7 - A Data Format - Heartbeat Message

1 Message Header
Data Area 72 C Set the Message header.
4.3.8. Resend Request Message
Table 4.3.8 - A Data Format - Resend Request Message

Set a Message Sequence Number that the receiver expects to receive after the last
Resend Start Message Sequence
2 8 C successfully received Message. Right-align the Resend Start Message Sequence Number,
Data Area
Number
suppressing zeros.
116

4.3.9. Skip Message
Table 4.3.9 - A Data Format - Skip Message

When multiple consecutive non-resend Messages exists, sets the Message Sequence
Skip Message Sequence Number of the last non-resend Message. Right-align the Skip Message Sequence
Data Area
2 8 C
Number Number, suppressing zeros.
If only a single non-resend Message exists, set zeros.
4.3.10. Reject Message
Table 4.3.10 - A Data Format - Reject Message

Set the Message Sequence Number of the reject target Message. Right-align the Reject
Reject Message Sequence Message Sequence Number, suppressing zeros.
2 8 C
Number Note that if the Message Sequence Number of the reject target Message is not identified,
Data Area
set zeros.
Set the Message type of the reject target Message.
3 Reject Message Type 2 C
Note that if the Message type of the reject target Message is not identified, set zeros.
4 Reject Reason Code 4 C The Reject Reason Code is set. Refer to "4.4.1. Reject Reason Code."
117

4.4. List of Reason Codes
4.4.1. Reject Reason Code
Table 4.4.1 - A Reject Reason Code

No. Reject Reason Code Description
1 0001 Incorrect Message Type.
2 0002 Incorrect Message Sequence Number.
3 0003 Incorrect Participant Code.
4 0004 Incorrect Virtual Server Number
5 0005 Incorrect Resend Flag.
6 0006 Incorrect Resend Start Message Sequence Number.
7 0007 MSN is greater than the current SAMSN.
8 0008 Incorrect ARMSN
9 0009 Incorrect SAMSN
10 0010 Incorrect Message Length
11 0011 Incorrect Number of Data Transaction
12 0012 Incorrect Skip Message Sequence Number
13 0013 Incorrect Format
118

4.4.2. Logout Reason Code
Table 4.4.2 - A Logout Reason Code

No. Logout Reason Code Description
1 0000 Logout request is valid.
2 0101 Incorrect Message Length.
3 0102 Time Out (Pre-Logout Response Timer).
4 0103 Time Out (Logout Request Timer).
5 0105 Time Out (Heartbeat Receipt Timer).
6 0106 Number of Times of Re-resend Request is reached.
7 0107 Number of Times of Reject Message is reached.
8 0108 Number of Times Same Message Received Repeatedly is reached.
9 0109 ESP link released by instruction of the upper layer.
10 0199 System Error
119

ESP (Exchange Standard Protocol)
Issued by: Tokyo Stock Exchange, Inc.

2-1 Nihombashi Kabutocho, Chuo-ku Tokyo 103-8220
Tel: 81-3-3666-0141
This English version is not an official translation of the original Japanese document. In cases where any differences occur between the English version
and the original Japanese version, the Japanese version shall prevail. TSE, Japan Exchange Group, Inc. (JPX), Japan Exchange Regulation (JPX-R),
and/or their affiliates shall not jointly or individually accept any responsibility or liability for damage or loss caused by any error, inaccuracy,
misunderstanding or misspelling with regard to this translation. This translation may be used only for reference purposes. TSE, JPX, JPX-R, and/or their
affiliates jointly or individually maintain rights to claim compensation for any damage or loss it may suffer from a violation of these conditions.
120

System Interface Specifications For Arrowhead - ESP (Exchange Standard Protcol)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Interface Specifications For Arrowhead - ESP (Exchange Standard Protcol)

Uploaded by

Copyright:

Available Formats

Confidential

System Interface Specifications for

ESP (Exchange Standard Protocol)

Tokyo Stock Exchange, Inc.

Terms and Conditions of Use

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

No. Created/Modified Version Page Summary of Change

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

No. Created/Modified Version Page Summary of Change

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

No. Created/Modified Version Page Summary of Change

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

1. Overview .................................................................................................. 1 3.6.3. Exceptions ................................................................................. 48

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

A number of terms used throughout these specifications are defined below.

No. Term Description Where to read for details?

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

No. Term Description Where to read for details?

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

No. Term Description Where to read for details?

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

No. Term Description Where to read for details?

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

About What These Specifications Cover in a Series of Documents

These specifications are a part of a series of system documents as shown below.

ESP (Exchange Standard Protocol) Specifications

Operation (Order/Notice) Specifications Data Format (Order/Notice)

Operation (Query) Specifications Data Format (Query)

Operation (Drop Copy) Specifications Data Format (Drop Copy)

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

1.1. System Overview

<Trading Participant> <Exchange>

Virtual Server Exchange Trading System

Order Entries, Queries, etc.

Acceptance Notices, Execution Completion Notice, Own Order Statuses, etc.

Figure 1.1 - a System Connection Diagram

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

1.2. System Components

The system consists of the following main components.

1.3. Scope of the Specifications

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

1.4. Relationship between Operation Specifications and ESP Specifications

System Interface Specifications for

ESP System Interface Specifications for

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

2.2. Port Number

<Trading Participant> <Exchange>

Server Machine Exchange Trading

Figure 2.2 - a IP Addresses and Port Numbers : Port Number

2.3. Establishment and Release of a TCP connection

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

3.1. Link Control Overview

Copyright(c) 2006-2015 Tokyo Stock Exchange, Inc. All Rights Reserved.

<Virtual Server> <Exchange Trading System>

Keep Alive Heartbeat Process

Message Gap Occur Mes. Recovery Process

Send/Receive Message Send/Receive Message

ESP Link Released Logout Process Mes. Seq. No. "reset"

* dotted line only represents event timing.