Currently the WebSocket features of Premia are limited to the Socket class in the TDAmeritrade service, which simply polls the API and then prints the responses to the console. However, a single instance of the stream isn't very useful when you have a watchlist full of symbols and multiple charts to update, so I want to convert the WebSocket thread as its implemented into a thread pool with an active listener/callback for all the data updates so it can be efficiently used for the type of tasks I detailed above.
Once the streams have been organized into a thread pool, some way of communicating with them in a thread safe manner needs to be devised for updating the GUI as requests come in. We should also take extra care not to clog up the buffer with requests, which means having an intimate understanding of the exchange of data going on. Taking the time to read the TDA Streaming Guide https://developer.tdameritrade.com/content/streaming-data will be helpful in testing. This can also play into the design of the callbacks/event handlers for #3
This is an advanced task, so be prepared to do a lot of threading, networking, and reading Boost documentation.
To help with this feature you should be knowledgeable with Boost.Asio https://www.boost.org/doc/libs/1_77_0/doc/html/boost_asio.html and Boost.Beast https://www.boost.org/doc/libs/1_79_0/libs/beast/doc/html/index.html
Currently the WebSocket features of Premia are limited to the Socket class in the TDAmeritrade service, which simply polls the API and then prints the responses to the console. However, a single instance of the stream isn't very useful when you have a watchlist full of symbols and multiple charts to update, so I want to convert the WebSocket thread as its implemented into a thread pool with an active listener/callback for all the data updates so it can be efficiently used for the type of tasks I detailed above.
Once the streams have been organized into a thread pool, some way of communicating with them in a thread safe manner needs to be devised for updating the GUI as requests come in. We should also take extra care not to clog up the buffer with requests, which means having an intimate understanding of the exchange of data going on. Taking the time to read the TDA Streaming Guide https://developer.tdameritrade.com/content/streaming-data will be helpful in testing. This can also play into the design of the callbacks/event handlers for #3
Here's a stack overflow article https://stackoverflow.com/questions/69601043/boost-beast-websocket-how-to-make-a-pending-async-read-queue-work-for-io-con I found that may help in converting the current implementation to using a thread pool, but the design for the callbacks/events still needs to be formulated.