Reacting to each tick events from the websocket

Question

I would like to design my trading system reacting to each tick events from the websocket stream i subscribed to.

So basically i have two options :

void WebsocketClient::on_write(beast::error_code ec,
                               std::size_t bytes_transferred) {
    boost::ignore_unused(bytes_transferred);

    ws_.async_read(buffer_,
                   beast::bind_front_handler(&WebsocketClient::on_message,
                                             shared_from_this()));
}

void WebsocketClient::on_message(beast::error_code ec,
                                 std::size_t bytes_transferred) {

    // signal generation and sending http request to place new orders here
    // first before calling async_read() below

    std::cout << "Received: " << beast::buffers_to_string(buffer_.cdata())
              << std::endl;

    ws_.async_read(buffer_,
                   beast::bind_front_handler(&WebsocketClient::on_message,
                                             shared_from_this()));
}

Or i could

void WebsocketClient::on_message(beast::error_code ec,
                            std::size_t bytes_transferred) {
    ws_.async_read(buffer_,
                   beast::bind_front_handler(&WebsocketClient::on_message,
                                             shared_from_this()));

    // signal generation and sending http request to place new orders here after
    // calling async_read()

    std::cout << "Received: " << beast::buffers_to_string(buffer_.cdata())
              << std::endl;
}

please give me your suggestions and other ideas i could look at! advance thanks!

score 1 · Accepted Answer · answered May 27 '22 at 21:42

1

There would be no tangible difference, unless

// signal generation and sending http request to place new orders here
// first before calling async_read() below

either

takes significant amount of time (design smell on IO threads)
exits the function by return/exception

That's because async_read by definition always returns immediately

answered May 27 '22 at 21:42

sehe

374,641
47
450
633

I mean in the first case if signal generation and placing of new orders is done before async_read then that IO thread is not blocked by that processing stage right ? And in the second case where callling async_read first before processing means completion handler on_message() will call after recieving new event while that processing(signal generation and placing of new orders) stage is still continued on the same IO thread, is that a problem ? @sehe – dopller May 28 '22 at 09:55
1

True. Like I said, it makes a difference if that takes a significant amount of time. What "significant" means depends on your application. If you don't want it on your IO thread, don't do that. – sehe May 28 '22 at 13:05
(sry for the ping again) @sehe just to clarify again, so i have two options here. 1) call async_read() after u have send the orders and all that signal generation stuffs 2) or do signal generations stuffs on other thread and keep IO thread running without any blockage I think the best option here is the first one right ? cuz why would i need to continue running websocket stream if i dont need that data when my bot already got the data it needed for further processing, and when that is done i start again. so the first one is ideal right ? – dopller May 28 '22 at 14:40
1

It depends *only* on your use case. Also there might be a flaw in your reasoning. Unless you reconnect the websocket each read, you might be forgetting that it is stream-oriented. So even if you "don't need that data" you will inevitably read it - because you'll read all the messages sequentially. – sehe May 28 '22 at 14:47
1

It really does sound like separating IO and processing makes more sense for your use-case. But we can't tell, because we have no idea about the volume of traffic coming in, the cost of "work" being done in your comment-lines and the volume/frequency of transactions generated. Even given all that, we don't know what rate limits apply for your server access. All in all, *you* and only *you* can be responsible for chosing the right balance here. – sehe May 28 '22 at 14:49

Reacting to each tick events from the websocket

1 Answers1