MQL：安全与机会
我订阅了每一个字。
好帖子。
雷纳特通常会来到这些地方，说你看不到狗屎，不明白从你的沙盒。
TheXpert:
好帖子。
在这些通常来Renat和说，你没有看到狗屎，不明白从你的沙盒。
让我们拭目以待。
ZS.举行投票将是一个好主意，这不是一个空洞的问题。
ZS.ZS.这也适用于四重奏。
现在是时候了...
需求是存在的。而这样的需求是在最有趣的任务中产生的。
离题了，但借这个机会，我提醒你，ResourceRead() 曾经被承诺过。它至少可以让终端内部的专家们交换大量的信息。
像往常一样，只谈好处，完全忽略了安全和后果。另外，评估是由一个交易员进行的。
任何开发者都可以为自己制定任何解决方案，并向/从他们的终端传输任何他们想要的东西。但我们不会做一个标准的孔，我们也不会为100%的所有终端做一个标准的全球孔。此外，我们不会进行网络http连接。
在接下来的构建中，将有一种与交易服务器进行自定义网络互动的新方法，这将允许MQL4/5上的经纪人和开发人员扩展终端的功能，支持在插件中编写处理程序的服务器。
任何开发者都可以为自己制定任何解决方案，并向/从他们的终端传输任何他们想要的东西。但我们不会做一个标准的孔，我们也不会为100%的所有终端做一个标准的全球孔。此外，我们不会进行网络http连接。
在接下来的构建中，将有一种与交易服务器进行自定义网络互动的新方法，这将允许MQL4/5上的经纪人和开发人员扩展终端的功能，支持在插件中编写处理程序的服务器。
Renat:
在接下来的构建中，将有一种与交易服务器进行自定义网络互动的新方法，允许MQL4/5上的经纪人和开发人员扩展终端功能，在处理程序被写入插件的服务器上支持。
关于这一点的更多细节？
在接下来的构建中，将有一种与交易服务器进行自定义网络互动的新方法，允许MQL4/5上的经纪人和开发人员扩展终端功能，在处理程序被写入插件的服务器上支持。
我敢说，双向佩恩的组织将从本质上使MT5只是第三方应用程序和交易所之间的传输链接。在这种情况下，所谓的新的独立程序的出现，在终端上的附加组件 - 事实上，MQ的直接竞争对手寄生在他们的技术上，并承诺使金融市场的工作 "更方便和富有成效"，每月只有29.95美元是不可避免的。
C-4:
我敢说，双向paim的组织将在本质上使MT5只是第三方应用程序和交易所之间的一个转移环节。在这种情况下，所谓新的独立程序的出现--适应终端--事实上，MQ的直接竞争对手寄生在他们的技术上，并承诺使金融市场的工作 "更加方便和富有成效"，每月只需29.95美元是不可避免的。
我敢说，双向paim的组织将在本质上使MT5只是第三方应用程序和交易所之间的一个转移环节。在这种情况下，所谓新的独立程序的出现--适应终端--事实上，MQ的直接竞争对手寄生在他们的技术上，并承诺使金融市场的工作 "更加方便和富有成效"，每月只需29.95美元是不可避免的。
正是如此。
更重要的是，每一个第一个程序基本上都会是间谍软件，并收集大量关于账户、历史和账户设置的关键信息。第三方开发者在这个问题上没有刹车--他们不关心安全和隐私的破坏。他们真的 "不明白 "问题出在哪里。当你抓住他们时，他们会回绝到最后一刻，然后归结为 "你拿走了我们的辛勤工作，而我们已经帮助你这么多年了！"。这还不包括侵犯我们的权利、许可证和公然的黑客行为。
我们已经看够了这种 "帮助"，因此正在收紧规则。
FAQ:
你能详细说明一下这一点吗？
你能详细说明一下这一点吗？
经纪人（或第三方开发商）可以用纯MQL4/MQL5编写程序，并合法地将其纳入他们的分发包（我们将把它纳入他们的分发包），并设置带有预设指标和EA的默认图表。我们不反对将定制的程序（仅基于纯MQL4/MQL5代码，没有DLL，没有狂热）纳入他们自己发行的经纪商。
这个程序可以实现自己的功能，由交易服务器支持。为此，为服务器编写了MetaTrader 4/5服务器API的插件，它可以接收和响应终端中MQL4/MQL5程序发送的自定义命令包。
因此，经纪人可以在不牺牲客户安全和不违反系统许可的情况下扩大终端的功能。第三方开发商有一个新的机会，可以合法地在内部销售他们的解决方案。
分析我多年来使用MQL的经验，并试图将其与我的需求相匹配，我意识到
最常见的绊脚石，从任务到任务都出现，是信息的双向交流。
这很简单：MQL的古老斧头--只有一种方法可以从专家顾问那里获得信息，那就是硬件上的文件。按照目前的标准，这些都是程序员辛苦工作的原始工具。
对这一事实的认识，对于理解必要的 发展方向并不嫌少。
而为了寻找其他的信息传输变体，有多少代码被铲除了!
但所有这些都可以归结为对非MQL工具的使用...不幸的是。
终端之间以及终端与其他应用程序之间的信息交换，向网站发送数据，向代理商发送信息或从代理商向EA发送信息--我们所有的人，亲爱的用户和开发者，可以继续这个列表。
在我们多年积极的MQL实践中，几乎所有可能的系统工具都被调整和重新测试过。
- 合法发送邮件、FTP、推送信息
- 终端文件夹外的文件
- 绘图
- 管道
- 插座
管道是由开发者给出的一种信息交换技术，但由于某些原因，它们被以截断的形式使用。MQL中的管道只能是客户端的。
我很惊讶，有一个问题：为什么只有客户端？ 这里是 "黑色的独脚"...
试图从安全方面分析这个限制，我得出的结论是：不，MQL服务器管道对安全没有影响。因为在我目前的版本中，自写的服务器exe文件是必须的，所以它并不安全，都是如此。
也许开发商太懒了？ 并非如此，他们积极支持和开发......
-----
一年多以前，Renat 建议我 将系统winsock2移植到MQL，而不需要任何自写 的dll（我在 文章 中部分描述了它是如何做到的）。
MQL代码被用来升级服务器 + 将其转换为非阻塞模式+用接受客户的毫秒计时器轮询（当时仍然如此）+用同样的计时器为他们服务......
雷纳特当时说，由于 "一些 "技术原因，这是不可能的。但结果却恰恰相反--一切皆有可能，甚至是最大的可能!
直接在图表上制作了专家服务器，并从互联网上的任何计算机连接到它--这是操作技术上的一个突破。直接针对p2p连接、复制器、同步器、优化器、分布式任务等。
-----
因此，回到我关于MQL进一步发展的问题，我想这样总结一下。
亲爱的开发者，你和我什么时候才能从古老的文件，迈向一个更舒适、更快、更好的工具--作为客户/服务器技术？
毕竟，你已经给了客户点数的事实--这自动意味着不可撤销地退出 了沙盒。因为MQL中的客户端管道意味着自写的服务器管道，而它只是在它的外面。
PS。
最近，作为一个例子，有人提出了一个关于向当地代理人转移信息的重要 话题。这是对你的又一次警醒。有很多这样的主题，每个MQL用户都试图根据自己的知识来解决这些问题。
直到现在，我还没有理解MQL内置工具对于交换信息的重要性。我还没有考虑到要求的水平。
但对此类话题的分析使我得出一个明确的结论--必须进行双向的信息交流!
收集石头的时候到了。