IClient connection status.

[Nucs]

There is no way to know if a client is connected, disconnected or suddenly lost connection. There is a heavy need for:

• Event for connection state change.
• Property for current connection state.

---

Current workaround for knowing if client is connected and is working.

a.1. accessing private field _socketClientof type SocketClientand then _clientSocketof type Socket via reflection to send a poll request.

b.1. Disabling timestamps feed (enabled by default) Level1Client.ReqTimestamps(false); b.2. Sending a timestamp request with 200ms timeout via Level1Client.ReqTimestamp(); b.3. If no response came in or exception was thrown - not connected.

When method 'a' and 'b' are true, socket is connected.

[mathpaquette]

Did you try using the AdminClient statuses? I think by properly naming your Level1Client you should be able to know if your client still connected using the Admin features. Not sure about it but I`ll check tomorrow.

[mathpaquette]

@Nucs did you check with AdminClient?

[Nucs]

I'm talking about knowing in a business layer if Level1Client has disconnected, lost connection or just idle because the specific stock is silent.

You'll need to be more specific because there is no documentation at all in any parts of the code. ClientsConnected from StatsMessage in AdminClient provides general count of connections. ClientStatsMessage still doesn't refer to Level1Client current state.

Edit: Looking again at AdminClient, there is not documentation available (in the library) regarding how it works or even towards how to interact with it. If you think it might help with knowing the connection state, examples are needed.

[mathpaquette]

I didnt forget you... Still working to find the time to add this. Before the end of the week for sure!

[mathpaquette]

Nucs, Level1 you will receive Timestamp every seconds, if not, something goes wrong.

[hunterfries]

Wanted to circle back to this...what about checking the status of the DerivativeClient? It is also streaming data and needs to handle connection state changes.

[hunterfries]

Bump here...what do we think about this?

[mathpaquette]

@hunterfries totally agree with you guys that would be nice to have such abiliality in every connected clients. I'll do it once I have spare time, right now focusing on my new contract...

[hunterfries]

No problem. In the meantime, would subscribing to the Level1Client's timestamp callback and then handling a disconnection be the current workaround? Something like:

IQFeedLauncher.Terminate(); IQFeedLauncher.Start(); // start your clients

@Nucs is this how you're handling this?

[Nucs]

The same way I wrote on the first post on a separate thread.

[mathpaquette]

But guys, do you agree that if there's no reconnect mechanism checking the status is a but useless or this is me that not getting the use case?

Suppose I add Connected prop in IClient, you think that's enough?

[hunterfries]

That or an implementation of the workaround above that fired a Disconnected event that we could hook onto. I would just want some input on the implementation.

[mathpaquette]

@hunterfries, yes, I think I prefer the Disconnected event. Ill do that. thanks

[10thBeast]

Hi All,

What is the Product_id in app.config file or user environment variable .From where i can get the product_id key value

[mathpaquette]

@10thBeast long story short, you need to buy a dev license from IQFeed

[Nucs]

IQFeed themselves use a product key in their test tools.. A little reverse engineering got me it. <add key="IQConnect:product_id" value="IQFEED_DIAGNOSTICS"/> Use it at your own risk, I'm not responsible for anything. you'll have to eventually purchase the dev pack for your own product.

[mathpaquette]

Guys, there's no easy way to know if a socket is still connected or not. Even the Connected property from Socket class can lie about his current status in the case the connection dropped unexpectedly. We need to have a HeartBeat mechanism but not supported by IQFeed...

Ill check what I can do with the Admin port to monitor the status with IQFeed Servers but there's no easy way to do it.

[Nucs]

You can always create a separate Level1Clientthat will use timestamps as heartbeat while a different client is used for data. Would be nice to have such a class provided with the library itself.