Overview
Now that subscription configuration is nearly universal, we can start to address abstracting the solution, and learning from the issues with multiplexing subscriptions.
Required features:
- Support connections per asset class
- Support runtime subscriptions, including FlushChannels
- Enabling pairs after subscription must work
- Support N+ connections due to subscription cap or rate-limiting
- Exchange base functions like
SubscribeToWebsocketChannels need to work for both types of exchanges
- Connection monitoring per connection
Design
- Remove Subscriptions and GenerateSubs from belonging to connections
The most pressing reason for that is that in a world where we might establish N+ connections due to connection rate limiting,
We can't possible generate the right subscriptions and (in the darkness) bind them at the connection level.
I believe Subscriptions must be an exchange level entity, which are then allocated to websockets in a one-to-one relationship.
- Router middleware to map connections and subscriptions
- Just-in-time connections after the first connection
- Separate Subscription configuration from runtime subscriptions
- So that "All pairs" continues to work with FlushChannels
- So we can always re-derive the store from the fanned out subscriptions
- Unify the does/doesn't nature of multi-connection websockets. Everything should just be the same
References
Overview
Now that subscription configuration is nearly universal, we can start to address abstracting the solution, and learning from the issues with multiplexing subscriptions.
Required features:
SubscribeToWebsocketChannelsneed to work for both types of exchangesDesign
The most pressing reason for that is that in a world where we might establish N+ connections due to connection rate limiting,
We can't possible generate the right subscriptions and (in the darkness) bind them at the connection level.
I believe Subscriptions must be an exchange level entity, which are then allocated to websockets in a one-to-one relationship.
References