OrderSendAsync()関数 - ページ 5

[Denis Kirichenko]

Urain:

もし、あなたの提案が既存の機能を補完するだけであれば、何もしません。そうでなければ、単純なMqlPacketTradeRequestの構造がどのようなものなのか、明確ではありません。

...MqlPacketTradeRequest構造がMqlTradeRequest構造の 動的配列の構造である場合、単純なクエリー構造で溢れたサーバーのロジック全体を破壊する可能性があります。

そうでなければ、端末レベルでこのパケットを別々のリクエストに分割しなければならず、この過負荷を導入した意味がなくなってしまうからです。

非同期構造だからこそ、このようなバリエーションに「合意」したようです。

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   );

どこで

packet_requestには、MqlTradeRequest 構造体の配列などが含まれます...

そうすると、これらの考えはすべて議論の素材になりますね :-)

[Yedelkin]

Urain:

IMHOでは、同じアプリケーションのバッチが必要なのはデモンストレーションのためだけで、仕事では異なるシンボル、異なるボリューム、そしてもちろん異なる方向のアプリケーションが使用されることになります。そのため、それぞれのレジェストを個別にチェックする必要があり、一括して 送る意味がありません。

まあ、ここは選ぶしかないでしょう。の1回限りの チェックで 500要素のプリフィル配列request[]を一度に 送信する関数OrderSendPacketAsync(MqTradeRequest& request[], MqlPacketTradeResult& packet_result) の開始を1回だけ行いました。のリターンコード10008を確認 しながら500回 OrderSendAsync()関 数を起動する。

[Yedelkin]

Urain:

...MqlPacketTradeRequest構造がMqlTradeRequest構造の 動的配列の構造である場合、単純なクエリー構造のために設計されたサーバーのロジック全体を壊すことができます。

動的配列を使用した取引要求が、どうして「サーバーのロジックを壊す」ことになるのでしょうか？ある型の構造体の変数を処理するブロックがあったとして、同じ型の配列の各要素にこのブロックを適用することを妨げるものは何でしょうか？同様に、最近のサーバが「単純なクエリ構造」である場合、OrderSendPacketAsync()関数によって送られた動的配列をサーバが受け取るとき、その配列の各要素に「単純なクエリ構造」ブロックを順番に適用できるようなループを追加することを妨げるものはないでしょう。

[Yedelkin]

papaklass:

私見ですが、OrderSendAsync()関数は注文送信のループを作るのではなく、パラメトリックにするべきだと思います。例えば OrderSendAsync(Symbol(), number, direction)のように。パラメータとして、-シンボル、-注文 数、-注文の方向（買い、売り）。

これは、動的配列とOrderSendPacketAsync() 関数を使用した大量取引要求の送信で、動的配列の各要素で 'symbol' と 'type' フィールドが同じである場合の特殊なケースと同様です。

[Yedelkin]

非同期取引では、特定のリクエストがどのように発生したかを正確に知ることはできません。特に、非同期リクエストの1つが部分的に実行されたときに、どれだけのボリュームが未完成であったかは分からない。

FX取引でも株式取引でも、履歴プロパティからの注文は、正しく理解されているか教えてください。

オーダーボリューム・カレント

未充填量

は、非同期リクエストがどの程度完全に実行されたかを明確に判断することができるのでしょうか？すなわち、外為市場で非同期的に送信された成行注文が履歴に表示されたとき、ORDER_VOLUME_CURRENT=0.0であれば、その注文は完全に執行されたと確信できるが、ORDER_VOLUME_CURRENTに0以外の値が含まれていれば、その値はその外為市場注文に対する未達成量として見なさ れるということでしょうか。

質問のきっかけは、ここhttps://www.mql5.com/ru/forum/3775/page28#comment_84851、ORDER_VOLUME_CURRENT プロパティが株式市場で使われる注文を指して いると強調されていることです。

[Yedelkin]

履歴に表示される非同期リクエストに関する質問です。

OrderSendAsync() が true を返し、result.retcode フィールドに 10008 が含まれる場合、Reference によると「リクエストが送信されたことを意味しますが、取引サーバーに届いたことを保証するものではありません」となっています。

質問：端末からの非同期リクエスト送信が成功したが、サーバーに届かなかった場合、そのようなリクエストは常に履歴に残るのでしょうか？つまり、非同期リクエストのサーバーへの送信が成功しても、それに関する情報が履歴に残らないということが起こりうるのでしょうか？このシナリオが可能であるとすれば、どのような条件下で？

[Renat Fatkhullin]

Yedelkin:

質問：端末からの非同期リクエストは成功したが、サーバーに届かなかった場合、そのようなリクエストの情報は常に履歴に残るのでしょうか？つまり、非同期リクエストは（すべての点で）正常にサーバーに送信されたのに、そのリクエストに関する情報が履歴に残らないということが起こりうるのでしょうか？このシナリオが可能であるとすれば、どのような条件下で？

リクエストがサーバーに届かなければ、クライアント端末に表示されるチャンスはない。

[Yedelkin]

Renat:
リクエストがサーバーに届かなければ、クライアント端末に表示されるチャンスはない。

おっと!正常に送信された非同期リクエストは、簡単に履歴に表示されなくなることが判明しました。

[---]

Yedelkin:
おっと!正常に送信された非同期リクエストは、簡単に履歴に残らないことが判明したのです。

いいえ。

[Renat Fatkhullin]

Yedelkin:
正常に送信された 非同期リクエストは、簡単に履歴に残らないことが判明したのです。

重要なのは、非同期リクエストには実質的に「送信成功」というステータスがないということです。

この機能が正常に終了すると、「クライアントから見て注文が正しく、ネットワークパイプに投げ込まれたので、OnTradeで回答を待ってください」というだけの意味となります。