是的,
DDE-request
是一种可能的 MetaTrader 终端集成方法,
但是......!
鉴于人们只需要单向的通信方向,并且业务领域不是任何关键任务领域。
虽然我记得当银行间货币市场交易依赖于 REUTERS 产品时,基于 Excel 电子表格的“分析”具有大量附加组件,但可以公平地说,这样的日子已经一去不复返了。只需比较在通过代理经纪商全面开放外汇交易之前的那些(仅银行间交易日)中常见的交易事件有多少。
在那一天,中间QUOTE
的延误以分钟为单位。
还有今天?
如果一个来源是 LP 提供者的数据馈送,则有许多单位,如果不是几十个 PriceDOMAINQUOTE
事件,一毫秒。
明白了吗?对于具有事件流
的系统而言,DDE 本身是一种危险的方法,并且可能很高兴知道,它在 Vista 推出时已经有效地停止了N [kTPS]
如果一个人的业务领域是处理 AUM 的风险价值超过几百万美元的外汇交易,那么没有人会冒表现不佳或服务中断的风险。
基于 DDE 的服务已在 MT4 交易域中结束,在Windows Vista 附近的某个地方被引入,因为它正式但间接地终止了对那些日子常用 DDE 服务的混合使用(在 wV 中正式实施,但大多数DDE 调用返回"Not Implemented"
错误/响应)。
这种第一手获得的经验已将人群转移到如何集成交易支持系统的其他方式上,并且在 wV 的噩梦经历中,这些设计根本没有返回以恢复服务,这造成了如此多的痛苦和成本。
最好的下一步:
假设上述项目不是周末的爱好玩具,则需要定义、找到和使用用于此类项目目标的最强大且独立于平台的工具。
有人可能会尝试重振DDE,但这将是一种让时光倒退几十年的尝试。
以同样的方式,一个人会尽力做到最好,不要浪费她/他的时间,将任何直接的应用程序到应用程序集成逻辑重新包装到开销和设计/性能折衷/人工REST - alike re的替罪羊-修饰(非常有限的)WebRequest()
函数调用。虽然有机会将 aWebRequest()
不仅用于 a pull-
,而且还用于准push-
数据服务,但成本和 http-header + http-body 有效负载编码 + 完整的 tcp/ip-stack 相关开销到目前为止还没有-对于给定的目的是合理的,一旦有更智能的设计工具可用
这种现代工具定义的几点:
- 性能扩展(发送 10k、100k、1M+ 更新/秒有多稳定)
- 集成支持(有多少语言绑定/平台支持该工具)
- 线程安全设计(可以使用多少线程(在 MetaTrader 终端受限代码执行环境的限制之外),以减轻任何不利的阻塞或性能瓶颈,并允许分布式系统处理方案的某种故障安全设计)
如果需要一些动手示例,可以看看nanomsg
ZeroMQ 工具和 MetaTrader 终端,它们已经接管了金融科技高性能、可扩展、低延迟的消息传递/信令世界,并且变得稳定/成熟-足以花费合理的时间。