Lightstreamer Connect fail on DEMO account

[swingwin]

I can't connect to the DEMO stream ("https://demo-apd.marketdatasystems.com") since December 2021 with a C# .NET application using the IG API
On the other hand the connection to a LIVE stream ("https://apd.marketdatasystems.com") works

It seems that the problem comes from the "DotNetClient_N2.dll" library.
Has anyone encountered the same problem ?

 

Edited January 22, 2022 by swingwin

[swingwin]

Many thanks @Tartempion.
In any case it is not won with Windows 7.
Because I don't see how to introduce this new property and how to install the TLS12 protocol
I did some tests today on my C# application but without success.

[swingwin]

For .NET applications the problem is clearly located in the .NET Framework and the way the TLS1.2 protocol is set up in it
So it is certainly not a problem linked to the "DotNetClient_N2.dll" library
Indeed :
- I made a test with the java application using the java library "sdk.client.java.se-5.1.1.1623.2.jar" ==> no connection problem and the data arrive correctly with the stream
- I converted this java library to .NET assembly using IKVMC
- my C#.NET application now uses the "sdk.client.java.se-5.1.1.1623.2.dll" library for lightstreamer connections, instead of the "DotNetClient_N2.dll" library
and then the lightstream connection fails with the following error message

"com.lightstreamer.ls_client.PushConnException: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake"

[charlieMk6]

You will need to install a fresh, clean copy of Windows 10 and then everything will work again.
Windows 10 has the underlying HTTPS SSL infrastructure needed for your code.
Other apps, like browsers, build their own HTTPS SSL infrastructure.
It is not possible to patch Windows 7, you are forced to upgrade or use a different code paradigm, like Java.
Note, installing Windows 10 over Windows 7 won't work as it keeps a lot of Windows 7 files, has to be a fresh, clean install of WIndows 10.

[teebeast]

Windows 7 (and 8.1 in January 2023) is out of support by Microsoft. As a developer I recommend you to keep your os, your development tools and used framework up to date. At least at offical supported versions.

[swingwin]

For now, I solved my problem so I can stay with windows 7 and keep my C# application intact.

I developed a DDE server in Python interfacing with the IG APIs.
I converted the Python application into an executable to improve performance.
And I retrieve the DDE in C# (or Excel) with the NDde.dll assembly.

I'll leave it at that for now and wait to test fast feeds in times of high volatility
But if the performance is not there I'm considering doing the same thing with an RTD server and/or with Java.

[swingwin]

I have completed the performance tests in periods of high volatility (US opening for example).
The performances are excellent even if the solution found is a bit twisted.

So I stay on this technical solution which works perfectly with Windows 7 and .NET.
The solution is :
API stream received by a compiled python application, which delivers the data on the workstation with a DDE server.
Thus any application can connect to this DDE server and exploit the stream of the IG APIs (personal application with .NET, Excel, Matlab, etc...). No latency was observed.

[swingwin]

Much simpler solution found to stay all C#.NET.
I use CURL to make the lightstreamer requests, and redirect the CURL output to a C#.NET "delegate", where I process the data stream received from the IG server.
Sincerely yours

[swingwin]

Has anyone used this Lightstreamer Haxe library in .NET version?
https://github.com/Lightstreamer/Lightstreamer-lib-client-haxe/tree/NET-v6.0.0-beta.2

Does it solve the problem mentioned in this thread?

The Haxe library is compatible with Lightstreamer Server since 7.3.2.
But is it the case for the LightStreamer IG server because IG still hasn't given the version used on their servers?
Sincerely

[teebeast]

I've tested it shortly with my project, but it's not running.

The problem with newer versions than 5.0.5 was, that the LS_CID has changed and was not accepted from server anymore. So I think that IG uses an older version of Lightstream Server. The LS_CID seems to be used to keep compatibility between client library and server.

Quote

LS_cid=jqWtj1twChtfDxikwp1ltvcC4BJ4KikvD578vy1sj.h67EK8MCb

Here my log:

Quote

