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)




"You are either overstaffed or people just don't have problems with your feed because customer support always answers the phone quickly." - Comment from Jay via Email
"I have to tell you though that using the IQFeed API is about the easiest and cleanest I have seen for some time." - Comment from Jim
"It’s so nice to be working with real professionals!" - Comment from Len
"Previously I was using *******. IQFeed is WAY more economical, and for my charting needs is just as good, if not better." - Comment from Public Forum Post
"I've never had DTN go out on me since switching. ******* would go down a couple times every month when I was using them." - Comment from Bryce in AL.
"The service is great, I see a noticeable improvement in my volume profiles over [broker]'s data feed" - Comment from Larry
"I just wanted to say how happy I am with your service. I was able to download the API docs last week and I was able to replicate Interactive Brokers historical bar queries and realtime bar queries over the weekend. That was about one of the fastest integrations that I've ever done and it works perfectly!!!!" - Comment from Jason via Email
"Thank God for your Data Feed as the only Zippers I see are on my pants (LOL), and no more 200 pip spikes to mess up charts." - Comment from Spiro via Email
"You are much better than lawyers or the phone company because you answer the phone when I call! I just love your customer service." - Comment from Isreal
"For anyone considering using DTN.IQ for a data feed, my experience with the quality of data and the tech support has been very positive." - Comment from Public Forum
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 »IQFeed Developer »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: 120
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: 120
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: 120
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: Sun November 17, 2019 9:37 AM CFBB v1.2.0 0 ms.
© AderSoftware 2002-2003