Hi,

Want to clear up some possible confusion -- some of the answers appear to refer to TunnelStreams, which is a feature based on private streams and concerns endpoint-to-endpoint communication.

The question appears to be about HTTP tunneling connections which are described here. See here for information on the connection types (specifically the HTTP and ENCRYPTED types). The Reactor is not required for HTTP connections (but can open them via the same connection types).

Hello @RAJ,

If you are using tunneling to connect to ADS, please refer to ETA Developer Guide, section

Tunneling on how to use HTTPS and encrypted connection.

If you are using Elekton Connect, connecting via EZD, to communicate to the hosted infrastrcuture upsteam, then EZD communication over the internet is secure, encrypted, and no action is required. The complete details can be found on Customer Zone EZD Installation Guide.

I'm using a ETA C API in Linux. The following link says that it can be done only using ETA Reactor and EMA API.

https://docs-developers.thomsonreuters.com/1512760538247/16304/Docs/WebDocs/wwhelp/wwhimpl/js/html/wwhelp.htm#href=API_Concepts/Chap_Consumers_Providers.3.16.html

I would like to implement this using ETA C API (not value add). Is there a code snippet you can share with me that demonstrates how to do this ?

Tunneling requires using ETA Reactor:

Opening a Tunnel Stream Code Sample

Would it be helpful to mention that Elektron C SDK includes the implementation of Reactor if you wish to examine it (Impl->Reactor->TunnelStream)? It's also possible to modify the included implementation for your use if you wish, the only caveat being that modified versions will not be eligible for support by Thomson Reuters..

My application is built on top of the ETA C API (not value add). I was told in the beginning of my development that the raw ETA C API doesn't miss any functionality that is available in the value add version (reactor).

What are my options if I need to change the client application that intends to make a secure connection to ADS using the ETA C API without the reactor ?

Hello @RAJ,

Yes.

Your best bet to implement this semantics on your own, as well as your working example, if the implementation you will find within the Reactor code within SDK (please see my previous answer). This is a time-consuming, involved effort, but the code of the Reactor is available to you, and you have the options to review, modify, and re-implement any part of it.

Please be informed, that modified/re-implemented VA will not be eligible for Thomson Reuters API support.

I looked at the code in Impl->Reactor->TunnelStream under Elektron C SDK. It looks to me that tunneling cannot be used with out the reactor even if I choose to customize my non-value add usage with tunneling.

Hello @RAJ,

Not fully sure if I understand the last question, think I do.

Yes, tunneling as implemented and available, is used as part of Reactor framework. As is it can not be used without it.

Yes, it would be an extensive design and effort to implement it on your own, on top of ETA.

I heard from my technical contact in Reuters that HTTP tunneling is available only in windows platform and not in Linux. Can you clarify ?

Also, I'm just a consumer of ADS and not a provider.

Hi @jim.carroll,

In the recent post, jirapongse.phuriphanvicha confirmed that HTTP and HTTPS tunneling is available only on Windows and not on Linux.

My original question was to make a secure connection using an ETA C API in Linux to the ADS system hosted by Reuters via internet.

My final takeaway here is that it can accomplished only by using Elektron Connect (via the EZD).

Is that correct ?

Hello @RAJ,

As you are intending to connect securely over the internet, Elektron Connect may be the appropriate option for you.

However, reading back through the discussion that has resulted, it seems that your organization may be in the process of selecting/migrating/upgrading your TR infrastructure/ connectivity.

If this is the case, the best decision on infrastructure and connectivity is not only driven by API, and I would recommend to setup a discussion with your account management team. Performance requirements, sizing, cost, maintenance, convenience, all are important considerations, and we would like your organization to be fully informed and to converge on the best decision for you.