差分

このページの2つのバージョン間の差分を表示します。

--- spec:jp:isv:connection [2023/09/29 16:28]
editor
+++ spec:jp:isv:connection [2024/01/22 09:57] (現在)
editor
@@ 行 30: / 行 30: @@
 === 2.1.1　本番面 ===
-本番面は本システムのサービスを利用することを目的とした環境である。利用可能時間は取引日の8:00（JST）から18:00（JST）である。\\
+本番面は本システムのサービスを利用することを目的とした環境である。利用可能時間は取引日の8:00（JST）から18:30（JST）である。\\
 投資家システムは、取引日の利用可能時間内に、CONNEQTORに対してログオンを行う。\\
 図 2.1.1に示すCONNEQTOR（本番面）、プライマリセンタのNW機器、arrownetの広域被災時においては、同環境でのサービス再開を目指し、当該機器が復旧するまで本サービスを停止する。また、耐障害性を考慮し投資家システムのFIXクライアントは同一IPアドレスまたは異なるIPアドレスで冗長化することが可能である。\\
@@ 行 100: / 行 100: @@
 投資家システムが利用するIPアドレス、ポート番号については利用申請時に投資家側から指定する。FIXクライアントを異なるIPアドレスで冗長化する場合は、現用系・待機系双方のIPアドレス、ポート番号を指定する。CONNEQTORのIPアドレス、ポート番号については利用申請時に取引所側で指定したものを使用する。IPアドレスおよびポート番号について取引所より割り当てられる箇所については下図を参照。
-{{ :draft:investorfix:図 3.2.2-1 IPアドレスとポート番号.svg?800 |図 3.2.2-1 IPアドレスとポート番号 (arrownet経由で接続する場合)}}
+{{ :spec:jp:isv:図 3.2.2-1 IPアドレスとポート番号.svg?800 |図 3.2.2-1 IPアドレスとポート番号 (arrownet経由で接続する場合)}}
 ;#;
 **図 3.2.2-1 IPアドレスとポート番号 **
@@ 行 147: / 行 147: @@
 FIXセションは(時間的に)複数のTCPコネクションをまたがって存続する。単一のFIXセションの中で、複数回のLogon/Logoutが可能である。
-{{ :draft:investorfix:図 4.2.1 TCPコネクションとFIXセションの関係.svg?800 |図 4.2.1 TCPコネクションとFIXセションの関係}}
+{{ :spec:jp:isv:図 4.2.1 TCPコネクションとFIXセションの関係.svg?800 |図 4.2.1 TCPコネクションとFIXセションの関係}}
 ;#;
 **図 4.2.1 TCPコネクションとFIXセションの関係**
@@ 行 318: / 行 318: @@
 FIXプロトコルの通信シーケンスには、大きく分けてLogonをやり取りする確立シーケンス、アプリケーションメッセージをやり取りするメッセージ送受信、Logoutをやり取りする解放シーケンスがある。以下にFIXプロトコルの通信シーケンスの概要を示す。
-{{ :draft:investorfix:図 6.1.1　シーケンス概要.svg?800 |図 6.1.1　シーケンス概要}}
+{{ :spec:jp:isv:図 6.1.1　シーケンス概要.svg?800 |図 6.1.1　シーケンス概要}}
 ;#;
 補足)一度解放した後でも、シーケンス番号は継続していることに注意。
@@ 行 334: / 行 334: @@
 (注意) Logon要求/応答のMsgSeqNumは必ずしも1とは限らない。
-{{ :draft:investorfix:図 6.1.2　確立（認証ＯＫ）.svg?800 |図 6.1.2　確立（認証ＯＫ）}}
+{{ :spec:jp:isv:図 6.1.2　確立（認証ＯＫ）.svg?800 |図 6.1.2　確立（認証ＯＫ）}}
 ;#;
 ** 図 6.1.2　確立（認証ＯＫ） **
@@ 行 342: / 行 342: @@
 CONNEQTORが投資家システムから受信したLogon要求の認証に問題があった場合、不当な接続相手と判断し、TCPコネクションの切断により接続を拒否する。
-{{ :draft:investorfix:図 6.1.3　確立（認証ＮＧ）.svg?800 |図 6.1.3　確立（認証ＮＧ）}}
+{{ :spec:jp:isv:図 6.1.3　確立（認証ＮＧ）.svg?800 |図 6.1.3　確立（認証ＮＧ）}}
 ;#;
 ** 図 6.1.3　確立（認証ＮＧ） **
@@ 行 350: / 行 350: @@
 投資家システムにおける能動型解放は、Logout要求に対してCONNEQTORからのLogout応答を受信し、この時点で解放が完了する。TCPコネクションの切断は投資家システムが行う。
