OrderSendAsync()函数 - 页 8 123456789 新评论 Renat Fatkhullin 2012.06.28 12:32 #71 TheXpert: 因为破损的数据包、丢弃的连接等等都是废话。不可靠的。不可靠 -- 你必须断开连接。为了以防万一，我们将保留发放给EA的贸易交易队列，并将其赠送。执行中的断线是一个问题，目前还不清楚如何处理它们。在任何情况下，我们将能够在重新连接后检查所有未结头寸。 Mykola Demko 2012.06.28 12:38 #72 TheXpert: 因为破损的数据包、丢弃的连接等等都是废话。不可靠的。不可靠的 -- 你必须反弹。让我们把苍蝇分开，把肉片分开。破碎的数据包对终端来说是一种异常情况，应该通过例外情况来处理，包括通过历史分析。但是，在每个贸易中解析历史太昂贵了。贸易的到来是一种正常情况，应该以低成本的方式处理。 TheXpert 2012.06.28 12:41 #73 Urain: 随你怎么做，我不是要激怒任何人。 [删除] 2012.06.28 12:59 #74 TheXpert: 你好。你甚至知道什么是异步吗？据我所知，为多币种EA引入这一功能（对于单币种EA，这一举措没有意义），唯一的目的是通过避免在服务器端执行订单的延迟 来节省时间。如果我说错了，请纠正我。除此之外，只剩下一个时间关键的部分--数据包在通信渠道上的传输。试图把 "未知的边界 "推到 "放弃（数据包）并继续运行 "的水平，你的问题比好处多。重要的是要全面地评估这个问题。可能的超时，如果有的话，很可能不仅影响到某一特定工具的交易能力，而且原则上也会影响到与服务器的通信不畅。此外，不清楚如何从专家顾问那里 估计：交易订单是在数据传输中丢失了，还是在服务器上等待了这么长的时间？而这意味着会出现重复交易订单的错误，这将导致违反MM，从而导致更高的风险。在我看来，任何专业的交易员（专家顾问）应该确保他的交易订单被服务器接受执行。此外，为了明确识别某个交易订单的状态（在OnTrade()函数 中），你需要一个从服务器上 收到的唯一值，以便将其应用于进一步处理（直到交易被执行（开仓/平仓）。它类似于OSI网络模型。我们不需要进入交易订单执行的渠道或物理层。让客户（MT5）执行这个运输功能。在应用层操作。 TheXpert 2012.06.28 13:03 #75 voix_kas:由于 订单执行 中没有服务器端的延迟，因此节省了时间。如果我说错了，请纠正我。以不等待请求的结果为代价。一般说来，是的。也就是说，对于订单和市场执行，它可能非常有用。除此以外，只剩下一个时间关键的部分--数据包在通信渠道上的传输。试图把 "未知的边界 "推到 "放弃（数据包）并继续运行 "的水平，你的问题比好处多。 嗯...不。你只需要在利益大于问题的时候使用它。在我看来，任何专业的交易员（顾问）需要确保他的交易订单被服务器接受执行。 那么异步选项就不适合你。一切都是可以解决的。 [删除] 2012.06.28 13:27 #76 TheXpert让我们再看一遍，在手指上。粗略的结构化的延迟。1.是时候让终端预先检查交易订单，将其 "打包 "到外发批次，并将其放入 "网络队列"。2.包含交易指令的数据包从客户端传输到服务器的时间。3.服务器接收交易订单并将其放入处理池的时间，并向客户发送该票据的唯一标识。4.预处理交易订单的正确性及其在交易大厅的放置时间。如果我指出了错误的地方，请纠正。我理解，你不想在第一点之后等待？而我则主张强制提供前三条。有两个问题需要回答，以便进一步讨论。1.延迟的比例比率。也就是说，平均而言，上述四项中的每一项需要多少时间，以百分比计算。如果分布是，例如，"0.5%-1.0%-1.0%-97.5%"，那么它就不值得了。2）超时和它对交易策略的影响。坦率地说，我无法说出一个不需要清楚了解订单是否已经发送到服务器的TS。这与长期和多货币套利都有关系。也就是说，交易订单的执行保证是不容置疑的。如果你不同意，请提供一个反例。 [删除] 2012.06.28 13:41 #77 papaklass: 在我看来，解决中断时的执行问题的最简单方法是不创建执行队列（取消执行），并在重新连接时通知用户取消执行。这样一来，就不会有什么歧义了。必须返回一张服务器票。这将确保订单到达服务器并被接受处理。在客户端建立狡猾的等待池不仅是一个不切实际的解决方案，我认为这是MT5客户端-服务器架构的一个严重设计 缺陷。 TheXpert 2012.06.28 13:50 #78 voix_kas:客户端上繁琐的等待池并不是一个优雅的解决方案。 这就是所要求的。如果你不需要，没有人强迫你使用它。voix_kas:TheXpert让我们再做一次，在手指上。粗略的结构化延迟。1. 终端预先检查交易订单的时间，将其 "打包 "成可调度的包裹，并将其放入 "网络队列"。2.从客户端向服务器发送包含交易指令的数据包的时间。服务器接收交易订单并将其放入处理池，并向客户发送此票据的唯一标识符的时间。4.预处理交易订单的正确性并将其放在交易大厅的时间。3是更好的划分。 3.1安置3.2 发送UID。如果我指出了错误的地方，请纠正。我理解，你不想在第一件物品之后等待？是的。另一方面，我赞成将前三条作为强制性规定。如果平移是半秒呢？它是异步的。使用这种模式到底有什么意义？ [删除] 2012.06.28 13:55 #79 TheXpert: 这就是所问的问题。如果你不需要，没有人强迫你使用它。你仍然没有回答我的问题。请给我一个具体的例子，在哪些情况下，你可以为了向不同角色发送的速度而不考虑交易订单 执行的保证？ Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Типы торговых операций www.mql5.com Стандартные константы, перечисления и структуры / Торговые константы / Типы торговых операций - Документация по MQL5 TheXpert 2012.06.28 14:04 #80 voix_kas:你仍然没有回答我的问题。请给我一个具体的例子，说明什么时候你可以为了向不同的符号发送的速度而不顾交易订单 的执行保证？没问题--投资组合交易+市场执行。 123456789 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
因为破损的数据包、丢弃的连接等等都是废话。不可靠的。不可靠 -- 你必须断开连接。
为了以防万一，我们将保留发放给EA的贸易交易队列，并将其赠送。
执行中的断线是一个问题，目前还不清楚如何处理它们。在任何情况下，我们将能够在重新连接后检查所有未结头寸。
因为破损的数据包、丢弃的连接等等都是废话。不可靠的。不可靠的 -- 你必须反弹。
让我们把苍蝇分开，把肉片分开。
破碎的数据包对终端来说是一种异常情况，应该通过例外情况来处理，包括通过历史分析。
但是，在每个贸易中解析历史太昂贵了。贸易的到来是一种正常情况，应该以低成本的方式处理。
你好。你甚至知道什么是异步吗？
据我所知，为多币种EA引入这一功能（对于单币种EA，这一举措没有意义），唯一的目的是通过避免在服务器端执行订单的延迟 来节省时间。如果我说错了，请纠正我。
除此之外，只剩下一个时间关键的部分--数据包在通信渠道上的传输。试图把 "未知的边界 "推到 "放弃（数据包）并继续运行 "的水平，你的问题比好处多。重要的是要全面地评估这个问题。可能的超时，如果有的话，很可能不仅影响到某一特定工具的交易能力，而且原则上也会影响到与服务器的通信不畅。
此外，不清楚如何从专家顾问那里 估计：交易订单是在数据传输中丢失了，还是在服务器上等待了这么长的时间？而这意味着会出现重复交易订单的错误，这将导致违反MM，从而导致更高的风险。在我看来，任何专业的交易员（专家顾问）应该确保他的交易订单被服务器接受执行。此外，为了明确识别某个交易订单的状态（在OnTrade()函数 中），你需要一个从服务器上 收到的唯一值，以便将其应用于进一步处理（直到交易被执行（开仓/平仓）。
它类似于OSI网络模型。我们不需要进入交易订单执行的渠道或物理层。让客户（MT5）执行这个运输功能。在应用层操作。
由于 订单执行 中没有服务器端的延迟，因此节省了时间。如果我说错了，请纠正我。
以不等待请求的结果为代价。一般说来，是的。也就是说，对于订单和市场执行，它可能非常有用。
除此以外，只剩下一个时间关键的部分--数据包在通信渠道上的传输。试图把 "未知的边界 "推到 "放弃（数据包）并继续运行 "的水平，你的问题比好处多。
嗯...不。你只需要在利益大于问题的时候使用它。
在我看来，任何专业的交易员（顾问）需要确保他的交易订单被服务器接受执行。
那么异步选项就不适合你。一切都是可以解决的。
TheXpert
让我们再看一遍，在手指上。粗略的结构化的延迟。
1.是时候让终端预先检查交易订单，将其 "打包 "到外发批次，并将其放入 "网络队列"。
2.包含交易指令的数据包从客户端传输到服务器的时间。
3.服务器接收交易订单并将其放入处理池的时间，并向客户发送该票据的唯一标识。
4.预处理交易订单的正确性及其在交易大厅的放置时间。
如果我指出了错误的地方，请纠正。我理解，你不想在第一点之后等待？而我则主张强制提供前三条。
有两个问题需要回答，以便进一步讨论。
1.延迟的比例比率。也就是说，平均而言，上述四项中的每一项需要多少时间，以百分比计算。如果分布是，例如，"0.5%-1.0%-1.0%-97.5%"，那么它就不值得了。
2）超时和它对交易策略的影响。坦率地说，我无法说出一个不需要清楚了解订单是否已经发送到服务器的TS。这与长期和多货币套利都有关系。也就是说，交易订单的执行保证是不容置疑的。如果你不同意，请提供一个反例。
在我看来，解决中断时的执行问题的最简单方法是不创建执行队列（取消执行），并在重新连接时通知用户取消执行。这样一来，就不会有什么歧义了。
必须返回一张服务器票。这将确保订单到达服务器并被接受处理。
在客户端建立狡猾的等待池不仅是一个不切实际的解决方案，我认为这是MT5客户端-服务器架构的一个严重设计 缺陷。
客户端上繁琐的等待池并不是一个优雅的解决方案。
这就是所要求的。如果你不需要，没有人强迫你使用它。
TheXpert
让我们再做一次，在手指上。粗略的结构化延迟。
1. 终端预先检查交易订单的时间，将其 "打包 "成可调度的包裹，并将其放入 "网络队列"。
2.从客户端向服务器发送包含交易指令的数据包的时间。
服务器接收交易订单并将其放入处理池，并向客户发送此票据的唯一标识符的时间。
4.预处理交易订单的正确性并将其放在交易大厅的时间。
3是更好的划分。
3.1安置
3.2 发送UID。
如果我指出了错误的地方，请纠正。我理解，你不想在第一件物品之后等待？
是的。
另一方面，我赞成将前三条作为强制性规定。
如果平移是半秒呢？它是异步的。使用这种模式到底有什么意义？
这就是所问的问题。如果你不需要，没有人强迫你使用它。
你仍然没有回答我的问题。请给我一个具体的例子，在哪些情况下，你可以为了向不同角色发送的速度而不考虑交易订单 执行的保证？
你仍然没有回答我的问题。请给我一个具体的例子，说明什么时候你可以为了向不同的符号发送的速度而不顾交易订单 的执行保证？
没问题--投资组合交易+市场执行。