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

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
1 0 0 2

Delayed ACKs from the websocket contributions API

Hi,

We are contributing around 20k update messages every 30s to the websocket contribution endpoint (contrib-ws1-amers1.platform.refinitiv.com), however we are seeing the ACKs coming in very delayed, up to a point where it is not possible for us to utilize them for correct failover/retry logic as suggested here (https://community.developers.refinitiv.com/questions/114212/ab-side-failover-using-websockets-api-for-data-con.html).

From my basic measurements it appears that the throughput of the system is 8 times lower than what we are streaming. We are only getting around 2.5k ACKs every 30s. From the login response message the limit should be 20k messages/s (```"Elements":{"TRCE:MaxMessagesPerSecond":20000}```).

What could be the issue here? Is there anything that our Content Manager can do for us on your end (e.g. change some configuration values)? The 20k update messages as we see them are being successfully sent over the websocket to your endpoint every 30s.


Thank you!

#technologywebsocketscontributionsrcc
icon clock
10 |1500

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

Hello @fjemiolo

Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query?


If so please can you click the 'Accept' text next to the appropriate reply? This will guide all community members who have a similar question.

Thanks,


AHS

Hi @wasin.w ,


I have raised a support ticket via the suggest website, but I have not received any useful information from the support team yet. The information you have posted below is old and confusing. The API clearly indicates in the login response message that it supports 20000 updates per second (increased from 5000 updates per second about 5 months ago). What makes it more confusing is that you have clearly answered in the shared thread that this is indeed the right way to find out the rate limit (see attached screenshot). Could you please clarify?


Thank you!

1710766337124.png


1710766337124.png (107.1 KiB)

Hello @fjemiolo

I am sorry for the outdated and confusing information. I just noticed that the maximum contributions per second for the WebSocket connection has been increased.

Based on my understanding, the TRCE:MaxMessagesPerSecond value indicates the maximum post message rate only, not the server response (ACK) rate. The response (ACK) rate is depending on the RCC WebSocket server side, so I suggest you ask the RCC support team to investigate the delay ACK response on their side.

I hope this information helps.

Hi @fjemiolo ,


Could you please have a look at my colleagues reply above and let us know if that addresses your question?


Best regards,

Haykaz

@fjemiolo

Hi,

Thank you for your participation in the forum.

Is the reply below satisfactory in answering your question?

If yes please click the 'Accept' text next to the reply, and then close the question. This will guide all community members who have a similar question.

Otherwise please post again offering further insight into your question.

Thanks,

AHS

Hi,

Please be informed that a reply has been verified as correct in answering the question, and marked as such.

Thank you,

AHS

1 Answer

· Write an Answer
Upvotes
Accepted
24.7k 54 17 14

Hello @fjemiolo

Based on this old Confirmation of Python WebSocket (directly to RCC) is good or not for our use case post, the maximum contributions per second of each connection type of RCC are as follows (as of 2021):

  • RSSL connection (for RTSDK C++/Java): 20,000 updates per second
  • WebSocket connection: 1000 updates per second

The RTSDK C/C++ or Java editions (EMA or ETA APIs) may be more suitable for your requirement (20k update messages every 30s) then the WebSocket API.

The WebSocket API is designed for easy to develop and support various programming languages via the standard WebSocket connection and JSON message format. While the RTSDK uses Refinitiv's proprietary TCP-based connection called RSSL. The RSSL connection encodes data in binary format which is highly optimized for data distribution more than a JSON string format in a WebSocket connection.

You can find more details in the following article and tutorials:

About the RCC ack delay issue, the WebSocket API is the server-side API, so you can contact the RCC support team directly via https://my.refinitiv.com/content/mytr/en/helpandsupport.html website to verify the issue on their end.

refinitiv-contributions-realtime.png

Alternatively, you can reach out to your LSEG Account team and arrange a discussion with the RCC product team to discuss your requirements/options further - as there may be additional limits on the RCC infrastructure.


icon clock
10 |1500

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

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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