Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)




"I will tell others who want to go into trading that DTN ProphetX is an invaluable tool, I don't think anyone can trade without it..." - Comment from Luther
"I just wanted to let you know how fast and easy I found it to integrate IQFeed into our existing Java code using your JNI client. In my experience, such things almost never go so smoothly - great job!" - Comment from Nate
"Thanks for following up with me. You guys do a great job in tech support." - Comment from Phelps
"DTN has never given me problems. It is incredibly stable. In fact I've occasionally lost the data feed from Interactive Brokers, but still been able to trade because I'm getting good data from DTN." - Comment from Leighton
"I "bracket trade" all major news releases and I have not found one lag or glitch with DTN.IQ feed. I am very comfortable with their feed under all typical news conditions (Fed releases, employment numbers, etc)." - Comment from Public Forum
"I was with ******* for 4 years at $230 a month, this is a huge savings for me, GOD BLESS YOU PEOPLE," - Comment from T.S. via Email
"This is an excellent value, the system is generous (allowing for 500 stocks) and stable (and really is tick-by-tick), and the support is fantastic." - Comment from Shirin via Email
"I have been using IQFeed now for a few years in MultiCharts and I have zero complaints. Very, very rare to have any data hiccups or anything at all go wrong." - Comment from Public Forum
"I've been using IQFeed 4 in a multi-threaded situation for the last week or two on 2600 symbols or so with 100 simultaneous daily charts, and I have had 100% responsiveness." - Comment from Scott
"I'm satisfied with IQFeed. It's the most reliable and fastest quote feed I have ever used. Although I'm a resident in China, it's still very fast!" - Comment from Xiaofei
Home  Search  Register  Login  Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
Follow DTNMarkets on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
»Forums Index »Archive (2017 and earlier) »IQFeed Developer Support »Port 5009 being reopened when port 9100 is opened?
Author Topic: Port 5009 being reopened when port 9100 is opened? (7 messages, Page 1 of 1)

taa_dtn
-DTN Evangelist-
Posts: 154
Joined: May 7, 2004


Posted: Jun 26, 2004 09:38 PM          Msg. 1 of 7
Hi, folks. I'm seeing some behavior in IQFeed 2.3.0.1 that I haven't been able to understand completely, so I thought I'd run it by you for a possible explanation.

It appears that each time my app opens port 9100 (e.g. to do a symbol search), a fresh connection to port 5009 is automatically opened by something in the IQFeed software stack. But when my app closes port 9100, the extra connection to port 5009 is not closed. These extra port 5009 connections just seem to hang around forever; according to netstat they're active and not in any of the TCP/IP closing-handshake states.

I've worked around this by opening port 9100 once and never closing it. Is that the intent of the API design, or are the stale connections to port 5009 a bug?

Allen

DTN_Vik_Kodipelli
-Interested User-
Posts: 11
Joined: May 7, 2004


Posted: Jun 29, 2004 03:42 PM          Msg. 2 of 7
Do you see this behaviour with the history socket client sample app too. I am not seeing any of this on my end. I do see the 5009 being opened but it gets closed when the app calls removeclientapp.


~~~~~~~~~~~~~~~~
Vik Kodipelli
Software Developer
DTN Market Access
http://www.iqfeed.net

~~~~~~~~~~~~~~~~

Edited by DTN_Steve_S on Sep 19, 2011 at 09:14 AM

taa_dtn
-DTN Evangelist-
Posts: 154
Joined: May 7, 2004


Posted: Jun 29, 2004 04:29 PM          Msg. 3 of 7
Quote: I am not seeing any of this on my end. I do see the 5009 being opened but it gets closed when the app calls removeclientapp.


My app doesn't call RemoveClientApp() until it stops monitoring at the end of the day or is closed by its user. It opened ports 9100 and 9200 only when they were needed and closed them afterwards, until I discovered that closing 9100 left an orphan connection to 5009. Large numbers of search or history requests meant large numbers of open connections to 5009. I was worried it might also mean large numbers of blocked threads or other resource leaks that might affect reliability or performance.

That's what I was getting at in my previous question. Is this behavior a bug, or is it just the intention of the API designers that ports never be closed and reopened? Normally I free up dynamic resources as soon as they're idle, and I would have expected IQConnect to do the same, but maybe that's the wrong assumption.

I'm happy to stick with whatever usage model the designers intended, so if you guys aren't concerned about the orphaned connections, all that's needed is a note in the documentation to help clarify things for future developers.

Allen

DTN_Vik_Kodipelli
-Interested User-
Posts: 11
Joined: May 7, 2004


Posted: Jun 30, 2004 10:04 AM          Msg. 4 of 7
I think the reason we have not had an issue with this so far is because most third party developers open these ports and then do not close them till the app shuts down. But as you said this is not a clean way of doing things. This has been brought to the notice of IQFeed developers and you can expect a fix or a new release soon.


~~~~~~~~~~~~~~~~
Vik Kodipelli
Software Developer
DTN Market Access
http://www.iqfeed.net
~~~~~~~~~~~~~~~~

Edited by DTN_Steve_S on Sep 19, 2011 at 09:14 AM

taa_dtn
-DTN Evangelist-
Posts: 154
Joined: May 7, 2004


Posted: Jun 30, 2004 01:28 PM          Msg. 5 of 7
Sounds good. Thanks for the followup!

Allen

tadams
-Interested User-
Posts: 18
Joined: May 7, 2004


Posted: Jul 1, 2004 09:41 PM          Msg. 6 of 7
Vik,

If I'm not mistaken this has been highlighted a few times, but phrased as 'Number of connections not decrementing'. After I've connected/disconnected to port 9100 roughly 2000 times, IQFeed crashes, Dr. Watson-style.

Some of the TCP/IP developers (Me) have encapsulated objects that spawn a connection for specific method calls. The local 'server', IQConnect, should really be able to determine when a disconnect happens.

As a workaround, I've had to create a quite nasty middleman that monitors the health of the IQConnect process and doubles as a TCP server. My objects connect to this server to receive IQConnect 'health' messages. When IQConnect crashes (multiple times daily), my objects are broadcast a message indicating that it's down. The middleman forcefully terminates IQConnect then restarts it. When 5009 is alive again, a broadcast is sent out indicating that all is OK again.

This is particularly troubling when I'm grabbing a series of historical data. Since I have to code around UP and DOWN events, lots of extra code is required to remember how far I've gotten. On the other hand the middleman is a lifesaver for realtime watches, as my UP event populates a watch list (if IQFeed crashes, the persistent middleman forces it back up ASAP and data capture resumes with no additional coding).

Users of the ActiveX objects won't have this issue, but also cannot recover from an IQConnect crash.

In summary, this is the most critical issue I've seen as it causes IQConnect to crash in the midst of data capture daily. Hope my marketing of the topic has an effect.....


Ted
Edited by tadams on Jul 1, 2004 at 09:46 PM

DTN_Natalie_H
-DTN Evangelist-
Posts: 175
Joined: May 10, 2004

DTN Market Access, LLC.


Posted: Jul 2, 2004 10:22 AM          Msg. 7 of 7
Ted,

We're looking into it. Thanks!

Natalie Hannan DTN Market Access, LLC.
 

 

Time: Fri April 12, 2024 10:21 AM CFBB v1.2.0 12 ms.
© AderSoftware 2002-2003