Concurrent usage EDP

Francis
Francis Newcomer
in WebSocket API

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.

Tagged:

Best Answer

  • nick.zincone
    nick.zincone admin
    Answer ✓

    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.

Answers

  • umer.nalla
    umer.nalla LSEG

    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.

  • Francis
    Francis Newcomer
    https://community.developers.refinitiv.com/discussion/comment/79233#Comment_79233
    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!

  • Francis
    Francis Newcomer
    https://community.developers.refinitiv.com/discussion/comment/79243#Comment_79243

    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

Categories