疑似TB数据中心问题

TRANS-AM

问题已解决

帅牛

这种情况我在模拟交易多次遇到，问题出在TB回报延迟，亦即后台（交易柜台）已经成交，但是结果不能正常反馈到客户端，导致客户端重复发单，这个问题在用户的客户端程序中无解！希望TB公司能彻底根治这个顽疾 否则实盘中可能导致客户爆仓。。。

lmxy202

看起来你是虽然用全局变量控制下单，但出现这种情况时仍然每个tick都会促发下单动作，你可以在下单前先check一下有没有未成交单，如果有，就先撤掉未成交单，只有在没有未成交单的情况下才下单，这样出现这种情况就只下一次单，然后每个tick可能只会下撤单的指令

小米

TRANS-AM 发表于 2013-2-22 15:28
今天实盘又出现了一次重复发单，挂在同一个软件账号下的模拟盘反而是正常的，实盘到交易服务器延迟是0，模 ...

首先，你所说的听到声音，TB看不到成交，而其它软件能看到。这个是成交回报的情况。可以据体说一下是哪个公司的帐号吗？是否是恒生的柜台？？

其次，使用a_sendorder发单 ，仅用A_GetOpenOrderCount==0以及持仓数等来判断是肯定不够的。在报单回报没有回到本地前，再来行情就有可能触发再次委托 。所以，使用a_sendorder要使用全局变量配合控制发单 。
F1帮助文档的策略进阶里有相关的模板，可以参考一下。

小米

TRANS-AM 发表于 2013-2-22 19:51
首先感谢管理员回答，全局变量SetGlobalVar肯定是有的，这是写A函数第一点要做的事情，不然A函数不可能模 ...

恒生接口，是会偶有成交回报不及时的问题，退出重登录不仍不行的话，可致电公司。

不太清楚你的全局变量控制20个tick计数是用于什么？或者方便的话将发单 这一段代码贴一下。

小米

TRANS-AM 发表于 2013-2-22 23:27
Params
        Numeric OrderTicks(20);
Vars

这样的写法，在20个TICK后，委托单的状态仍不能回到本地，就会再发单了。
换一个控制方法吧。恒生柜台以及模拟帐户联通线路都偶有状态不能及时回到本地的情况发生。从而导致控制不住

帅牛

我之前说过，这个“回报延迟”的问题在用户客户端程序中无解！好比无法去证明公理一样。这个问题既和用户的程序无关，也和用户的网络环境无关（假使不是因为网络太慢，换句话说，即使用户的网络环境延迟是0，这个问题依旧存在）。

请TB同仁相信大家的能力，尤其是已经用过TB几个月，并动手写过数千行TB程序的人，断不会不知道通过全局变量来控制重复发单问题。并不是出了什么问题缺省就怀疑客户的程序是否写得有问题。

回到这个问题，我第一次发现重复发单，也猜测是不是自己程序有什么问题。尝试过无数的方法，最终发现是TB的机制问题 -- 即可能出现后台成交了，但无法正常将成交信息返回到客户端，从而导致重复发单。

我再来梳理下思路：在所有TB的函数中，A_GetOpenOrderCount（有无未成交的委托单）是最重要的函数，只有通过它（注意是“只有”），才能判断是否开仓或平仓成功。但现在的问题是，客户端程序开仓后，在A_GetOpenOrderCount==0时，持仓数却可以为0，这在逻辑上是矛盾的，从而会导致重复发单。而重复发单的问题，TB会按照客户当前最大资金量开仓，一旦行情瞬间逆转，而且幅度很大，直接爆仓。。。！！比如股指期货模拟交易，100万资金量，TB经常能开7个单。这点想到实盘我就害怕。

和TB公司电话、网络沟通过多次，希望TB公司能彻底解决这个问题。即为什么开仓成功了，客户端却无法获知？（再次说明，这和网络无关）从理论上讲，不应该出现这个问题。问题根源还是在TB客户端底层通讯上！希望TB资深研发同事看下TB Datacenter底层代码。早日彻底解决这个问题。