-{{ :draft:investorfix:図 6.1.4　能動型解放.svg?800 |図 6.1.4　能動型解放}}
+{{ :spec:jp:isv:図 6.1.4　能動型解放.svg?800 |図 6.1.4　能動型解放}}
 ;#;
 ** 図 6.1.4　能動型解放 **
@@ 行 369: / 行 369: @@
 CONNEQTORがHeartBeatを使用する時のシーケンスである。Logon応答のHeartBtIntで指定した時間が経過しても、何らメッセージを送信しない場合に、HeartBeatを送信する。
-{{ :draft:investorfix:図 6.1.5　ハートビート送信.svg?800 |図 6.1.5　ハートビート送信}}
+{{ :spec:jp:isv:図 6.1.5　ハートビート送信.svg?800 |図 6.1.5　ハートビート送信}}
 ;#;
 ** 図 6.1.5　ハートビート送信 **
@@ 行 377: / 行 377: @@
 投資家システムがHeartBeatを使用する場合、CONNEQTORは、投資家システムから受信するメッセージの間隔を監視する。監視時間が経過しても何らメッセージが送信されてこない場合、CONNEQTORはTestRequestを送信して投資家システムの生存を確認する。再度、何らかの原因で投資家システムから応答がない場合、CONNEQTORは回線、または投資家システムに異常が発生したと判断してTCPコネクションを切断する。
-{{ :draft:investorfix:図 6.1.6　受信ハートビート監視タイムアウト.svg?800 |図 6.1.6　受信ハートビート監視タイムアウト}}
+{{ :spec:jp:isv:図 6.1.6　受信ハートビート監視タイムアウト.svg?800 |図 6.1.6　受信ハートビート監視タイムアウト}}
 ;#;
 ** 図 6.1.6　受信ハートビート監視タイムアウト **\\
@@ 行 387: / 行 387: @@
 投資家システムからのResendRequestを受信した場合、ResendRequestの要求内容に従って再送処理を行う。Rejectを除く管理メッセージは再送対象外であるため、再送範囲にこれらのメッセージが含まれていた場合には、SequenceReset-GapFillの送信で代替する。
-{{ :draft:investorfix:図 6.1.7　投資家システムからResendRequest（再送要求）受信.svg?800 |図 6.1.7　参加者システムからResendRequest（再送要求）受信}}
+{{ :spec:jp:isv:図 6.1.7　投資家システムからResendRequest（再送要求）受信.svg?800 |図 6.1.7　参加者システムからResendRequest（再送要求）受信}}
 ;#;
 ** 図 6.1.7　投資家システムからResendRequest（再送要求）受信 **
@@ 行 399: / 行 399: @@
 (注意) CONNEQTORは、欠落メッセージの先頭以降の全メッセージをResendRequestの再送要求範囲とする。(EndSeqNo=0固定)
-{{ :draft:investorfix:図 6.1.8　AplMessages受信でGap検出.svg?800 |図 6.1.8　AplMessages受信でGap検出}}
+{{ :spec:jp:isv:図 6.1.8　AplMessages受信でGap検出.svg?800 |図 6.1.8　AplMessages受信でGap検出}}
 ;#;
 ** 図 6.1.8　AplMessages受信でGap検出 **
@@ 行 407: / 行 407: @@
 CONNEQTORがLogon要求受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、先ず投資家システムにLogon応答を送信してから、ResendRequestを送信してメッセージの再送を要求する。例えば、システムダウンで投資家システムからのメッセージをロストした場合に、このシーケンスが実行される。
-{{ :draft:investorfix:図 6.1.9　Logon要求受信でGap検出.svg?800 |図 6.1.9　Logon要求受信でGap検出}}
+{{ :spec:jp:isv:図 6.1.9　Logon要求受信でGap検出.svg?800 |図 6.1.9　Logon要求受信でGap検出}}
 ;#;
 ** 図 6.1.9　Logon要求受信でGap検出 **
@@ 行 415: / 行 415: @@
 Logout要求受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。その後、再送を要求したメッセージが全て届いたらLogout応答を送信する。
-{{ :draft:investorfix:図 6.1.10　Logout要求受信でGap検出.svg?800 |図 6.1.10　Logout要求受信でGap検出}}
+{{ :spec:jp:isv:図 6.1.10　Logout要求受信でGap検出.svg?800 |図 6.1.10　Logout要求受信でGap検出}}
 ;#;
 ** 図 6.1.10　Logout要求受信でGap検出 **
@@ 行 423: / 行 423: @@
 HeartBeat受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。
