フォルツァ執行上の問題点 - ページ 124 1...117118119120121122123124125126127128129130131...156 新しいコメント GoVegas 2018.12.17 17:28 #1231 足を踏み入れて......と言われた Sergey Chalyshev 2019.01.04 14:22 #1232 またサーバーがおかしくなった(((;゜Д゜))) 3 分間ハングアップした後、[Request timeout] と表示される。 2019.01.04 14:18:20.427 Trades 'xxxxx': modify #97538997 buy limit 1.00 BR-3.19 -> price: 57.39, sl: 0.00, tp: 0.00) done in 47.866 ms 2019.01.04 14:18:28.399 Trades 'xxxxx': modify order #97538868 sell limit 1.00 BR-3.19 at 57.51 sl: 0.00 tp: 0.00 -> 57.55, sl: 0.00 tp: 0.00 2019.01.04 14:18:28.445 Trades 'xxxxx': accepted modify order #97538868 sell limit 1.00 BR-3.19 at 57.51 sl: 0.00 tp: 0.00 -> 57.55, sl: 0.00 tp: 0.00 2019.01.04 14:18:28.445 Trades 'xxxxx': modify order #97538868 sell limit 1.00 BR-3.19 at 57.51 sl: 0.00 tp: 0.00 -> 57.55, sl: 0.00 tp: 0.00 placed for execution 2019.01.04 14:18:28.461 Trades 'xxxxx': deal #56712593 sell 1.00 BR-3.19 at 57.51 done (based on order #97538868) 2019.01.04 14:21:28.407 Trades 'xxxxx': failed modify order #97538868 buy 0.00 BR-3.19 at market sl: 0.00 tp: 0.00 -> 57.55, sl: 0.00 tp: 0.00 [Request timeout] ディスカバリーサーバー、ターミナルビルド1947。どうすればいいのか? prostotrader 2019.01.06 15:27 #1233 Sergey Chalyshev:またサーバーがおかしくなった(((;゜Д゜))) 3 分間ハングアップして、[Request timeout] となる。 ディスカバリーサーバー、ターミナルビルド1947。どうしたらいいのでしょうか?セルジュ! これはある種の失敗作だ(以前は見かけなかった)。 この注文は修正前の価格57.51で執行された。 MT5サーバーが取引所に修正注文を出したのは14:18:28.445 なので、おそらくこれは取引所自体の 不具合でしょう。 で、トランザクションが行われた14:18:28.461 2019.01.04 14:18:28.461 Trades 'xxxxx': deal #56712593 sell 1.00 BR-3.19 at 57.51 done (based on order #97538868) サーバー(取引所)内で何かが「凍結」されているはずで、「凍結」された注文が見つからなかったので、「リクエストタイムアウト」 した。質問へ どうしたらいいのか? 答えは、OnTradeTransaction(TRADE_TRANSACTION_DEAL_ADD)です。 によって追加されました。 私は、非同期の注文送信と 以下の注文追跡モデルを使用しています。 //+------------------------------------------------------------------+ // Expert Trade Transaction function | //+------------------------------------------------------------------+ void OnTradeTransaction( const MqlTradeTransaction &trans, const MqlTradeRequest &request, const MqlTradeResult &result ) { switch(trans.type) { case TRADE_TRANSACTION_REQUEST: //Получение тикета ордера break; case TRADE_TRANSACTION_DEAL_ADD: //Произошла сделка (отложенный ордер) break; case TRADE_TRANSACTION_HISTORY_ADD: //Ордера нет (исполнился, отменен и т.д) break; case TRADE_TRANSACTION_ORDER_UPDATE: switch(trans.order_state) { case ORDER_STATE_PLACED: //Ордер размешен (модификация) break; case ORDER_STATE_PARTIAL: //Ордер исполнился частично break; case ORDER_STATE_REJECTED: case ORDER_STATE_EXPIRED: // break; } break; } } JRandomTrader 2019.01.06 18:53 #1234 prostotrader:OnTradeTransaction(TRADE_TRANSACTION_DEAL_ADD) を使用すれば、取引を見逃すことはなく、したがって、注文に何が起こったかを知ることができます。 によって追加されました。 私は、非同期の注文送信と、以下の注文追跡モデルを使用しています。 ここで質問です。 何らかの理由で必要なOnTradeTransaction イベントを逃した場合(例:インターネット障害、 荷物の紛失、コンピュータの再起動、イベントキューのオーバーフロー)、次に どうすればよいのでしょう? prostotrader 2019.01.06 23:08 #1235 JRandomTrader:ここで質問です。 何らかの理由で正しいOnTradeTransaction イベントを見逃した場合(例:インターネットがクラッシュした、パケットが失われた、コンピュータが再起動した、イベントキューがオーバーフローした)、次のアクションは 何でしょうか。あなたが挙げたそれぞれのケースに対応するアクションがあります。 例えば、コンピュータが再起動され、保留中の注文があった場合、Expert Advisorがロードさ れた後、チェックします。 このシンボルに設定された注文を確認します。(考慮すべきことはたくさんありますが、すべて解決可能です) Andrey Gladyshev 2019.02.13 08:29 #1236 Aleksey Vyazmikin:実用的な観点からは、確かに便利なのですが、端末がすべてを同期させようとして遅くなるのは想像に難くありませんし、このデータを非同期で到着させることに意味があるのかどうかもわかりません。タイミングが悪かったのか、乱入してすみません。ちょうどここに座って、このスレッドを読み返しているところです。非同期で言うところの)。カップのイベントに関するデータを非同期で到着させることは、カップのデータのみを分析する場合に有効である。つまり、レベル別の入札の動きです。そして、突然カップの状態のあらゆる変化が利用できるようになれば、次に起こることとは無関係にこれを利用することができるようになります。こんな感じです。 Aleksey Vyazmikin 2019.02.13 08:31 #1237 Andrey Gladyshev:お邪魔して申し訳ありません、時期が悪かったかもしれません。このスレを読み返しているところです。非同期で言うところの)。カップのデータのみを分析する場合、カップ内のイベントに関するデータの非同期到着は便利かもしれません。つまり、レベル別の入札の動きです。そして、突然カップの状態のあらゆる変化が利用できるようになれば、次に起こることとは無関係にこれを利用することができるようになります。こんな感じです。私が理解する限り、カップのブラインドは、一定の頻度で交換によって放送される、すなわち、すべての変更は、ちょうど取得することはできません。 それと、やはり理解できないのは、それで何をするのか、ということです。特に、強い動きがあったときに、遅れてデータが来るようでは...。 Andrey Gladyshev 2019.02.13 08:43 #1238 Aleksey Vyazmikin:私が理解する限り、株式キャストは一定の頻度で取引所から放送されており、すなわち、それぞれの変化を得るだけの方法はありません。 で、やっぱりわからないのは、それでどうするのかってこと。特に、強い動きがあったときに、遅れてデータが来るようでは...。逆質問をして、それに答える。文字通り取引所に座っていれば、株の状態についてより有意義な情報(正確にはタイムリーな情報)を得ることができるのだろうか。例えば、コロケーションの話です。 Aleksey Vyazmikin 2019.02.13 08:47 #1239 Andrey Gladyshev:逆質問をして、それに答える。文字通り取引所に座っていれば、株の状態についてより有意義な情報(タイムリーというべきか)を得ることができるのだろうか。例えば、コロケーションの話です。交換の様子も放送される予定です。それとも、レートフレームのロスを想定しているのでしょうか? Andrey Gladyshev 2019.02.13 08:47 #1240 しかも、どの取引所かにもよる。うちは考えていません。 1...117118119120121122123124125126127128129130131...156 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
足を踏み入れて......と言われた
またサーバーがおかしくなった(((;゜Д゜)))
3 分間ハングアップした後、[Request timeout] と表示される。
ディスカバリーサーバー、ターミナルビルド1947。
どうすればいいのか?
またサーバーがおかしくなった(((;゜Д゜)))
3 分間ハングアップして、[Request timeout] となる。
ディスカバリーサーバー、ターミナルビルド1947。
どうしたらいいのでしょうか?
セルジュ!
これはある種の失敗作だ(以前は見かけなかった)。
この注文は修正前の価格57.51で執行された。
MT5サーバーが取引所に修正注文を出したのは14:18:28.445 なので、おそらくこれは取引所自体の 不具合でしょう。
で、トランザクションが行われた14:18:28.461
サーバー(取引所)内で何かが「凍結」されているはずで、「凍結」された注文が見つからなかったので、「リクエストタイムアウト」 した。
質問へ どうしたらいいのか?
答えは、OnTradeTransaction(TRADE_TRANSACTION_DEAL_ADD)です。
によって追加されました。
私は、非同期の注文送信と 以下の注文追跡モデルを使用しています。
OnTradeTransaction(TRADE_TRANSACTION_DEAL_ADD) を使用すれば、取引を見逃すことはなく、したがって、注文に何が起こったかを知ることができます。
によって追加されました。
私は、非同期の注文送信と、以下の注文追跡モデルを使用しています。
ここで質問です。
何らかの理由で必要なOnTradeTransaction イベントを逃した場合(例:インターネット障害、 荷物の紛失、コンピュータの再起動、イベントキューのオーバーフロー)、次に どうすればよいのでしょう?
ここで質問です。
何らかの理由で正しいOnTradeTransaction イベントを見逃した場合(例:インターネットがクラッシュした、パケットが失われた、コンピュータが再起動した、イベントキューがオーバーフローした)、次のアクションは 何でしょうか。
あなたが挙げたそれぞれのケースに対応するアクションがあります。
例えば、コンピュータが再起動され、保留中の注文があった場合、Expert Advisorがロードさ れた後、チェックします。
このシンボルに設定された注文を確認します。(考慮すべきことはたくさんありますが、すべて解決可能です)
実用的な観点からは、確かに便利なのですが、端末がすべてを同期させようとして遅くなるのは想像に難くありませんし、このデータを非同期で到着させることに意味があるのかどうかもわかりません。
タイミングが悪かったのか、乱入してすみません。ちょうどここに座って、このスレッドを読み返しているところです。非同期で言うところの)。カップのイベントに関するデータを非同期で到着させることは、カップのデータのみを分析する場合に有効である。つまり、レベル別の入札の動きです。そして、突然カップの状態のあらゆる変化が利用できるようになれば、次に起こることとは無関係にこれを利用することができるようになります。こんな感じです。
お邪魔して申し訳ありません、時期が悪かったかもしれません。このスレを読み返しているところです。非同期で言うところの)。カップのデータのみを分析する場合、カップ内のイベントに関するデータの非同期到着は便利かもしれません。つまり、レベル別の入札の動きです。そして、突然カップの状態のあらゆる変化が利用できるようになれば、次に起こることとは無関係にこれを利用することができるようになります。こんな感じです。
私が理解する限り、カップのブラインドは、一定の頻度で交換によって放送される、すなわち、すべての変更は、ちょうど取得することはできません。
それと、やはり理解できないのは、それで何をするのか、ということです。特に、強い動きがあったときに、遅れてデータが来るようでは...。私が理解する限り、株式キャストは一定の頻度で取引所から放送されており、すなわち、それぞれの変化を得るだけの方法はありません。
で、やっぱりわからないのは、それでどうするのかってこと。特に、強い動きがあったときに、遅れてデータが来るようでは...。逆質問をして、それに答える。文字通り取引所に座っていれば、株の状態についてより有意義な情報(正確にはタイムリーな情報)を得ることができるのだろうか。例えば、コロケーションの話です。
逆質問をして、それに答える。文字通り取引所に座っていれば、株の状態についてより有意義な情報(タイムリーというべきか)を得ることができるのだろうか。例えば、コロケーションの話です。
交換の様子も放送される予定です。それとも、レートフレームのロスを想定しているのでしょうか?