Closed GregGamba closed 3 years ago
@GregGamba thanks for raising this @mrut2pac can you please give it a look since you're investigating this right now?
@GregGamba is that the only problematic one you figured out ?
@mathpaquette, yes it was the only one. Didn't seem to matter what combination of fields were used, once Type was involved everything gets thrown off.
@GregGamba did you communicate that with IQFeed or not yet. this is an interesting one. @BunkerCoder did you notice it ?
@mathpaquette no, tbh with you I have no clue how to deal with this, lol. I figured out a workaround to achieve what I needed and came here in hopes it would help. What did I do?
@GregGamba let me get some feedbacks from the folks who are using it and see if it comes from our side or their.
most probably the issue comes from us this time.
@GregGamba did you communicate that with IQFeed or not yet. this is an interesting one. @BunkerCoder did you notice it ?
I'll take a look.
@GregGamba - The Type field contains Q for Update messages or P for Summary messages. You get one Summary message when you start watching, and the rest are Update messages. Adding the Type field is breaking the parsing logic because Type is already included in the message and can't be added twice.
The data you're looking for is in the Message Contents field. From the 6.0 Protocol docs:
Possible single character values include: C - Last Qualified Trade. E - Extended Trade = Form T trade. O - Other Trade = Any trade not accounted for by C or E. b - A bid update occurred. a - An ask update occurred. o - An Open occurred. h - A High occurred. l - A Low occurred. c - A Close occurred. s - A Settlement occurred. v - A volume update occurred. NOTE: you can get multiple codes in a single message but you will only get one trade identifier per message. NOTE: It is also possible to receive no codes in a message if the fields that updated were not trade or quote related.
I'll have to figure out the best way to handle this, but you should definitely not include the Type field for now.
@mathpaquette - I have a simple fix locally which basically prevents adding Type (throws) to the dynamic field list (but still supports the property to avoid breaking existing client code). However, I'm fighting an issue in the integration tests that causes my IQFeed Connection Manager to freeze up as soon as it gets to the Level2 tests (I don't have a L2 subscription, and an error window pops that I haven't captured yet). This prevents me from doing mid-session testing because I have live clients that need to collect real-time data. Once I've had a chance to isolate the issue (and hopefully resolve), I'll do the PR. (It seems a little pointless with #107 looking good and the simple workaround above, but I'll do it for completeness.) BTW - I'm on IQFeed Version 6.1.0.20. What version are you using?
Update - Just saw this: namespace IQFeed.CSharpApiClient.Tests.Integration.Streaming.Level2 { /**
I'll re-test after the session without L2 and submit the PR.
Dynamic Level1 Streaming, trying use the field "Type" to identify trades vs updates. When I add "Type" to my list of fields it causes all the other data (Bid,Ask,Last etc) to come back weird (1s, and 2s,).
Pic1: Type commented out -- everything works just fine![image](https://user-images.githubusercontent.com/11835590/112995351-1ff14100-9139-11eb-90dd-eadc7dcd9a5d.png)
Pic 2: Type included -- everything comes back weird![image](https://user-images.githubusercontent.com/11835590/112995503-4a42fe80-9139-11eb-857e-752317615681.png)