SL/TP注文の受付 - ページ 7 12345678 新しいコメント fxsaber 2022.01.11 08:53 #61 fxsaber 取引リスク やEAロジックの観点からどの程度致命的であるかは、一概には言えません。明確に言えることは、「サーバーが注文を失う」というバグは存在するということです。 ZZY 上記の負け注文については、すでに以前の記事で説明しましたが、今回は以下のものを追加したいと思います。オープンポジションのテイクポイントに到達した。サーバーは対応するTP-market注文を生成し、端末に配信しました（Expert Advisorはそれを見ています）。すると、このTP-marketの注文は、Terminalからだけでなく、Serverからも消えてしまったのです。 建築的にはこんな感じです。 価格がTakeOpenポジションのレベルに達したとき。 サーバーはテイクオーダーをトリガーとして、テイクオーダーのチケットが作成され、その情報がターミナルから利用可能になります。 注文」が引用符で囲まれているのは、これがサーバーにとって不完全な注文であり、その正しさのチェックをパスしなければならないからである。 注文」がチェックをパスしない場合（Terminal の OrderCheck として）、ゲートウェイに送信されない、つまり、有効な注文のステータスを取得しない。その場合、取引履歴には入りません。 例えば、すでに決済状態にあるオープンポジションのTPトリガーがあった場合、チェックは失敗する可能性があります。 このように、現在のフルオーダー（チェックを通過し、取引履歴に残る（拒否された場合も））とファントム・オーダー（チェックを通過せず、取引履歴に残らない）を端末で確認することができるのです。2人とも自分のチケットを持つことになる。理論的には、ファントムオーダーは同じチケットを持つことができます。 この方式は、MT5サーバーの非同期アーキテクチャに起因して設計されています。TerminalのOrderSendAsyncのロジックに多少似ています。サーバーが正しくファントムオーダーの情報を端末に送信しているかどうかを確認するまでは何とも言えません。 fxsaber 2022.04.30 06:03 #62 TPを搭載。 Формирование очередей исполнения торговых ордеров в MT5. www.mql5.com При анализе истории торгов обратил вниманием на интересную деталь влияния TP открытых позиций на исполнение лимитных ордеров. Переворот. Для подтверждения сделанной гипотезы был написан такой скрипт A100 2022.04.30 09:29 #63 fxsaber #:TP機能。 技術的には、ここに矛盾はない。この例のTPは指値注文より早く設定されています - だから早く執行されるのです。TPはЖで奇妙な方法で実行される-それは別の問題である もし、最初にポジションを建ててからTP注文を出し、その後TPするだけなら-結果は同じですが-、考えることはたくさんありますね。 fxsaber 2022.04.30 10:15 #64 A100 #:技術的には、ここに矛盾はない。この例のTPは指値注文より早く設定されています - だから早く執行されるのです。しかし、TPが変な形で 実行されてしまう......それはまた別の問題です。もし、最初にポジションを持ち、次にリミットオーダーを出し、TPだけを行うとしたら、結果は同じでしょう--。 この例は、説明のためのものです。結論は、例のごとくではありません。 A100 2022.04.30 19:25 #65 fxsaber #:この例は、説明のためのものです。結論は、例のごとくではありません。 つまり、他の条件がすべて同じであれば、TPがその前の指値注文よりも早く執行されるのは正常ではない、ということが明らかな例を作ってください。 fxsaber 2022.04.30 22:55 #66 A100 #:つまり、他の条件がすべて同じであれば、TPがその前のLimit注文よりも早く実行されるのは正常ではない、ということが明らかです。 証拠はいらない。MQはその仕組みを知っている。 A100 2022.05.01 00:07 #67 fxsaber #:証拠はいらない。MQが意識しているのは、自分たちのためにどうするかということです。 詳細を把握しているのか疑問です。数ページにわたって エラーはないと主張 され（当時はまだ慣例だった）、その後（さらに数ページ後に）何かが間違っていると認められ、調査 することになったことを覚えています。 そして、具体的で明確な例がないのであれば、（今日の現実では）結果的に調べる理由がないことになります。 fxsaber 2022.05.01 06:34 #68 A100 #:そして、具体的で明確な例がないのであれば、（今日の現実では）結果的に調べる理由がないことになるのです。 事例があっても、それに対処する理由があるとは限りません。MQは単に問題に気づかないか、関係ないと思われている。 A100 2022.05.02 08:06 #69 fxsaber #:事例が あれば必ず問題が発生するわけではありません。MQは単に問題に気づかないか、関係ないと思われている。 重要な問題とは、以下の場合のみです。TPが執行されず（価格が消えて時間がない）、その結果リミットも執行されない。 Andrey Khatimlianskii 2022.05.02 09:49 #70 ちなみに、そうですね、面白いです。小さなリミッターが巨大なポジションのTPと同レベルで、そのTPが大きいからとリダイレクトされたら、リミッターは埋めるチャンスすらないのでは？ これなら操作できそうですね。 12345678 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ZZY 上記の負け注文については、すでに以前の記事で説明しましたが、今回は以下のものを追加したいと思います。オープンポジションのテイクポイントに到達した。サーバーは対応するTP-market注文を生成し、端末に配信しました（Expert Advisorはそれを見ています）。すると、このTP-marketの注文は、Terminalからだけでなく、Serverからも消えてしまったのです。
建築的にはこんな感じです。
例えば、すでに決済状態にあるオープンポジションのTPトリガーがあった場合、チェックは失敗する可能性があります。
このように、現在のフルオーダー（チェックを通過し、取引履歴に残る（拒否された場合も））とファントム・オーダー（チェックを通過せず、取引履歴に残らない）を端末で確認することができるのです。2人とも自分のチケットを持つことになる。理論的には、ファントムオーダーは同じチケットを持つことができます。
この方式は、MT5サーバーの非同期アーキテクチャに起因して設計されています。TerminalのOrderSendAsyncのロジックに多少似ています。サーバーが正しくファントムオーダーの情報を端末に送信しているかどうかを確認するまでは何とも言えません。
TPを搭載。
TP機能。
技術的には、ここに矛盾はない。この例のTPは指値注文より早く設定されています - だから早く執行されるのです。TPはЖで奇妙な方法で実行される-それは別の問題である
もし、最初にポジションを建ててからTP注文を出し、その後TPするだけなら-結果は同じですが-、考えることはたくさんありますね。
技術的には、ここに矛盾はない。この例のTPは指値注文より早く設定されています - だから早く執行されるのです。しかし、TPが変な形で 実行されてしまう......それはまた別の問題です。
もし、最初にポジションを持ち、次にリミットオーダーを出し、TPだけを行うとしたら、結果は同じでしょう--。
この例は、説明のためのものです。結論は、例のごとくではありません。
この例は、説明のためのものです。結論は、例のごとくではありません。
つまり、他の条件がすべて同じであれば、TPがその前の指値注文よりも早く執行されるのは正常ではない、ということが明らかな例を作ってください。
つまり、他の条件がすべて同じであれば、TPがその前のLimit注文よりも早く実行されるのは正常ではない、ということが明らかです。
証拠はいらない。MQはその仕組みを知っている。
証拠はいらない。MQが意識しているのは、自分たちのためにどうするかということです。
詳細を把握しているのか疑問です。数ページにわたって エラーはないと主張 され（当時はまだ慣例だった）、その後（さらに数ページ後に）何かが間違っていると認められ、調査 することになったことを覚えています。
そして、具体的で明確な例がないのであれば、（今日の現実では）結果的に調べる理由がないことになります。
そして、具体的で明確な例がないのであれば、（今日の現実では）結果的に調べる理由がないことになるのです。
事例があっても、それに対処する理由があるとは限りません。MQは単に問題に気づかないか、関係ないと思われている。
事例が あれば必ず問題が発生するわけではありません。MQは単に問題に気づかないか、関係ないと思われている。
重要な問題とは、以下の場合のみです。TPが執行されず（価格が消えて時間がない）、その結果リミットも執行されない。
ちなみに、そうですね、面白いです。小さなリミッターが巨大なポジションのTPと同レベルで、そのTPが大きいからとリダイレクトされたら、リミッターは埋めるチャンスすらないのでは？
これなら操作できそうですね。