OrderSendAsync()関数 - ページ 8 123456789 新しいコメント Renat Fatkhullin 2012.06.28 10:32 #71 TheXpert: パケットの破損や接続の切断など、でたらめだから。信頼性がない。信頼性が低い -- 接続を切らなければならない。念のため、EAに発行するためのトレードトランザクションのキューは残しておき、プレゼントする予定です。実行時のコミュニケーションギャップが問題だが、どのように対処するのがベストなのかはまだ明確ではない。いずれにせよ、再接続後はすべてのオープンポジション を確認できるようになります。 Mykola Demko 2012.06.28 10:38 #72 TheXpert: パケットの破損や接続の切断など、でたらめだから。信頼性がない。頼りない......立ち直るしかない。フライとカツを別々にしよう。パケット破損は端末の異常事態であり、履歴解析などの例外処理を行う必要があります。しかし、すべてのTradeで履歴を解析するのはコストがかかりすぎます。トレードの到着は正常な状態であり、低コストで対応する必要があります。 TheXpert 2012.06.28 10:41 #73 Urain: 好きなようにすればいい、誰かを煽るつもりはない。 削除済み 2012.06.28 10:59 #74 TheXpert: こんにちは。非同期が何なのか知っているのか？私の理解では、多通貨EAにこの機能を導入しても（単通貨EAではこの取り組みは意味がない）、目的はサーバー側での注文実行の遅延を 回避することによる時間短縮のみです。間違っていたら訂正してください。それとは別に、通信路を使ったデータパケットの伝送というタイムクリティカルな部分だけが残されている。未知の境界線」を「（パケットを）落として走り出す」レベルまで押し上げようとすると、メリットよりも問題が多くなります。問題を総合的に評価することが重要です。タイムアウトの可能性があった場合、特定の商品の取引ができないだけでなく、原則的にサーバーとの通信ができないことも影響すると思われます。また、Expert Advisorから どのように推定すればよいのかがわからない。取引注文がデータ転送中に失われたのか、それともサーバー上でこれほど長い間順番待ちをしているのか。そしてそれは、重複した取引注文のミスを意味し、MMの違反、ひいてはリスクの上昇につながる。私の考えでは、プロのトレーダー（Expert Advisor）は、自分の取引注文がサーバーで実行されることを確認する必要があります。さらに、ある取引注文の状態を（OnTrade()関数 内で）明確に識別するために、サーバから 受け取った一意の値を、その後の処理に適用する必要があります（取引が実行されるまで（ポジションのオープン/クローズ））。OSIネットワークモデルに似ている。取引注文の執行に関するチャネルや物理的なレイヤーに立ち入る必要はありません。このトランスポート機能をクライアント（MT5）に行わせる。アプリケーション層で動作させる。 TheXpert 2012.06.28 11:03 #75 voix_kas:サーバー側での注文実行 の遅延が ないため、時間短縮が可能です。間違っていたら訂正してください。リクエストの結果を待てないという代償を払って。一般的には、そうですね。つまり、注文や市場の実行には非常に便利かもしれません。これを除けば、残された時間はデータパケットを通信路に送信するというタイムクリティカルな部分だけである。未知の境界線」を「（パケットを）落として走り出す」レベルまで押し上げようとすると、メリットよりも問題が多くなります。 まあ...いいえ。利点が問題点を上回るときに使えばいいだけです。私の考えでは、プロのトレーダー（アドバイザー）であれば、自分の取引注文がサーバーで執行されることを確認する必要があります。 その場合、非同期のオプションは適していません。すべては解決可能です。 削除済み 2012.06.28 11:27 #76 TheXpertもう一度、指で確認してみましょう。遅延の大まかな構造化1.端末が取引注文を事前チェックし、送信バッチに「パック」し、「ネットワークキュー」に入れる時間です。2.取引注文を含むデータパケットをクライアントからサーバーに送信した時刻。3.サーバーが取引注文を受信して処理プールに入れ、このチケットの一意の識別子をクライアントに送信する時刻。4.取引注文の正否と取引所への配置を前処理する時間です。もし、私の指摘に間違いがあれば、訂正してください。1点目から待ちたくないということですね？一方、私は前3者の利用を義務化することを提唱しています。さらに議論を深めるためには、2つの質問に答える必要があります。1.遅延の比例比率。それは、上記の4つの項目がそれぞれどれくらいの割合で時間がかかっているかを平均的に表しています。例えば「0.5%-1.0%-97.5%」のような分布であれば、意味がないことになります。2）タイムアウトとその取引戦略への影響。正直なところ、注文がサーバーに送られたかどうかを明確に把握する必要がないTSは、ひとつも挙げることができません。これは、長期的かつ多通貨の裁定取引に関連するものである。つまり、取引注文の執行の保証を問うことはできないのです。異論があれば反例を示してください。 削除済み 2012.06.28 11:41 #77 papaklass: 私の考えでは、ブレーク時の実行問題を解決する最も簡単な方法は、実行キューを作らず（実行をキャンセル）、再接続時にキャンセルしたことをユーザーに通知することです。そうすれば、曖昧さがなくなります。サーバーチケットの返却が必要です。これにより、注文がサーバーに届き、処理が受理されることが保証されます。クライアント側で巧妙な待機プールを構築することは、非現実的な解決策であるだけでなく、MT5のクライアント・サーバー・アーキテクチャの重大な設計上の 欠陥と呼んでもよいでしょう。 TheXpert 2012.06.28 11:50 #78 voix_kas:クライアント側での煩雑な待ち受けは、エレガントな解決策とは言えません。 これが求められていたものです。使わなくてもいいなら、誰も無理に使うことはない。voix_kas です。TheXpertもう一度、指の上でやってみよう。遅延の大まかな構造化1. 端末が取引注文を事前チェックし、ディスパッチ可能なパッケージに「パック」し、「ネットワーク・キュー」に入れるまでの時間。2.取引注文を含むデータパケットをクライアントからサーバーに送信した時間。サーバーが取引注文を受信して処理プールに入れ、このチケットの一意の識別子をクライアントに送信する時刻。4.取引注文の正否を前処理して取引所に出す時間。3は分離した方が良い 3.1 配置3.2 uidを送信する。もし、私の指摘が誤っていたら、訂正してください。1点目から待たされるのは嫌だということですね？はい。一方、私は、最初の3つを義務化することに賛成です。もしPingが0.5秒なら？非同期式なんです。このモードを使う意味は全くないのですか？ 削除済み 2012.06.28 11:55 #79 TheXpert: これが問われていることです。使わなくてもいいなら、誰も無理に使うことはない。あなたはまだ私の質問に答えていません。異なるキャラクターへの送信速度のために、取引注文の 執行保証を無視できるのはどのような場合か、具体例を挙げてください。 Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Типы торговых операций www.mql5.com Стандартные константы, перечисления и структуры / Торговые константы / Типы торговых операций - Документация по MQL5 TheXpert 2012.06.28 12:04 #80 voix_kas:あなたはまだ私の質問に答えていません。異なるシンボルに送るスピードのために、取引注文の 執行保証を無視できる場合の具体例を教えてください。問題なし - ポートフォリオ取引＋市場執行 123456789 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
パケットの破損や接続の切断など、でたらめだから。信頼性がない。信頼性が低い -- 接続を切らなければならない。
念のため、EAに発行するためのトレードトランザクションのキューは残しておき、プレゼントする予定です。
実行時のコミュニケーションギャップが問題だが、どのように対処するのがベストなのかはまだ明確ではない。いずれにせよ、再接続後はすべてのオープンポジション を確認できるようになります。
パケットの破損や接続の切断など、でたらめだから。信頼性がない。頼りない......立ち直るしかない。
フライとカツを別々にしよう。
パケット破損は端末の異常事態であり、履歴解析などの例外処理を行う必要があります。
しかし、すべてのTradeで履歴を解析するのはコストがかかりすぎます。トレードの到着は正常な状態であり、低コストで対応する必要があります。
こんにちは。非同期が何なのか知っているのか？
私の理解では、多通貨EAにこの機能を導入しても（単通貨EAではこの取り組みは意味がない）、目的はサーバー側での注文実行の遅延を 回避することによる時間短縮のみです。間違っていたら訂正してください。
それとは別に、通信路を使ったデータパケットの伝送というタイムクリティカルな部分だけが残されている。未知の境界線」を「（パケットを）落として走り出す」レベルまで押し上げようとすると、メリットよりも問題が多くなります。問題を総合的に評価することが重要です。タイムアウトの可能性があった場合、特定の商品の取引ができないだけでなく、原則的にサーバーとの通信ができないことも影響すると思われます。
また、Expert Advisorから どのように推定すればよいのかがわからない。取引注文がデータ転送中に失われたのか、それともサーバー上でこれほど長い間順番待ちをしているのか。そしてそれは、重複した取引注文のミスを意味し、MMの違反、ひいてはリスクの上昇につながる。私の考えでは、プロのトレーダー（Expert Advisor）は、自分の取引注文がサーバーで実行されることを確認する必要があります。さらに、ある取引注文の状態を（OnTrade()関数 内で）明確に識別するために、サーバから 受け取った一意の値を、その後の処理に適用する必要があります（取引が実行されるまで（ポジションのオープン/クローズ））。
OSIネットワークモデルに似ている。取引注文の執行に関するチャネルや物理的なレイヤーに立ち入る必要はありません。このトランスポート機能をクライアント（MT5）に行わせる。アプリケーション層で動作させる。
サーバー側での注文実行 の遅延が ないため、時間短縮が可能です。間違っていたら訂正してください。
リクエストの結果を待てないという代償を払って。一般的には、そうですね。つまり、注文や市場の実行には非常に便利かもしれません。
これを除けば、残された時間はデータパケットを通信路に送信するというタイムクリティカルな部分だけである。未知の境界線」を「（パケットを）落として走り出す」レベルまで押し上げようとすると、メリットよりも問題が多くなります。
まあ...いいえ。利点が問題点を上回るときに使えばいいだけです。
私の考えでは、プロのトレーダー（アドバイザー）であれば、自分の取引注文がサーバーで執行されることを確認する必要があります。
その場合、非同期のオプションは適していません。すべては解決可能です。
TheXpert
もう一度、指で確認してみましょう。遅延の大まかな構造化
1.端末が取引注文を事前チェックし、送信バッチに「パック」し、「ネットワークキュー」に入れる時間です。
2.取引注文を含むデータパケットをクライアントからサーバーに送信した時刻。
3.サーバーが取引注文を受信して処理プールに入れ、このチケットの一意の識別子をクライアントに送信する時刻。
4.取引注文の正否と取引所への配置を前処理する時間です。
もし、私の指摘に間違いがあれば、訂正してください。1点目から待ちたくないということですね？一方、私は前3者の利用を義務化することを提唱しています。
さらに議論を深めるためには、2つの質問に答える必要があります。
1.遅延の比例比率。それは、上記の4つの項目がそれぞれどれくらいの割合で時間がかかっているかを平均的に表しています。例えば「0.5%-1.0%-97.5%」のような分布であれば、意味がないことになります。
2）タイムアウトとその取引戦略への影響。正直なところ、注文がサーバーに送られたかどうかを明確に把握する必要がないTSは、ひとつも挙げることができません。これは、長期的かつ多通貨の裁定取引に関連するものである。つまり、取引注文の執行の保証を問うことはできないのです。異論があれば反例を示してください。
私の考えでは、ブレーク時の実行問題を解決する最も簡単な方法は、実行キューを作らず（実行をキャンセル）、再接続時にキャンセルしたことをユーザーに通知することです。そうすれば、曖昧さがなくなります。
サーバーチケットの返却が必要です。これにより、注文がサーバーに届き、処理が受理されることが保証されます。
クライアント側で巧妙な待機プールを構築することは、非現実的な解決策であるだけでなく、MT5のクライアント・サーバー・アーキテクチャの重大な設計上の 欠陥と呼んでもよいでしょう。
クライアント側での煩雑な待ち受けは、エレガントな解決策とは言えません。
これが求められていたものです。使わなくてもいいなら、誰も無理に使うことはない。
TheXpert
もう一度、指の上でやってみよう。遅延の大まかな構造化
1. 端末が取引注文を事前チェックし、ディスパッチ可能なパッケージに「パック」し、「ネットワーク・キュー」に入れるまでの時間。
2.取引注文を含むデータパケットをクライアントからサーバーに送信した時間。
サーバーが取引注文を受信して処理プールに入れ、このチケットの一意の識別子をクライアントに送信する時刻。
4.取引注文の正否を前処理して取引所に出す時間。
3は分離した方が良い
3.1 配置
3.2 uidを送信する。
もし、私の指摘が誤っていたら、訂正してください。1点目から待たされるのは嫌だということですね？
はい。
一方、私は、最初の3つを義務化することに賛成です。
もしPingが0.5秒なら？非同期式なんです。このモードを使う意味は全くないのですか？
これが問われていることです。使わなくてもいいなら、誰も無理に使うことはない。
あなたはまだ私の質問に答えていません。異なるキャラクターへの送信速度のために、取引注文の 執行保証を無視できるのはどのような場合か、具体例を挙げてください。
あなたはまだ私の質問に答えていません。異なるシンボルに送るスピードのために、取引注文の 執行保証を無視できる場合の具体例を教えてください。
問題なし - ポートフォリオ取引＋市場執行