0

QuickFIX/J以下のシナリオでの (FIX 4.2) の動作を明確にしたかったのです。このQuickFIX/J通信には、次の 2 つの関係者が関係しています。

  1. Iと呼ばれるクライアント イニシエーター。
  2. Aと呼ばれる当社のアクセプタープログラム。

Aにログオンすると、彼らは FIX メッセージを tag と交換します。接続が確立されると、注文の送信を開始します。しかし、私が予期せず接続を切断し、その時点でAがIのすべてのオープン注文に対してキャンセルを送信することを決定する可能性があります(これは有効です。なぜなら、Aは私が失敗した理由や、いつ生き返るかを知らないからです) 。35=A

この切断時のキャンセル手順全体は、Aのみによって開始および処理されることに注意してください。これは、 AのonLogout(...)メソッドから開始され、通常の注文管理メカニズムによって処理されます。I35=Fのオープン注文ごとに1 つのメッセージが生成され、キャンセルが成功するたびに( ) が生成されます。ExecutionReport35=8

私が生きて戻ってきたとき、以前の注文がすべてキャンセルされたことを認識できるように、これらのs を何らかの方法で私ExecutionReportに届ける必要があります。のメッセージ キューの実装は、アプリケーション レベルの支援なしでこれを処理するという印象を受けました。すべてのメッセージは、相手方 ( http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/169 )に確実に配信されます。QuickFIX/JQuickFIX

しかし、私の理解に反して、AのログにExecutionReports が表示されなかったり、再接続したときにsが配信されなかったりしたため、以前の注文がキャンセルされたことに気づきませんでした。inのメソッドの次のソース コードが原因で、ログが記録されないことに気付きました。QuickFIXsendRaw(Message message, int num)SessionQuickFIX/J

/**
 * Send the message
 *
 * @param message is the message to send
 * @param num is the seq num of the message to send, if 0, the next expected sender seqnum is used.
 * @return
 */
private boolean sendRaw(Message message, int num) {
    ...
        } else {
            try {
                application.toApp(message, sessionID);
            } catch (final DoNotSend e) {
                return false;
            } catch (final Throwable t) {
                logApplicationException("toApp()", t);
            }
            messageString = message.toString();
            if (isLoggedOn()) { // happens only if session is connected
                result = send(messageString); // logging happens within "send"
            }
        }
    ...
}

Iの切断ExecutionReportによって開始されたキャンセルのメッセージが生成されている間、セッションはログオンしていませんでした。同じ理由で、メッセージがキューに入れられなかったと思います（生き返ったときにメッセージを受信しないという事実に基づいています）。send(messageString);

QuickFIX/J私たちの会社は、すべてのメッセージが損失なく配信されることを保証するという信念に基づいて多くの実装を行いましたが、上記のシナリオに関する私の観察はそうではありません。

QuickFIX/Jセッションがログオンしていない場合、このシナリオで のメッセージ キューはどのように動作すると予想されますか? 関係なくメッセージをキューに入れ、セッションが将来再び利用可能になったときに送信されるのを待つべきですか、それともセッションがダウンしている間キューイングを停止するべきですか?

4

3 に答える 3

1

メソッドの最後に次のprivate boolean sendRaw(Message message, int num)コードがあります。

if (num == 0) {
    final int msgSeqNum = header.getInt(MsgSeqNum.FIELD);
    if (persistMessages) {
        state.set(msgSeqNum, messageString);
    }
    state.incrNextSenderMsgSeqNum();
}

セッションが接続されていない場合に、後で配信するためにメッセージを実際に保存するwillstate.set(msgSeqNum, messageString)呼び出し。messageStore.set(sequence, message)

私の知る限り、セッションが正常にログオンするまで、すべてのメッセージがキューに入れられます。

于 2016-01-31T22:49:32.410 に答える
0

これが私の 10 セントです。QF/J が、シーケンス番号に基づいて、アクティブなセッションのメッセージ配信を保証し、ギャップが満たされると...

セッションが失われた場合、何も保証する方法はありません。シーケンス番号の不一致が検出されたら、再接続時にギャップを埋めるようにイニシエーターとアクセプターを構成する必要があります。うーん、設定で ResetOnDisconnect フラグは何と言っていますか? ResetOnLogout はどうですか?

QF でセッションを待っているメッセージの「キュー」はないと思います。セッションがディスコされ、QF キューがいっぱいになり続けるか、永久にアクティブであったことを意味する再確認ができないためです。これは、QF ができることではありません。誰でも簡単に操作できます。

ディスコがある場合は、OnLogout を使用して実行レポートを切断されたクライアントに送信することもできません! まず第一に、OnLogout はすべてのディスコで常に呼び出されるわけではありません。第二に、QF の内部に入ると、メッセージを送信するセッションが見つからないため、除外されます。QF の内部キューがこの状況を処理するとは思えません。繰り返しますが、配信が保証されるのは、接続が確立されたときです...これは依存関係です。ただし、どこかに記録されることを期待しています。あなたのロギング設定は何ですか？

理由を確認する必要があると思います: 「/ が生き返ったとき、以前の注文がすべてキャンセルされたことを認識できるように、これらの ExecutionReports を / に何らかの方法で配信する必要があります。」ディスコではすべての注文がキャンセルされたものと見なされるというプロセスではないでしょうか。なぜ/その確認が必要なのですか? それは当然ですよね？これは、QF ベースとは別にコーディングする必要がある場合があります。

于 2016-01-14T12:44:54.580 に答える
0

これを読んでください。

一部の企業は、メッセージでタグ35002(切断時にキャンセル) をサポートしており、可能な値は次のとおりです。LOGON

  • 0:代金引換を使用しない
  • 1: 「正常な」ログアウトが送信された場合にのみ COD を使用する
  • 2: あらゆる「ネットワーク」切断で COD を使用する
  • 3: 1 と 2

取引先がこれをサポートしているかどうかを確認してください。QuickFIX のサポートは確認していませんが、タグを自分で手動で追加するか、FIX 辞書をカスタマイズしてタグをサポートすることができます。

どうやら、これは高頻度トレーダーによってよく使用されます。私はその業界に詳しくないので、コメントセクションで質問します。

于 2016-01-16T20:08:37.543 に答える