search

mathpaquette / IQFeed.CSharpApiClient

IQFeed.CSharpApiClient is fastest and the most well-designed C# DTN IQFeed socket API connector available
MIT License
120 stars 43 forks source link

Support protocol 6.2 #61

Closed NichUK closed 1 year ago

NichUK commented 4 years ago

Hi @mathpaquette,

Are you interested in a PR to support 6.1?

I've got a completely working version, although because MarketSummary is in beta, and subject to change, it's handled semi-dynamically, which obviously is a little slower, but no reflection. Otherwise it fits pretty well with everything that you've done previously, architecturally speaking.

I've also written some, but obviously not enough, tests to go along with it.

I'm sure there are some improvements to be made, and I'll probably get to them in a bit, but I had a hard need to get 6.1 functional for the project I'm doing.

Nich

mathpaquette commented 4 years ago

Hi @NichUK thanks for reaching out. Sure, I think the goal here is to support as close as possible IQFeed apis. Lets create a PR ill review and comment on the shape of it.

THanks Mathieu

mathpaquette commented 3 years ago

Create a PR to protocol_6.2 branch

NichUK commented 3 years ago

So I've started looking at 6.2, and done some initial prep-work. There are three sections to the protocol update this time. 1) TradeCorrectionMessages - easy, and done. 2) Level 2 - new watch type (by market order), more levels of depth (up to 40 for some exchanges) and a change in the format of messages received. Each message now only provides one side, so there will be more, smaller messages. This is a breaking change though, so I think we should probably create a new set of methods to handle it, and drop the old ones, so that people have to consciously update their application. As long as IQ supports protocol 6.1, it should also be possible to keep the old methods, and force them to use a separate connection where the protocol is set to 6.1. 3) New Lookup Data Message Identifiers. Basically, this means that lookup data messages will now be prefixed with a single character (similarly to level 1 streaming message) which details what type the message is, and therefore how it should be handled. After a quick look, I'd say that means that we can probably radically simplify the message handling in that section, and restructure it like the level 1 streaming message architecture. No more MessageContainer, I think. The message types stay the same, but are prefixed: LH - History Data LM - Market Summary Data LN - News Data LC - Chains Data LS - Symbol Data

<edit> I've remembered the gotcha that I wanted to raise with the lookup data message identifiers... If there is existing data in files, then that won't have the identifier. So... we can know what sort of data the file contains, but obviously we'll have to support both old and new data formats - although I'm assuming that there's no message container in the data file, so we should still be able to simplify everything. </edit>

@mathpaquette, how does that all sound to you?

mathpaquette commented 3 years ago

So I've started looking at 6.2, and done some initial prep-work. There are three sections to the protocol update this time.

  1. TradeCorrectionMessages - easy, and done.
  2. Level 2 - new watch type (by market order), more levels of depth (up to 40 for some exchanges) and a change in the format of messages received. Each message now only provides one side, so there will be more, smaller messages. This is a breaking change though, so I think we should probably create a new set of methods to handle it, and drop the old ones, so that people have to consciously update their application. As long as IQ supports protocol 6.1, it should also be possible to keep the old methods, and force them to use a separate connection where the protocol is set to 6.1.
  3. New Lookup Data Message Identifiers. Basically, this means that lookup data messages will now be prefixed with a single character (similarly to level 1 streaming message) which details what type the message is, and therefore how it should be handled. After a quick look, I'd say that means that we can probably radically simplify the message handling in that section, and restructure it like the level 1 streaming message architecture. No more MessageContainer, I think. The message types stay the same, but are prefixed: LH - History Data LM - Market Summary Data LN - News Data LC - Chains Data LS - Symbol Data
I've remembered the gotcha that I wanted to raise with the lookup data message identifiers... If there is existing data in files, then that won't have the identifier. So... we can know what sort of data the file contains, but obviously we'll have to support both old and new data formats - although I'm assuming that there's no message container in the data file, so we should still be able to simplify everything.

@mathpaquette, how does that all sound to you?

Sorry didn't notice this before. Umm. I got your point.

I dont think we should and have to return these identifiers to the user at all.. Basically, the way the lib has been designed, we dont really really about them at all because we do one request per connection at any given time. Its better to have multiple clients responsible for each their request in parallel. Overall, we can keep the same structure, we just need to discard the first identifier and parse... (I think).

NichUK commented 3 years ago

Yes, I think I have a structure that should work now. Similar to last time. I’ll have a PR for you in a couple of days most likely.

mathpaquette commented 3 years ago

Yes, I think I have a structure that should work now. Similar to last time. I’ll have a PR for you in a couple of days most likely.

Sounds good. Man they will support NASDAQ OpenView this is quite exciting stuff TBH. Are you guys using L2?

NichUK commented 3 years ago

We're experimenting with L2 right now. We'll definitely get into using it at some point though.

On 4 Apr 2021, at 22:31, Mathieu Paquette @.***> wrote:



Yes, I think I have a structure that should work now. Similar to last time. I’ll have a PR for you in a couple of days most likely.

Sounds good. Man they will support NASDAQ OpenView this is quite exciting stuff TBH. Are you guys using L2?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/mathpaquette/IQFeed.CSharpApiClient/issues/61#issuecomment-813102403, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AACUVKAQAQDRYXXA6YACGALTHDLBVANCNFSM4MDK52GA.

mathpaquette commented 2 years ago

@NichUK are we good to merge to master ?

NichUK commented 2 years ago

I haven't looked at this for a while, but I was happy with it back then...