MQL：セキュリティと機会
良いポストです。
レナートは普通にこれらに来て、サンドボックスから糞が見えない、理解できないって言ってる。
良いポストです。
これらは通常、Renatを来て、あなたのサンドボックスからクソを見ないと理解していないと言う。
楽しみに待っていよう。
ZS. 投票を行うのは良いアイデアだと思います。
ZS.ZS.これはカルテットにも適用されます。
ニーズはあるのです。そして、そのようなニーズは、最も興味深い仕事の中で生まれるのです。
オフトピックですが、この機会に、ResourceRead() がかつて約束されていたことを思い出します。少なくとも、端末内部の専門家が大量の情報をやり取りすることは可能だ。
開発者なら誰でも、自分たちで好きなソリューションを作り、好きなように端末に送受信することができる。しかし、標準的なホールを作るつもりはありませんし、100％すべての端末に対応するグローバルな標準ホールを作るつもりもありません。さらに、ネットワークhttp接続もしない。
次のビルドでは、トレードサーバーとのカスタムネットワーク相互作用の新しい方法があり、MQL4/5のブローカーと開発者は、ハンドラがプラグインで書かれているサーバー上のサポートでターミナルの機能を拡張することができます。
次のビルドでは、MQL4/5上のブローカーや開発者が、ハンドラがプラグインで書かれているサーバー上のサポートで端末機能を拡張できるように、トレードサーバーとのカスタムネットワーク対話の新しいメソッドが用意される予定です。
あえて言えば、双方向のパイムを編成することで、MT5は実質的にサードパーティアプリケーションと取引所の間の転送リンクに過ぎないということでしょう。この場合、いわゆる新しい独立したプログラム、つまり端末への適応が登場する。実際、MQの技術に寄生し、金融市場での仕事を「さらに便利で生産的に」することを約束する直接の競争相手が、月額わずか29.95ドルで現れるのは必然的なことである。
その通りです。
さらに重要なことは、最初のプログラムはすべて本質的にスパイウェアであり、アカウント、履歴、アカウント設定に関する 重要な情報を大量に収集することです。サードパーティの開発者は、この問題に対してブレーキがかからない。彼らはセキュリティやプライバシーの破壊を気にしない。何が問題なのか、純粋に「わからない」のである。捕まえると、最後まで反発して、「長年助けてもらっているのに、私たちの苦労を奪うのか！」となってしまうのです。これは、私たちの権利の侵害、ライセンスの侵害、完全なハッキングは言うまでもありません。
このような「助け合い」はもうたくさんなので、ルールを厳しくしているのです。
この点について、詳しく教えてください。
ブローカー（またはサードパーティの開発者）は純粋なMQL4/MQL5でプログラムを書き、合法的にそれを彼らの配布パッケージに含めることができ（我々はそれを彼らの配布パッケージに含める）、プリセットの指標とEAでデフォルトチャートをセットアップすることができます。我々は、カスタマイズされたプログラム（純粋なMQL4/MQL5コードのみをベースとし、DLLや狂信的なものを含まない）をブローカー独自の配布物に含めることに反対しているわけではありません。
このプログラムは、取引サーバーがサポートする独自の機能を実装することができます。この目的のために、MetaTrader 4/5 Server API用のプラグインがサーバー用に書かれており、ターミナル内のMQL4/MQL5プログラムから送られるカスタムコマンドパケットを受信して応答することができます。
そのため、ブローカーは顧客のセキュリティを犠牲にすることなく、またシステムのライセンスに違反することなく、端末の機能を拡張することができます。サードパーティの開発者は、自社ソリューションを合法的に、かつ自社内で販売する新たな機会を得ることができます。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
長年のMQLの経験を分析し、自分のニーズとマッチングさせようとした結果、気づいたのです。
タスクごとに現れるつまずきの中で最も多かったのは、双方向の情報 交換であった。
それは簡単です：MQLの古代の斧 - Expert Advisorから情報を取得する唯一の方法、それはハードウェア上のファイルである。現在の基準では、プログラマーの努力の原始的な道具である。
この事実を認識することは、必要な 開発の方向性を理解する上で、少なからず必要なことである。
そして、他の情報伝達のバリエーションを求めて、どれだけのコードがかき集められたことでしょう。
でも、どれもMQL以外のツールを使うことに集約されるのですが...。残念ながら。
端末間や端末と他のアプリケーションとの情報交換、サイトへのデータ送信、エージェントへの情報送信、エージェントからEAへの情報送信など、ユーザーや開発者の皆さんは、このリストを続けることができます。
私たちは長年にわたってMQLを積極的に実践し、ほとんどすべてのシステムツールを適応させ、再テストしてきました。
- メール、FTP、Pushメッセージの合法的な送信
- ターミナルフォルダ外のファイル
- マッピング
- パイプ
- ソケット
パイプは情報交換の技術として開発者から与えられているのに、なぜか切り捨てられた形で使われている。MQLのパイプは、クライアントサイドのみ可能です。
驚きと疑問があるのですが、なぜクライアントサイドだけなのでしょうか？ こちらでは「黒一文字」なのですが...。
この制限をセキュリティの観点から分析しようとしたところ、MQLサーバーパイプはセキュリティに影響を与えないという結論に達しました。私の現在のバージョンでは、自作のサーバーexeファイルが必須なので、一概に安全とは言えません。
開発者が怠慢なのでは？ そんなことはない、積極的にサポートや開発をしている...。
-----
1年以上前、Renatは 私にシステムのwinsock2を自作 DLLなしでMQLに移植することを勧めてくれました（その方法については 記事に 一部記載しました）。
MQLのコードを使って、サーバーをアップエンド し、 ノンブロッキングモードに変換し、ミリ秒タイマー（当時はまだそう でした）でポーリングしてクライアントを受け入れ、同じタイマーでクライアントにサービスを提供する......というものでした。
レナートは当時、「ある」技術的な理由でこれは不可能だと言っていた。しかし、その逆で、すべてが可能であり、最大限の可能性を持っていることがわかったのです。
エキスパートサーバーをチャート上に直接作り、インターネット上のどのコンピューターからでも接続できる--これは画期的な操作技術だった。p2p接続、コピー機、シンクロナイザー、オプティマイザー、分散タスクなどへ直接ターゲッティング。
-----
そこで、MQLのさらなる発展についての質問に戻りますが、このようにまとめたいと思います。
親愛なる開発者の皆さん、あなたと私はいつになったら、古代のファイルから、より居心地の良い、より速く、より優れたツールであるクライアント/サーバー技術へとステップアップできるのでしょうか？
結局、クライアントにピップを与えたということは、自動的にサンドボックスからの取り消し不能な退出を 意味するのです。MQLのクライアントパイピングは、サーバーパイピングの自作を意味し、まさにアウトなため。
PS.
最近、その例として、現地代理店への情報伝達について重要な トピックが挙げられました。これでまた一つ、目が覚めたのではないでしょうか。このようなトピックはたくさんあり、MQLユーザーはそれぞれ自分の知識に応じて解決しようとしています。
これまで私は、MQLに内蔵された情報交換ツールの重要性を理解していませんでした。要求水準は考えていない。
しかし、このような話題を分析すると、「双方向の情報交換が必要 だ！」という明確な結論に至ります。
石を集めるときが来たのだ。