問題タブ [quickfix]

LOGON メッセージを受信した後にいくつかの操作を実行し、LOGON が失敗したかどうかを判断したい (たとえば、ユーザー名とパスワードを確認する) が... LOGON メッセージを受信した直後に QuickFIX/J が再送信される:

この機能を無効にする方法は?

2 番目の質問です。LOGON が失敗した場合、LOGOUT メッセージなどを再送信する必要がありますか?

バックエンドが完全にC++であるトレーディングアプリケーションを作成しています（QuickFixエンジンを使用）。このバックエンドの上にDjangoでWebアプリケーションを構築し、ユーザーが注文できるようにします。Django（python）とC ++アプリケーションはどちらも、独自のプロセスとアドレス空間で実行されます。注文/メッセージをDjangoからC++に渡すのに最適なアイデアは何だと思いますか？

また、これは取引アプリケーションであるため、遅延が最大の懸念事項です。そのため、Djangoからデータベースに注文してから、C++アプリケーションからフェッチする必要はありません。

私は現在、共有メモリまたは他のIPCメカニズムを介してそれを行うことを検討しています。これは良い考えですか？

FIXプロトコル（QuickFix for C ++）を使用して取引アプリケーションを作成しようとしています。コンピューターには6枚のNICカードが構成されています。FIXアプリケーション（この場合はイニシエーターとして機能）に、使用可能な6つすべてのうちの1つの特定のNICカード（IPアドレス）を使用させるにはどうすればよいですか？イニシエーター設定では、ソースIP /ポートではなく、ターゲットホスト/ポートのみを設定できます。

また、同じアプリケーション内で2枚以上のNICカードを同時に（負荷分散の目的で）使用できるようにするにはどうすればよいですか？

ありがとうございました

