OrderSendAsync()関数 - ページ 2

[Yedelkin]

hrenfx:

明確にする必要がある。

OrderSendのTRADE_RETCODE_PLACEDがサーバーレスポンスです。

OrderSendAsync の TRADE_RETCODE_PLACED が端末応答となる。

同じコードでありながら、その意味はまったく異なる。開発者はこの曖昧さを修正する可能性が高いです。

だからこそ、理解すべきなのです。

は、適切な文脈で理解されなければならない。

それでは、OrderSend 関数を使用して取引要求を送信 する場合、サーバーはどのような条件で TRADE_RETCODE_PLACED コードを返さなければならないのか、説明してください。なぜなら、OrderSendAsync関数のコメントとRocheの回答によると、このまさにTRADE_RETCODE_PLACEDコードは、端末からサーバーへのリクエスト送信が成功したことだけを示しているからです。つまり、リクエストがサーバーに届き、その処理/チェックが始まるとすぐに、サーバーは「処理結果に基づいて」他の「本当の」サーバーコードを生成しなければならないことがわかります。では、なぜサーバー（つまりサーバ）がTRADE_RETCODE_PLACEDコードを返さなければならないのか、このコードがリクエストのライフタイム段階を指すのであれば、リクエストがサーバに現れる前なのか、よく理解できないのです。それとも、TRADE_RETCODE_PLACEDコードは、OrderSend機能に関連して、他の意味を持つのでしょうか？

[hrenfx]

OrderSend は、サーバーと端末の両方から応答を受け取ることができます (端末のフィルタリングが失敗した場合)。

OrderSendAsyncは、常に端末からの応答のみを受信します。サーバーからの応答を受け取るには、onTradeで適切なイベントをキャッチする必要があります。

[Yedelkin]

hrenfx:

OrderSend は、サーバーと端末の両方から応答を受け取ることができます (端末のフィルタリングが失敗した場合)。

次のような考え方は正しいでしょうか。

端末はOrderSendからの要求を確認し、サーバへの送信に成功し、retcodeは中間値であるTRADE_RETCODE_PLACEDを受信している。この時点で接続は中断され、OrderSendが 返すことができるのは、retcodeフィールドに貼り付けられたTRADE_RETCODE_PLACEDコードだけですか？これはOrderSendがTRADE_RETCODE_PLACEDを返す例になるのでしょうか？

[hrenfx]

Yedelkin:

次のような考え方は正しかったのでしょうか。

端末はOrderSendからの要求を確認し、サーバへの送信に成功し、retcodeは中間値TRADE_RETCODE_PLACEDを受信している。この時点で接続は中断され、OrderSendが 返すことができるのは、retcodeフィールドに貼り付けられたTRADE_RETCODE_PLACEDコードだけですか？OrderSendがTRADE_RETCODE_PLACEDを返すと、その例になるのでしょうか？

そうかもしれませんが、どうでしょう。このような通信の途絶に対しては、TimeOut-timeを介してTRADE_RECODE_TIMEOUTとなる可能性が高いです。

正直、OrderSendの場合、何のためのナーフなのか理解できません。おそらく、開発者がヘルプでもっと説明してくれるでしょう。

P.S. 私はMQL5で一行も書いていません。したがって、私の考えはすべて無視していただいて結構です。

[Yedelkin]

...それでも、それはナンセンスだ。Client Terminal User Guide (January 2012) によると、注文段階の1つとして「set(placed) - dealer accepted order」段階があるとのことです。

つまり、マニュアルによると、注文はすでにサーバーに正常に到達しているときに、取引要求のライフステージを通知しているのです。また、OrderSendAsync()関数の 説明には、全く逆のことが書かれています。TRADE_RETCODE_PLACEDコードは、サーバーへの到着に依存しないのだそうです。

[Yedelkin]

hrenfx:

正直なところ、OrderSendの場合、このオタクさが必要なのかがわからない。

個人的には、自分の時代に「リターンコード処理」が必要というのがよかったです。しかし、そのような処理を正しく書くためには、それがどのようなものであるかを知らなければならない。TRADE_RETCODE_PLACEDの コードが一体何に関連しているのか、長い間理解しようとしてきました。

[hrenfx]

一般に、OrderSendAsyncを介して、誰でもMyOrderSendを連発することができます。

1. OrderSendAsyncを呼び出した。
2. onTradeでサーバーからの適切なレスポンスを待ちます。
3. この応答でMyOrderSendを終了しました。

この実装により、MyOrderSend は通常の OrderSend と完全に同一になる（通常のライブラリで OrderSendAsync を介して実装することにより、単純に API から排除することができる）。

[Yedelkin]

hrenfx:

この実装により、MyOrderSend は通常の OrderSend と完全に同一になる（通常のライブラリで OrderSendAsync を実装することにより、API から単純に排除することができる）。

自己啓発のための面白いアイデアです。しかし、onTrade がパラメータ化されていない限り、スタッフ ライブラリで onTrade を使用するチェックは、おそらくOrderSend 関数 自体よりもはるかに遅くなります。間違っているかもしれません。

[hrenfx]

一般に、OrderSendAsync 入力はMetatraderの歴史的なイベントである。取引APIが存在している間（Metatrader3から（それ以前のものは見ていない））、ずっとメタトレーダーは、独自の言語で実装されているとはいえ、その本質はほとんど変わっていないのです。OrderSendAsyncは、Metaquotesの取引APIに対する最初の実質的な変更です。

今回の開発者の方々に心からお祝いを申し上げるとともに、非同期モデルが十分な機能を発揮することを祈念します

[Yedelkin]

テクニカルメッセージ面白い発言を1つのスレッドに集める。

Renat:

なお、1つの口座から同時に執行できる注文 数には制限があり、今後も制限を設ける予定です。今、私の記憶違いでなければ、16件の応募があります。

非同期オペレーションは、「許容オーダー数のウィンドウ」に注意して動作し、前のバッチの一部が実行されるのを待ってから次のバッチを送信します。さらに、バカ／テストフラッディングに対するプロテクションも用意される。これまでは、許可するアプリケーションの数がオーバーフローするとエラーになりました。

OrderSendAsyncによる新しい非同期操作の方法は、主な問題を解決します - それは即座に12の操作を行うことができます。これは非常に強力なツールであり、サーバーやブローカーによるBANの可能性を常に視野に入れ、慎重に使用する必要があります。