谁已经尝试了信号订阅，以获取ATC 2012参与者的尾巴？ - 页 5 123456789101112...83 新评论 Andrey Khatimlianskii 2012.10.08 22:06 #41 St.Vitaliy:也想一想挤奶女工。 你无法避免奶妈们的投诉，我直接写了这篇文章。 Mikhail Antropov 2012.10.08 23:34 #42 租用一个信号是放空的... 知道为什么吗？ Vasiliy Sokolov 2012.10.09 00:47 #43 Renat:此外，还有其他几个问题需要解决。如何处理即将到来的符号穿越？如何处理不可避免的存款过剩和保证停止？当你在一段时间内失去通信时，你如何恢复布局？ 这真是复印机的噩梦，然后还有多个信号的混乱。当没有人有机会证明所有滚动的正确性时，如何向交易员解释最后的混乱局面？我们特意将该系统简化为一个信号，摆脱了最糟糕的后果。特别是考虑到大多数交易将很可能通过云服务器的可信执行令牌机制，这将把信号复制延迟减少到几毫秒。等一下，你不是在开发架构吗？现在是你在写关于用符号搞乱位置和相交的文章。雷纳特。有一个非交易机制来复制交易，它没有连接损失，在重新连接后没有同步问题（想象一下15分钟或2小时没有连接），而且可以100%严格控制。另外，还有MetaTrader 4，没有网状结构。 而网状物本身与此毫无关系。曾几何时，一些人需要开发一个适当的架构，使多币种在净价模式下透明地工作。事实上，一切都被一些爱好者的粗糙想法所限制，这些想法在文章中描述，致力于创建多币种，由于其复杂性和不可靠，只提供给狭窄的 "入门者 "圈子。因此，"成千上万的家庭主妇 "仍然选择MT4，只是因为它对每笔交易的控制很简单，不需要担心哪笔交易应该被关闭，哪笔止损应该被重新安排。 Vasiliy Sokolov 2012.10.09 00:53 #44 Renat:我们特意将该系统简化为一个信号，摆脱了最糟糕的后果。特别是由于大多数交易可能会通过云服务器的可信执行令牌机制，这将使信号复制的延迟减少到几毫秒。 老兄，信号交易的全部意义在于创建一个投资组合。看看产品，A**ri--对管理人员/机器人库的需求本身就创造了这些服务。 Vasiliy Sokolov 2012.10.09 01:06 #45 Renat:到目前为止，你没有提出任何解决问题的办法，只是说 "你没有什么可做的，一般来说，任务是小菜一碟"。考虑到我们为这个问题绞尽脑汁的时间更长。而我们并没有停留在第一步 "嗯，是的，理论上是可以做到的"。实际上，你所有评论的本质被简化为 "给与basta，理论上是可能的，所以不要否认，而我懒得超越第一步的阐述"。 那么你认为独立开发者能做什么呢？MT5是僵化的单片机。他们能做的最好的事情是创造另一个拐杖，并在相应的文章中描述它。如果不将其整合到产品中，你就无法编写一个质量系统。亲身了解这个问题，我可以说，你不能不在服务器端保存状态记录。那么你认为第三方开发者应该如何解决这个问题？最后，他们尽其所能地去做。他们创造了像MQL5<-> DLL <-> SQL这样的拐杖和组合，这很难维护，也不适用于你所推广的大众市场。 Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о запущенной MQL5-программе www.mql5.com Стандартные константы, перечисления и структуры / Состояние окружения / Информация о запущенной MQL5-программе - Документация по MQL5 Renat Fatkhullin 2012.10.09 01:22 #46 komposter: 有特色的是，我之前的帖子中所有的建设性语言都被忽略了 )不幸的是，你方面根本没有任何建设性的意见。只有 "给与 "+单向的声明。也就是说，你没有描述如何解决多个信号的冲突，也没有对如何从失去连接中恢复的问题给出答案。另外，你根本没有解决即将发生的冲突趋于100%概率的责任问题。我并没有白白指出 "我可以为我自己做，我来解决，没关系 "的大众服务解决方案的不可能性。 Vasiliy Sokolov 2012.10.09 01:27 #47 就这个话题而言，我可以根据自己的经验说，这个问题非常复杂，不是简单的复制就能解决的。传统上，它可以分为三个部分。信号复制系统。它 被简化为接收来自交易机器人池的信号，对总头寸进行强制性控制。投资组合管理的体系。一 套规则，根据这套规则，联合账户的资金被重新分配到交易机器人的子账户。 资金管理/风险 管理的体系。一套控制风险的规则和数学公式，并决定投资组合的资本化方式。所有这些在实践中都很难安排，此外，还需要对现有的架构进行严重的修改。 Renat Fatkhullin 2012.10.09 01:38 #48 C-4:等一下，建筑不是你设计的吗？现在你自己也在写立场和性格的重合。我看到很少有人真正思考过处理的实施问题。虽然，你可以从 "给我一个解决方案，交易者需要它，把状态存储在服务器上 "这句话中理解思路。这是可以理解的：把问题最大限度地转移给别人，不去管，如果出了问题--批评他们执行不力。但是，如果你从经纪人、系统供应商、网络基础设施，然后才是交易者的角度来评估这个问题，你会发现所提出的信号混合解决方案并没有一个合理和安全的解决方案。 Andrey Khatimlianskii 2012.10.09 01:39 #49 Renat:不幸的是，根本就没有建设性的态度。只有 "给予和接受 "+单向的声明。换句话说，你没有描述如何解决多个信号的冲突，也没有回答如何从失去通信中恢复的问题。另外，你根本没有解决即将发生的冲突趋于100%概率的责任问题。我并没有白白指出 "我可以为我自己做，我来解决，没关系 "的大众服务解决方案的不可能性。 禁止我发表未经证实的言论。只要答应我，你会去休息。 Renat Fatkhullin 2012.10.09 01:41 #50 C-4: 那么你认为独立开发者能做什么呢？MT5是僵化的单片机。他们能做的最好的事情是创造另一个拐杖，并在相应的文章中描述它。如果不将其整合到产品中，你就无法编写一个质量系统。亲身了解这个问题，我可以说，你不能不在服务器端保存状态记录。那么你认为第三方开发者应该如何解决这个问题？最后，他们尽其所能地去做。他们创造了MQL5<-> DLL <-> SQL的拐杖式 拐杖和组合，难以维护，而且不适用于大众市场，而你却如此称赞。你错了。MQL5是如此的开放和实用，你几乎可以做任何事情。没有必要用DLL和SQL做拐杖，使用文件操作并在磁盘上存储你需要的一切就足够了。全局变量数据库非常稳定，在重新启动或崩溃时不会丢失。而服务器上的状态存储是medgies和评论。要学会少用它们。 123456789101112...83 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
也想一想挤奶女工。
租用一个信号是放空的...
知道为什么吗？
此外，还有其他几个问题需要解决。
我们特意将该系统简化为一个信号，摆脱了最糟糕的后果。特别是考虑到大多数交易将很可能通过云服务器的可信执行令牌机制，这将把信号复制延迟减少到几毫秒。
等一下，你不是在开发架构吗？现在是你在写关于用符号搞乱位置和相交的文章。
有一个非交易机制来复制交易，它没有连接损失，在重新连接后没有同步问题（想象一下15分钟或2小时没有连接），而且可以100%严格控制。另外，还有MetaTrader 4，没有网状结构。
我们特意将该系统简化为一个信号，摆脱了最糟糕的后果。特别是由于大多数交易可能会通过云服务器的可信执行令牌机制，这将使信号复制的延迟减少到几毫秒。
到目前为止，你没有提出任何解决问题的办法，只是说 "你没有什么可做的，一般来说，任务是小菜一碟"。
考虑到我们为这个问题绞尽脑汁的时间更长。而我们并没有停留在第一步 "嗯，是的，理论上是可以做到的"。
实际上，你所有评论的本质被简化为 "给与basta，理论上是可能的，所以不要否认，而我懒得超越第一步的阐述"。
有特色的是，我之前的帖子中所有的建设性语言都被忽略了 )
不幸的是，你方面根本没有任何建设性的意见。只有 "给与 "+单向的声明。
也就是说，你没有描述如何解决多个信号的冲突，也没有对如何从失去连接中恢复的问题给出答案。
另外，你根本没有解决即将发生的冲突趋于100%概率的责任问题。我并没有白白指出 "我可以为我自己做，我来解决，没关系 "的大众服务解决方案的不可能性。
就这个话题而言，我可以根据自己的经验说，这个问题非常复杂，不是简单的复制就能解决的。传统上，它可以分为三个部分。
所有这些在实践中都很难安排，此外，还需要对现有的架构进行严重的修改。
等一下，建筑不是你设计的吗？现在你自己也在写立场和性格的重合。
我看到很少有人真正思考过处理的实施问题。
虽然，你可以从 "给我一个解决方案，交易者需要它，把状态存储在服务器上 "这句话中理解思路。这是可以理解的：把问题最大限度地转移给别人，不去管，如果出了问题--批评他们执行不力。
但是，如果你从经纪人、系统供应商、网络基础设施，然后才是交易者的角度来评估这个问题，你会发现所提出的信号混合解决方案并没有一个合理和安全的解决方案。
不幸的是，根本就没有建设性的态度。只有 "给予和接受 "+单向的声明。
换句话说，你没有描述如何解决多个信号的冲突，也没有回答如何从失去通信中恢复的问题。
另外，你根本没有解决即将发生的冲突趋于100%概率的责任问题。我并没有白白指出 "我可以为我自己做，我来解决，没关系 "的大众服务解决方案的不可能性。
那么你认为独立开发者能做什么呢？MT5是僵化的单片机。他们能做的最好的事情是创造另一个拐杖，并在相应的文章中描述它。如果不将其整合到产品中，你就无法编写一个质量系统。亲身了解这个问题，我可以说，你不能不在服务器端保存状态记录。那么你认为第三方开发者应该如何解决这个问题？最后，他们尽其所能地去做。他们创造了MQL5<-> DLL <-> SQL的拐杖式 拐杖和组合，难以维护，而且不适用于大众市场，而你却如此称赞。
你错了。
MQL5是如此的开放和实用，你几乎可以做任何事情。没有必要用DLL和SQL做拐杖，使用文件操作并在磁盘上存储你需要的一切就足够了。全局变量数据库非常稳定，在重新启动或崩溃时不会丢失。
而服务器上的状态存储是medgies和评论。要学会少用它们。