VeighNa量化社区
你的开源社区量化交易平台
Member
avatar
加入于:
帖子: 5
声望: 0

使用uft交易接口进行委托,成交后,发现回报记录里面成交数量大于总数量。如图:

description
找到对应的成交回报处理代码,发现部分代码如下:

    def update_trade(self, data: dict) -> None:
        """"""
        symbol = data["InstrumentID"]
        exchange = EXCHANGE_UFT2VT[data["ExchangeID"]]
        sessionid = data["SessionID"]
        order_ref = data["OrderRef"]
        orderid = f"{sessionid}_{order_ref}"

        order = self.orders.get(orderid, None)
        if order:
            order.traded += data["TradeVolume"]

            if order.traded < order.volume:
                order.status = Status.PARTTRADED
            else:
                order.status = Status.ALLTRADED

            self.gateway.on_order(order)

        trade_time = generate_time(data["TradeTime"])
        timestamp = f"{data['TradingDay']} {trade_time}"
        dt = datetime.strptime(timestamp, "%Y%m%d %H:%M:%S")
        dt = CHINA_TZ.localize(dt)

其中,if order片段的逻辑个人理解为——收到成交回报时,如果找到对应的委托回报记录,则将其已成交数据累加当前成交回报记录中的成交数量,并在更新对应状态后执行回调。
当时进行别的测试,每笔委托就下1手,然后短时间下了24笔。
通过打印发现:如果收到成交回报后还收到对应的委托回报,那么就会将数据覆盖,进而呈现正确的数据;
但如果成交回报是最后收到的(指该笔委托),那么对应的委托回报的数据就会错误。

对比ctp接口,是没有这段代码的,不清楚为什么此处要加上,是为了处理什么东西吗?
那带来的上述图中的错误又怎么办?
比如,我下10手,然后部分成交情况下,很可能导致显示全部成交,这个时候就不能进行撤单操作了

Administrator
avatar
加入于:
帖子: 4547
声望: 324

其中,if order片段的逻辑个人理解为——收到成交回报时,如果找到对应的委托回报记录,则将其已成交数据累加当前成交回报记录中的成交数量,并在更新对应状态后执行回调。
当时进行别的测试,每笔委托就下1手,然后短时间下了24笔。
通过打印发现:如果收到成交回报后还收到对应的委托回报,那么就会将数据覆盖,进而呈现正确的数据;
但如果成交回报是最后收到的(指该笔委托),那么对应的委托回报的数据就会错误。

对比ctp接口,是没有这段代码的,不清楚为什么此处要加上,是为了处理什么东西吗?
那带来的上述图中的错误又怎么办?
比如,我下10手,然后部分成交情况下,很可能导致显示全部成交,这个时候就不能进行撤单操作了

CTP接口中提供了流机制,来保证推送永远是OrderData先到,然后是TradeData到,且每条数据流上包含了自己的完整信息。

UFT接口底层基于恒生T2SDK,没有这个机制,而是在UFT极速API中采用简单的推送数据进行了模拟,因此在极端情况下(短时间大量下单,且网络不稳定)就会出错,我们这里的写法是一种纠偏机制。

如果测试中发现有BUG,请在Github上开个Issue,我们同事会来处理。

Member
avatar
加入于:
帖子: 5
声望: 0

用Python的交易员 wrote:

CTP接口中提供了流机制,来保证推送永远是OrderData先到,然后是TradeData到,且每条数据流上包含了自己的完整信息。

UFT接口底层基于恒生T2SDK,没有这个机制,而是在UFT极速API中采用简单的推送数据进行了模拟,因此在极端情况下(短时间大量下单,且网络不稳定)就会出错,我们这里的写法是一种纠偏机制。

老师,您好!
如果vnpy首先处理TradeData的信息,在采用了纠偏机制的情况下,当TradeData到达时就会将traded进行累加,但后面当OrderData到达时,会重新取出最新收到的数据进行覆盖,这时纠偏机制无意义。
如果首先处理好OrderData的信息,当TradeData后到时就会将traded进行重复累加,导致数据显示错误——这种场景下纠偏机制是错误的。
这样的话,感觉纠偏机制没有起到很好的作用。
至于提到数据流完整性问题,代码中没有进行区分处理。如果不确定信息是否完整,这时一个简单的纠偏机制也解决不了,它必须保证包含完整信息的数据后到才能正确处理业务了吧?

Administrator
avatar
加入于:
帖子: 4547
声望: 324

一念成仙 wrote:

用Python的交易员 wrote:

CTP接口中提供了流机制,来保证推送永远是OrderData先到,然后是TradeData到,且每条数据流上包含了自己的完整信息。

UFT接口底层基于恒生T2SDK,没有这个机制,而是在UFT极速API中采用简单的推送数据进行了模拟,因此在极端情况下(短时间大量下单,且网络不稳定)就会出错,我们这里的写法是一种纠偏机制。

老师,您好!
如果vnpy首先处理TradeData的信息,在采用了纠偏机制的情况下,当TradeData到达时就会将traded进行累加,但后面当OrderData到达时,会重新取出最新收到的数据进行覆盖,这时纠偏机制无意义。
如果首先处理好OrderData的信息,当TradeData后到时就会将traded进行重复累加,导致数据显示错误——这种场景下纠偏机制是错误的。
这样的话,感觉纠偏机制没有起到很好的作用。
至于提到数据流完整性问题,代码中没有进行区分处理。如果不确定信息是否完整,这时一个简单的纠偏机制也解决不了,它必须保证包含完整信息的数据后到才能正确处理业务了吧?

是的,UFT接口这里就是个设计上的坑,而且这么多年了都没有填上。。。

© 2015-2022 上海韦纳软件科技有限公司
备案服务号:沪ICP备18006526号

沪公网安备 31011502017034号

【用户协议】
【隐私政策】
【免责条款】