Support protocol 6.2

[NichUK]

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]

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]

Create a PR to protocol_6.2 branch

• [ ] Expanded our level one update/summary field sets to include: Trade Aggressor - Identifies if the trade was executed at the bid or the ask. (CME group and ICE exchanges currently) Trade Day Code - The trading day of month that the trade applies to.
• [ ] Expanded fundamental data offering to include: Base Currency - Currency used at exchange of origin. Contract Size - The units associated with 1 contract of a given root. Contract Months - The trading months associated with a given root. Minimum Tick Size - Minimum price change. First Delivery Date Open Time - Standard opening time per root. Close Time - Standard closing time per root. FIGI - global symbol/instrument identifier. Security Sybtype - identifies non-standard options, binary options, and ETF

[NichUK]

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]

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]

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]

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]

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]

@NichUK are we good to merge to master ?

[NichUK]

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