For a deeper look into our Elektron API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
Francis avatar image
1 ●0 ●0 ●0

Concurrent usage EDP

Hi all,


I have the following query about using EDP to connect to the websocket api from multiple instances of an application.

I realise that we are allowed 5 concurrent mounts per machineID to authenticate, but these must share access tokens rather than actively authentication 5 separate times.


If I refresh a token in a separate running piece of code - is there a rule/invariant about how quickly the old token will expire & my code that is listening to a websocket will fail?


With the current model that requires token sharing rather than concurrent logins - how can I avoid downtime? I'm unsure how this is possible & how other's have solved this problem previously.


I realise the last question is fairly open ended but I'm having trouble coming up with a solid solution.


Thanks in advance for the help.

websocketsrrtorefinitiv-realtime-optimised
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

2 Answers

Upvotes
Accepted
nick.zincone avatar image
9.7k ●49 ●38 ●60

Hi @Francis,

When you acquire a refresh token from AAA, the response will inform you when you need to refresh your access tokens. This value has been currently set to 300 seconds (5 minutes). To ensure your tokens do not expire, I would suggest you refresh 90% of this time, I.e. 270 seconds.

if you plan on running multiple instances of your application, I would suggest you reach out to your account manager and request for multiple IDs. I don’t think creating a complicated distributed queue of applications where a master within that group is responsible for refreshing tokens and ships them around to other members is required to manage the limitations of the current authentication. There are plans in the future to utilize a alternative authentication mechanism address the current limitation.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Francis avatar image Francis
Hi Nick, thanks for the quick response.


So you wouldn't suggest dealing with this problem at all? If I need 5 instances, rather than hand tokens around you'd suggest asking for 5 machineIDs instead?
Yes that would be much easier than handling tokens in a distributed manner. I was wondering if a separate process refreshed the token how each distributed instance might pick it up quick enough before seeing failures.


I'll ask my account manager for more machineIDs as this feels the easiest.


Thanks!

Upvotes
umer.nalla avatar image
20.3k ●73 ●10 ●20

Hi @Francis

In the simple test scripts I was using, I shared the token and the token expiry time with the other instances - so they knew when to fetch the new token from the main instance.

In terms of the expiry time, you can get the expires_in value from the auth response as described in Authorization - All about tokens

TBH - if you discussed the multiple mount scenario with your Account Team when you signed up, I would recommend you discuss the possibility of obtaining multiple machineIDs - to avoid sharing tokens.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Francis avatar image Francis

Hi - thanks for the reply!


Yes I considered using a timetolive attribute. However this wouldn't be perfect in a distributed system so there may still be occasions where a couple of seconds could pass before an instance picks up the new token. Here I suspect I'd get disconnected from the websocket.


Yes given your reply and the other I'm going to ask our account manager for more machineIDs to avoid this issue.


Thanks

Click below to post an Idea Post Idea