New example (crypto and ai) - WORK IN PROGRESS, DO NOT MERGE #3037

MungoG · 2025-10-02T17:12:47Z

No description provided.

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.cpp

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

example/websocket/client/crypto-ai-ssl/json_price_decoder.hpp

example/websocket/client/crypto-ai-ssl/live_price_listener.cpp

vinniefalco · 2025-10-02T23:32:36Z

example/websocket/client/crypto-ai-ssl/live_price_listener.cpp

+    double price = 0;
+
+    // Design note: the json parsing could be done without using the exception
+    // interface, but the resulting code would be considerably more verbose.


we need to fix that then, or explore alternatives

example/websocket/client/crypto-ai-ssl/live_price_listener.hpp

vinniefalco · 2025-10-02T23:41:30Z

example/websocket/client/crypto-ai-ssl/live_price_listener.hpp

+    // so that the next async_* function is not called until *after* the previous asynchronous
+    // function is complete. However the strand is included since it makes our threading assumptions
+    // explicit for future developers.
+    boost::asio::strand<boost::asio::io_context::executor_type> strand_;


The purpose of a strand is not really to queue operations, it is to ensure that two operations do not execute concurrently. A subtle distinction.

"we could "get away" without using a strand," is not quite true, because of composed operations.

Sorry, I don't understand. What do you mean by "composed operations" in this context?

It needs an explanation too big for here

Tanner Sansbury touches on it explicitly here https://stackoverflow.com/questions/12794107/why-do-i-need-strand-per-connection-when-using-boostasio/12801042#12801042

…h check

sdarwin · 2025-10-03T19:44:39Z

please rebase on develop, to try ashtum's CI modifications.

ashtum · 2025-10-09T11:23:49Z

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

+    template<class Executor>
+    class historic_fetcher_op
+    {
+        enum class state {


The use of state seems unnecessary, the majority of completion handlers have unique signature and for those that don't (like write and read) we can define a tag type and use asio::prepend to prepend the tag value.
It would look like something like this:

struct on_write{}; struct on_read{}; // signature for write void operator()( Self& self on_write, , system::error_code ec , std::size_t bytes_transferred); // signature for read void operator()( Self& self on_read, , system::error_code ec , std::size_t bytes_transferred); // call site 1 beast::http::async_write( ssl_stream_, request_, asio::prepend(std::move(self), on_write{}) ); // call site 2 beast::http::async_read( ssl_stream_, buffer_, response_, asio::prepend(std::move(self), on_read{})

interesting technique! I hadn't thought of this. You can also use the fauxroutines (in boost/asio/coroutine.hpp)

The problem with using fauxroutines here is that we have a few incompatible function call signatures:

// resolve void operator()( Self& self , system::error_code ec , asio::ip::tcp::resolver::results_type results) // connect void operator()( Self& self , system::error_code ec , asio::ip::tcp::resolver::results_type::endpoint_type ep) // write/read void operator()( Self& self , system::error_code ec , std::size_t bytes_transferred);

Although technically, we can only use the fauxroutine for the write/read operations, because that's where we have to deal with more than one operation.

The downside of asio::prepend is that it creates multiple different function template instantiations of essentially the same asio implementation code

The downside of asio::prepend is that it creates multiple different function template instantiations of essentially the same asio implementation code

If I'm not mistaken, the completion token type is unique for each composed type anyway (it's essentially the Self object type). So, unless we use different tag types for the same operation, like:

async_write(..., asio::prepend(std::move(self), on_write1{})); async_write(..., asio::prepend(std::move(self), on_write2{}));

there shouldn't be any difference.

ashtum · 2025-10-09T11:26:16Z

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

+        client_type&     client_;
+        resolver_type&   resolver_;
+        ssl_stream_type& ssl_stream_;
+
+        buffer_type&   buffer_;
+        request_type&  request_;
+        response_type& response_;


Would it be possible for historic_fetcher_op to just take a reference to historic_fetcher?

that would be better, yes

ashtum · 2025-10-09T11:29:18Z

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

+            } break;
+            default: {
+                // This should not happen.
+                throw std::logic_error("unreachable");


Composed operations should never throw exceptions, because the exception would be thrown from the call site of asio::io_context::run(). They should instead complete with an error (though in this case, it seems to be only for debugging purposes).

ashtum · 2025-10-09T11:42:26Z

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

+            request_.version(11);
+            request_.method(beast::http::verb::get);
+            request_.set(beast::http::field::host, client.get_host());
+            request_.set(beast::http::field::user_agent, BOOST_BEAST_VERSION_STRING);


It is recommended not to perform preparation work that modifies the state of the io_object (historic_fetcher in this case) in the constructor. This is because we can create deferred operations that are planned to be executed later, for example:

auto op1 = fetcher.async_historic_fetch(asio::deferred); auto op2 = fetcher.async_historic_fetch(asio::deferred); // Both of these deferred operations have called the constructor of the composed operation, // but neither has been scheduled for execution yet.

(me, taking notes; master class here)

didn't know that...

@ashtum I am slightly confused as to how to make the code completely robust here. Let's have a conversation in the morning if that's okay for you.

I think he means to launch the async ops in a separate member function, such as operator()(Self& self) ? Example: https://github.com/vinniefalco/http_io/blob/b24d776d5ac6243099828a161f8f0f9265c1b356/example/client/visit/main.cpp#L112

Yes, the preparation work should happen inside operator()(Self& self) instead of the constructor.

ashtum · 2025-10-09T11:46:07Z

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

+                        , request_
+                        , response_)
+                    , token
+                    , exec);


