Hi all

I am new to IQFeed but after good advice from Tim I managed getting started with the help of the ConsoleBenchmark code example. I have the "challenge" that I am running on Linux and therefore have to rephrase parts of the code to compile it. It also adds the extra layer of using Wine though it was actually straightforward.

Now I am trying to receive historical data via the LookupSocket but here I run into trouble.

The program starts by connecting to the AdminSocket, then the LookupSocket. After connecting I send information about the protocol I'll use ("S,SET PROTOCOL,5.1\r\n"). I am a bit confused since in the examples I find such commands terminated with "\n" some places, "\r\n" elsewhere. My impression is that the last is the correct format, but I would be very happy if someone would give me a punch the right direction. No matter how I terminate the command my application outputs "err:ole:CoUninitialize Mismatched CoUninitialize" which I think comes from Wine. But still I get suspicious that I might do something wrong. At this point the program runs without any further trouble.

Second I send the command telling what format and symbol I would like to receive data on and now I run into real problems. I have tried 2 approaches:

1) If I use a Linux'yfied version of the receive code logic in the ConsoleBenchmark application I receive (using recv in Linux) confirmation of the protocol, i.e., "S,CURRENT PROTOCOL,5.1", but then nothing else arrives. The application just hangs in the following receive.

2) If I use a version of the receive code logic from the HistorySocket example I receive a string that looks like \\000\000\000\... but no data.

First of all I would of course be interested if someone has an idea about what might go wrong. I would also be interested if someone can see why the 2 approaches yield different results.

Please let me know if you need further information to help diagnosing what I am doing wrong.

I will be very happy for any hint that might lead me in the right direction.

All the best, Peter

Good morning,

There should not be any need to change the sample code on the benchmark for it to run with Wine that I have heard of, but if you could send me your changes I will take a look to see what jumps out at me. It appears that something is getting corrupted in your socket, but I am not sure what.

You can also enable logging, via right click on the system tray icon ->support->Launch diagnostics, and then add logging so you can see what the socket is actually receiving and returning, versus what you are getting in your output.

/r/n is expected to follow all of your commands that you will send to the server. Since the servers are Linux based though, many of the returns will just be /n terminated as per the docs. If you have one that doesn't look right though, let me know and I will check.

S,SET PROTOCOL,5.1<CR><LF>
S,CURRENT PROTOCOL,5.1<LF>

Tim

Hi Tim

Thanks once again for really good advice! What you explain about the difference in <CR><LF> and <LF> makes good sense and fits with my observations in the documentation.

I have tried to turn logging on via send a "S,SET LOG LEVELS,.." command which has not worked. I had not tried the right click option on the system tray icon which as you described led me to set log levels. Examining the logs it turned out that the command I sent requesting historical data on the lookup socket did not work why I did not receive anything. Fair enough :). After changing the code the problem disappeared but I honestly do not know what caused it. Sorry for wasting your time, but your answers helped go in the right direction and solve the issue myself. So I am very happy.

With regards to changing code to make it run on Wine, you are right nothing is needed in the sense that ale the compiled .exes that ship with the API works (all I have tried at least). But on Linux I am compiling with gcc and some function have different names, signature and/or are implemented differently (I think) under the hood. I am sorry for not making that clear in my original post.

Once again thanks for your great help and support, Peter