On various threads over the years people have requested API support under Linux or alternatively a Java client that would provide cross-platform support.
As neither of these appears to be forthcoming, a number of people have had success in running the existing client under WINE on linux.

Would anyone out there care to share their experience and possibly provide some pointers and hints?

We have very good linux knowledge and reasonable Windows experience but none with WINE.

Does DTN have any experience with IQFeed under WINE? If so, would you consider an unofficial (ie unsupported) HowTo document?

Dennis, as Jay has mentioned on other threads, we have put some work into a Java version of the feed intended to be cross platform but right now that project has once again been delayed due to other higher priorities that need to be addressed. I realize that isn't great news but I just wanted to put that out there to show that we have heard the requests of our customers for more support than just windows and we are working on options to fulfil those requests (although slowly). Currently, as you acknowledged, WINE is the best way to go for those needing linux support.

Unfortunately I don't have a whole lot of knowledge on the subject. However, for what it's worth, here has been my experience in that area.

When these reports first started surfacing I was able to get it running under WINE on a, then current, distro of SuSe (I'm thinking it was SuSe 10 or maybe 10.1). Since then, we haven't had any reports of it not working so we haven't gone back and tried to verify again.

I'm not a linux guru by any stretch of the imagination, but everything was pretty straight forward for me. After the linux install, I installed WINE via one of the built in software managers (I can't remember what the one on SuSe is called) and then simply ran the IQFeed install under WINE to get everything running. I do remember that I had some issues getting the Microsoft Visual C++ Redistributable installed that IQFeed requires but a google search gave me that answer. After it was installed, it was as simple as launching IQConnect. At that time we were still requiring use of IQ32.dll soi the launching app had to be run under WINE as well. I suspect that it wouldn't be as hard now that we don't requrie IQ32.dll to launch the feed.

From my experience, it seemed like the way that WINE works is basicallly by emulating 3 separate pieces of the OS. First, it creates a File Structure similar to what windows uses (with C:\windows\ and C:\Program Files, etc). Next it emulates the windows registry. And Last it intercepts any calls to the Windows API by the application that is running and translates them to the appropriate linux kernal calls (and directs storage to the file structure and registry). I'm sure there is a bit more to it, but that was the experience that I had.

Thank you for your response.

I did try to use IQFeed with WINE some time ago when IQ32.dll was required to launch and had a few problems but didn't persist.

I'll give it another go with the later IQFeed and hopefully will have more luck.

I run IQFeed under WINE on a headless server. One extra step I had to do was install Xvfb, the X virtual frame buffer. I also kick off the script with a DISPLAY=:1 (based on how I configured Xvfb).

I use IqFeed under Wine with a scala client that communicates with it via TCP/IP and that works just fine. I developed it on OSX and deploy on linux.

Would DTN be willing to release enough information for the community to work on our own ports of IQFeed? Developers in the field may have the resources to complete the project. We have the desire to develop market apps for iPhone and iPad. Java is not an option on those platforms. We need an API to write to that exists on DTN servers, not on an intermediate client layer, using an efficient binary protocol, like RTMP for example.

Unfortunately this isn't as simple as building ports for different operating systems or platforms. We are evaluating other connectivity methods (such as direct to server) but have to take several things into consideration. One of the biggest is exchange regulations. Another is that the IQFeed service would likely blow up any mobile device out there due to the speed in which we send data. From a business perspective, we must take into account that on an iPad or other device, users may not want, or need to see every tick or be able to watch 500 symbols at a time. We don't have a way to throttle down our data currently. We are currently working on backend server changes that will give us more flexibility to support additional platforms in the future. Once we are ready, we will be sure to announce the new interfaces here.

---

Jay Froscheiser
DTN

Thanks for your reply, Jay. Good to hear from you.

The reason I mentioned the RTMP (real time messaging protocol) is that it supports throttling. It's designed for video and other realtime data streams. Stock data is much like video - it's realtime, packets must be in sequence, latency needs to be minimized, requires an efficient binary data stream, and different types of clients need to be supported at different frame rates from the same data source (connection speed, device CPU, what have you).

Adobe released the RTMP spec about a year and a half ago. The RTMP protocol is embedded in Flash Player on all the mobile platforms like Android and Microsoft.

While the iPad won't directly support Flash Player itself due to the fact that it downloads executable code, they ARE allowing Flash apps to run after they are cross compiled to a native executable, so again, RTMP is going to be easily available there as well.

There are open source implementations of RTMP available, in all sorts of languages... If your server could accept incoming client connections over RTMP, you would instantly be cross platform, while adhering to a popular messaging protocol at the same time, which is open to other implementations.

The natural binary object format on top of RTMP is AMF3. It's a hierarchical binary data object (de)serialization format. There are all kinds of AMF3 implementations that are also open source.

I think iPad users will want to watch many symbols, just with a throttled data rate, and once a given bar closes on the chart, the bar could be read from the historical cache to make sure the highs and lows represent the data they missed. The iPad is not always on a Cellular network - they have WiFi... I see how a lot of historical research could be done with iPad, even with proprietary indicators.