堡垒。执法问题 - 页 125

新评论
 
Andrey Gladyshev:
是的，而且这取决于什么交换。我不认为我们的。

我不知道其他人的情况。但原理是一样的--接收客户的出价，广播一个框架，再次接收和广播--整个问题是这些框架的频率和出价的频率。

 
Aleksey Vyazmikin:

交易所将以同样的方式进行广播。或者你是在暗示，杯子的框架有损失？

这些观点需要分别加以确认。以何种采样率拍摄的。

 
Andrey Gladyshev:

这些观点需要分别加以确认。图像是以何种采样率拍摄的。

这可能是在他们网站的文档中。

 
Aleksey Vyazmikin:

我不知道其他人的情况。但原理是一样的--接收客户的请求，广播一个帧，再次接收和广播--整个问题是这些帧的频率和请求的频率。

事实证明，我已经回答了。

 
我说的是CME。你必须阅读这些文件。
 
Andrey Gladyshev:
我是说CME。你必须阅读这些文件。

这也是FORTS，只是美国。期货。

 
而总的来说，这个计划，简而言之，就是在某些层面上找到一些片面性。其目的是跟踪近距离的小范围运动。没有遥远的目标。
 
Sergey Chalyshev:

服务器又搞砸了(((.

悬挂3分钟，然后[请求超时]

发现服务器，终端建立1947。
我应该怎么做？



在以下情况下，我有几次正好挂断了3分钟的电话。

1）我与服务器短时间内失去连接，例如100ms。

2) 一个专家顾问发出删除订单的请求（OrderSend()）。

3) 第二个EA发送请求，删除同一订单（OrderSend()）。

4）只要第一个EA连接+轻微延迟，OrderSend()就会成功，订单确实被删除。

5）第二个EA "挂起"。在调用OrderSend()整整3分钟后，它终止了，结果是：retcode=10012 comment="Request timeout"。


考虑到订单确实被删除，而且第一个EA已经看到了这一点，交易所与此无关，这只是终端和EA的互动。似乎当与服务器的交易操作 完成后，只有第一个等待执行该操作的EA得到答复。如果有其他专家顾问在等待相同的操作，他们不会收到答案，操作的执行将以超时方式完成。

 
Aleksey Vyazmikin:

据我所知，股票的抛出是由交易所以一定的频率播报的，也就是说，每一个变化都不可能随便得到。

而且，我仍然不明白，它应该用它来做什么？特别是当有强烈的运动时，数据会有延迟......。
在mosbirch网站上搜索 "完整订单记录"。
 
Dmitriy Skub:
在mosbirch网站上搜索 "完整订单记录"。

我发现这个信息

该测试涉及战斗服务器在关闭批处理的情况下发布完整的请求日志流，以及战斗服务器发布一个聚合堆栈，数据以10ms的量子形式分组，类似于Plaza II/Gate服务。

所以量化是10ms。或者其他的东西，我应该发现的是有用的吗？

1...118119120121122123124125126127128129130131132...156
新评论