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]
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]
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]
* Improve backward compatibility of the new SSL implementation.
* Add wrapper for SSL_CTX_set_default_verify_paths().
* Document which OpenSSL functions the ssl::context member functions use.
* Add SSL certificate verification callbacks, and add a new
ssl::rfc2818_verification function object for simple peer certificate
verification based on the host name.
* Use std::atomic<> when available.
* Prefer to use std::array when it is available.
* Use std::shared_ptr and std::weak_ptr when available.
* Use a lightweight scoped smart pointer.
* Fix some shadow variable warnings with g++ 4.6.
[SVN r70384]
* Added support for C++0x move construction and assignment to sockets, serial
ports, POSIX descriptors and Windows handles.
* Regenerate documentation.
[SVN r70092]
