Some beginner questions regarding WebSocket API

hege

Hi,

I am in charge to migrate a MLIP based C#/.NET application to WebSocket API. The application is basically contributing RICs data. I have now looked through the documentation and the C# sample code, and have some initial questions:

1. Redundancy concept:
In MLIP, having parallel connections to two independent servers with automatic failover was a requirement to achieve high availability. I could not find anything like this in the WebSocket API documents.
How is the redundancy / high availability / resilience concept implemented in WebSocket API (if there is any)?

2. Authentication:
Some of your samples implement an authentication request prior to login, while others do the login immediately.
Is the authentication request to the auth server always mandatory when contributing data?

3. Ping / Pong
The documentation states, that either side can actively send Ping requests, while to should respond such requests by a Pong.
What is the recommended strategy when implementing a Contribution application with high availability demands: Should we actively issue Pings, and what would be a reasonable interval?

4. Contribution workflow
If I have understood correctly, data contribution is implemented by using Post messages. This requires opening an event stream and issuing an Item request before we can send a Post message for this RIC.
Do we have to wait for the Item response message, before we can send the post message?

Kind regards,
Wolfgang

Gurpreet

Hi @hege ,

I assume you are migrating from MLIP to Refinitiv Contribution Channel, so my answers below are applicable to RCC. Most of your questions will be answered in a working contribution sample. I would recommend that you go through the article and this tutorial to see how an application is implemented. There is a working python sample application which shows the steps required.

1. Redundancy concept: The application developer is responsible for coding in resiliency in the application by opening two websocket connections.

2. Authentication: Application will first get an access token from token endpoint using password grant, and then open a websocket connection, and send a login JSON message with this token as a payload.

3. Ping / Pong : In the event of no network activity, server will send a ping message and application should respond with a pong.

4. Contribution workflow: Contribution data is sent In JSON POST messages and does not require opening an item stream.

umer.nalla

Hi @hege

A few other comments to add to my colleague's response above.

In terms of resiliency, you may find some benefit from briefly studying the Websocket API C# Consumer exampleMarketPriceRdpGwServiceDiscovery at websocket-api/Applications/Examples/RDP/CSharp at master · Refinitiv/websocket-api (github.com).
Whilst the above example is a consumer (and not a Posting example) it does support hot standby.

Also, in terms of the opening of the stream, you will note from the tutorial - Contributing Data to RCC via WebSocket - that the Post is sent on the Login Stream which remains open whilst you are logged in.

hege

Hi,

Thanks a lot for your responses. This helps a lot!

By the way, I just detected your forum answers accidently. Notifications by e-mail for responses posted in this forum does not work for me. Is there any way to enable mail notifications?

I have not seen the CSharp examples hidden in the RDP folder of the GitHub examples before. Thanks for pointing me to this.

New question regarding redundancy:

In this sample app mentioned ("MarketPriceRdpGwServiceDiscovery"), the available service endpoints are dynamically requested from the discovery server. As my clients are major European financial institutions, they have strict security regulations and so enforce strict firewall regulations. Therefore, a firewall rule for each WebSocket server to be used needs to be configured well before. How can we handle this situation?

Kind regards,

Wolfgang

umer.nalla

Hi @hege

I am not an expert on firewalls etc, however, since the list of endpoints returned does not change that often could the clients not configure the firewall to allow the various endpoints?

You can also create a My.Refinitiv ticket for the Real-time Optimised service and obtain advice from the RTO team on how to best handle the firewall situation.

Note that as well as Service Discovery, you can choose to specify known endpoints (as shown in the MarketPriceRdpGwAuthenticationExample). Although the service discovery option is better, this could be an alternative if your clients are unable to configure their firewall to work with the service discovery.

In terms of the email alerts, please check your spam/junk folders - if you cannot find them please let us know and we can raise a ticket with our forum support team.

hege

Hi Umer Nalla,

thanks again for your great support!

I will then check with your colleagues at the Frankfurt office of Refinitiv, who are in charge of assisting us the setup for our migration project, how to best handle the services / firewall issue. This might take its time though, as no one of them seems to be available right now (general holiday season in Germany).

I did not find any notifications in my spam folder, by the way.

One more question: In the "WebSocket API Protocol Specfication" document, I found the message type "Status message". When is it likely to receive messages of this type, and how should be best react on this? Simply trying to reconnect until this succeeds?

There are also remarks at some types of "Error message", that it requires special setup in the configuration (so for 22.6 Unexpected Key: "NOTE: This error is caught ONLY when the following configuration parameter is present: *ads*catchUnknownJsonKeys: True"). Where is this setup file and who is taking care of this config?

Kind regards,

Wolfgang

umer.nalla

Hi @hege

I will report your issue regards the lack of notification emails - you may receive direct contact from the portal support team.

In terms of status messages, they can be received in various scenarios e.g. you may receive a Suspect Data status message if the upstream server thinks the data is stale etc. This should eventually be followed by a Refresh msg when the issue is resolved.

If you receive a Stream Closed Status then that means the item subscription has been closed.

• If that is a data item and you are 100% certain the item is a valid one, then you can retry the instrument after a short wait. We recommend trying only a few times before alerting user intervention - in other words, don't keep retrying indefinitely.
• If the Close is for the Login stream, then this means you have been logged out of the server and should try login back in. Again, we recommend trying only a few times before alerting user intervention.

umer.nalla

Hi @hege

The following parameter is set to False in the RTO ads-fanout servers.

*ads*catchUnknownJsonKeys : False