1. Home
  2. Article Catalog
  3. Choosing your Refinitiv Real-Time Streaming API

Choosing a Refinitiv Real-time Streaming API

Umer Nalla
Developer Advocate Developer Advocate

Knowledge Prerequisite – Must have a basic understanding of what Real-Time Streaming data is.

 

Refinitiv offers several choices when it comes to consuming Real-Time streaming data – from a lowest-level ultra high-performance Transport level API to a highest-level helper library in Python & C# (and soon TypeScript).

Using the decision tree below in conjunction with the notes contained herein, should help you narrow down the choice of the most likely candidate(s) to meet your requirement.

Primary Determining Factor

Based on my experience of working with a variety of client developers, the primary deciding factor is usually one of the following:

  • Performance requirement - the implementation requires high/very high performance e.g. the ability to consume several (hundreds of) thousands of streaming updates a second - or lowest possible latency for algorithmic trading
  • Programming language – the development team are restricted in the choice of language(s) they can code in

Performance

As you can see from the diagram, the factor does not necessarily have to be mutually exclusive e.g. if you want the highest performance and can code in Java/C++ or C then both paths lead you to the Enterprise APIs that form the Refinitiv Real-Time SDKs (RT-SDKs)

Conversely, for a specialised use case like algorithmic trading (which demands the lowest possible latency) the path will lead you to the only choice of the Enterprise Transport API (ETA) which

  • Is Open-source, highest performance, lowest latency and is the foundation of the Refinitiv Real-Time SDK.
  • Allows applications to achieve the highest throughput, lowest latency, low memory utilization, and low CPU utilization
  • Available in C and Java flavours.

Language choice

If outright performance is not the overriding factor, then you have several choices available in terms of language and API/Library choice.

If you can code in Java or C++, the Enterprise Message API(EMA) is probably the best choice as an:

  • Open source, data-neutral, multi-threaded, ease-of-use API (a wrapper around ETA)
  • Offering a High Level of performance suitable for 95% of usage scenarios

However, if your language of choice is .NET, Python, Typescript then you have the following options:

  • Websocket API – raw standard Websocket based interface to streaming data
  • Refinitiv Data (RD) Library – high-level ease of use wrapper for the Websocket API

If you are wondering why you may use the RD library over the raw Websocket; the library takes care of various administrative tasks including login, authentication and connection management.
NOTES regarding RD Library:

  • Python and .NET beta versions of RD Library are currently available as 'RDP Library' and will be rebranded to RD Library once released.
  • Typescript version of the RD Library should be available in Q3/Q4 of 2021

For any other languages that support standard Websocket creation and JSON data parsing, you can use the above mentioned raw Websocket API.

Whilst using the Websocket API requires the developer to handle things like login, connection handling & item recovery etc - we do provide basic examples in several languages demonstrating these techniques.

Performance comparison with legacy APIs

API

Thread Safety

Throughput

Latency

Memory Footprint

Transport API

Safe and Aware

Very High

Lowest

Lowest

Message API

Safe and Aware

High

Low

Low

RFA

Safe and Aware

High

Low

Medium

SFC C++
SFC Java (JSFC)
 

None

Medium

High

Medium-High

WebSocket API

*

*

*

*

* performance achievable with Websocket API would depend considerably on the programming language, Websocket library used etc.

Data Formats

Both the Enterprise Transport and Message API use our Open Message Model (OMM) at the application level and the binary Refinitiv Wire Format (RWF) at the transport level.

OMM provides data building blocks, a bit like ‘Lego’ but for data and you can use the ‘Lego’ to build rich data models to represent things like Full-depth order books or Yield curve data. This contrasts with the flat ‘Field-Value’ pair representation used by our legacy APIs.

RWF uses binary encoding to optimize network distribution – reduced message sizes leads to an increase in total throughput and a decrease in overall latency. Again, this contrasts with the delimited ASCII based representation used by the legacy MarketFeed format.

The Websocket API and the RDP Library use the human-readable JSON format for outgoing requests and incoming response messages.

 

Connectivity

API/Library

Deployed Server (RTDS)

Cloud
(Refinitiv Data Platform)

Desktop
(Eikon/ Workspace)

Transport API

X

X

 

Message API

X

X

 

RD Library

X

X

X

WebSocket API

X

X

 

In terms of connectivity, all the above APIs/libraries will allow you to consume streaming data from our cloud-based Real-time services (such as Real-Time Optimized) and your deployed Refinitiv Real-Time Distribution System (formerly known as TREP).

Additionally, the RD library will also allow you to connect to an instance of the Eikon or Workspace application running on the same PC.

 

Data Contribution

If you wish to implement perform Contributions (also known as Inserting/Posting) in your application, the following choices are currently available:

API

Deployed Server (ADS)

Cloud
(Refinitiv Contribution Channel)

Transport API

X

X

Message API

X

X

WebSocket API

X

X

All three of the above APIs will allow you to Contribute data via your deployed ADS server or directly & securely over the internet to the Refinitiv Contribution Channel.

 

Data Publication

API

Interactive Provider (Managed Publisher)

Non-Interactive Provider
(Un-Managed Publisher)

Transport API

X

X

Message API

X

X

WebSocket API

X*

 

*Coming soon

Next Steps / Additional Reading

Once you have narrowed down your choice of API - please refer to the additional articles and links to tutorials etc on the upper right-hand side of the article.

If you are concerned about the performance characteristics and whether a particular API will meet your requirements, the best option is to run some performance tests in your own environment using your own typical data universe - to get an indication of what you can expect in terms of real-life performance. 

The RT-SDK includes source code for performance test utilities - for both ETA and EMA located in the PerfTools folder of each API. Using these examples as a basis for any testing you wish to perform should make any such task easier.

For the Websocket API, you may find my Python Websocket TestClient example useful - as a starting point for any test script you wish to create. There is also a similar example for the RD Python library.

Testing with Docker Images / AWS EC2
You will also note from the above links panel that we have made available Docker Images for RT-SDK and Websocket API. In addition to this, we also provide an AWS AMI containing the RT-SDKs and Websocket API. Hopefully, this should make it easier for you to experiment with the various APIs.

Conclusion

As the article outlines, we have a range of APIs which can be used for real-time streaming data and the exact one you choose will depend on various factors - which I hope I have covered in this article. However, if you do need further guidance, feel free to post your query/concerns on our Developer Forum and/or reach out to your Refinitiv Account representative to arrange a further discussion.

 

streaming real-time api