API Websocket + Replay + Renew Token?

API Developers
1

Hi @Alexander

I have been able to use my strategy to create and execute trades in both replay + demo. Great api once I wrapped my little brain around it.

One thing that I did notice was when I was replaying a chunk of data, my connection seemed to stop receiving data or messages. I am using Python’s Websockets library and do handle for closed connections etc (but don’t seem to even see an exception or the ‘c’ data frame occurring).

On further debug, it seems to happen after a certain amount of time. Examples:

  1. Say I initialize a replay for "startTimestamp": "2022-07-28T07:00:00.000-04:00", "speed": 400, "initialBalance": 50000, it works fine until 2022-07-38T11:00:05.933-04:00 or roughly 4 hours replay time.

  2. Say I initialize a replay for 2022-07-38T11:00:05.933-04:00, it seems to fail a little after 3 PM or in ~4 hours of replay time.

At 400% speed, this coincides with roughly 1 hour of real time.

A few questions:

  1. Can you run replay events indefinitely?
  2. I came across another post API Order Failures - #21 by Arthur where it discusses renewing the access token. I am currently not renewing the web socket’s access token (my rationale is I make only web socket requests). Do we think this is the culprit?
  3. For renewing the accessToken, I get we pass the existing accessToken to /auth/renewAccessToken. If I automatically make that request, will the web socket on the server’s side handle that and be updated (as I don’t send the access token with each request).
  4. Replay shares MD_Client + Trade_Client socket connections. If I call “renewAccessToken” in MD_Client, won’t I have issues of then calling Trade_Client’s renewal? Or can I freely call it with whichever accessToken was originally used to create the web socket connection?

Sorry I was stumped since no socket errors or socket disconnects appeared but I think this might be the culprit.

Thanks!

2

You can actually access the WebSocket indefinitely once authorized. What you need to watch for on the replay socket is being throttled. You may notice the socket keeps you in sync with replay time by sending “clock” events. They look like this:

{ "t": JSON Timestamp, "s": 400 }.

After a certain amount of time, the socket will start returning “clock” events where "s": 0. This means that the server has throttled your possibly neglected session to reduce overhead. However, often this is not the case and we want to keep the replay going. To do so, send a request to the replay/changeSpeed with this body:

replay/changeSpeed
0

{ "speed": 400 }

Calling this operation should set it back to 400% speed.

3

Hi Alexander!

Ah, I was listening to clock events but I didn’t realize it would send back the “s” differently (or well throttle). This is probably my issue.

Final question - Do I need to send the message Id as 0? Or should I still increment that as normal?

Thanks for your help!

4

My apologies, the 0 was just a placeholder. You should increment as normal.