Jump to content

charlie303

Community Member
  • Posts

    15
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by charlie303

  1. @TartempionWell Done! May I ask what machine your code is running on? Is it Windows 7? My research says Windows 7 OS can't install the TLS Cipher Suite for HTTPS SSL that you are using, though independent apps running on Windows 7 can build their own, eg Brave Browser, Firefox, SOAPUI which is written in java and I guess the Python environment too, must all build their own HTTPS SSL stack independent of Microsoft. Maybe there is a way of adding it. It seems Microsoft programmers are out of luck (again) as we are hard wired to the underlying OS despite all the marketing hype about how 'open source' the framework supposedly is. Forced into upgrades for little benefit. My solution for now is to use my second machine for development as my code works - no changes whatsoever, still uses the DotNetClient_N2.dll. I'm impressed with your solution as I was with @mf2for rolling your own libraries. When I get time I will do the same for my code. Their is information out there about the HTTP Clients in .Net and libraries like CurlThin for C#. Would you care to share the few lines of Webclient / StreamReader you use? It is frustrating that needless small changes to libraries / server setups break existing apps. Open Source is the future. I say needless because IG have different HTTPS Cipher Suites on their servers for the REST API and the STREAM API. If it was a technical or security decision then why the differences? Scroll down and compare Configuration -> Cipher Suites if you have time. https://www.ssllabs.com/ssltest/analyze.html?d=api.ig.com https://www.ssllabs.com/ssltest/analyze.html?d=demo-apd.marketdatasystems.com
  2. Progress! but not yet a solution. I was able to get my DotNetClient_N2.dll code working on my second machine! It is a Windows 10 Home machine and is normally used for music production, I don't want to clog it up with a development environment. I will copy over a .exe of @TeeBeast app to test later on. My new line of investigation is the HTTPS SSL stack. I had this problem a long time ago when I was on XP and IG updated their HTTPS SSL stack. XP couldn't handle it and there was no way to patch as it is hard coded into the OS. That forced me to upgrade to Windows 7. SOAP UI still worked on Windows XP then because it uses its own SSL implementation written in java of course whereas I believe all .Net code goes through the Windows HTTP SSL stack. I'm using https://www.howsmyssl.com/ to initially compare the stacks between both machines and see if it is possible to patch my Windows 7 machine to the same stack as my Windows 10. @swingwin Are you on Windows 10? Is it fully updated? I don't know if it is possible to find out what SSL stack and in what order IG are using. It would be helpful in future if IG could post to a sticky thread the changes they make to their servers. Charlie
  3. I'm tending to think that there is not a bug in the LightStreamer code as their libraries seem to be used extensively around the internet. IG are keen to point out to stick to LightStreamer .Net Standard client libraries v5.0.5 when the latest stable build is v5.1.3. Why the reluctance to move to the latest library? I've never had any problems with upgrading Newtonsoft.Json. Or have I got this wrong too. I may test against other versions of the library but feel this will be a wild goose chase. Diagnosing the problem from the client end is difficult because in Fiddler I am not seeing any detailed HTTP Headers. If someone at IG's end could look at the LightStreamer server logs when one of us was trying to connect I'm sure useful information would be gleaned. I guess a possible solution would be to roll our own libraries built from the socket level up but I am not fancying that. Isn't that what the provider libraries are supposed to do?
  4. @swingwin Thanks for the update. That still doesn't explain why some people can get @teebeastand @jlz code to work. Were all tests conducted with the same account username and password details? Are you able to test with someone else's credentials? My suspicions point to the problem being isolated to .Net libraries and the IG LightStreamer server setup for certain users. Though what those users have in common that is causing the problem I don't know. This would explain why the IG team are reluctant to investigate if they are not experiencing the problems from a java / IG STREAM Companion point of view. They don't want to fiddle with settings. IG support for Microsoft users is woeful. I've phoned the helpdesk again and will persist.
  5. @swingwin That wouldn't explain why some people can get @teebeastor @jlzcode to work as we are all using the same libraries. Why aren't they blocked? My IG Stream Companion still works. I was going to try and get the java code to work so I appreciate your feedback on that. Other threads talk about regional IP address settings and where the account residency is located. Others about being on a blocklist because of over use in the past. I've seen people mention the problem with what appears to be Excel spreadsheets and I don't think they use .Net libraries as they are COM based, though I haven't investigated. The truth is I don't know and I am pretty much out of ideas, especially after I went down the OAuth V3 Authentication rabbit hole and I am wary about erroneous speculation. I'm tending to think there is an issue at IGs end that they won't acknowledge because they are more java focused. I'm scratching around in the dark at the moment but will continue to push the helpdesk to address the issue. Why haven't any IG admins posted on this thread? They do so on others when they have an answer. Charlie
  6. I guess I'm having a bad day ;-( I've just installed Visual Studio 2019. I can load and run @teebeast code but no streaming data! I'm on Windows 7. 64 bit machine. Time to take a break. I will look @mf2 stuff tomorrow. There are posts in other threads about IG knowing there is some problem at their end, fingers crossed, maybe it will just work in the morning. Many thanks for all your help though. Charlie
  7. Please keep us informed. Some of us are going crazy with Lightstreamer issues.
  8. I saw that post and saw you added the Refresh-tokens call. Thanks Are you actually getting live market prices? on CS.D.AUDUSD.MINI.IP for example? Is @swingwin still having issues? Seems we are not the only ones
  9. I'm having similar issues. I was wrong (again!) about requiring OAuth login Authentication. I've created a very simple Windows Form app where I copy and paste the CST and XST tokens over from the IG API Companion page. I hard code the lightstreamer endpoint and my client account ID. I have stripped some very light code from both @jlz / algotrader and @teeBeast projects just to see if I can prove the functionality. I can get a 'true' result when I connect to the lightstreamer endpoint but after that I can not stream any data at all. I do get a lot of HTTP 204 No Content The IG Stream Companion still works. I'm on Visual Studio 2017 and have upgraded to .Net Framework 4.8. When I get the Lighstreamer .Net Standard 5.0.5 package from NuGet I also download .Net Standard libraries themselves. Sometimes I have had to restart the IDE and update again through NuGet to ensure I have the latest versions of the .Net Standard libraries. I am still on Lighstreamer 5.0.5 and now the latest version of Newtonsoft JSON. It tells me I connect but nothing else. I looked at @mf code to see if there are any hidden properties in the connection options (for example I will explore setting polling to 0) but I find the whole issue somewhat frustrating, especially when my previous Lightstreamer code worked a charm. Have IG Labs tested for .Net? I will look at sending a create session.txt file to see if I can get that working. @mf2 could you post a create_session.txt file and the complete URL you send it to? Are you @TeeBeast actually getting live streaming data of market prices? I use CS.D.AUDUSD.MINI.IP in the IG Stream Companion and no problems. What am I missing?
  10. @TommyT I'm guessing during a 'scheduled maintenance' IG implemented the same changes to their LIVE environment that have been running on their DEMO environment for a few months now. I'm guessing the main change that is affecting posters on this thread is that you will now be required to login to the REST API with a Version 3 Authenticate session call. $10 says your code is still using Version 2! @mf2 Many, many thanks for your help and showing the way. I think the problem is we need to go to Version 3 authenticate on the REST API and then all else will fall into place. Sorry, if I confuse the issue about going on about 'libraries'. Time to just code and make it work. Appreciate the tip about it not been a 100% OAuth implementation. I will post some code if/when I get it working. It would be nice if IG could post somewhere updates to their REST / STREAM implementation just to give us a heads up in future. Charlie
  11. @mf2 Many Thanks for your help you have steered me in the right direction. I understand now the libraries you are referring to are probably the javascript client libraries v6 which the IG Companions use. I downloaded Fiddler and did some investigation and have revisited code samples. Here's what I have gleaned so far and what I hope to do next. It seems to me the issue is to do with logging in to the REST API using OAuth - which is detailed here as POST v3.0 https://labs.ig.com/rest-trading-api-reference/service-detail?id=600 Once this is achieved I then need to retrieve the session tokens (CST and XST) which will allow me to connect to the LightStreamer server. If any one wishes to follow this it is in the IG API companion, first Login (OAuth) then just below in Session Details set 'Retrieve session tokens to true'. On the right hand side you will see the CST and XST headers retrieved). This explains why @jlz code did not work for me because it is still using REST API Authenticate V2 and not the V3 OAuth method. @jlz code has the new .Net Standard library (v5.0.5) but this, apparently, is not enough. I owe @TeeBeast a lot more credit because in his fork (listed in this thread) he does use the V3 OAuth authentication code. I initially struggled with his code because I am developing in Visual Studio 2017 and his fork, I believe is for Visual Studio 2019. The Windows Presentation Forms project failed to load for me as well but after a lot of deep diving (especially with Notepad) I was able to understand most of it (or so I like to thnk!). Some of the REST API code seems a little too tightly coupled with WPF which is not ideal for me as I still prefer good old chunky Windows Forms. His implementation of V3 OAuth seems 'indepth' but this is not intended as a criticism as some research shows OAuth code and libraries for C# / .Net are very complicated and overblown. I'm kind of stripping his code to make it work in Visual Studio 2017 but he has pointed me in the right direction too. I had to change some project build options too so as to use C# v7.x. The V3 OAuth login explains why @Tartempion was having trouble as they too were probably using Authentication V2 within LabView. I downloaded the java code sample (and Eclipse IDE) as the reports are this works. It seems to me the IG guys are very much java centric and have allowed the .Net guys to sink or swim. In the code (I'm not a java programmer) it seems to use V3 OAuth and then kinda downgrades and uses V2 to get the necessary CST and XST tokens from the HTTP headers for LightStreamer login). So, I am currently trying to get my head around OAuth for C# - it is not documented on IG Labs website which version they use so I'm going to assume for now V2. If I can get some code to login (I managed to do this with a heavily hacked version of @TeeBeast) then I will need to write some code to obtain the CST and XST tokens for LightStreamer login). Then I should be able to connect and get live prices, etc. This current thinking explains to me the issues reported here. Why the legacy .Net client does / does not work. Why the newer one also has intermittent results. Why java works. Why Visual Studio 2017 users have trouble. Why developers think the problem is focused around the LightSreamer STREAM API end when it actuality it could be the REST API login method. Why the IG Companions work but C# code fails. Incidentally, I took the bold move of disabling my DEMO API Key on the My IG website and was then able to create a new one. I don't think IG Markets have any block lists as such, I just think they are more java centric and have other priorities. I will keep this thread updated and if I can get it working I will post some code. It might be that you do not necessarily have to move to LightStreamer .Net Standard v5.0.5 libraries and the legacy ones will work once you can get round the AuthenticateV3 OAuth login hurdle. It's on my list because as of the time of writing I'm not blown away by .Net standard though I understand LightStreamer for .Net Standard is easier to use. Or, I'm wrong and the problem is elsewhere. Fingers crossed. Feedback appreciated, especially from @TeeBeast, who it looks had to hand crank the java code into C#, no easy task. I see from some of his GitHub issues people were having the CST / XST issue, for example at the end of https://github.com/IG-Group/ig-webapi-dotnet-sample/issues/18 He and @jlz seem to be the main drivers of keeping C# / .Net code relevant. Maybe there should be one thread / github page to hold C# /.Net code / VB.Net, etc. Charlie
  12. @mf2 Thanks for the reply. I've been going crazy as this weekend (Sat 14 May 2022) my LIVE LightStreamer API Key stopped working, though the API Companion website is still working. Could you provide me with any more information? What software did you use to diagnose the API Companion? POSTMAN? SOAPUI? Wireshark? When you say version 6 - do you mean LightStreamer Server? I have been using from C# both the legacy client (DotNetClient_N2.dll) and the .Net Standard client v5.0.5. Is there a new client? v6? Any more info would be appreciated. If I get it working I will post a detailed breakdown. Thanks Charlie
  13. So I've waited a few days now for a reply from IG (I received an automated one so I know they got my email which included a link to this thread) and so far none has been forthcoming. I'm not surprised if I'm being honest. I've got a feeling that from IG's point of view it is not really worth their time on the issue of DEMO API Keys. I borrowed a DEMO API Key from a good friend who has had an account with IG for a few years now and had exactly the same problem. I could login from both a browser and from code but the Lightstreamer connection in code failed. I know my friend has not overly used the DEMO API Key for development as he is not a programmer so the problem is not due to overuse. From reading other posts here on this thread the problem isn't due to using C# libraries, whether using the legacy library (DotNetClient_N2.dll) or the new .Net Standard one (v5.0.5 - which incidentally only seemed to achieve adding 350MB of libraries to my project). @Tartempion mentioned using LabVIEW at the socket level and having the same problem. @teebeast mentioned obtaining a new DEMO API Key because of a possible blocklist. I can only guess that there is some issue at IG's end with DEMO API Keys that were issued sometime ago. To be fair, I can understand why this is not a priority for IG. The return on investment is probably not worth it for the resources they would have to devote (skilled, knowledgeable personnel, time, money, etc). I guess that the number of retail clients that use the DEMO API and who are financially viable for IG is very, very low. They are probably more invested in their web, app, MetaTrader and ProRealTime platforms. I actually see this as a positive as I believe in my ideas and skills and now speculate there aren't many doing what I am doing. It is a bit of a poor mark though as I feel as an engineer/programmer, you should know your kit inside out and top to bottom as best you can. Or, at least, reply with an email saying it is not IG's priority at this time to resolve the issue. When I logged onto my friends demo account I noticed that he had trades that were well over a year old and still running (Buy Oil @ US$49!). As a suggestion to IG could they not completely reset/reboot the Demo environment every now and then, after giving advance warning to clients that all demo trades would be wiped? I have decided to continue development of my software for the IG API. I have over a period of time compiled notes and so I am familiar with the implementation and some of its quirks. For example TRADE CONFIRMS on both the REST API and STREAM APIs isn't ideal. I will have to develop against PRODUCTION using my live account which is far from ideal but there are markets that have low margin requirements and price per points (eg the crypto EOS) so hopefully I won't lose money. I'm glad I am not developing from scratch. I've decided though that in the future any new trading software I develop will be for MetaTrader 4. I only have a limited understanding of its API and I hear debugging is a pain. To many it would look like a step backwards but MetaTrader 4 has one great advantage in that I am not tied to any one broker. So if my account were locked or frozen I may have the option to move elsewhere. This is not intended as a criticism of IG who obviously want active clients but if you look at recent world events in say Canada or Russia, Governments can freeze bank accounts without due legal process or notice. Onwards and upwards. Charlie
  14. @teebeast Thanks for the swift reply. Surprise surprise I'm having difficulty creating a new DEMO API Key. The My IG website says there is a problem so I've contacted IG support and hopefully they can reset something. The fact that I'm having trouble doing this does tend to suggest they have taken steps to ensure their servers aren't overloaded which is what I've read in other community posts and is fair enough. I'll keep you posted.
  15. Hi, I'm also having problems connecting to LightStreamer DEMO. My code which used to work fine has recently stopped working. Everything is fine for PROD. Even the undocumented 'Heartbeat' function works. This is using the .Net client DotNetClient_N2.dll. I tried jlz / algoTrader's code (thanks) and got that working for PROD but again not for DEMO. This code uses the .Net Standard LightStreamer client v5.0.5 as I understand it. So that's 2 different C# libraries not working for DEMO. The IG Companion works fine, not had a single problem with that. I've not yet had the time to delve into the HTTP headers, I used to use SOAP UI for that kind of deep dive so I don't know what error codes are being returned if any. Someone here posted about - "Login failed: 403 (Forbidden) error.public-api.exceeded-api-key-allowance" which seems plausible but I haven't diagnosed for so I can't verify. It wouldn't explain to me though why I can still use the IG Streaming Companion concurrently whilst the C# code fails. I could for example connect to LightStreamer DEMO in Brave browser (SUCCESS), then run my code (both client libraries FAIL) and then connect again to LightStreamer DEMO in Oprah browser (SUCCESS). Any permutation on this produces similar results. It seems to me there is a difference between the PROD and DEMO server settings at IG's end. Is there anyway we can escalate? I really don't fancy developing against PROD or wrapping some kind of Java client. Thanks for the help on this thread. Charlie
×
×
  • Create New...
us