Client id may duplicate

[richwomanbtc]

Problem

I tried gridtrading_live.rs in rust example. When operating for long periods of time, warnings Coincidentally, creates a duplicated client order id. This order request will be expired. occur, and the bot can't no longer create new orders. This might be due to a conflict in the client order id.

Alternatives

It seems that the implementation of the order manager for Binance generates a 16-digit random number and matches it with the open order's id, but it would be sufficient to generate a sequencial number instead of a random number, and would also improve tick to trade.

[nkaz001]

I will look into it. Do you have any logs that could help to figure out the problem?

[richwomanbtc]

Sorry, I have no logs currently. However, massiveCoincidentally, creates a duplicated client order id. This order request will be expired. warning occur when I run the gridtrading_live.rs with Endpoint::Public and 1000SHIBUSDT for few minutes.

I tried a few changes, and there did not seem to be a conflict in the client order id. When I comment out the code shown below, the warning doesn't occur at least for about six hours, although the error Bot received an unmanaged order. This should be handled by a Connector. sometimes occurs. https://github.com/nkaz001/hftbacktest/blob/526fe20939bd62de1996d98b25d6218e743ae71a/rust/src/connector/binancefutures/ordermanager.rs#L270-L272 It seems that the cause is not duplication of id, but that order_id_map is stuck in some unexpected state.

[richwomanbtc]

Bot received an unmanaged order. This should be handled by a Connector. occurs after Pong timeout, so the issue might be due to my unstable network.

[nkaz001]

It's still unclear, but in my opinion, the issue arises because the previous version doesn't clear the order states when it loses the connection. When it reconnects, it cancels all working orders, but the previous version doesn't clear the local order states, so new orders could conflict with the canceled but unrecognized orders. The current development version tries to solve this issue. Could you try again when version 0.2.0 is released? I expect to release it soon.

[richwomanbtc]

Of cource! In addition, I will try with AWS instance for more stable networks.

btw, although this is not directly related to this issue, I remember the low latency ws will send different forms of json rather than normal streams, so the parser will fail when using low latency endpoint. I will check this, and if it be true, I will open another issue.

[nkaz001]

oh, please let me know. Since I cannot access the low latency streams or APIs, I have no way to know or test.

[nkaz001]

@richwomanbtc v0.2.0 has been released. please let me know if the problem still occurs.

[richwomanbtc]

@nkaz001 It works fine now! Thank you so much.

[richwomanbtc]

oh, please let me know. Since I cannot access the low latency streams or APIs, I have no way to know or test.

It was my mistake. I just checked and fstream and fstream-mm return exactly the same json.

[nkaz001]

Since I cannot access the low-latency APIs and streams, could you tell me how much latency is reduced compared to the public APIs and streams? under normal market conditions and during fast-moving market conditions?

[richwomanbtc]

I can't show you the latency stats soon, but it is faster a little in usual, and is not affected much during bursts. If I have time this week, I'll try to do a detailed latency measurement.