-{{ :draft:investorfix:図 6.1.11　HeartBeat受信でGap検出.svg?800 |図 6.1.11　HeartBeat受信でGap検出}}
+{{ :spec:jp:isv:図 6.1.11　HeartBeat受信でGap検出.svg?800 |図 6.1.11　HeartBeat受信でGap検出}}
 ;#;
 ** 図 6.1.11　HeartBeat受信でGap検出 **
@@ 行 432: / 行 432: @@
 (注意)Gap検出時にはTestRequestの応答としてのHeartBeat送信は行わない。
-{{ :draft:investorfix:図 6.1.12　TestRequest受信でGap検出.svg?800 |図 6.1.12　TestRequest受信でGap検出}}
+{{ :spec:jp:isv:図 6.1.12　TestRequest受信でGap検出.svg?800 |図 6.1.12　TestRequest受信でGap検出}}
 ;#;
 ** 図 6.1.12　TestRequest受信でGap検出 **
@@ 行 440: / 行 440: @@
 ResendRequest受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、投資家システムからの再送要求を処理した後に、ResendRequestを送信してメッセージの再送を要求する。
-{{ :draft:investorfix:図 6.1.13　ResendRequest受信でGap検出.svg?800 |図 6.1.13　esendRequest受信でGap検出}}
+{{ :spec:jp:isv:図 6.1.13　ResendRequest受信でGap検出.svg?800 |図 6.1.13　esendRequest受信でGap検出}}
 ;#;
 ** 図 6.1.13　ResendRequest受信でGap検出 **
@@ 行 448: / 行 448: @@
 SequenceReset-GapFill受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、まだGapFill処理中であったとしても、再度、投資家システムにResendRequestを送信してメッセージの再送を要求する。
-{{ :draft:investorfix:図 6.1.14　SequenceReset-GapFill受信でGap検出.svg?800 |図 6.1.14　SequenceReset-GapFill受信でGap検出}}
+{{ :spec:jp:isv:図 6.1.14　SequenceReset-GapFill受信でGap検出.svg?800 |図 6.1.14　SequenceReset-GapFill受信でGap検出}}
 ;#;
 ** 図 6.1.14　SequenceReset-GapFill受信でGap検出 **
@@ 行 456: / 行 456: @@
 Reject受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。
-{{ :draft:investorfix:図 6.1.15　Reject受信でGap検出.svg?800 |図 6.1.15　Reject受信でGap検出}}
+{{ :spec:jp:isv:図 6.1.15　Reject受信でGap検出.svg?800 |図 6.1.15　Reject受信でGap検出}}
 ;#;
 ** 図 6.1.15　Reject受信でGap検出 **\\
@@ 行 466: / 行 466: @@
 シーケンスGapを検出してResendRequestを送信した後で、すれ違いにApplication Messageを受信した場合、受信したApplication MessageにもシーケンスGapを検出して、再度ResendRequestを送信する。再送メッセージが再び消失することも考えられるため、CONNEQTORは、シーケンスGapを検出する都度、必ずResendRequestの送信を行う。
-{{ :draft:investorfix:図 6.1.16　ResendRequest（再送要求）とAplMessagesのすれ違い.svg?800 |図 6.1.16　ResendRequest（再送要求）とAplMessagesのすれ違い}}
+{{ :spec:jp:isv:図 6.1.16　ResendRequest（再送要求）とAplMessagesのすれ違い.svg?800 |図 6.1.16　ResendRequest（再送要求）とAplMessagesのすれ違い}}
 ;#;
 ** 図 6.1.16　ResendRequest（再送要求）とAplMessagesのすれ違い **
@@ 行 481: / 行 481: @@
 CONNEQTORの正常系メッセージの基本的なシーケンスを、以下の図 6.2.1に示す。
-{{ :draft:investorfix:図 6.2.1　RFQ送信から約定通知受信（正常系）のシーケンス.svg?600 |図 6.2.1　RFQ送信から約定通知受信（正常系）のシーケンス}}
+{{ :spec:jp:isv:図 6.2.1　RFQ送信から約定通知受信（正常系）のシーケンス.svg?600 |図 6.2.1　RFQ送信から約定通知受信（正常系）のシーケンス}}
   - 投資家システムはCONNEQTORにRFQを送信。
   - CONNEQTORは投資家システムにRFQ受付通知を送信。
@@ 行 494: / 行 494: @@
 RFQ送信で業務エラーとなった場合の基本的なシーケンスを、以下の図 6.2.2に示す。
-{{ :draft:investorfix:図 6.2.2　RFQ送信（業務エラー系）のシーケンス.svg?600 |図 6.2.2　RFQ送信（業務エラー系）のシーケンス}}
+{{ :spec:jp:isv:図 6.2.2　RFQ送信（業務エラー系）のシーケンス.svg?600 |図 6.2.2　RFQ送信（業務エラー系）のシーケンス}}
   - 投資家システムはCONNEQTORにRFQを送信。
   - CONNEQTORは投資家システムにRFQ受付拒否通知を送信。