serverAddress changed: https://demo-apd.marketdatasystems.com
event: nr:serverAddress.changed <m=100 du=20 nr=1400>
adapterSet changed: null
user changed: xxxxx
password changed
Connection requested: details: {serverAddress => https://demo-apd.marketdatasystems.com, user => xxxxx, libVersion => dotnet_standard_client 6.0.0-beta.2 build 20230405} options: {keepaliveInterval => 0, serverInstanceAddressIgnored => false, firstRetryMaxDelay => 100, contentLength => 50000000, sessionRecoveryTimeout => 15000, pollingInterval => 0, idleTimeout => 19000, slowingEnabled => false, requestedMaxBandwidth => BWUnlimited, stalledTimeout => 2000, reverseHeartbeatInterval => 0, HTTPExtraHeadersOnSessionCreationOnly => false, retryDelay => 4000, reconnectTimeout => 3000}
event: connect <m=100 du=20 nr=1400>
goto: <m=101 du=20 nr=1400>
goto: <m=101 du=20 nr=1410>
event: select.create <m=101 du=20 nr=1410>
Status: CONNECTING
WS connecting: wss://demo-apd.marketdatasystems.com/lightstreamer headers(null) proxy(null) certificateValidator(false)
goto: <m=120 du=20 nr=1410>
event: du:create <m=120 du=20 nr=1410>
goto: <m=120 du=21 nr=1410>
Subscription requested: subId: 1 {requestedSnapshot => SnpYes, mode => MERGE, items => [MARKET:IX.D.DAX.IFMM.IP], fields => [BID,OFFER]}
sub#subscribe(1) in <m=1>
sub#goto(1) <m=2>
event: send.control <m=120 du=21 nr=1410>
WS event: open
event: ws.open <m=120 du=21 nr=1410>
Sending session create: LS_user=xxxxx LS_cid=xxxxx LS_send_sync=false LS_cause=api
WS sending: wsok
WS sending: create_session
LS_user=xxxxx&LS_cid=xxxxx&LS_send_sync=false&LS_cause=api&LS_password=CST-xxxxx
goto: <m=121 du=21 nr=1410>
event: transport.timeout <m=121 du=21 nr=1410>
Websocket suspended
WS disposing
goto: <m=115 du=21 nr=1410>
event: du:retry <m=115 du=21 nr=1410>
Retrying connection. Cause: Websocket transport not available
goto: <m=115 du=23 nr=1410>
event: retry.timeout <m=115 du=23 nr=1410>
goto: <m=116 du=23 nr=1410>
event: select.create <m=116 du=23 nr=1410>
Sending session create: LS_polling=true LS_polling_millis=0 LS_idle_millis=0 LS_user=Z43B2S LS_cid=xxxxx LS_cause=ws.unavailable
HTTP sending: https://demo-apd.marketdatasystems.com/lightstreamer/create_session.txt?LS_protocol=TLCP-2.4.0 LS_polling=true&LS_polling_millis=0&LS_idle_millis=0&LS_user=xxxxx&LS_cid=xxxxx&LS_cause=ws.unavailable&LS_password=CST-xxxxx headers(null)
goto: <m=130 du=23 nr=1410>
event: du:create <m=130 du=23 nr=1410>
goto: <m=130 du=21 nr=1410>
HTTP event: text(CONERR,65,Unsupported protocol version: com.lightstreamer.b.b1@51dd3b73)
HTTP event: complete
event: CONERR <m=130 du=21 nr=1410>
CONERR 65 Unsupported protocol version: com.lightstreamer.b.b1@51dd3b73
HTTP disposing
Status: DISCONNECTED
goto: <m=100 du=21 nr=1410>
event: du:terminate <m=100 du=21 nr=1410>
Disconnected. Cause: 65 - Unsupported protocol version: com.lightstreamer.b.b1@51dd3b73
Transports enabled again.
goto: <m=100 du=20 nr=1410>
goto: <m=100 du=20 nr=1400>

 

[swingwin]

@teebeast: many thanks for these tests.

I will not try this library if it does not work with IG servers.
I will continue with my personal .NET library based on HTTP calls using CURL.

[SergioLage]

On 16/05/2022 at 05:03, mf2 said:

FWIW, the programming language does not really matter and you don’t need any special libraries to access the LightStreamer API. You can send standard HTTP requests and it works, as long as you stick to the protocol. Personally, I prefer this approach as this makes my program independent from any third-party libraries.

Regarding version 6.0, I meant that the LightStreamer API Companion adds `LS_client_version=6.0` to the request. Note that you don’t need any JavaScript client libraries to access the API via JavaScript, you could use AJAX and/or the .txt endpoint instead of the .js endpoint.

The issue is just that some details in the specification are left to speculation or interpretation, therefore it requires some experimenting. Furthermore, you need to make sure that you process Chunked requests properly if you don’t use polling.

Session V3 authentication can be used in your program, you just have to issue another Session V1 REST Api call afterwards to retrieve the CST and XST tokens, as you observed. Also, the documentation is here, you just need to scroll down to V3: https://labs.ig.com/rest-trading-api-reference/service-detail?id=600

(Note that IG calls this "oauth", but its really not)

So here is what I am doing:

1. Authenticate with the REST api via a V3 session call
2. Issue a V1 session call to get the XST and CST token
3. Send the following HTTP POST request to the lightstreamer server, at `/lightstreamer/create_session.txt`:

"LS_cause=new.api&LS_polling=true&LS_polling_millis=0&LS_idle_millis=0&LS_client_version=6.0&LS_user=<IG Account ID>&LS_password=CST-<CST-Token>|XST-<XST-Token>&LS_container=lsc&"

Some notes:

1. I use polling, which is not recommended, but its fine for my case.
2. The `|` in the password needs to be escaped properly.

Hi Mf2, would you mind sharing part of your code that connects and handles the IG streaming connection? 🙂

 

[mf2]

@SergioLage Interestingly, it seems that there is no proper way to post code in this forum – neither as a listing (no appropriate formatting) nor as an attachment (the filetype is not accepted).

So here is a very minimal C example, which gets you a working connection: http://0x0.st/H_rX.c

Note however, to subscribe to order status etc. you need to supply the other parameters like LS_user etc. which I wrote in my other post about.