記事"DLLを使用せず、名前のつけられたパイプを使っての MetaTrader 5との通信"についてのディスカッション

 

新しい記事 DLLを使用せず、名前のつけられたパイプを使っての MetaTrader 5との通信 はパブリッシュされました:

多くの開発者が同じ課題に出会います。安全性の低い DLL を使わずトレーディングターミナルのサンドボックスを手に入れる方法です。もっとも簡単で安全な方法の一つは、通常のファイル処理で動作する標準的な「名前付きパイプ」を使用することです。名前付きパイプにより、プロセッサ内でプログラム間のクライアントサーバー通信を行うことができます。サーバー、クライアント、それらの間のデータ交換、パフォーマンスのベンチマークを含んだ C++ 言語および MQL5 での実用例を見ていきます。

多くの開発者が同じ課題に出会います。安全性の低い DLL を使わずトレーディングターミナルのサンドボックスを手に入れる方法です。

もっとも簡単で安全な方法の一つは、通常のファイル処理で動作する標準的な「名前付きパイプ」を使用することです。名前付きパイプにより、プロセッサ内でプログラム間のクライアントサーバー通信を行うことができます。本件に関してはすでに発表済みの記事 A DLL-free solution to communicate between MetaTrader 5 terminals using Named Pipes で DLL へのアクセスの有効化を示していますが、ここではクライアントターミナルの標準的で安全な機能を使用していきます。

MSDN ライブラリで名前付きパイプに関する情報をもっと見つけることができますが、ここでは C++ 言語および MQL5言語での実用例に取り組みます。サーバー、クライアント、それらの間のデータ交換を実装し、基準に従ってパフォーマンスを評価します。

作者: MetaQuotes Software Corp.

 
テスターでピップは機能しますか?
 
Graff:
テスター内でパイプは機能しますか?

異なる端末間の通信がテスターで機能するのはなぜですか?

テスターで動作するイベントを使ってください。

 
Urain:

なぜテスターでは異なる端末間の通信が機能するのでしょうか?

試してみてください。 でも、なぜだかわからないんです...。:)


イベントを通してやれば、テスターでは機能します。

イベントを通してって、端末間の 通信?

;)

 

名前付きパイプラインはローカルエージェントでは動作しますが、クレードでは無効になります。

つまり、個々のテストと大量のローカルエージェントの両方が、サードパーティの(ローカルだけではない)pipサーバに接続できます。

 
MetaDriver:
やってみる価値はあるよ。:)


イベントを通じて?

;)

テスターのプログラム間の通信が必要なら、1つの端末のプログラム間のデータ転送のタスクが目に見える。
 
Urain:
テスター内のプログラム間の通信が必要な場合、1つの端末内のプログラム間のデータ転送というタスクは明らかであり、これはイベントを通じて行うことができ、このすべてのナンセンスを省略し、私の答えは非常に論理的である。
私はそれに入った、それは彼が外部プログラムからテストプロセスを監視することに興味を持っているだけのように私には思えた。
 

ざっと見て、2つの使い方があります:

このトピックに関する記事も興味深いでしょう。

 
Rosh:

ざっと見て、2つの使い方があります:

このトピックに関する記事は興味深いでしょう。

残念ながら、これはWindows用のC言語でプログラミングする方法を知っている人にのみ可能です:

Renat:
ただ、これはクライアントサポートであり、サーバーコネクターはターミナルでは作成できないことに注意してください。

つまり、クライアント・サーバー技術では、サーバーの仲介なしに2つのクライアントがお互いを見ることはできません。他のプログラミング言語でも名前付きチャンネルを作成することができるか調べてみたが、残念ながら、ほとんどの言語では、Windows用のクライアントは標準的な方法で作成できるが、Unix用のチャンネルはほとんどどこでも問題なく作成できる。

そこで、2つの名前付きチャネルを全二重接続するための、EXEシェル形式のゲートウェイが必要になる:

  1. 2つの名前付きチャネルAとBを作成する。
  2. チャンネルAへの接続をリッスンする最初のサブプロセスを作成する。
  3. メッセージを待っているクライアントがチャネルAに接続した後、 チャネルBの接続をリッスンする2番目のサブプロセスを作成する。
  4. 最初のサブプロセスをオンにして、チャネルAからチャネルBへバイトストリームをループ転送する。
  5. クライアントがチャネルBに接続するとすぐに、チャネルBからチャネルAへのループでバイトストリームを読み取るために、2番目のサブプロセスが開始される。
  6. 2番目のクライアントがチャネルBからチャネルAへの最初のメッセージの送信を開始する。
  7. などが繰り返され、どこかのクライアントが落ちるまで続く。1

もちろん、シングルタスクのMQLスクリプトでは、クライアントは情報を非同期で受信したり送信したりできないので、全二重は必要ない。しかし、半二重が適しているのは、サーバーが交換プロトコルを知っていて、あるクライアントから別のクライアントへの送受信がどこで終わるかを簡単に計算でき、逆のモードに切り替えられる場合だけである。もしサーバーがテレパシー能力を持たないためにこのことを知らず、クライアントだけが知っているプロトコルを使ってやりとりしている場合、2つのサブプロセスを持つ全二重が必要となる。このようなゲートウェイは、各クライアントが他のクライアントと通信するためのチャネルを1つしか持たず、クライアント側からの接続順序が何の役割も果たさないので便利である。ゲートウェイのアルゴリズムは、プロトコルに従って最初のクライアントであるクライアントの接続の可能性を排除し、2番目のクライアントが接続する前にメッセージを送信する必要があり、空白への送信は発生しません。

