OnTradeTransaction
OnTradeTransaction イベントが保証されない のはなぜですか？
開発者は答えるのに疲れているのでしょう。回答するようにします。OnTradeTransaction は イベント であるため、定義上保証されない。イベントの送信は保証されても、受信は保証されない。あるイベントが発生したとき、ユーザー端末がシャットダウンしたり、インターネットとの接続が切れたりして、そのイベントに対応できなくなることを想定してください。確率は低いですが、不可能ではありません。
事象を分析するのではなく、貿易環境を分析 し、貿易環境が変化した場合にのみ、必要な判断をすることが必要である。OnTransactionは非常に限られた場合にのみ使用することができ、通常は使用しない方がよいでしょう。MetaTrader 4にはOnTransactionがなく、それなしで非常にうまく管理しています。
開発者は答えるのに疲れているのでしょう。答えてみようと思います。OnTradeTransaction はイベント であるため、定義上保証されない。イベントの送信は保証されても、受信は保証されない。あるイベントが発生したとき、ユーザー端末がシャットダウンしたり、インターネットとの接続が切れたりして、そのイベントに対応できなくなることを想定してください。確率は低いですが、不可能ではありません。
事象を分析するのではなく、貿易環境を分析 し、貿易環境が変化した場合にのみ、必要な判断をすることが必要である。OnTransactionは非常に限られた場合にのみ使用することができ、通常は使用しない方がよいでしょう。MetaTrader 4 を見てください。OnTransaction がなく、誰もがそれなしでうまくやっています。
mt5と違い、mt4ではネッティングがない分、ポジション管理がしやすいので、OnTransactionの良し悪しはそこにあると思います。
つまり、技術的な理由だけでイベントが保証されないのですか？すべてがうまくいけば、端末はこのイベントを100％保証するはずなのですが？
MT4では、ネッティングがないため、MT5とは異なり、ポジション管理が非常に簡単です。 そのため、MetaTraderではOnTransactionがホットまたはコールドとなります。
技術的な理由だけで開催が保証されないということですか？すべてがうまくいけば、端末はこのイベントを100％保証するはずなのですが？
ネッティングはOnTradeTransaction の 必要性に影響を及ぼさない。
2つ目の質問は、開発者自身が答えるしかないでしょう。私が気づいたのは、OnTradeTransactionが非常に安定しているということだけです。イベント受信ロスは検出されませんでした。
ネッティングは OnTradeTransaction の必要性に影響を及ぼさない。
Netting はポジションの会計処理に影響し、このような単純な問題で多くの問題を引き起こした。一方、OnTradeTransaction もポジションの会計処理に必要である。
MT4では一般的にネッティングがないため、MT5と違ってポジション管理がしやすいので、OnTransactionはホットでもコールドでもいいんです。
技術的な理由だけで開催が保証されないということですか？すべてがうまくいけば、端末はこのイベントを100％保証するはずなのですが？
開発者は、優先的に製品の特性を選択します。 MT4の優先特性は、MQL4との連携のしやすさでした。
MT5では、第一レベルの優先順位は明らかにスピード（と柔軟性）です。すべての製品の機能を最大に引き出すことは不可能です。これは理論に矛盾する。
最速の製品は、必然的にクライアントのプログラマーに多くの（知識、経験、労力を）要求することになる。
この技術的な問題は一体何なんだ。冷静に考えてみよう。
MT5を開発していて、取引アクションのためのHFTブロックを書くというタスクがあるとします。
一方ではサーバーからトランザクションレコードをキューに入れ、他方ではこれらのレコードをXXX-expertに渡さなければならない。
XXXエキスパートでは、OnTradeTransaction() ハンドラ内で、ユーザーが任意の「ポルノ」を持つことができるのです!
この機能がいつまで実行されるかは全く不明です。
このキューには、サーバーから送られてきたものの、まだXXX-expertに転送されていない数百件のレコードが含まれていることがあります。
このような状況で、何を保証できるのでしょうか？データのスピードや完成度？
また、本質的にHFTにしか貢献しない機能のために、時代遅れの情報を「保存」することに意味があるのでしょうか？
みんな！
読んでいて、不思議に思うことがあるのですが...。
OnTradeTransactionは、どこにも「掘る」ことなく、最新の情報を入手することができます
注文や取引で
この機能の使い方を知らないだけでしょう。
みんな！
読んでいて、不思議に思うことがあるのですが...。
OnTradeTransactionは、どこにも「掘る」ことなく、最新の情報を入手することができます
注文や取引で
この機能の使い方を知らないだけでしょう。
あなたもやり方がわからないのでは？OnTradeTransactionは特定のタスクを解決するためのサービス機能であり、あなたのように取引に使用することはできません。なぜOnTradeTransactionは保証されないのですか？」 - Expert Advisorは、あなたのようにOnTradeTransactionを通じて取引環境を構築するのではなく、システムで利用できるもの、特に注文と 取引の履歴にのみ 依存するからです。
一方では、そうですね。一方、サーバーにリクエストを送ったが、まだオペレーションが実行されていない場合はどうでしょう。注文とポジションのリスト（と口座履歴）しかない場合、どのような状態にあるのかを知ることができるのでしょうか？
MT4では、すべての取引操作が同期的に行われるため、そのような問題はありません。しかし、その結果、パフォーマンスが低下してしまうのです。
一方では、そうですね。一方、サーバーにリクエストを送ったが、まだオペレーションが実行されていない場合はどうでしょう。注文とポジションのリスト（と口座履歴）しかない場合、どのような状態にあるのかを知ることができるのでしょうか？
MT4では、すべての取引操作が同期的に行われるため、そのような問題はありません。しかし、その結果、パフォーマンスが低下してしまうのです。
注文を送信してから次の成行シグナルが出るまでの時間が、注文の実行 時間を超えている場合は、何もする必要がありません。ロジックは簡単で、非同期のオーダーを送信し、スレッドから離れ、そのことを忘れるのです。次の瞬間、信号を確認するために待ちます。その時点で取引環境に変化がなければ、Expert Advisorは再び市場参入のシグナルを探し、市場参入の注文を繰り返す。逆に、すべてがうまくいって注文が執行された場合、Expert Advisorは環境分析後にポジションを持っていることを認識し、新しいポジションを再び開くことはありません。つまり、この方法では、Expert Advisorの状態が市場環境と一致することが保証 されています。
高頻度取引では、注文の執行に匹敵する時間（6～100ミリ秒）の後に新しいシグナルが発生することがあり、状況はより複雑になる。この場合、ロックをしないわけにはいきません。Expert Advisor は、最後に注文を送信した時刻を記憶しておく必要があります。OnTransaction でエラーが発生した場合、ロックアウトはリセットされ、Expert Advisor は再び取引を行うことができます。
多くの人が好んで祈るOnTradeTransactonは、HFTでは役に立ちませんので、注意が必要です。新規参入シグナルは、OnTradeTransaction における取引の成功に関する応答よりも速く到着する可能性があります。OnTradeTransactonを使用するしないにかかわらず、ブロッキングは必要です。
OnTradeTransaction で発生するエラーはどのように制御するのですか？ エラー発生時にExpert Advisorの取引ロジックをその場でどのように 変更するのか、という反問で答えることができます。- できません。事前に適切なチェックを行わないとエラーが発生する（お金の有無、量、などなど）。しかし、一度起きてしまったことは、修正することができません。したがって、OnTradeTransaction でできる最善のことは、このエラーをログに出力し（後で Expert Advisor のロジックを修正するため）、ロックが使用されている場合はそれを削除することです。このため、OnTradeTransaction を使用する必要があります。
今にミカラスの信者がやってきてトマトを投げつけるだろうが、放っておけばいい。しかし、端末の取引環境を踏まえてこそ、信頼性の高い売買ロジックが組めるのだと、私はいつも繰り返しています。それ以外のものは使えません。
OnTradeTransaction イベントが保証されない のはなぜですか？
OnTradeTransaction は、OrderSendAsinc 要求に対するサーバーの応答結果である。
OrderSendAsinc関数自体が非同期であることは、その名前にも記されている。これは、この関数がサーバーへのリクエストを起動し、その送信結果（リクエストの送信が成功したかどうか）をプログラムに返したことを意味します。
それは、「雄鶏が鳴いたから夜が明けない」という原理に従っている。このため、OnTradeTransaction におけるサーバーからの応答は保証されない。そこで何が起こるかわからない。
類似の機能として、OrderSend と OrderSendAsinc がある。
最初のものは同期型で、どんなに時間がかかってもサーバーからの応答を黙って待ちます（サーバーがリクエスト処理した結果を返します）。
2つ目は非同期で、サーバーからの応答を待たず、すぐに操作 結果を返します（ただし、サーバーへのリクエスト送信が成功したかどうかの結果は返します）。
OrderSendAsincは、迅速な意思決定が必要な場合に必要です。テストによると、OrderSendAsincは1秒間に数百のリクエスト送信を処理することができます（ただし、このスピードはサーバーからの応答を待っていないことによるものです）。
遅延 "応答を受信するために正確に端末はOnTradeTransactionイベントを生成します（プログラムが応答を受信し続けているという事実のために条件付きで遅延、実際には、遅延は秒またはミリ秒でカウントされます）。
OrderSend との違いは、OnTradeTransaction は一つの注文に対して何度も発生し、サーバーがどのようにリクエストを処理したかについて新たに受け取った情報を端末に通知することができる点である。OnTradeTransactionの注文処理の段階を見ることができるということです。
サーバーが受け付けた注文 OnTradeTransaction
注文が OnTradeTransaction のキューに入れられました。
注文する ...OnTradeTransaction
注文する ...OnTradeTransaction など。
注文の最初のイベント以外のすべてのイベントには、イベント OnTradeTransaction への応答がどの注文で受信されたかを正確に識別するためのチケットが添付されます。
最初のイベントは、チケットとrequest_idで署名されています。request_id は、注文が送信された直後に、OrderSendAsinc 関数からユーザが取得する。このように、特定の OrderSendAsinc の反復は OnTradeTransaction で得られた結果とリンクしている。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索