Fqsns #295
Merged
Fqsns #295
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Bleh, CI is actually failing due to this change: So i guess even more hassle to test things 😂 |
iamzoltan
reviewed
Apr 9, 2022
| @@ -18,9 +18,9 @@ | |||
| Kraken backend. | |||
|
|
|||
| """ | |||
| from contextlib import asynccontextmanager | |||
| from contextlib import asynccontextmanager as acm | |||
There was a problem hiding this comment.
this is definitely cleaner
Allocate and `.started()` return the `ShmArray` from here as well in prep for tsdb integration.
In order to support instruments with lifetimes (aka derivatives) we need generally need special symbol annotations which detail such meta data (such as `MNQ.GLOBEX.20220717` for daq futes). Further there is really no reason for the public api for this feed layer to care about getting a special "brokername" field since generally the data is coming directly from UIs (eg. search selection) so we might as well accept a fqsn (fully qualified symbol name) which includes the broker name; for now a suffix like `'.ib'`. We may change this schema (soon) but this at least gets us to a point where we expect the full name including broker/provider. An additional detail: for certain "generic" symbol names (like for futes) we will pull a so called "front contract" and map this to a specific fqsn underneath, so there is a double (cached) entry for that entry such that other consumers can use it the same way if desired. Some other machinery changes: - expect the `stream_quotes()` endpoint to deliver it's `.started()` msg almost immediately since we now need it deliver any fqsn asap (yes this means the ep should no longer wait on a "live" first quote and instead deliver what quote data it can right away. - expect the quotes ohlc sampler task to add in the broker name before broadcast to remote (actor) consumers since the backend isn't (yet) expected to do that add in itself. - obviously we start using all the new fqsn related `Symbol` apis
Use fqsn as input to the client-side EMS apis but strip broker-name stuff before generating and sending `Brokerd*` msgs to each backend for live order requests (since it's weird for a backend to expect it's own name, though maybe that could be a sanity check?). Summary of fqsn use vs. broker native keys: - client side pps, order requests and general UX for order management use an fqsn for tracking - brokerd side order dialogs use the broker-specific symbol which is usually nearly the same key minus the broker name - internal dark book and quote feed lookups use the fqsn where possible
- move to 3.9+ type annots - add initial draft `open_history_client()` endpoints - deliver `'fqsn'` keys in quote-stream init msgs
iamzoltan
approved these changes
Apr 11, 2022
| Basically the idea here is for all client-ish code (aka programs/actors | ||
| that ask the provider agnostic layers in the stack for data) should be | ||
| able to tell which backend / venue / derivative each data feed/flow is | ||
| from by an explicit string key of the current form: |
guilledk
approved these changes
Apr 11, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fqsn= "fully qualified symbol name"Basically the idea here is for all client-ish code (aka programs/actors that ask the provider agnostic layers in the stack for data) should be able to tell which backend / venue / derivative each data feed/flow is from by an explicit string key of the current form
<instrumentname>.<venue>.<suffixwithmetadata>.<brokerbackendname>.I have thoughts that we should actually change this to be more like an "attr lookup" (like how the web should have done urls, but marketting peeps ruined it etc. etc.):
<broker>.<venue>.<instrumentname>.<suffixwithmetadata>This preps for new derivatives search support in the
ibbackend coming in #294 (which will get rebased and likely renamed after this).Moar,