理論的には、名前付きチャネルの数は無制限なので、アルゴリズムに従ってシングルタスクのシンプレックスゲートウェイを作成することが可能である:

  1. ゲートウェイからクライアントへの送信のために、最初の名前付きチャネルが作成される。
  2. 最初のクライアントが接続を確立した後、クライアントからのメッセージを受信するための2番目のチャネルが作成される。
  3. 送信クライアントが2番目のチャネルに接続した後、受信チャネルから送信チャネルへのバイトストリームをループする。
  4. クライアントが脱落したらすぐに両方のチャネルを削除し、ステップ1に進む。

この場合、2つのクライアントを半二重で接続するには、このようなゲートウェイが2つ必要であり、単方向のみの場合は1つになる。全二重ゲートウェイと比較して不利な点は、MQLスクリプトで2つのチャンネル(受信用と送信用)を記述する必要があることと、その中で接続の順序を厳密に守る必要があることである。このゲートウェイのアルゴリズムは、2番目のクライアントが接続する前に、プロトコルに従って最初にメッセージを送信しなければならないクライアントを接続する可能性を排除し、空白への送信は発生しません。

当然ながら、ゲートウェイは、受信-送信-接続のクライアントの順序に応じて、チャンネル名を設定する可能性を提供する必要がある。

もしC言語でプログラミングしている人がこのようなゲートウェイを作成し、EXEにコンパイルしてここに掲載すれば、他のプログラミング言語でタンバリンすることなく、標準のMQL5ツールを使ってスクリプト、Expert Advisor、インジケーター間の接続を簡単に作成できるだろう。

理論的には、C言語プログラマーとの共著で、MQL以外の言語でサーバーを作らないように(C言語でプログラミングできないのは私だけではないはずですよね)、そのようなゲートウェイでクライアントを適切に接続する方法を具体例とともに記事にすることもできます。つまり、私からはMQLでの記事と例を、C-shプログラマーからはCとEXE-shnikiでのゲートウェイのソースを。報酬は分担する。

 
サーバーはシンプルで、/releaseディレクトリにあるコンパイル済みのexeファイルを含め、すべてソースで構成されている。テストは簡単に繰り返すことができる。
 
Renat:
ちなみに、例では誰も待つ必要のない全二重のやりとりを示している。サーバーはシンプルで、/releaseディレクトリにあるコンパイル済みのexeファイルを含め、すべてソースにある。テストは簡単に繰り返すことができる。

問題はそこではない。あなたの例を実行してみました。うまくいった。しかし、何の役にも立たない。つまり、試してみただけで、もう必要ないので削除してもいいのだ。

一方では、あなたはdllを取り除くことができましたが、他方では、アプリケーションの使用には、やはり他のプログラミング言語の松葉杖が必要です。

提案された方法の欠点は、MQL以外の言語でアプリケーションを開発し、Windows APIをサポートしているプログラマーにのみ適しているということです。つまり、提案された例は普遍的なものではなく、修正なしに他のタスクに適応させることはできない。そして、誰もが異なるタスクを持っている。そしてこれは、ユーザーがMQLに加えて別の言語を勉強するために、2つのスクリプト間の情報の初歩的な交換さえも作成しなければならないことを意味するので、その上に、交換プロトコルに関連するロジックの一部を記述する必要があるサーバーを作成します。

私は、ゲートウェイを一度作成し、コンパイルして、すべての来訪者に提供することで、標準的なMQLツールだけを使用して、どのユーザーでも接続を作成できるようにすることを提案します。

例えば、私にとっては、開いている生ファイルがCであろうと閉じている生ファイルがCであろうと違いはない。なぜなら私はC言語では何も書かないし、フライトを整理するのにも時間がかかるからだ。同じ生ファイルをコンパイルすることもできない。そして、ピュアJavaでも、他の多くのプログラミング言語でも、標準的なツールを使ってファイルストリーム経由のクライアント接続だけを作ることができる。少なくとも2つの名前付きチャンネルを シンプレックスで接続するゲートウェイがあれば、何の問題もないだろう。クライアントに交換プロトコルを書いて、いくつかのゲートウェイを経由して接続し、デバッグすればすべてがうまくいく。つまり、それぞれのタスクのために別個のサーバーを設計・作成する必要はない。

そして現時点では、つまりゲートウェイがなければ、多くの人がC言語用の開発環境をインストールしたり、新しいプログラミング言語を学んだりしなければならない。

ゲートウェイは、あるクライアントから受け取ったものを別のクライアントに送信する。つまり、情報交換のプロトコルやC言語の知識とは関係なく、普遍的なものなのだ。

つまり、情報交換のプロトコルやC言語の知識に依存しない普遍的なものなのだ。C言語で何かを開発する人は、何の問題も感じないだろう。それ以外の人たちは、好きなようにこのシステムを扱うことができる。