CCXT Websocket Integration

[tolgakaratas]

CCXT Websocket Integration

[aleksandar-babic]

This might be useful not just for performance improvements, but to avoid the rate limiting in certain exchanges (e.g Binance) when multiple instances of freqtrade are running from the same external IP.

[xmatthias]

Well it's neither a new idea, nor will it improve performance as significant as you'd think.

In my tests, endpoints like "fetch_ohlcv" for a 50 pair whitelist provide you the data for all pairs ~3-4 seconds after the candle starts.
Changing this to the websocket implementation, you can get to roughly 1.5-2s (if you're playing it safe and assume a slight clock drift) (tested on binance spot).

Now i've only tested this for ohlcv data for now - which is a branch that will need more testing - and where this functionality will be limited to exchanges where behavior was tested.

---

While there's "probably" bigger advantages for other endpoints (like orderbook data) - the way ccxt currently works, implementing that is currently not feasible / reasonable.
The data transferred over the network becomes big pretty fast even for one pair.
While that can be neglected to some degree as "i'm in a position, so it does need more data" - this is made worse by the fact that ccxt doesn't allow unsubscribing from a websocket stream (you can no longer consume it - but the data in the background will still be sent to your system).

This means that for a bot with a 50pair whitelist, with a decent amount of trades and an average trade duration, you can probably expect to be subscribed to the orderbook stream for all pairs within a week (or max a month).

While the same will be true for volumepairlists, where you'll "drag along" all streams for old data - that's (probably) neglectible from a data transfer perspective - whereas for orderbooks, it's not.

So until unsubscribing is implemented, i don't see this as a feature we'll be going to add.

---

For the feature itself (websockets for ohlcv) - it's available and i'm testing it currently (already for quite some time, actually).
It's still missing a few documentation parts - and for sure tons of testing - but i can see to make that available as a PR soonish.

[dnuno89]

This might be useful not just for performance improvements, but to avoid the rate limiting in certain exchanges (e.g Binance) when multiple instances of freqtrade are running from the same external IP.

I have this same exact issue but ... Would two freqtrade instances connected to the same exchange through WebSocket share the data feed?

[xmatthias]

Would two freqtrade instances connected to the same exchange through WebSocket share the data feed?

No, freqtrade instances are seen as independent and i don't see this changing anytime soon.

there's no guarantee that the pairlist or exchange is the same - and you can stop each instance at any moment.

[tolgakaratas]

We are getting this errors many times.
I believe many people also getting this error.
It should be done as soon as possible.

freqtrade.exchange.common - INFO - Applying DDosProtection backoff delay: 1
freqtrade.exchange.common - WARNING - _get_funding_fees_from_exchange() returned exception: "binance 418 Client Error (418) {"code":-1003,"msg":"Way too many requests; IP(xxx.xxx.xxx.xxx) banned until 1714528071029. Please use the websocket for live updates to avoid bans."}". Retrying still for 3 times.
freqtrade.exchange.common - INFO - Applying DDosProtection backoff delay: 2

freqtrade.exchange.common - WARNING - _get_funding_fees_from_exchange() returned exception: "binance 418 Client Error (418) {"code":-1003,"msg":"Way too many requests; IP(xxx.xxx.xxx.xxx) banned until 1714528071029. Please use the websocket for live updates to avoid bans."}". Retrying still for 2 times.

[stash86]

1. You get that because you are running multiple bots on one IP address. You can reduce the number of bots if you want to avoid that
2. As answered above as well, switching to websocket won't really solve your issue. You still can get hit with websocket's rate limit if you have plenty of bots running in one IP address.
3. If you think it's need to be done "as soon as possible", we are open to review your PR. Otherwise, please refrain from setting any deadline.

Search for unofficial binance proxy. It can solve your issue for now.

[tolgakaratas]

Binance proxy also not doing this job. If somebody know how to modify this 2 projects as needed please offer a solution:

https://github.com/nightshift2k/binance-proxy
https://github.com/adrianceding/binance-proxy

[stash86]

well, I have been using it for 2 years and have no issue. It's doing its job perfectly. There is no need for modification

[tolgakaratas]

We are running 10 account in 1 server and planning to add more.

### This answer from binance support :

The WS feature isn't from CCXT PRO, it's from Binance. You shouldn't be passing through CCXT rather developing using standard websocket practices.

3-4 seconds down to 1-2 is already a 50% increase, which is considerable.

This isn't about speed, it's about weight consumption.

Querying a user account balance takes 5 weight:
https://binance-docs.github.io/apidocs/futures/en/#futures-account-balance-v2-user_data

GET /fapi/v2/balance

Weight: 5

Multiply that by 10 users, that's 50 weight. If you do that every 10 seconds, that 300 weight in 1 minute.

Replacing this with Websocket user data stream:
https://binance-docs.github.io/apidocs/futures/en/#user-data-streams

Means any updates to account balance will be updated immediately. So than you:
A. Don't need to request to get the data
B. Consume 0 WEIGHT in knowing the users balances

You've just shaved 300 weight just by changing one endpoint to websocket

Like this, position information, account information, Margin calls, etc. All handled by the WS that consumes 0 weight

This is why the message you get is clear:
code":-1003,"msg":"Way too many requests; IP(xxx.xxx.xxx.xxx) banned until 1713399718937. Please use the websocket for live updates to avoid bans."

Because you're making too many excessive REST requests which could be simply changed to websocket

Futures orders consume 0 weight.
https://binance-docs.github.io/apidocs/futures/en/#new-order-trade

Weight: 0

(They have their separate limits)

So realistically, if you MAYBE query let's say position information or modify an order here or there, you should be virtually at 0 of weight consumption

So the error you are getting is because the code is not optimized to be operating with that many users. Using REST requests is fine in the short term, but even if you were to get an increased weight limit, it's not unlimited.

There's also the speed part behind it. A standard REST request depending on the server is estimated at 1000ms
WS-API (not WS) can be as low at 10-100ms. And WSS is real time as well

Klines have their own update speed attached, but for example if you're querying klines on REST you're consuming weight. on WSS, there is no weight

[xmatthias]

@tolgakaratas We'll be adding support for websockets once it's ready.
Please keep in mind that this project is maintained by volunteers in their free time.

Hence we will not provide any information on timing - as it's often difficult to predict how much actual time will be available to work on this (everyone involved in this Project does so in their spare time, voluntarily - and has a full time job - and often family to go along with it).

The last few messages do nothing to speed this up, or provide anything new.
Also with websockets, you will not be able to run 10 or more bots from the same ip address - simply based on the fact that also websockets "consume weight".
The solution to this is quite simple - scale horizontally, using several servers (this will NOT change when using websockets).

I've hence hidden the last comments - as they provide nothing of value to this issue.
Please don't force me to lock this issue to avoid further spam.
(i'll also be hiding my own comment as off-topic) - as it's NOT actually related to what this issue is requesting.