写了这么多，是帮助TB同事深刻认识到这个问题的严重性，而无半点责骂抱怨之意，我是希望一辈子在TB这条大船上啊。。，衷心希望TB公司茁壮发展！

谢谢！！


帅牛
2013.2.23

小米

TRANS-AM 发表于 2013-2-23 09:22
求指点思路，换什么控制方法比较好，感谢小米

可参考F1策略进阶里的方法，只要发过委托就改变全局变量的值以控制同一条件下只发单 一次。

小米

帅牛 发表于 2013-2-23 18:22
我之前说过，这个“回报延迟”的问题在用户客户端程序中无解！好比无法去证明公理一样。这个问题既和用户的 ...

谢谢您对TB的支持与理解，也谢谢您给出的建议，我会转交开发人员的。

首先，我们从来没有怀疑或是说过大家对编程不懂或不精通这样的话。如果在我以往的回复言辞中表现出这样的意思，那我向您道歉。

在客户以往的问题中，我常常是根据自己的经验来给出回复的。当然，所谓我的经验，仍有不对的地方。有发现不对的，我过后也会回贴说明自己的错误之处。当然，如果大家发现了也可以给我指出。谢谢。
就拿这个贴子来说。我从头到尾并没有说过楼主没有编写公式的的能力。无非是指出我认为可能导致问题的地方。先强调使用全局变量这一点没有错吧？？在楼主说有全局变量了我要求看这部分的代码，这一点上应该也没有错吧？ 在看完楼主的代码之后，我也没有说楼主的代码有误过吧？相反，我个人认为楼主的这个20tick的控制的想法很有新意，是值得我学习的。同时，我有说到，在因为恒生柜台接口的特殊性，才建议楼主换其它的控制方法。这一点上，应该也没有错吧？

我们再来讨论一下a_getopenordercount.  此函数表示的是帐户里当前合约的“已报”状态的单子。只有委托单 提交到了交易所，没有成交，才返回到本地为“已报”状态 。并不是一下委托 ，本地就有一个a_getopenorder>0的。一个委托单从客户端提交，通过网络到达柜台 ，交易所，得到状态再返回到客户端，这一过程都是需要一定时间 的，无论客户端本地的延迟是否为0，并不能保证一个tick之内一定可以返回到本地的。如果不能保证，就那必然需要全局变量来控制同一条件下的委托只下一次。那么由此，“在A_GetOpenOrderCount==0时，持仓数却可以为0”这句应该不矛盾吧。。。

有关恒生偶尔的状态回报慢或不回报的问题，我们与恒生的工作人员沟通过多次仍无果。目前暂时的处理方法只能客户发现情况，我通知我们，我们再转达期货公司技术人员去处理服务器。
模拟柜台，目前只架在电信线路上，联通上是通过一前置机转发，当遇到前置机出错或是南北互通不好时，使用联通的模拟帐户就会表现为登录帐号困难或是成效交回报慢。
此问题，技术人员已经在想办法改进中。谢谢！

小米

TRANS-AM 发表于 2013-2-24 12:44
因为要在公式里实现很多功能，比如发单以后，不成交怎么处理（A_DeleteOrder等等），部分成交怎么处理， ...

我有强调同一个条件下只发一单 ，并非指一个交易只发一单 就完事。如需加仓等，需要另外的处理了。
现在你所提到的不止开仓，还有不成交的处理等，这些问题确实是成交状态回不来等会引发的一系列问题。但目前来说回报的问题涉及接口，并非TB公司单方面可以解决。建议或者换一个柜台的帐号吧。

进阶里的写法主要是判断了HasSendOrder ==0时放可发单 ，一旦有发单动作就赋值为1.这里的判断都与成交回报无关。我没太懂这样如何与状态回报有关？