フォルツァ執行上の問題点 - ページ 34 1...272829303132333435363738394041...156 新しいコメント Vladimir Pastushak 2015.09.01 17:21 #331 Михаил:2014.12.16にこのスレッドを立ち上げました。現在、2015年9月です。 公平を期すために、オリジナルのプラットフォーム構想による全般的な遅れを指摘する必要があります。 は非常に早く修正 されましたが、開発者が「フローティングシングル」の遅延を真摯に受け止めなかったことは限りなく残念です。これは、取引において致命的であることが判明しました（デモとリアル口座で異なるブローカーでテストされたため）。を見ると、MT5のサーバー部分で遅延が 発生していることが一目瞭然です）。このエラーの検出がユーザーによって行われ、開発者によって行われなかったのは非常に残念なことです。レナートは2014.12.29に「作業は継続する」と断言しましたが。"時折発生するターミナルまでのフローティングレスポンスの納期は、まだケアできていないので、引き続き 取り組んでいく。" マイケル、もしかしたら、この遅れは機材のせいかもしれませんね？それとも、機材は常に故障なく動くものだと思っているのでしょうか？サーバーハードウェアの開発者に手紙を出すのは意味があることかも？ Mikhail Filimonov 2015.09.01 17:32 #332 Vladimir Pastushak: マイケル、もしかして遅延の原因は機材にあるのでは？それとも、機材は常に故障なく動くものだと思っているのでしょうか？サーバーハードウェアの開発者に手紙を出すのは意味があることかも？ウラジミール！この書き込みと過去ログをよく読むべし!DIFFERENT BROKERSは、デモでもリアル口座でも同じ効果を発揮します。 Vladimir Pastushak 2015.09.01 17:52 #333 Михаил:ウラジミール！この書き込みと過去ログをよく読むべし!リアルブローカーとデモブローカーで同じ効果がある！？非常に多くの場合、証券会社のビジネスの作成/メンテナンスは、順番にほぼ同じサーバを置く専門会社によって行われ、すなわち、別のブローカーと機器が1と同じである...異なるブローカーのサーバーが同じラックに並んでいることがあるのですが...。 Mikhail Filimonov 2015.09.01 18:10 #334 Vladimir Pastushak:非常に多くの場合、証券会社のビジネスの作成/サービスは、順番にほぼ同じサーバを置く専門のオフィスによって処理される、すなわち、ブローカーが異なっているが、機器が同じである...異なるブローカーのサーバーが1つのラックに収まっていることがある ...ウラジミール！大きなお願いがあるんです。作らないでくださいよ。 Vladimir Pastushak 2015.09.01 18:14 #335 Михаил:ウラジミール！あなたに大きなお願いがあります。妄想はやめてください。このビジネスの仕組みがわからないと、誰かが妄想しているとは限らない、証券会社を設立するには人脈が必要なのか？この投稿からEAでサーバーをテストしていると理解していいのでしょうか？https://www.mql5.com/ru/forum/38456/page37#comment_1869077 ФОРТС. Вопросы по исполнению www.mql5.com С большими проблемами удалось это сделать (начальник отдела по работе с профессиональными клиентами ДЦ Открытие Евгений Сергеевич,. - Страница 37 - Категория: автоматические торговые системы Vladimir Pastushak 2015.09.01 20:50 #336 以下は私のログです。MT5サーバーは1分間に何回、1秒間に何回リクエストを処理できるんだろう...。 ファイル: 20150901.log 758 kb Mikhail Filimonov 2015.09.02 07:08 #337 今朝( リアル) Accsess server 4:2015.09.02 10:00:18.610 Trades 'xxxxx': sell limit 5.00 MIX-12.15 at 172475 2015.09.02 10:00:18.619 Trades 'xxxxx': sell limit 5.00 MIX-12.15 at 172475 placed for execution in 9 ms 2015.09.02 10:00:18.926 Trades 'xxxxx': cancel order #19725208 sell limit 5.00 MIX-12.15 at 172475 2015.09.02 10:00:18.941 Trades 'xxxxx': cancel order #19725208 sell limit 5.00 MIX-12.15 at 172475 placed for execution in 15 ms 2015.09.02 10:00:20.215 Trades 'xxxxx': buy limit 3.00 TATN-12.15 at 28402 2015.09.02 10:00:29.538 Trades 'xxxxx': buy limit 3.00 TATN-12.15 at 28402 placed for execution in 9324 ms 2015.09.02 10:00:29.608 Trades 'xxxxx': modify order #19725217 buy limit 3.00 TATN-12.15 at 28402 sl: 0 tp: 0 -> 28404, sl: 0 tp: 0 2015.09.02 10:00:31.504 Trades 'xxxxx': cancel order #19725136 sell limit 5.00 UJPY-12.15 at 120.69 2015.09.02 10:00:31.510 Trades 'xxxxx': sell limit 2.00 FEES-12.15 at 6831 2015.09.02 10:00:31.817 Trades 'xxxxx': modify order #19725217 buy limit 3.00 TATN-12.15 at 28402 sl: 0 tp: 0 -> 28523, sl: 0 tp: 0 2015.09.02 10:00:33.713 Trades 'xxxxx': cancel order #19725179 buy limit 1.00 URKA-12.15 at 19590 2015.09.02 10:00:33.733 Trades 'xxxxx': modify order #19725217 buy limit 3.00 TATN-12.15 at 28402 sl: 0 tp: 0 -> 28404, sl: 0 tp: 0 placed for execution in 4125 ms 2015.09.02 10:00:33.751 Trades 'xxxxx': cancel order #19725136 sell limit 5.00 UJPY-12.15 at 120.69 placed for execution in 2248 ms 2015.09.02 10:00:33.752 Trades 'xxxxx': sell limit 2.00 FEES-12.15 at 6831 placed for execution in 2241 ms 2015.09.02 10:00:33.762 Trades 'xxxxx': modify order #19725217 buy limit 3.00 TATN-12.15 at 28404 sl: 0 tp: 0 -> 28523, sl: 0 tp: 0 placed for execution in 1946 ms 2015.09.02 10:00:33.900 Trades 'xxxxx': cancel order #19725217 buy limit 3.00 TATN-12.15 at 28523 2015.09.02 10:00:34.654 Trades 'xxxxx': modify order #19725269 sell limit 2.00 FEES-12.15 at 6831 sl: 0 tp: 0 -> 6829, sl: 0 tp: 0 2015.09.02 10:00:35.603 Trades 'xxxxx': cancel order #19725179 buy limit 1.00 URKA-12.15 at 19590 placed for execution in 1890 ms 2015.09.02 10:00:35.610 Trades 'xxxxx': cancel order #19725217 buy limit 3.00 TATN-12.15 at 28523 placed for execution in 1710 ms 2015.09.02 10:00:35.624 Trades 'xxxxx': modify order #19725269 sell limit 2.00 FEES-12.15 at 6831 sl: 0 tp: 0 -> 6829, sl: 0 tp: 0 placed for execution in 970 ms 2015.09.02 10:00:36.004 Trades 'xxxxx': modify order #19725269 sell limit 2.00 FEES-12.15 at 6829 sl: 0 tp: 0 -> 6808, sl: 0 tp: 0 2015.09.02 10:00:36.014 Trades 'xxxxx': modify order #19725269 sell limit 2.00 FEES-12.15 at 6829 sl: 0 tp: 0 -> 6808, sl: 0 tp: 0 placed for execution in 9 ms これを「シングル」ディレイと呼んでいいのでしょうか？そのため、代替チェック（CheckOrders()）機能が作動しています。2015.09.02 10:00:21.419 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:21.529 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:21.638 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:21.747 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:21.856 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:21.856 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:22.932 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:23.042 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:23.151 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:23.260 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:23.369 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:23.369 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:24.461 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:24.570 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:24.680 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:24.789 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:24.898 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:24.898 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:25.974 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:26.084 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:26.193 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:26.302 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:26.411 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:26.411 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:27.503 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:27.612 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:27.721 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:27.831 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:27.940 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:27.940 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:29.021 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:29.125 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:29.235 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:29.344 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:29.453 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:29.453 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:31.060 Forts_trader (TATN-9.15,H1) CheckOrders: Buy ордер модифицирован. Билет = 19725217 2015.09.02 10:00:32.894 Forts_trader (UJPY-9.15,H1) CheckOrders: Sell ордер не удалён! Билет = 19725136 2015.09.02 10:00:32.894 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 1 получить билет Sell ордера... 2015.09.02 10:00:33.010 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 2 получить билет Sell ордера... 2015.09.02 10:00:33.088 Forts_trader (TATN-9.15,H1) CheckOrders: Buy ордер модифицирован. Билет = 19725217 2015.09.02 10:00:33.119 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 3 получить билет Sell ордера... 2015.09.02 10:00:33.228 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 4 получить билет Sell ордера... 2015.09.02 10:00:33.337 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 5 получить билет Sell ордера... 2015.09.02 10:00:33.337 Forts_trader (FEES-9.15,H1) CheckOrders: Не получен билет Sell ордера! 2015.09.02 10:00:34.773 Forts_trader (URKA-9.15,H1) CheckOrders: Buy ордер не удалён! Билет = 19725179 2015.09.02 10:00:35.115 Forts_trader (TATN-9.15,H1) CheckOrders: Buy ордер не удалён! Билет = 19725217 Aytugan Khafizov 2015.09.02 14:46 #338 Михаил:今朝（リアル）Accsess server 4:ディスカバリー社からの情報では、AS4は使わない方が良いとのことです。AS2を使用した方が良い Mikhail Filimonov 2015.09.02 21:16 #339 Aytugan Khafizov:Michaelさん、Discoveryアクセスポイントからのログインログを解析した結果、以下のことがわかりました。1) データセンターのログをターミナルに接続すると、これらのpingは10ms程度に保たれますが、最大で500msのスパイクがあります。Access Server2 2015.08.25 08:48:15.666 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 10.89 ms) Access Server3 2015.08.25 00:07:19.069 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 500.40 ms) Access Server3 2015.08.25 08:48:28.696 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 12.03 ms) Access Server3 2015.08.26 04:10:52.879 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 506.13 ms) Access Server3 2015.08.27 01:08:15.820 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 8.12 ms) Access Server2 2015.08.27 01:08:18.776 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.12 ms) Access Server2 2015.08.27 02:32:48.278 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.07 ms) Access Server2 2015.08.27 09:05:51.324 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.65 ms) Access Server3 2015.08.27 09:06:04.272 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.75 ms)アクセスポイントから端末へのPingです。| зона ответственности Биржи || зона ответственности Открытия || интернет || клиент | [биржа (ФОРТС)] <==> [шлюз Plaza2] <===> [шлюз в MOEX] <=> [MT5 торговый сервер] <=> [Точка доступа] <================> [Терминал] そのため、MT5端末-MT5アクセスポイントの経路ですでに問題が発生しており、取引に到達していないことがわかります。2) 他のクライアントのpingを分析したところ、変動はありましたが、安定したパターンは見つかりませんでした（例えば、同時にpingが大幅に増加する場合など）。それをどうするか？ 1) 端末にpingロギング機能を追加しました。この機能は次のベータ版リリースで利用可能になる予定です。発売されたら、ここに掲載します。また、将来的にはコンポーネント間の定期的なping計測をプラットフォームに組み込み、ネットワーク上の問題（の可能性）を調べる予定です。2) Discoverに追加でネットワーク情報を要求してみました。アクセスサーバー4は、アクセスポイント（2,3）とは異なるプロバイダー経由でインターネットに接続し、Discoverネットワーク内でトレードサーバーと異なる方法で接続されています。ある予感が...。ふと思ったのですが、端末に注文（オーダー）を送ったという ログが 残ったらどうでしょう？しかし、送信されなかった（遅延）、それなら（なぜターミナルからMT5サーバーへのPingが長すぎるのか）説明がつく。 Aytugan Khafizov 2015.09.03 06:59 #340 Михаил:端末が注文（オーダー）を送ったという ログを 残したらどうだろうと思ったんです。が、実際には送信していない（遅延している）ことが、すべての説明となります（なぜターミナルからMT5サーバーへのPingが大きすぎるのか）。端末はサーバーと1本のTCP接続を保ち、サーバーとログ、チャート、取引注文をやり取りする。もちろん、注文の優先順位は高いです。取引要求送信のための別コネクションの確立に数秒と非常に長い時間を要するため、単一コネクションでの運用を行う。そのため、端末では次のようなことが起こります。端末の取引部は、内部の端末接続マネージャにデータを送信するコネクションマネージャーがOSにデータを渡すオペレーティングシステムがインターネットにデータを送信する インターネットからデータが来た場合、OSはそれが端末向けであると判断し、端末接続マネージャを呼び出し、端末接続マネージャは内部プロトコルに従ってデータが属する端末コンポーネントを判断する接続中のすべてのTCPパケットには連番が振られている。パケットを受信するごとに、OSは受信確認を送信する。また、OSは受信したパケットを監視し、このような番号のパケットが受信されていないことを確認すると、送信者に対して、このような番号のパケットを再送するようにという特別なメッセージを送信します。そのため、パケットが「途中で」失われたとしても、アプリケーションには知らされず、両側のオペレーティングシステムが失われたパケットを補うことになる。しかし、再送には時間がかかり、OSは「古い」パケットをすべて順番に受信するまで「新しい」パケットの再送を行わない。そのため、アプリケーション側からは、OSが回復させたパケットの損失が遅延として見えてしまう。Open側では、取引サーバーが「問題のある」取引の実行を1-2msで記録していることがわかります。現在のところ、「取引所」-「ゲートウェイ」、「ゲートウェイ-トレーディングサーバー」、「トレーディングサーバー-アクセスポイント」の各セクションに問題はないとのことです。現在、アクセスポイントと「アクセスポイント-端末」の部分を扱っています。 1...272829303132333435363738394041...156 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
2014.12.16にこのスレッドを立ち上げました。
現在、2015年9月です。
公平を期すために、オリジナルのプラットフォーム構想による全般的な遅れを指摘する必要があります。
は非常に早く修正 されましたが、開発者が「フローティングシングル」の遅延を真摯に受け止めなかったことは限りなく残念です。
これは、取引において致命的であることが判明しました（デモとリアル口座で異なるブローカーでテストされたため）。
を見ると、MT5のサーバー部分で遅延が 発生していることが一目瞭然です）。
このエラーの検出がユーザーによって行われ、開発者によって行われなかったのは非常に残念なことです。
レナートは2014.12.29に「作業は継続する」と断言しましたが。
"時折発生するターミナルまでのフローティングレスポンスの納期は、まだケアできていないので、引き続き 取り組んでいく。"
マイケル、もしかして遅延の原因は機材にあるのでは？それとも、機材は常に故障なく動くものだと思っているのでしょうか？サーバーハードウェアの開発者に手紙を出すのは意味があることかも？
ウラジミール！
この書き込みと過去ログをよく読むべし!
DIFFERENT BROKERSは、デモでもリアル口座でも同じ効果を発揮します。
ウラジミール！
この書き込みと過去ログをよく読むべし!
リアルブローカーとデモブローカーで同じ効果がある！？
非常に多くの場合、証券会社のビジネスの作成/メンテナンスは、順番にほぼ同じサーバを置く専門会社によって行われ、すなわち、別のブローカーと機器が1と同じである...
異なるブローカーのサーバーが同じラックに並んでいることがあるのですが...。
非常に多くの場合、証券会社のビジネスの作成/サービスは、順番にほぼ同じサーバを置く専門のオフィスによって処理される、すなわち、ブローカーが異なっているが、機器が同じである...
異なるブローカーのサーバーが1つのラックに収まっていることがある ...
ウラジミール！
大きなお願いがあるんです。
作らないでくださいよ。
ウラジミール！
あなたに大きなお願いがあります。
妄想はやめてください。
このビジネスの仕組みがわからないと、誰かが妄想しているとは限らない、証券会社を設立するには人脈が必要なのか？
この投稿からEAでサーバーをテストしていると理解していいのでしょうか？https://www.mql5.com/ru/forum/38456/page37#comment_1869077
以下は私のログです。
MT5サーバーは1分間に何回、1秒間に何回リクエストを処理できるんだろう...。
今朝( リアル) Accsess server 4:
これを「シングル」ディレイと呼んでいいのでしょうか？
そのため、代替チェック（CheckOrders()）機能が作動しています。
今朝（リアル）Accsess server 4:
ディスカバリー社からの情報では、AS4は使わない方が良いとのことです。
AS2を使用した方が良い
Michaelさん、Discoveryアクセスポイントからのログインログを解析した結果、以下のことがわかりました。
1) データセンターのログをターミナルに接続すると、これらのpingは10ms程度に保たれますが、最大で500msのスパイクがあります。
Access Server2 2015.08.25 08:48:15.666 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 10.89 ms)
Access Server3 2015.08.25 00:07:19.069 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 500.40 ms)
Access Server3 2015.08.25 08:48:28.696 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 12.03 ms)
Access Server3 2015.08.26 04:10:52.879 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 506.13 ms)
Access Server3 2015.08.27 01:08:15.820 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 8.12 ms)
Access Server2 2015.08.27 01:08:18.776 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.12 ms)
Access Server2 2015.08.27 02:32:48.278 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.07 ms)
Access Server2 2015.08.27 09:05:51.324 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.65 ms)
Access Server3 2015.08.27 09:06:04.272 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.75 ms)
アクセスポイントから端末へのPingです。
| зона ответственности Биржи || зона ответственности Открытия || интернет || клиент |
[биржа (ФОРТС)] <==> [шлюз Plaza2] <===> [шлюз в MOEX] <=> [MT5 торговый сервер] <=> [Точка доступа] <================> [Терминал]
そのため、MT5端末-MT5アクセスポイントの経路ですでに問題が発生しており、取引に到達していないことがわかります。
2) 他のクライアントのpingを分析したところ、変動はありましたが、安定したパターンは見つかりませんでした（例えば、同時にpingが大幅に増加する場合など）。
それをどうするか？
1) 端末にpingロギング機能を追加しました。この機能は次のベータ版リリースで利用可能になる予定です。発売されたら、ここに掲載します。また、将来的にはコンポーネント間の定期的なping計測をプラットフォームに組み込み、ネットワーク上の問題（の可能性）を調べる予定です。
2) Discoverに追加でネットワーク情報を要求してみました。
アクセスサーバー4は、アクセスポイント（2,3）とは異なるプロバイダー経由でインターネットに接続し、Discoverネットワーク内でトレードサーバーと異なる方法で接続されています。
ある予感が...。
ふと思ったのですが、端末に注文（オーダー）を送ったという ログが 残ったらどうでしょう？
しかし、送信されなかった（遅延）、それなら（なぜターミナルからMT5サーバーへのPingが長すぎるのか）説明がつく。
Михаил:
端末が注文（オーダー）を送ったという ログを 残したらどうだろうと思ったんです。
が、実際には送信していない（遅延している）ことが、すべての説明となります（なぜターミナルからMT5サーバーへのPingが大きすぎるのか）。
端末はサーバーと1本のTCP接続を保ち、サーバーとログ、チャート、取引注文をやり取りする。もちろん、注文の優先順位は高いです。取引要求送信のための別コネクションの確立に数秒と非常に長い時間を要するため、単一コネクションでの運用を行う。
そのため、端末では次のようなことが起こります。
- 端末の取引部は、内部の端末接続マネージャにデータを送信する
- コネクションマネージャーがOSにデータを渡す
- オペレーティングシステムがインターネットにデータを送信する
インターネットからデータが来た場合、OSはそれが端末向けであると判断し、端末接続マネージャを呼び出し、端末接続マネージャは内部プロトコルに従ってデータが属する端末コンポーネントを判断する接続中のすべてのTCPパケットには連番が振られている。パケットを受信するごとに、OSは受信確認を送信する。また、OSは受信したパケットを監視し、このような番号のパケットが受信されていないことを確認すると、送信者に対して、このような番号のパケットを再送するようにという特別なメッセージを送信します。そのため、パケットが「途中で」失われたとしても、アプリケーションには知らされず、両側のオペレーティングシステムが失われたパケットを補うことになる。しかし、再送には時間がかかり、OSは「古い」パケットをすべて順番に受信するまで「新しい」パケットの再送を行わない。そのため、アプリケーション側からは、OSが回復させたパケットの損失が遅延として見えてしまう。
Open側では、取引サーバーが「問題のある」取引の実行を1-2msで記録していることがわかります。現在のところ、「取引所」-「ゲートウェイ」、「ゲートウェイ-トレーディングサーバー」、「トレーディングサーバー-アクセスポイント」の各セクションに問題はないとのことです。現在、アクセスポイントと「アクセスポイント-端末」の部分を扱っています。