4

名前が示すように、1 人のトレーダー (送信者) から複数の他のトレーダー (受信者) にトレードをミラーリングするために使用される「トレード コピー」ソフトウェアがあります。これには、次の 3 つの主要コンポーネントがあります。

1. 送信側クライアント。

2. サーバー。

3. 受信側クライアント。

送信者 -> サーバー -> 受信者

送信側はMQLスクリプトを使用して構築されます。MQL は、C++ を使用して構築されたトレーダー向けのプログラミング言語です。送信者は 1 人であるため、送信者コードは取引情報 (またはシグナル) をサーバーにプッシュします。サーバーはシンプルな MySQL データベースを備えた PHP ベースで、管理者はこのシグナルの転送先ユーザーを管理できます。レシーバーも MQL を使用して構築されています。しかし、現在は独自の手法を使用して構築されています。明確にするために、コードを初めて手に入れたので、元のプログラマーはどこにも見当たりません (予想どおり)。問題に戻ると、受信側のクライアントには、更新のためにサーバーを「ポーリング」しているように見えるコードがあります。MQL は C++ ライブラリを使用して、 InternetOpenUrlAを使用するInternetReadFile関数を呼び出しました. MQL は X ミリ秒ごとにサーバーにリクエストを送信して、新しいシグナルがあるかどうかを確認し、見つかった場合はプルします。MQL コードの提供が役立つ場合は、それを行うことができます。

今私の質問に。

  1. これは良いアプローチですか？受信ユーザーが数百人に増え、各ユーザーが X ミリ秒ごとにサーバー (または InternetReadFile を使用して行っていること) を "ポーリング" するとどうなりますか。X によっては、ある時点でサーバーの CPU を強制終了するだけではありませんか? これはプル サービスとして実装されているように見えますが、すべての受信側クライアントが常に要求するのではなく、サーバーがこの情報をプッシュする必要があると考えています。

  2. 上記の質問に対する答えが「それは悪いアプローチです」である場合、最良のアプローチは何ですか? サーバーから各レシーバーにソケット通信を介して信号をプッシュするのは良い考えですか? 受信側のクライアント エンドで「ポート フォワーディング」や「IP の変更」などの問題が予想されますか? それとも、プログラムで克服できますか?

コードを提供し、さらに明確にします。

4

1 に答える 1

4

ポーリングするものはすべて、遅延を引き起こし、余分なトラフィックを生成するため、逃れられません。理想的には、「ソケットからソケットへ」またはzeromqのようなものを使用した非同期プッシュ（これもソケット経由で、抽象化されたばかり）のイーサダイレクトソリューションを使用することをお勧めします。

問題は、トレーダー ターミナル内で実行するときに努力する価値があるかどうかです。端末からサーバー、端末へと移動しているため、遅延はすでに固有のものです。さらに、ブローカーの実行速度だけでなく、受信側での実行によっても遅延が発生します。したがって、最終的には、市場が動いているときに、オリジナルとコピーの間に大きな違いが見られ、ソリューションの目的が台無しになります。この機能は実際にはブローカーによって提供され、サーバー API プラグインまたはマネージャー API (少なくとも) に実装されるべきものです。そのほとんどのブローカーの設定の不足: 遅延 + スプレッド + マークアップは、「良い」取引をコピーすることによって得たい場合、クライアントの利点を食い尽くします。

ネットワークの問題に対処するには、クライアントが mt4 を実行していることを知っているので、クライアント マシンで 443 アウトバウンドを開く必要があることも知っています。また、特に現在のソリューションでは通信に http が使用されているため、http(80) も同様に開いていることを確信できます。したがって、443 または 80 でサーバー ホストを作成し、送信者と受信者の両方がクライアントとしてサーバーに接続する場合、クライアント IP とファイアウォールの設定は重要ではありません。インストール/トラブルシューティング中にクライアント側のポートを微調整できるように、いつでも何らかのファイルベースの構成を実装できます。最後に、ネットワークの問題がポーリングであろうと非同期であろうと、すべてソケット上の tcp に要約されます。

于 2012-11-27T17:41:25.273 に答える