Hi,
the general Websocket API Info states:
The base endpoint is: wss://ws-fapi.binance.com/ws-fapi/v1
Does this mean that for the endpoint above the base url should be changed to wss://ws-fapi.binance.com/ws-fapi/v2?
No. Use the same /ws-fapi/v1 endpoint, but send "method": "v2/account.position" in requests (instead of "account.position") to use version 2 of the position information request.
There is no wss://ws-fapi.binance.com/ws-fapi/v2 at the moment.
thanks for the info. I’m building a pretty extensive connector in rust for bn futures.
For the websockets it’s a bit unclear what the implications of these two points are:
- A single connection is only valid for 24 hours; expect to be disconnected at the 24 hour mark
- WebSocket connections have a limit of 10 incoming messages per second.
It is 100% certain that every socket is closed after 24 hours? Regardless of ping requests being returned? A software therefore needs a method of re-subscribing upon 24 hours or just reconnecting?
Are subscriptions deleted upon 24 hours?
10 incoming messages: If this is true, it seems to encourage to just spin up one socket per stream, as 10 per second seems pretty limiting for a real-time trading environment. There are so many situations where this gets exceeded. Say one would have 1 socket and subscribe to 50 streams for depth updates, this would certainly limit the updates being received. Would messages be skipped or just delayd? Is there any packet loss? Is it recommended to have more sockets rather than few sockets subscribing to multiple streams?
Yes, eventually you will be disconnected. Typically after 2 or 3 days, not exactly at 24-hour mark. This happens even if you respond to pings on time. Subscriptions are associated with connection, you will need to subscribe again after opening a new connection.
Basically, if you want to avoid interruptions in the market data stream, it is recommended that you open a new connection before the 24-hour mark. This way you control the timing (for example, every 12 hours), and you can keep two connections running during the handover, ensuring no events are missed.
The incoming message rate limit is for messages from the client (you) to the server: basically, that’s a limit on subscription and unsubscription commands. Usually you don’t need to send them frequently.
There is no rate limit on the market data events from the server to you. However, you need to keep up with the streams. If you are unable to receive the events from all the streams you subscribed to, you will fall behind and eventually will be disconnected. Depending on your network, application architecture, and requirements it might make sense to open multiple connections, split the streams between them, and process the sockets in parallel.