問題タブ [quickfixj]

ソケット フラッシュ動作に関連していると思われる発信メッセージにかなりの遅延がある問題を解決しようとしています。私は、quickfixj イニシエーターからアクセプターへの発信 FIX メッセージのパケット キャプチャを行ってきました。

環境を要約すると、Java イニシエーターは、別のサーバー上のサーバー ソケットへのソケット接続を確立します。どちらのサーバーも Redhat Enterprise Linux 5.10 を実行しています。インターフェイスの netstat からの MSS は 0 です。NIC の MTU はすべて 1500 です (ループバック インターフェイスでは無限だと思います)。アプリケーション側では、メッセージは quickfixj によってバイト配列にエンコードされ、ソケットに書き込まれます。ソケットは、TCP_NODELAY を有効にして構成されています。

ループバック インターフェイスを使用してイニシエーターと同じサーバーでアクセプター (ServerSocket) を実行すると、送信側のレイテンシーがないため、レイテンシーの原因としてアプリケーションを排除できるとほぼ確信しています。これは、ループバック インターフェイスを使用したパケット キャプチャ エントリの例です。

主な関心事は、1/ パケット長 (ここでは最大で 2851) にもかかわらず、各パケットに PUSH フラグが設定されていることです。2/ ここで測定しているレイテンシの尺度は、メッセージがエンコードされる前に設定された「送信時間」と、パケット キャプチャ時間の「時間」です。パケット キャプチャは、データを送信しているイニシエーターと同じサーバーで実行されています。10,000 パケットのパケット キャプチャの場合、ループバックを使用する場合、「SendingTime」と「Time」の間に大きな違いはありません。このため、送信遅延の原因であるアプリケーションを排除できると思います。

アクセプターが LAN 上の別のサーバーに移動すると、MTU サイズを超えるパケットの送信遅延が悪化し始めます。これは、キャプチャのスニペットです。

ここで重要なことは、パケットが MSS (MTU から派生) よりも小さい場合、PUSH フラグが設定され、送信者の遅延がないことです。Nagle のアルゴリズムを無効にすると、これらの小さなパケットに PUSH が設定されるため、これは予想されることです。パケット サイズが MSS (この場合は 1514 のパケット サイズ) よりも大きい場合、パケットがキャプチャされた時間と SendingTime の差は 35 ミリ秒に跳ね上がります。

大きなパケット サイズのメッセージがループバック インターフェイスで 1 ミリ秒未満で送信されたため、この 35 ミリ秒の遅延がメッセージをエンコードするアプリケーションによって引き起こされた可能性は低いと思われます。キャプチャは送信側でも行われるため、MTU セグメンテーションも原因ではないようです。最も可能性の高い理由は、PUSH フラグが設定されていないため (パケットが MSS よりも大きいため)、OS レベルのソケットおよび/または TCP スタックが 35ms 後までフラッシュすることを決定していないことです。他のサーバーのテスト アクセプターは低速なコンシューマーではなく、同じ LAN 上にあるため、ACK はタイムリーです。

> MSSパケットの遅延を送信するこのソケットの原因について、誰かが何かポインタを与えることができますか? 米国の実際の取引相手に対して、この送信者の遅延は 300 ミリ秒にも達します。パケット サイズが MSS より大きい場合、以前の ACKS に関係なくすぐに送信されると思いました (ソケット バッファー サイズを超えない限り)。通常、Netstat は 0 のソケット q と風サイズを示し、起動時からでも、すべての > MSS パケットで問題が発生するようです。これは、ソケットが何らかの理由ですぐにフラッシュしないことを決定しているように見えますが、どのような要因がそれを引き起こす可能性があるかは不明です.

編集: EJP で指摘されているように、Linux にはフラッシュがありません。私が理解しているように、ソケット送信はデータをLinuxカーネルのネットワークバッファに入れます。そして、これらの非プッシュ パケットの場合、カーネルは前のパケットからの ack を待ってから配信しているようです。これは私が期待するものではありません.TCPでは、ソケットバッファがいっぱいになるまでパケットが配信されることを期待しています。

明示的なログアウトが送信されたセッションで、quickfixj は再接続を試みますか。

私はそれについて尋ねたところ、そうではないと言われましたが、確認したい.

このような場合、再接続するにはどうすればよいですか? 考えられるすべての解決策を歓迎します。

session.logoutと の違いを理解するのを手伝ってくれませんかsession.generateLogout。

ログアウト メッセージを明示的に作成して送信することもできます。それは他の2つとどう違うのですか？

私は FIX に比較的慣れていないため、接続を試みるのはこれが初めてです。QuickFixJ ライブラリを使用して、提供された UAT 環境に接続しようとしています。具体的には、quickfixj-all-1.6.0.jar を使用しています

ここからサンプル コードを実装しましたsocketAcceptor.start()。

完全なコード サンプルは次のとおりです。

私が得ているエラーは

「SenderCompID->TargetCompID」変数が提供されていますが、ここのサンプルからは削除されています。

quickfix.mina.message.FIXProtocolCodecFactory.addMessageDecoder(Ljava/lang/Class;)V socketAcceptor.start メソッド内でスローされます。FIX UAT環境を指すように構成例を変更しただけなので、これの原因はわかりません

jar に含まれるメソッドがこのエラーをスローする理由がわかりません。この段階でメッセージを送信しようとしているのではなく、接続を開こうとしているだけです。この例は、他の人にとってはうまくいったようです。

ここにあるFIXクライアントの例を使用してもまったく同じエラーが発生します

文字セットを変更するか追加する必要があります

そのため、メイン関数に上記を追加しましたが、quickfixj ログに改行が表示されません。何か案は？

quickFIXJ を再構築せずにこのエラーを処理する方法はありますか?

quickfix/j との接続を確立しようとしていますが、会社のファイアウォールの背後にあります。したがって、プロキシ経由でアクセプターに接続する必要があります。新しいバージョン 1.6.0 でプロキシのサポートが追加されたことをインターネットで見ましたが、その方法についての説明は見つかりませんでした。イニシエータからプロキシを使用してサーバー (アクセプタ) への接続を確立する方法を誰か説明してもらえますか?

ありがとうございました