Generic question here, but I think its important. We've all been getting emails about the new Production Servers, but I've never been able to find information that explains what exactly does that mean.

My assumption is that when my client IQFeed application connects, it 'connects' to the (a) production server(s). That said, what is the differences that I should be aware of as a developer between this new production servers?

The Production servers are the servers that you connect to on an everyday basis. They are often also refered to as the "LIVE" system.

We are nearing a MAJOR serverside release for IQFeed. This release is currently scheduled to go into production on June 16th. It requires that you be running the latest version of IQFeed in order to make sure you have accurate data. It also includes the second resolution in the feed.

The Pre-Production servers that you have been hearing about is the new server code running in a test environment. In the emails you have been receiving, you will find instructions on how you can connect your software to these new servers to make sure that your software is ready for the changes in the feed that are going to happen when they roll out onto the "LIVE" system.

Does this help clear things up?

Well you confirmed what I thought was true, but there is still the other issue of what is new, etc, in this version.

More specifically, I remember reading articles here that talk about how you were putting in new algorythems to smooth over data holes. Or that it would be faster, etc.

Can you give us some idea about why the move to the new server farm? Or point me to where I might find that data?

Thanks!

Pretty much everything you need to know has been sent via the developer notices. If you didn't keep them, you can access the archive of developer notices by logging into the developer area of the website and clicking the link in the left hand menu. If you have questions about anything specificly, feel free to email me at developer support (or get in touch with me in chat) and I will do the best I can to answer them.

The primary need for the new servers is to do some architectural changes in the interprocess communications within the servers.

Almost all of the new features within the servers are internal changes that the outside client will never see. Better administration controls, better debugging tools, better data monitoring toold, etc.

The exception to this is addition of seconds in the timestamp of trades and moving strike price and expiration date to the Fundamental message.

If I missed anything here, I'm sure that Jay will correct me but it should be safe to assume that anything else you have read about is either not being implemented at this time and/or is not directly related to the release of the new servers.

But as always, if you have specific questions about something, feel free to contact me via chat or via email and I'll look into it.

Okay, I have read all the developer notes and have one last question: when we connect using the new Client 4.2.1.4 are we automatically connecting to the new servers or do we still have to configure it to get to the new servers (for testing)?

Thanks

IQConnect will always connect to the current Production servers unless configured to connect differently. This has not changed with IQFeed 4.2.1.4.

When you make the configuration change on your local computer, you will be connecting to the Pre-Production servers and you should make sure to change it back in order to connect to the Production servers again. When the new servers go into Production (currently scheduled for the weekend of June 16th), no changes will be required by the end user to connect to the new servers.

Just a thought:

As this is a MAJOR server-side release, and you are also in the process of releasing backwards-incompatible changes to the IQFeed client, isn't it about time to change a more major release number of the client?

What does 4.2.1.4 actually mean? This is not a minor change.

I would have thought that considering the watershed nature of the current bunch of changes, it might rate a release number of 4.3 at the very least and you could even entertain calling it release 5.

My question is whether you have had any luck getting 4.0+ to work with SOCKS software.

I currently use 2.1 in a SOCKS environment and it works fine but have had no luck getting the newer versions to work properly.

I've tried all the SOCKS software: Aventail, Hummingbird, Permeo, etc. No luck

Disabling the old clients will hurt.

p.s. current version is use is 2.3.1, not 2.1

Dennis, We actually did start with a Major release for these changes. As you are probably aware, having been a developer for several years, these new servers are a long time overdue. The 4.x line started with compatability for the new server design. 4.0.0.0 (which was never officially released ) and 4.1.1.1 (the first official release of the 4.x) implemented ALL of the necessary changes to at least connect and get data. Support for the only backwards incompatable change (second resolution) was released in this version. It was also announced at that time that the change was to be implemented. Unfortunately it has taken us much longer than expected to actually get it implemented serverside.

The changes to the client from 4.2.0.7 to the current 4.2.1.4 are simply bugfixes from the previous versions in the 4.x line. The new fields are not new from the server. They have been being sent for quite some time but due to an oversight in development, they were not being sent to the client applications. Additionally, it is a comma delimited feed so adding fields to the end of the feed should not break backwards compatability. The other changes, like the volume bug, were exactly that, bugs. And I'm fairly certain you would agree that bug fixes normally do not warrant even a minor version.

Now with that said, yes, you are right that we could have incremented the minor version number (or even the major again) and we did consider doing exactly that. But the powers that be, decided the fate of this release was to be versioned 4.2.1.x and the above reasoning was taken into account in making the decision.


squirlhntr,
I am not exactly sure where to start with this. We have never officially "supported" SOCKS. Obviously it worked with an older version but there was nothing in the code specificly that would have made it work and to be entirely honest, I am not at all familair with the SOCKS protocol to know what could have changed. If I were to guess, I would say it has to be a change within the internals of MFC's CAsyncSocket Class that is causing the difference.

Either way, there is almost certainly not going to be another client release prior to the new servers rolling into production which means some sort of workaround will be required.

Thanks Steve.

Yeah I don't understand SOCKS either which is why I got so confused as to how it went from working to not. I do understand that it's not supported, which is fine; I do write software for a living after all

I will investigate further and see if I can find a workaround. If it is an MFC class there must be a way to hook into it in some way and override what it is doing; the odd thing is that connecting goes fine, and the IQ ports show up, but they are not in a "listening" status.

Back to work.

Steve,

FYI I had no luck getting the standard SOCKS (Permeo, Aventail, etc) clients to work.

However I found a free (for personal use) "mini" SOCKS program published by Permeo (originally written by NEC) that does the trick called "SocksCap". The only thing is it doesn't work automatically, you have to launch your program from SocksCap.

Small price to pay though for a functioning client.