@@ 行 504: / 行 504: @@
 RFQが取消等となった場合の基本的なシーケンスを、以下の図 6.2.3に示す。
-{{ :draft:investorfix:図 6.2.3　RFQが取消等となった場合のシーケンス.svg?600 |図 6.2.3　RFQが取消等となった場合のシーケンス}}
+{{ :spec:jp:isv:図 6.2.3　RFQが取消等となった場合のシーケンス_s.svg?600 |図 6.2.3　RFQが取消等となった場合のシーケンス}}
   - 投資家システムはCONNEQTORにRFQを送信。
   - CONNEQTORは投資家システムにRFQ受付通知を送信。
@@ 行 521: / 行 521: @@
 CONNEQTOR送信電文が、プロトコル不正（FIXプロトコル4.2(Errata)に準拠していない）により投資家システムで正常電文と認識されない場合のシーケンスを以下の図 6.3.1に示す。
-{{ :draft:investorfix:図 6.3.1　【電文不正時のシーケンス】.svg?600 |図 6.3.1　【電文不正時のシーケンス】}}
+{{ :spec:jp:isv:図 6.3.1　【電文不正時のシーケンス】.svg?600 |図 6.3.1　【電文不正時のシーケンス】}}
   - 投資家システムはCONNEQTORからの電文をFIXプロトコル不正と認識した場合、CONNEQTORへRejectを送信する。
   - 投資家は東証と連絡を取り、障害原因の調査を行う必要がある。
@@ 行 535: / 行 535: @@
 投資家システム送信電文が、プロトコル不正（FIXプロトコル4.2(Errata)に準拠していない）によりCONNEQTORで正常電文と認識されない場合のシーケンスを以下の図 6.3.2に示す。
-{{ :draft:investorfix:図 6.3.2　【電文不正時のシーケンス】.svg?600 |図 6.3.2　【電文不正時のシーケンス】}}
+{{ :spec:jp:isv:図 6.3.2　【電文不正時のシーケンス】.svg?600 |図 6.3.2　【電文不正時のシーケンス】}}
   - CONNEQTOR は投資家システムからの電文をFIXプロトコル不正と認識した場合、投資家システムにRejectを送信する。
   - 再度不正電文を受信した場合は、その都度投資家システムにRejectを送信する。
@@ 行 553: / 行 553: @@
 　CONNEQTOR送信電文が、データ不正（軽度エラー）により投資家システムで正常電文と認識されない場合のシーケンスを以下の図 6.3.3　【電文不正時のシーケンス】に示す。
-{{ :draft:investorfix:図 6.3.3　【電文不正時のシーケンス】.svg?600 |図 6.3.3　【電文不正時のシーケンス】}}
+{{ :spec:jp:isv:図 6.3.3　【電文不正時のシーケンス】.svg?600 |図 6.3.3　【電文不正時のシーケンス】}}
   - 投資家システムにて電文の内容に不正を検出した場合、CONNEQTORにLogout（要求）を送信しFIXセションの解放を行い、さらに東証と連絡を取り、障害原因の調査を行う必要がある。
   - 障害原因を取り除いたのち、投資家システムよりLogon（要求）をCONNEQTORに送信し、FIXセションの確立を行う。
@@ 行 566: / 行 566: @@
 CONNEQTORにて電文の内容に不正を検出した場合のシーケンスを以下の図 6.3.4に示す。
-{{ :draft:investorfix:図 6.3.4　【電文不正時のシーケンス】.svg?600 |図 6.3.4　【電文不正時のシーケンス】}}
+{{ :spec:jp:isv:図 6.3.4　【電文不正時のシーケンス】.svg?600 |図 6.3.4　【電文不正時のシーケンス】}}
   - CONEQTORにてデータ不正（軽度エラー）を検出した場合、投資家システムへエラー内容をReject (エラー）にセットし送信する。
   - 当該入力電文は無効となるが、FIXセションの解放は行わず、次の入力電文の処理は続行される。
@@ 行 592: / 行 592: @@
 一日の運用を以下の図7.1.1に示す。
-{{ :draft:investorfix:図7.1.1　【一日の運用】.svg?600 |図7.1.1　【一日の運用】}}
+{{ :spec:jp:isv:図7.1.1　【一日の運用】.svg?600 |図7.1.1　【一日の運用】}}
 一日の初回の Logon 時にシーケンス番号をリセットする。

CONNEQTOR

ユーザ用ツール

サイト用ツール

差分

ページ用ツール