OrderSendAsync()関数 - ページ 3

[Yedelkin]

テクニカルメッセージ面白い発言を1つのトピックに集めること。

sergeev:

Yedelkin:
どの口座のプロパティが、実行キューの同時注文の制限を担当するのでしょうか？この数字をプログラムで調べることは可能でしょうか？

OrderSendAsync= false関数の 結果は、単に次のようになります。

つかいみちにしてください

[Mykola Demko]

Rosh:

スレッドを興味深く読み直し、実際にテストまでして、ここに自動売買の露骨な差別を発見しました。

以下は、マニュアルポジションのクローズに関する ログです（下から上に向かって分かりやすい時系列になっています）。

2012.04.26 22:32:05     Trades  '686934': deal #9256820 sell 0.02 EURUSD at 1.32391 done (based on order #10091825)
2012.04.26 22:32:05     Trades  '686934': order #10091825 sell 0.02 / 0.02 EURUSD at 1.32391 done
2012.04.26 22:32:05     Trades  '686934': accepted instant sell 0.02 EURUSD at 1.32391
2012.04.26 22:32:04     Trades  '686934': instant sell 0.02 EURUSD at 1.32391

ここでは、注文が送信され、注文が受け付けられ、注文にチケットが割り当てられ、最後に注文が実行される、という流れになっています（解釈のずれはあるかもしれませんが、だいたいこんな感じです）。すべてがクラシックです。

唯一の不思議な点は、取引イベントが、どのカテゴリーでトリガーされたか、またどの順番でトリガーされたか（最後の2つのカテゴリーについて）を（端末内で）確実に知っていることです。そうでなければ、このようなコメントを出力することは不可能で、プログラマーはこの情報を得るために車輪を再び発明しなければならないでしょう。そして、OrderSendAsync関 数の状況は、全くシンプルさを増していませんでした。

ただし、注文執行のスピードが上がっていることには注意が必要です。今は、キューに入れられたオーダーに気づく暇もなく、すでに実行されているのです。

---

つまり、注文のパックがあり、それぞれが理論上4つのTradeを持ち、それぞれのTradeでそれぞれの注文を制御する必要があります。

したがって、4*Number_Order*Number_Orderの コントロールポイントがあり、すなわち、10個のオーダーに対して400、100個のオーダーに対して40000となるのです。そして、万が一、取引数が4より少ない注文があった場合、2回目の注文を出す前に（1回目の注文が成立しなかった場合）、まさに4番で待機することになるので、制御ロジック全体が崩壊してしまうのです。

[Andrey Dik]

サーバーにトレードオーダーの スタックを送信しました。

各注文について、個別に実行チェックを行う必要がありますか？そして、いつまで返事を待てばいいのか。

[---]

joo:

各注文は別々にモニターする必要があるのでしょうか？

はい

また、回答はどのくらい待てばいいのでしょうか？

ブローカーによって異なる。STPであれば、むしろその流動性プロバイダーの問題である。

[Mykola Demko]

sergeev:

うん

証券会社によって同じ機能を持つわけではありません。STPであれば、流動性プロバイダーへの質問となります。

いや、全部コーヒーの粉で推測している。 手動で窓を開けると、買うを押して、リクオートか 約定を待って、OKを押して終わりです。

オートモードで開くと、基準点があるはずで、そこから2回目のリクエストを送らなければ、すべてOKになります。

上の投稿にSZSが追加されました、読み直してください。

[---]

Urain:

いや、手動でウィンドウを開いて、買いを押して、リクオートや約定を待って、OKを押したら終わりというのは、全部当てずっぽうなんですよ。

いいえ。これは、リターンコードがDONE(10009)の場合です。

しかし、あなたのトレードをプロバイダーに渡すブローカーがあります。そしてこの場合、すぐにPLACED(10008)と返されるのです。ちなみに、成行注文の場合、このレスポンスにはDealチケットはありません。オーダーチケットのみ です。

また、OrderSendAsyncの場合、注文のチケットすら存在しないでしょう。

オートモードでは、2回目のリクエストを送信する基準点がそうでなければ、すべてOKです。

さて、MT4でもリクオートの基準値はどうなっているのでしょうか？無限ループを作り、オーダーの削除やオープンを待つことはありません。

セーブ状態のチェックなど、すべてがカチカチです。

[Yedelkin]

OrderSendAsync()関数を実行してみました。

//+------------------------------------------------------------------+
//|                                               OrderSendAsync.mq5 |
//+------------------------------------------------------------------+
MqlTradeResult  res={0};
MqlTradeRequest req={0};
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   req.action=TRADE_ACTION_PENDING;
   req.symbol=_Symbol;
   req.volume=1.0;
   req.price=3.0;
   req.type=ORDER_TYPE_BUY_STOP;
   req.type_filling=ORDER_FILLING_RETURN;
   switch(OrderSendAsync(req,res))
     {
      case  true:
         Print("retcode=",res.retcode,", order=",res.order,", deal=",res.deal);
         break;
      default: Print("Неудача при отправке запроса функцией OrderSendAsync()");
     }
  }

で応えた。

2012.05.02 21:12:33 OrderSendAsync (USDCHF,M1) retcode=10008, order=0, deal=0

簡単な質問があります。OrderSendAsync()関数を使って取引要求が 送信されたとき、注文チケットも分からないのに、どうやってその 運命を追跡するつもりですか？コメントは仲介業者が記入する必要があります。

[Renat Fatkhullin]

非同期モードは、一括して注文を入力するために設計されていますが、単一のトランザクションのためには設計されていません。単一のトランザクションでは、同期モードを使用する方がよいでしょう - すべてが同じ速度で実行され、完全なサービスを受けることができます。

OnTradeの非同期トランザクションの実行を追跡します。確かにこれはより複雑な道ですが、それが非同期の代償なのです。

[Yedelkin]

Renat:
非同期モードは、一括して注文を入力するために設計されていますが、単一のトランザクションのためには設計されていません。単一のトランザクションでは、同期モードを使用する方がよいでしょう - すべてが同じ速度で、フルサービスで実行されます。

OnTradeの非同期トランザクションの実行を追跡します。確かに、より複雑な方法ですが、それが非同期の代償なのです。

大量の注文を一括送信する際に、500件の取引依頼の 行方をどのように追跡するのでしょうか？大量の注文を一括して送る場合、多くの単発の取引で構成されるため、履歴の前と現在の状態を比較するという原則を皆が使うのでしょうか。他に方法はないのでしょうか？

[Renat Fatkhullin]

理解の根底にあるのは、非同期処理で
1) 応答の適時性または可用性を保証するものではありません。
2) 開発者による個別の操作待ち行列を明確に要求する。

つまり、注文のリストを生成し、OnTradeの中でチェックし充填する必要があるのです。もちろん、これは堪え難いことです。

私たちとしては、非同期キューを透過的に維持し、そこに答えを入れ、キューから処理されたエントリーをチェックしたり取り出したりする便利な関数をトレーダーに提供することができます。OnTradeで非同期に、または注文のバッチを送信した直後にループ内でポーリングすることで同期的にキューを確認することができます。

EA開発者のルーティンワークから解放されることで、開発者の生活が楽になる。