QuickFix (C#) を使用して Fix イニシエーターを作成しています。ユーザー名とパスワードを使用して FXCM サーバーにログオンしようとしています。しかし、私の onLogon メソッドは決してトリガーされません。SocketInitior が開始されると、onCreate メソッドが実行され、次に onLogout メソッドが呼び出されます。onCreate メソッドの後、onLogon メソッドが実行されているはずですが、実行されていません。したがって、initiator.isLoggedOn() メソッドは常に false を返します。どうすれば正常にログオンできますか?

私の QuickFix.Application インターフェイス実装アプリケーションは次のとおりです。

イニシエーター.start(); の後 onLogon メソッドが実行されていません。

主なプログラムは次のとおりです。

次のコードを使用して、価格ストリームを購読しようとしています。

生成される FIX メッセージは次のとおりです。

8=FIX.4.2 9=140 35=V 34=2 49=SENDER_COMP_ID 52=20110909-15:44:02.855 56=TARGET_COMP_ID 55=EUR/USD 146=1 262=634511906383686907 263=1 264=1 265 =N 267=2 269=1 10=079

タグ 146 の直後に 55 が来るように、タグの順序を変更する必要がありますsetField。別の順序で呼び出してみましたが、毎回同じ結果が得られます。

メッセージタグの順序を処理する正しい方法は何ですか?

編集 - 問題は解決しました:

DumbCoder の提案に従い、addGroup代わりに を使用してメッセージを作成しましたsetField。次のコードサンプルも役に立ちました: http://forexforums.dailyfx.com/fix-api-support/411090-fix-api-example.html

注: このサンプルは Java で作成されており、QF44 を対象としています。

私は眠れぬ夜を過ごし、quickfix_net.dll と quickfix_net_messages.dll の 64 ビット バージョンを持つQUICKFIXを構築しようとしました。

私の C# フレームワークは 64 ビットで、通常提供されている QUICKFIX dll は 32 ビットなので、他に選択肢はありません (アプリを 32 ビットに戻すことはオプションではありません)。

VS_10 ソリューションがすぐにビルドされることを期待していましたが (かわいそうな素朴なバニー...)、多くの #include "xxxxxx.h" ステートメントで、多数の未検出のライブラリ エラー (ソース ファイル "xxxxxx.h" を開けません) があります。私が試した 2 つのプロジェクト ソースでこの動作が発生しました。私はどちらかというと .net 派で、自分でこれを修正できなかったので困惑しています。

元のプロジェクト ソースはここからダウンロードでき、私が最も興味を持っている 64 ビット フォークはここ
にあります。quickfix_vs10.sln を開いてクリーン コンパイルを行っていただける方がいらっしゃいましたら、少なくとも 2 時間はお時間をいただけると思います。仕事に戻る前に会社の地下室で寝ます。

編集 ：

詳細なエラー:

• 認識できない #include "quickfix/foo" がたくさんあります > 全体のソリューションからすべての "quickfix/" プレフィックスを削除する必要があります
• 'FIX' : クラスまたは名前空間の名前ではありません (特に FieldMap.h 内)
• 型指定子がありません - int と見なされます。注: C++ は default-int -'QuickFix::FieldNotFound __gc &' をサポートしていません: 値または参照によって管理対象オブジェクトをスローまたはキャッチできません

私は何百ものそれぞれを持っています... :(

EDIT : EFFICIENT ANSWER

REAL .Net FIX エンジンが必要な場合は、VERSAFIXまたはQUICKFIX/Nを選択することをお勧めします。 どちらもネイティブ .Net およびオープン ソースであるため、x64 dll (または必要に応じて x86) としてコンパイルできます。

• QUICKFIX/N が登場したばかりで、非常に有望です。投稿から数か月後に出てきたのは残念です:(
  
• VERSAFIXの時点で、私の会社はそれを6か月間使用しており、これまでのところかなり満足しています. (プロジェクトの開始者であるラス・カリーは、技術的に堅実で反応が良いです。)

MarketDataIncrementalRefresh から次の値を取得するにはどうすればよいですか?

• シンボル/楽器
• オファー
• 入札
• オファーサイズ
• 入札サイズ

Quoteたとえば、次のようなメッセージ処理に精通しています。

で同じアプローチを試みましたMarketDataIncrementalRefreshが、そのようなメソッドはなく、フィールドが存在してもisSetField常に戻ります。false

MarketDataIncrementalRefreshメッセージの例:

8 = fix.4.29 = 22535 = x34 = 349 = abc52 = 20110928-12：47：53.31656 = Targetcompid262 = 634528216663837491268 = 2279 = 0269 = 0278 = 1555 = 15555 = 10012715151515151515555 = 15555555555555555555555555555555555555555555555555555555555555555555555 255=豪ドル/カナダドル270=1.0130715=豪ドル271=1000000346=110=094

FIX アプリケーションを構築するために、quickfixengine を使用しています。quickfix にはドキュメントがほとんどなく、まるでブラックホールのようです。タイプである変数がありますFIX::Account。FIX 文字列型であることはわかっていますが、文字列を取得するにはどうすればよいですか (c-string にする)。このようなことを試しましたが、コンパイルに合格しません。

コンパイラ エラー: 'class FIX::Account' には 'c_str' という名前のメンバーがありません</p>

基本的に、すべての FIX タイプのコンストラクター、インターフェースを知る方法を知りたいですか? これらを含むファイルはどれですか？

ありがとうございました

私の QuickFIX クライアントは毎日ログイン前にログアウトを送信しています。ログイン前にこのログアウトメッセージを送信しないことは可能ですか...?

以下は、私が現在使用している設定です。

..そして、以下は私が毎日受け取るログメッセージです:

に加入した後MarketDataRequest、しばらく見積もりを受け取ることができます。しかし、1 時間ほど経つと、価格の流れは下がります。この問題に対するブローカー サポートの対応は次のとおりです。

クライアントの TCP バッファーがいっぱいであるために更新をクライアントにプッシュできなかったため、クライアントを切断しました。これは、ネットワーク ドロップまたはアプリケーションが側で消費を停止し、受信バッファーがいっぱいになり、TCP ack の送信を停止したことが原因である可能性があります。

QuickFix で TCP バッファを解放するにはどうすればよいですか?

(QuickFix.NET v4.2 を使用)