Sequence numbers

API Developers Community Support
1

I have two questions.
According to the documentation, the sequence numbers should be unique for the session. Does that count for each websocket endpoint, example: Should the marketdata and API share the same sequence number? Is the marketdata and API both considered unique sessions?

Also after I authorize my session I get a payload, there’s an accessToken and mdAccessToken. I’ve always used accessToken on both API and md websockets to authorize, it seems to work fine but maybe this isn’t the proper way to do this. Can I get some clarifications on these two issues?

2

Hello @beebee,

Regarding the unique message IDs - these only have to be unique per websocket instance. So you can start at 0 whenever you create a new WebSocket. It would be fine to start at 0 for both the MD socket and user data socket. You could even keep your current sequenced ID when you restart your WebSockets as long as you never send the same ID to the same WebSocket instance twice.

Regarding the mdAccessToken this only exists for backwards compatibility purposes with the Trader application. You can safely use accessToken for all requests that require a token.

3

Thank you for the clarification.

I ran into an issue earlier that the below quote touches on.

I have an open marketdata websocket connection, then I get a connection close message from that open connection, no errors the connection just drops. In an instance like this where the websocket connection closes for some unknown reason, I can just reconnect to the session and keep going?

With this question in mind, if the connection was open for some time longer than the taccessToken expiration time. I need to call refresh access token periodically and keep a copy of that accessToken for instances where I get a disconnect and need to reconnect?

4

The best way to stay connected beyond your original access token’s expiry is to call auth/renewAccessToken. It takes no parameters, it only requires a non-expired access token to be in the header. It will return a new token with a new expiration time. If you’ve stored your access tokens via sessionStorage or some other way, you should replace the old token and expiration after you call this endpoint.

In the event that the socket closes unexpectedly, you can always run a reconnect procedure.

let mySocket = new WebSocket(MY_URL)

mySocket.onopen = () => { /* auth procedure */ }

mySocket.onmessage = msg => { /* msg decode procedure */ }

mySocket.onclose = () => {
  mySocket = new WebSocket(MY_URL)
  mySocket.onopen = () => { /* auth procedure */ }
  mySocket.onmessage = msg => { /* msg decode procedure */ }
}

It is probably best to wrap up the socket procedures’ implementations in some kind of wrapper function/class/object to abstract operations like this into single function calls like MySocket.connect(), MySocket.reconnect(), etc.

5

Thank you, I do have those authentication functions tucked away since they’re mainly called on websocket on_open message.

i was just a bit surprised to see the socket dropped unexpectedly a few times today.

I am not sure if it’s just me but the platform seems to have some technical difficulties today. The market data is not updating. Hope all is well on the server.