フォルツァ執行上の問題点 - ページ 125

新しいコメント
 
Andrey Gladyshev:
はい、そしてそれはどのような交換かによって異なります。私たちのことは考えていません。

他の人はどうかわからないけど。しかし、クライアントからの入札を受け、フレームを放送し、また受信して放送するという原理は同じです。問題は、このフレームの頻度と入札の頻度です。

 
Aleksey Vyazmikin:

交換は同じように放送されます。それとも、カップのコマ落ちがあるとおっしゃるのでしょうか？

これらの点については、別途認識する必要があります。どのようなサンプリングレートで撮影されているのか。

 
Andrey Gladyshev:

これらの点については、別途認識する必要があります。画像がどのようなサンプリングレートで撮影されているか。

おそらく、同社のホームページのドキュメントに記載されているはずです。

 
Aleksey Vyazmikin:

他の人はどうかわからないけど。しかし、クライアントからのリクエストを受信し、フレームをブロードキャストし、また受信とブロードキャストを繰り返すという原理は同じで、問題はこのフレームの頻度とリクエストの頻度なのです。

すでに回答済みであることがわかりました。

 
CMEについてです。ドキュメントを読まなければならない。
 
Andrey Gladyshev:
CMEということです。ドキュメントを読まなければならない。

これもFORTS、アメリカだけです。先物

 
そして、一般的には、要するに、ある程度のレベルで横並びを見つけるという計画なのです。近傍の小さな動きを追跡することが目的です。遠くの目標はない。
 
Sergey Chalyshev:

またサーバーがおかしくなった(((;゜Д゜)))

3 分間ハンギングした後、[Request timeout] を実行する。

Discovery Server、Terminal Build 1947。
どうしたらいいんだろう？



以下のようなケースで、3分ちょうどのハングアップが何度か発生しました。

1) サーバとの接続が短時間（例えば100ms）途絶えました。

2) あるExpert Advisorが注文の削除要求を送信する（OrderSend() ）。

3) 2番目のEAが同じ注文の削除依頼を出す（OrderSend() ）。

4) 最初のEAが接続すると同時に＋少し遅れてOrderSend()が正常に完了し、注文は確かに削除されます。

5) 2つ目のEAが「ハングアップ」する。OrderSend()が呼び出されてからちょうど3分後、retcode=10012 comment="リクエストタイムアウト "という結果で終了しています。


注文が本当に削除され、最初のEAがこれを見たことを考慮すると、取引所は何の関係もなく、単なる端末とEAの相互作用である。サーバーとの取引操作が 完了すると、この操作の実行を待っている最初のEAだけが回答を得るようです。同じ操作を待っているExpert Advisorがある場合、その回答は受け取らず、タイムアウトで操作の実行を終了します。

 
Aleksey Vyazmikin:

私が理解する限り、株式のキャストは、一定の頻度で交換によって放送されている、すなわち、すべての変更は、ちょうど取得することはできません。

それと、やはり理解できないのは、それで何をするのか、ということです。特に、強い動きがあったときに、遅れてデータが来るようでは...。
モスバーガーのホームページで「フルオーダーログ」と検索してください。
 
Dmitriy Skub:
モスバーガーのホームページで「フルオーダーログ」と検索してください。

こんな情報が ありました。

テストでは、バッチングをオフにしたフルリクエストログストリームを発行するバトルサーバーと、Plaza II/CGateサービスと同様に10ms単位でデータをグループ化したアグリゲーションスタックを発行するバトルサーバーを用意しました。

つまり、量子化は10msです。それとも何か、役に立つことを発見するはずだったのか？

1...118119120121122123124125126127128129130131132...156
新しいコメント
理由: