The epoll_reactor now supports the use of regular file descriptors with
posix::stream_descriptor, provided the I/O operations on them never fail
with EAGAIN or EWOULDBLOCK. If the descriptor cannot be added to the
epoll set using epoll_ctl, and errno is EPERM (indicating an unsupported
descriptor type), then no error condition is raised. Instead, any
operation which would require a trip through the reactor will fail.
This adds new enums context_base::tls, context_base::tls_client and
context_base::tls_server. These allow connections to use any supported
TLS version. (N.B. the deprecated version SSLv3 is explicitly disabled
if you use these values.)
Some application code using asio::ssl::stream<> explicitly tests for the
SSL_R_SHORT_READ error. For compatibility, when using older versions of
OpenSSL we will define the ssl::error::stream_truncated to use this
value.
The getaddrinfo function is now used by default unless Mac OS X 10.4 or
earlier is detected. Its use may also be explicitly disabled by defining
ASIO_DISABLE_GETADDRINFO.
- SSLv2 has been completely removed from OpenSSL, even without OPENSSL_NO_SSL2
- there is a new threading API without locking callbacks
- struct SSL_CTX has been made opaque and must be used via accessor functions
- some cleanup functions have been removed
(from Marcel Raad <raad@teamviewer.com>)
This error replaces uses of SSL_R_SHORT_READ, and indicates that the
SSL stream has been shut down abruptly. (I.e. the underlying socket
has been closed without performing an SSL-layer shutdown.)
This fixes support for read-only file descriptors, such as those
obtained from libpcap by calling pcap_get_selectable_fd.
Fixes boost trac ticket #10367.
Reverted the previous change to ignore ERROR_MORE_DATA. Instead,
the error will propagated as with any other (i.e. in an error_code
or thrown as a system_error). For code that needs to handle partial
messages, the error_code overload should be used.
Fixes boost trac ticket #10034.
This change fixes a potential race condition when using run_one() from
multiple threads. It also paves the way for the future addition of
timed io_service::run() overloads.
Repeated re-registration of kqueue event filters seems to behave as
though there is some kind of "leak" on MacOS, culminating in a suspended
close() system call and an unkillable process. To avoid this, we will
register a descriptor's kqueue event filters once only i.e. when the
descriptor is first created.
We must take care not to hold a shared_ptr to the coroutine across
its own suspension point, otherwise it will not be unwound by the
io_service destructor. Move-enabled C++11 compilers take care of this
automatically, but with C++03 we must explicitly reset the shared_ptr.
Fixes boost trac ticket #9731.
This change adds limited support for using Asio with the Windows
Runtime. It requires that the language extensions be enabled. Due to the
restricted facilities exposed by the Windows Runtime API, the port comes
with the following caveats:
* The core facilities such as the io_service, strand, buffers, composed
operations, timers, etc., should all work as normal.
* For sockets, only client-side TCP is supported.
* Explicit binding of a client-side TCP socket is not supported.
* The cancel() function is not supported for sockets. Asynchronous
operations may only be cancelled by closing the socket.
* Operations that use null_buffers are not supported.
* Only tcp::no_delay and socket_base::keep_alive options are supported.
* Resolvers do not support service names, only numbers. I.e. you must
use 80 rather than http.
* Most resolver query flags have no effect.
[SVN r85764]
To mitigate the risk of certain attacks, SSL compression is now disabled
by default. To enable, you can use the new ssl::context::clear_options()
function like so:
my_context.clear_options(asio::ssl::context::no_compression);
[SVN r84486]
Four new protocol classes have been added:
- asio::generic::datagram_protocol
- asio::generic::raw_protocol
- asio::generic::seq_packet_protocol
- asio::generic::stream_protocol
These classes implement the Protocol type requirements, but allow the
user to specify the address family (e.g. AF_INET) and protocol type
(e.g. IPPROTO_TCP) at runtime.
A new endpoint class template, asio::generic::basic_endpoint, has been
added to support these new protocol classes. This endpoint can hold any
other endpoint type, provided its native representation fits into a
sockaddr_storage object.
When using C++11, it is now possible to perform move construction from a
socket (or acceptor) object to convert to the more generic protocol's
socket (or acceptor) type. If the protocol conversion is valid:
Protocol1 p1 = ...;
Protocol2 p2(p1);
then the corresponding socket conversion is allowed:
Protocol1::socket socket1(io_service);
...
Protocol2::socket socket2(std::move(socket1));
For example, one possible conversion is from a TCP socket to a generic
stream-oriented socket:
asio::ip::tcp::socket socket1(io_service);
...
asio::generic::stream_protocol::socket socket2(std::move(socket1));
The conversion is also available for move-assignment. Note that these
conversions are not limited to the newly added generic protocol classes.
User-defined protocols may take advantage of this feature by similarly
ensuring the conversion from Protocol1 to Protocol2 is valid, as above.
As a convenience, the socket acceptor's accept() and async_accept()
functions have been changed so that they can directly accept into a
different protocol's socket type, provided the protocol conversion is
valid. For example, the following is now possible:
asio::ip::tcp::acceptor acceptor(io_service);
...
asio::generic::stream_protocol::socket socket1(io_service);
acceptor.accept(socket1);
[SVN r84363]
Added new buffer-based interfaces:
add_certificate_authority, use_certificate, use_certificate_chain,
use_private_key, use_rsa_private_key, use_tmp_dh.
Thanks go to Nick Jones <nick dot fa dot jones at gmail dot com>, on
whose work this commit is based.
[SVN r84325]
Thanks go to Alvin Cheung <alvin dot cheung at alumni dot ust dot hk>
and Nick Jones <nick dot fa dot jones at gmail dot com>, on whose work
this is based.
[SVN r84320]
Add new overloads of the SSL stream's handshake() and async_handshake()
functions, that accepts a ConstBufferSequence to be used as initial
input to the ssl engine for the handshake procedure.
Thanks go to Nick Jones <nick dot fa dot jones at gmail dot com>, on
whose work this commit is partially based.
[SVN r84319]
Asynchronous operations may represent a continuation of the asynchronous
control flow associated with the current handler. Asio's implementation
can use this knowledge to optimise scheduling of the handler.
The asio_handler_is_continuation hook returns true to indicate whether a
completion handler represents a continuation of the current call
context. The default implementation of the hook returns false, and
applications may customise the hook when necessary. The hook has already
been customised within Asio to return true for the following cases:
- Handlers returned by strand.wrap(), when the corresponding
asynchronous operation is being initiated from within the strand.
- The internal handlers used to implement the asio::spawn() function's
stackful coroutines.
- When an intermediate handler of a composed operation (e.g.
asio::async_read(), asio::async_write(), asio::async_connect(),
ssl::stream<>, etc.) starts a new asynchronous operation due to the
composed operation not being complete.
To support this optimisation, a new running_in_this_thread() member
function has been added to the io_service::strand class. This function
returns true when called from within a strand.
[SVN r84314]
for returning a C++11 std::future from an asynchronous operation's
initiating function.
To use asio::use_future, pass it to an asynchronous operation instead of
a normal completion handler. For example:
std::future<std::size_t> length =
my_socket.async_read_some(my_buffer, asio::use_future);
Where a completion handler signature has the form:
void handler(error_code ec, result_type result);
the initiating function returns a std::future templated on result_type.
In the above example, this is std::size_t. If the asynchronous operation
fails, the error_code is converted into a system_error exception and
passed back to the caller through the future.
Where a completion handler signature has the form:
void handler(error_code ec);
the initiating function returns std::future<void>. As above, an error
is passed back in the future as a system_error exception.
[SVN r84313]
stackful coroutines. It is based on the Boost.Coroutine library.
Here is an example of its use:
asio::spawn(my_strand, do_echo);
// ...
void do_echo(asio::yield_context yield)
{
try
{
char data[128];
for (;;)
{
std::size_t length =
my_socket.async_read_some(
asio::buffer(data), yield);
asio::async_write(my_socket,
asio::buffer(data, length), yield);
}
}
catch (std::exception& e)
{
// ...
}
}
The first argument to asio::spawn() may be a strand, io_service or
completion handler. This argument determines the context in which the
coroutine is permitted to execute. For example, a server's per-client
object may consist of multiple coroutines; they should all run on the
same strand so that no explicit synchronisation is required.
The second argument is a function object with signature (**):
void coroutine(asio::yield_context yield);
that specifies the code to be run as part of the coroutine. The
parameter yield may be passed to an asynchronous operation in place of
the completion handler, as in:
std::size_t length =
my_socket.async_read_some(
asio::buffer(data), yield);
This starts the asynchronous operation and suspends the coroutine. The
coroutine will be resumed automatically when the asynchronous operation
completes.
Where a completion handler signature has the form:
void handler(error_code ec, result_type result);
the initiating function returns the result_type. In the async_read_some
example above, this is std::size_t. If the asynchronous operation fails,
the error_code is converted into a system_error exception and thrown.
Where a completion handler signature has the form:
void handler(error_code ec);
the initiating function returns void. As above, an error is passed back
to the coroutine as a system_error exception.
To collect the error_code from an operation, rather than have it throw
an exception, associate the output variable with the yield_context as
follows:
error_code ec;
std::size_t length =
my_socket.async_read_some(
asio::buffer(data), yield[ec]);
**Note: if asio::spawn() is used with a custom completion handler of
type Handler, the function object signature is actually:
void coroutine(asio::basic_yield_context<Handler> yield);
[SVN r84311]
incomplete and broke out-of-band handling. Fixed epoll_reactor::start_op so
that it is now exactly the same as the older, working version.
[SVN r78664]
BOOST_ASIO_STRAND_IMPLEMENTATIONS to the number.
Programs can now define BOOST_ASIO_ENABLE_SEQUENTIAL_STRAND_ALLOCATION to
switch the allocation of strand implementations to use a round-robin approach
rather than hashing.
Fix potential strand starvation issue that can occur when strand.post() is used.
[SVN r74955]
* Split the task_io_service's run and poll code.
* Use thread-local operation queues in single-threaded use cases (i.e. concurrency_hint is 1) to eliminate a lock/unlock pair.
* Only fence block exit when a handler is being run directly out of the io_service.
* Prefer x86 mfence-based fenced block when available.
* Use a plain ol' long for the atomic_count when all thread support is disabled.
* Allow some epoll_reactor speculative operations to be performed without holding the lock.
* Improve locality of reference by performing an epoll_reactor's I/O operation immediately before the corresponding handler is called. This also improves scalability across CPUs when multiple threads are running the io_service.
* Pass same error_code variable through to each operation's complete() function.
* Optimise creation of and access to the io_service implementation.
[SVN r74826]