Instead of taking exec in the argument we can use the ssl_stream_'s executor:

ssl_stream_.get_executor();

In case of asio::async_compose you can just directly pass the io_object itself (ssl_stream_):

return asio::async_compose< CompletionToken, void(system::error_code)>( historic_fetcher_op<Executor>( *this , resolver_ , ssl_stream_ , buffer_ , request_ , response_) , token , ssl_stream_);

this does raise the question of how best to parameterize the template types. should it be typename Executor? typename Stream?

vinniefalco · 2025-10-09T19:52:24Z

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

+            } break;
+            default: {
+                // This should not happen.
+                throw std::logic_error("unreachable");


we have BOOST_UNREACHABLE for this (spelling?)

Just what I was looking for, thanks (as std::unreachable is not available yet).

vinniefalco · 2025-10-09T19:52:53Z

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

+            , asio::ip::tcp::resolver::results_type results)
+        {
+            if (ec) {
+                state_ = state::error;


does this mean anything if we are completing?

Probably not. When I put this in I thought I might have to check the state of the object after io.run finished.

However Mohammad's tag trick is neater than having a state (a full state machine is overkill for this and just makes the code harder to read)

you should check out fauxroutines

vinniefalco · 2025-10-09T19:53:51Z

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp

+            switch (state_) {
+            case state::resolving: {
+                // Set a timeout on the operation
+                beast::get_lowest_layer(ssl_stream_).expires_after(std::chrono::seconds(30));


I believe this depends on the lowest layer being beast::basic_stream or something like that. The stream with the built-in timeout. I would prefer we didn't use that, because it is an overly complex and cumbersome design made obsolete by asio's new "cancelation" features. We don't want to teach it and we should probably deprecate it in beast somehow.

MungoG added 2 commits September 29, 2025 19:15

move code to beast fork

32466cc

work in progress

86e9baf

vinniefalco reviewed Oct 2, 2025

View reviewed changes

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.cpp Outdated Show resolved Hide resolved

vinniefalco reviewed Oct 2, 2025

View reviewed changes

example/websocket/client/crypto-ai-ssl/historic_price_fetcher.hpp Outdated Show resolved Hide resolved

vinniefalco reviewed Oct 2, 2025

View reviewed changes

example/websocket/client/crypto-ai-ssl/json_price_decoder.hpp Outdated Show resolved Hide resolved

vinniefalco reviewed Oct 2, 2025

View reviewed changes

example/websocket/client/crypto-ai-ssl/live_price_listener.cpp Outdated Show resolved Hide resolved

vinniefalco reviewed Oct 2, 2025

View reviewed changes

example/websocket/client/crypto-ai-ssl/live_price_listener.cpp Outdated Show resolved Hide resolved

vinniefalco reviewed Oct 2, 2025

View reviewed changes

example/websocket/client/crypto-ai-ssl/live_price_listener.cpp Outdated Show resolved Hide resolved

vinniefalco reviewed Oct 2, 2025

View reviewed changes

example/websocket/client/crypto-ai-ssl/live_price_listener.hpp Outdated Show resolved Hide resolved

vinniefalco reviewed Oct 2, 2025

View reviewed changes

MungoG added 3 commits October 3, 2025 09:10

fix repo in copyright notice

a303ba6

change beast::error_code to system::error_code and remove write lengt…

09cfd38

…h check

persist subscription json string and remove some dead code

47a0995

MungoG and others added 2 commits October 8, 2025 16:38

historic price fetcher to use composed operations - work in progress

090d9cd

Merge branch 'boostorg:develop' into mungo-new-crypto-ai-example

66220dd

ashtum reviewed Oct 9, 2025

View reviewed changes

vinniefalco reviewed Oct 9, 2025

View reviewed changes

MungoG added 3 commits October 15, 2025 14:57

switch from using a state to tagging

b19a7a1

address git comments re historic price fetcher

c468a52

more github feedback changes

41f4d9f

Uh oh!

New example (crypto and ai) - WORK IN PROGRESS, DO NOT MERGE #3037

Are you sure you want to change the base?

New example (crypto and ai) - WORK IN PROGRESS, DO NOT MERGE #3037

Uh oh!

Conversation

MungoG commented Oct 2, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sdarwin commented Oct 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vinniefalco Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vinniefalco Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

vinniefalco Oct 9, 2025 •

edited

Loading

vinniefalco Oct 9, 2025 •

edited

Loading