boost-asio

My code is as follows: declaration: boost::asio::ssl::stream<boost::asio::ip::tcp::socket> m_remote_socket; m_remote_socket.shutdown(ec); if (ec) { cdbug<<"id: "<<m_id<<", error when ssl shutdown: " <<boost::system::system_category().message(ec.value()).c_str(); } m_remote_socket.lowest_layer().shutdown(boost::asio::ip::tcp::socket::shutdown_both, ec); if (ec) { cdbug<<"id: "<<m_id<<", error when tcp shutdown: "<<boost::system::system_category().message(ec.value()).c_str(); } Each time I call m_remote_socket.shutdown , it will get an error. Such kind of unknown error with a really big error

I am using Boost 1.66.0, in which asio has built-in support for interoperating with futures (and for some time now). The examples I've seen online indicate how to achieve this cleanly when using networking functions such as async_read , async_read_some , etc. That is done by providing boost::asio::use_future in place of the completion handler, which causes the initiating function to return a future as expected. What kind of object do I need to provide or wrap my function in to get the same behavior from boost::asio::post ? My purpose for posting the work is to execute it in the context of a

I am looking for a way to call different functions by a string input. I have a map that ties each unique string to a function pointer and a lookup function to search the map and return a pointer if found. Now the trick is, I need a way to store and return pointers to functions with at least different return types, if possible, also with different signatures. The usage would be: Get a string input from a network socket -> find and execute the found function -> shove the result straight back into the socket to be serialized and sent, not caring what actually happened. Is this doable? If not, how

I will be creating x amount of threads in my server-app. x will be the amount of cores on the machine, and these threads will be (non-hyperthread) core-bound. Naturally with this scheme I would like to distribute incoming connections across the threads with the aim of ensuring that once a connection is assigned to a thread, it will only be served out of that particular thread. How is this achieved in boost::asio ? I am thinking: a single socket bound to an address shared by multiple io_service 's where each threads gets it's own io_service . Is this line of reasoning correct ? edit: looks like

This is a SSCCE from my Boost.Asio project based on the examples. It took me about an hour to track the bug down to this: #include <boost/bind.hpp> #include <boost/asio.hpp> #include <boost/shared_ptr.hpp> class Connection { public: Connection(boost::asio::io_service& io_service) : socket(io_service) {} private: boost::asio::ip::tcp::socket socket; }; class Server { public: Server() : signal_monitor(io_service) { signal_monitor.add(SIGINT); signal_monitor.add(SIGTERM); signal_monitor.async_wait( boost::bind(&Server::handle_signal_caught, this) ); } void run() { // comment out the next line and

I'm developing code that uses boost::asio . To test it, I need to mock a set of classes from this library. I'm using Google Mock, which allows for mocking virtual methods. The usual (and tedious) process would be to write an interface for each of the classes I need to use. On the other hand, the Google Mock Cookbook describes an alternative when it comes to mocking non-virtual methods: using templates. The problem in my case is that I might need to mock several classes at the same time (so using templates directly wouldn't work). So I thought: why not use two-levels of templates? I came up

I've been searching the net for answers but I can't seem to find a complete answer. Scenario: I have a client API and a server. An application uses the client API to talk to the server. Both TCP and UDP are used to communicate between the client API and the server. All of this has been written using ASIO. The client API connects to the server via TCP, then sends commands via TCP and receives responses via TCP. The client API also listens to a UDP address where it receives real-time data continuously. The environment is a mix of machines running WIN32 and WIN64. All of the machines also have 2