Feature Request: Web Socket Heartbeats

[timothymarois]

Hello,

We need Web Socket heartbeats sent into the stream every 10 or 30 seconds. This helps us developers know we're still logged-in and collecting data, and allows us to manage the web socket itself. In some scripts, web sockets consume infinite while loops causing nothing else to happen unless the payload is returned, when there is no activity, there's no payload, causing the control over the script to be limited. This heartbeat will be beneficial in controlling the stream status.

For both trade_updates and account_updates (all streaming should have a heartbeat)

https://docs.alpaca.markets/api-documentation/api-v2/streaming/

TD Ameritrade Developer API, they are doing the heartbeat in response with a timestamp like this: {"notify":[{"heartbeat":"1584715191635"}]} every 10 seconds.

There have been some votes for this on the Slack channel.

Thanks.

[d-e-s-o]

Doesn't the websocket protocol have built in pings/pongs that cater to this use case? I certainly see them floating around. What value-add does a separate heartbeat bring?

Edit: Here is a websocket "reference": https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#Pings_and_Pongs_The_Heartbeat_of_WebSockets

[timothymarois]

@d-e-s-o – Not all types of scripts have the ability to do that. Some scripts are forced to be stuck in the loop of the stream waiting for data, otherwise, it's unable to do anything else. A heartbeat allows you to know that you are still connected to Alpaca and this helps allow the script to do other actions when a heartbeat is received.

[d-e-s-o]

Well, then it's on you, isn't it? If you can't access the information you need at your layer then you need to go to the layer where the information is available. Two mechanisms accomplishing the same thing add useless complexity & traffic without any benefit.

[umitanuki]

Agree with @d-e-s-o , while I can see where @timothymarois is coming from, it is each client program's responsibility not to be blocked indifinetely when there is no message is pushed in my opinion. It could rather be waste of cycles and/or noise that cause another problems both on the server and each client to do such heart beating if there is no strong use case, but I might be missing something.

[timothymarois]

I have thought more about it and agree that the Web Sockets by the standard of rfc6455 have the pings built-in, therefore there isn't a solid case to support the feature.