You need to create a new boost::asio::ip::tcp::socket each time you reconnect. The easiest way to do this is probably to just allocate the socket on the heap using a boost::shared_ptr (you could probably also get away with scoped_ptr if your socket is entirely encapsulated within a class). E.g.: bool MyClient::myconnect() { bool isConnected = false; … Read more
Think of a system where a single io_service manages sockets for hundreds of network connections. To be able to parallelize workload, the system maintains a pool of worker threads that call io_service::run. Now most of the operations in such a system can just run in parallel. But some will have to be serialized. For example, … Read more
Here’s a trick I learned from python network programming (google) to figure out my machine’s ip address. This only works if you have an internet connection and can connect to google.com and does give me my home machine’s 192.168.x.x private address. try { boost::asio::io_service netService; udp::resolver resolver(netService); udp::resolver::query query(udp::v4(), “google.com”, “”); udp::resolver::iterator endpoints = resolver.resolve(query); … Read more
This is precisely the problem null_buffers was designed for. Sometimes a program must be integrated with a third-party library that wants to perform the I/O operations itself. To facilitate this, Boost.Asio includes a null_buffers type that can be used with both read and write operations. A null_buffers operation doesn’t return until the I/O object is … Read more
This is done in order to make sure that connection object outlives the asynchronous operation: as long as the lambda is alive (i.e. the async. operation is in progress), the connection instance is alive as well.
Is there a simple way to avoid this problem ? Yes, maintain an outgoing queue for each client. Inspect the queue size in the async_write completion handler, if non-zero, start another async_write operation. Here is a sample #include <boost/asio.hpp> #include <boost/bind.hpp> #include <deque> #include <iostream> #include <string> class Connection { public: Connection( boost::asio::io_service& io_service ) … Read more
I believe the two are essentially identical. The reason they provide both is to provide interfaces similar to both iostreams (which have a read_some member) and sockets (which have a receive). As Peter Tseng pointed out, async_receive does also have an overload that accepts socket_base::message_flags, which async_read_some does not.
Change -llibboost_system to -lboost_system. In linux, the “lib” prefix in front of a library is not used when referencing said library.
In short, consistency. The services attempt to meet user expectations set forth by the services Boost.Asio provides. Using an internal io_service provides a clear separation of ownership and control of handlers. If a custom service posts its internal handlers into the user’s io_service, then execution of the service’s internal handlers becomes implicitly coupled with the … Read more
I extracted the error values from asio/error.hpp on Linux (I’m using header only asio not boost::asio by the way), here they are: asio::error::access_denied 13 asio::error::address_family_not_supported 97 asio::error::address_in_use 98 asio::error::already_connected 106 asio::error::already_started 114 asio::error::broken_pipe 32 asio::error::connection_aborted 103 asio::error::connection_refused 111 asio::error::connection_reset 104 asio::error::bad_descriptor 9 asio::error::fault 14 asio::error::host_unreachable 113 asio::error::in_progress 115 asio::error::interrupted 4 asio::error::invalid_argument 22 asio::error::message_size 90 asio::error::name_too_long … Read more