boost/asio
2
0
Fork 0
mirror of https://github.com/boostorg/asio.git synced 2026-01-28 06:42:08 +00:00
Code Issues Projects Releases Wiki Activity
Files
d499517905abf5deab322d32e2ba03b8a7e4e829
asio/example/cpp03/tutorial/daytime_dox.txt
Christopher Kohlhoff 603397befb Merge from trunk. 
------------------------------------------------------------------------
r84301 | chris_kohlhoff | 2013-05-17 07:34:54 +1000 (Fri, 17 May 2013) | 2 lines

Enable handler type requirements static_assert on clang.

------------------------------------------------------------------------
r84308 | chris_kohlhoff | 2013-05-17 09:26:04 +1000 (Fri, 17 May 2013) | 3 lines

Add new traits classes, handler_type and async_result, that allow
the customisation of the return type of an initiating function.

------------------------------------------------------------------------
r84311 | chris_kohlhoff | 2013-05-17 11:38:47 +1000 (Fri, 17 May 2013) | 81 lines

Add the asio::spawn() function, a high-level wrapper for running
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);

------------------------------------------------------------------------
r84312 | chris_kohlhoff | 2013-05-17 12:25:10 +1000 (Fri, 17 May 2013) | 4 lines

Move existing examples into a C++03-specific directory, and add a new
directory for C++11-specific examples. A limited subset of the C++03
examples have been converted to their C++11 equivalents.

------------------------------------------------------------------------
r84313 | chris_kohlhoff | 2013-05-17 12:35:08 +1000 (Fri, 17 May 2013) | 26 lines

Add the asio::use_future special value, which adds first-class support
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.

------------------------------------------------------------------------
r84314 | chris_kohlhoff | 2013-05-17 13:07:51 +1000 (Fri, 17 May 2013) | 27 lines

Add a new handler hook called asio_handler_is_continuation.

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.

------------------------------------------------------------------------
r84315 | chris_kohlhoff | 2013-05-17 20:06:50 +1000 (Fri, 17 May 2013) | 3 lines

Partially decouple Asio from other boost components via an extra level
of indirection.

------------------------------------------------------------------------
r84316 | chris_kohlhoff | 2013-05-17 20:15:21 +1000 (Fri, 17 May 2013) | 2 lines

Minor cleanup.

------------------------------------------------------------------------
r84319 | chris_kohlhoff | 2013-05-17 20:52:08 +1000 (Fri, 17 May 2013) | 9 lines

Support handshake with re-use of data already read from the wire.

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.

------------------------------------------------------------------------
r84320 | chris_kohlhoff | 2013-05-17 20:57:02 +1000 (Fri, 17 May 2013) | 6 lines

Support for creation of TLSv1.1 and TLSv1.2 contexts.

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.

------------------------------------------------------------------------
r84322 | chris_kohlhoff | 2013-05-17 21:00:49 +1000 (Fri, 17 May 2013) | 5 lines

Add set_verify_depth function to SSL context and stream.

Thanks go to Nick Jones <nick dot fa dot jones at gmail dot com>, on
whose work this commit is based.

------------------------------------------------------------------------
r84325 | chris_kohlhoff | 2013-05-17 21:04:11 +1000 (Fri, 17 May 2013) | 9 lines

Allow loading of SSL certificate and key data from memory buffers.

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.

------------------------------------------------------------------------
r84345 | chris_kohlhoff | 2013-05-18 21:24:59 +1000 (Sat, 18 May 2013) | 2 lines

Update copyright notices.

------------------------------------------------------------------------
r84346 | chris_kohlhoff | 2013-05-18 21:54:59 +1000 (Sat, 18 May 2013) | 3 lines

Remove the stackless coroutine class and macros from the HTTP server 4
example, and instead make them a part of Asio's documented interface.

------------------------------------------------------------------------
r84347 | chris_kohlhoff | 2013-05-18 22:01:59 +1000 (Sat, 18 May 2013) | 4 lines

Fix basic_waitable_timer's underlying implementation so that it can
handle any time_point value without overflowing the intermediate
duration objects.

------------------------------------------------------------------------
r84348 | chris_kohlhoff | 2013-05-18 22:07:00 +1000 (Sat, 18 May 2013) | 3 lines

Fix a problem with lost thread wakeups that can occur when making
concurrent calls to run() and poll() on the same io_service object.

------------------------------------------------------------------------
r84349 | chris_kohlhoff | 2013-05-18 22:13:17 +1000 (Sat, 18 May 2013) | 3 lines

Fix implementation of asynchronous connect operation so that it can cope
with spurious readiness notifications from the reactor.

------------------------------------------------------------------------
r84361 | chris_kohlhoff | 2013-05-19 07:56:31 +1000 (Sun, 19 May 2013) | 1 line

Remove some trailing spaces and fix another copyright notice.

------------------------------------------------------------------------
r84363 | chris_kohlhoff | 2013-05-19 14:55:11 +1000 (Sun, 19 May 2013) | 53 lines

Add generic socket protocols and converting move constructors.

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 r84388]
2013-05-20 12:32:20 +00:00

503 lines
13 KiB
Plaintext
Raw Blame History

//
// Copyright (c) 2003-2013 Christopher M. Kohlhoff (chris at kohlhoff dot com)
//
// Distributed under the Boost Software License, Version 1.0. (See accompanying
// file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//
/**
\page tutdaytime1 Daytime.1 - A synchronous TCP daytime client
This tutorial program shows how to use asio to implement a client application
with TCP.
\dontinclude daytime1/client.cpp
\skip #include
We start by including the necessary header files.
\until asio.hpp
The purpose of this application is to access a daytime service,
so we need the user to specify the server.
\until }
All programs that use asio need to have at least one boost::asio::io_service
object.
\until boost::asio::io_service
We need to turn the server name that was specified as a parameter to the
application, into a TCP endpoint. To do this we use an
boost::asio::ip::tcp::resolver object.
\until tcp::resolver
A resolver takes a query object and turns it into a list of endpoints. We
construct a query using the name of the server, specified in <tt>argv[1]</tt>,
and the name of the service, in this case <tt>"daytime"</tt>.
\until tcp::resolver::query
The list of endpoints is returned using an iterator of type
boost::asio::ip::tcp::resolver::iterator. (Note that a default constructed
boost::asio::ip::tcp::resolver::iterator object can be used as an end iterator.)
\until tcp::resolver::iterator
Now we create and connect the socket. The list of endpoints obtained above may
contain both IPv4 and IPv6 endpoints, so we need to try each of them until we
find one that works. This keeps the client program independent of a specific IP
version. The boost::asio::connect() function does this for us automatically.
\until boost::asio::connect
The connection is open. All we need to do now is read the response from the
daytime service.
We use a <tt>boost::array</tt> to hold the received data. The boost::asio::buffer()
function automatically determines the size of the array to help prevent buffer
overruns. Instead of a <tt>boost::array</tt>, we could have used a <tt>char
[]</tt> or <tt>std::vector</tt>.
\until read_some
When the server closes the connection, the boost::asio::ip::tcp::socket::read_some()
function will exit with the boost::asio::error::eof error, which is how we know to
exit the loop.
\until }
Finally, handle any exceptions that may have been thrown.
\until }
\until }
See the \ref tutdaytime1src "full source listing" \n
Return to the \ref index "tutorial index" \n
Next: \ref tutdaytime2
*/
/**
\page tutdaytime1src Source listing for Daytime.1
\include daytime1/client.cpp
Return to \ref tutdaytime1
*/
/**
\page tutdaytime2 Daytime.2 - A synchronous TCP daytime server
This tutorial program shows how to use asio to implement a server application
with TCP.
\dontinclude daytime2/server.cpp
\skip #include
\until using
We define the function <tt>make_daytime_string()</tt> to create the string to
be sent back to the client. This function will be reused in all of our daytime
server applications.
\until boost::asio::io_service
A boost::asio::ip::tcp::acceptor object needs to be created to listen
for new connections. It is initialised to listen on TCP port 13, for IP version 4.
\until tcp::acceptor
This is an iterative server, which means that it will handle one
connection at a time. Create a socket that will represent the connection to the
client, and then wait for a connection.
\until acceptor.accept
A client is accessing our service. Determine the current time
and transfer this information to the client.
\until }
\until }
Finally, handle any exceptions.
\until }
\until }
See the \ref tutdaytime2src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tutdaytime1 \n
Next: \ref tutdaytime3
*/
/**
\page tutdaytime2src Source listing for Daytime.2
\include daytime2/server.cpp
Return to \ref tutdaytime2
*/
/**
\page tutdaytime3 Daytime.3 - An asynchronous TCP daytime server
\section tutdaytime3funcmain The main() function
\dontinclude daytime3/server.cpp
\skip int main()
\until try
\until {
We need to create a server object to accept incoming client connections. The
boost::asio::io_service object provides I/O services, such as sockets, that the
server object will use.
\until tcp_server
Run the boost::asio::io_service object so that it will perform asynchronous operations
on your behalf.
\until return 0;
\until }
\section tutdaytime3classtcp_server The tcp_server class
\dontinclude daytime3/server.cpp
\skip class tcp_server
\until public:
The constructor initialises an acceptor to listen on TCP port 13.
\until private:
The function <tt>start_accept()</tt> creates a socket and initiates an
asynchronous accept operation to wait for a new connection.
\until }
The function <tt>handle_accept()</tt> is called when the asynchronous accept
operation initiated by <tt>start_accept()</tt> finishes. It services the client
request, and then calls <tt>start_accept()</tt> to initiate the next accept
operation.
\until }
\until }
\section tutdaytime3classtcp_connection The tcp_connection class
We will use <tt>shared_ptr</tt> and <tt>enable_shared_from_this</tt> because we
want to keep the <tt>tcp_connection</tt> object alive as long as there is an
operation that refers to it.
\dontinclude daytime3/server.cpp
\skip class tcp_connection
\until shared_ptr
\until }
\until }
In the function <tt>start()</tt>, we call boost::asio::async_write() to serve the data
to the client. Note that we are using boost::asio::async_write(), rather than
boost::asio::ip::tcp::socket::async_write_some(), to ensure that the entire block of
data is sent.
\until {
The data to be sent is stored in the class member <tt>message_</tt> as we need
to keep the data valid until the asynchronous operation is complete.
\until message_
When initiating the asynchronous operation, and if using boost::bind(), you
must specify only the arguments that match the handler's parameter list. In
this program, both of the argument placeholders (boost::asio::placeholders::error and
boost::asio::placeholders::bytes_transferred) could potentially have been removed,
since they are not being used in <tt>handle_write()</tt>.
\until placeholders::bytes_transferred
Any further actions for this client connection are now the responsibility of
<tt>handle_write()</tt>.
\until };
\section tutdaytime3remunused Removing unused handler parameters
You may have noticed that the <tt>error</tt>, and <tt>bytes_transferred</tt>
parameters are not used in the body of the <tt>handle_write()</tt> function. If
parameters are not needed, it is possible to remove them from the function so
that it looks like:
\code
void handle_write()
{
}
\endcode
The boost::asio::async_write() call used to initiate the call can then be changed to
just:
\code
boost::asio::async_write(socket_, boost::asio::buffer(message_),
boost::bind(&tcp_connection::handle_write, shared_from_this()));
\endcode
See the \ref tutdaytime3src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tutdaytime2 \n
Next: \ref tutdaytime4
*/
/**
\page tutdaytime3src Source listing for Daytime.3
\include daytime3/server.cpp
Return to \ref tutdaytime3
*/
/**
\page tutdaytime4 Daytime.4 - A synchronous UDP daytime client
This tutorial program shows how to use asio to implement a client application
with UDP.
\dontinclude daytime4/client.cpp
\skip #include
\until using boost::asio::ip::udp;
The start of the application is essentially the same as for the TCP daytime
client.
\until boost::asio::io_service
We use an boost::asio::ip::udp::resolver object to find the correct remote endpoint to
use based on the host and service names. The query is restricted to return only
IPv4 endpoints by the boost::asio::ip::udp::v4() argument.
\until udp::v4
The boost::asio::ip::udp::resolver::resolve() function is guaranteed to return at
least one endpoint in the list if it does not fail. This means it is safe to
dereference the return value directly.
\until udp::endpoint
Since UDP is datagram-oriented, we will not be using a stream socket. Create an
boost::asio::ip::udp::socket and initiate contact with the remote endpoint.
\until receiver_endpoint
Now we need to be ready to accept whatever the server sends back to us. The
endpoint on our side that receives the server's response will be initialised by
boost::asio::ip::udp::socket::receive_from().
\until }
Finally, handle any exceptions that may have been thrown.
\until }
\until }
See the \ref tutdaytime4src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tutdaytime3 \n
Next: \ref tutdaytime5
*/
/**
\page tutdaytime4src Source listing for Daytime.4
\include daytime4/client.cpp
Return to \ref tutdaytime4
*/
/**
\page tutdaytime5 Daytime.5 - A synchronous UDP daytime server
This tutorial program shows how to use asio to implement a server application
with UDP.
\dontinclude daytime5/server.cpp
\skip int main()
\until boost::asio::io_service
Create an boost::asio::ip::udp::socket object to receive requests on UDP port 13.
\until udp::socket
Wait for a client to initiate contact with us. The remote_endpoint object will
be populated by boost::asio::ip::udp::socket::receive_from().
\until throw
Determine what we are going to send back to the client.
\until std::string message
Send the response to the remote_endpoint.
\until }
\until }
Finally, handle any exceptions.
\until }
\until }
See the \ref tutdaytime5src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tutdaytime4 \n
Next: \ref tutdaytime6
*/
/**
\page tutdaytime5src Source listing for Daytime.5
\include daytime5/server.cpp
Return to \ref tutdaytime5
*/
/**
\page tutdaytime6 Daytime.6 - An asynchronous UDP daytime server
\section tutdaytime6funcmain The main() function
\dontinclude daytime6/server.cpp
\skip int main()
\until try
\until {
Create a server object to accept incoming client requests, and run
the boost::asio::io_service object.
\until return 0;
\until }
\section tutdaytime6classudp_server The udp_server class
\dontinclude daytime6/server.cpp
\skip class udp_server
\until public:
The constructor initialises a socket to listen on UDP port 13.
\until private:
\until {
The function boost::asio::ip::udp::socket::async_receive_from() will cause the
application to listen in the background for a new request. When such a request
is received, the boost::asio::io_service object will invoke the
<tt>handle_receive()</tt> function with two arguments: a value of type
boost::system::error_code indicating whether the operation succeeded or failed, and a
<tt>size_t</tt> value <tt>bytes_transferred</tt> specifying the number of bytes
received.
\until }
The function <tt>handle_receive()</tt> will service the client request.
\until {
The <tt>error</tt> parameter contains the result of the asynchronous operation.
Since we only provide the 1-byte <tt>recv_buffer_</tt> to contain the client's
request, the boost::asio::io_service object would return an error if the client sent
anything larger. We can ignore such an error if it comes up.
\until {
Determine what we are going to send.
\until make_daytime_string()
We now call boost::asio::ip::udp::socket::async_send_to() to serve the data to the
client.
\until boost::asio::placeholders::bytes_transferred
When initiating the asynchronous operation, and if using boost::bind(), you
must specify only the arguments that match the handler's parameter list. In
this program, both of the argument placeholders (boost::asio::placeholders::error and
boost::asio::placeholders::bytes_transferred) could potentially have been removed.
Start listening for the next client request.
\until start_receive
Any further actions for this client request are now the responsibility of
<tt>handle_send()</tt>.
\until }
\until }
The function <tt>handle_send()</tt> is invoked after the service request has
been completed.
\until }
\until }
See the \ref tutdaytime6src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tutdaytime5 \n
Next: \ref tutdaytime7
*/
/**
\page tutdaytime6src Source listing for Daytime.6
\include daytime6/server.cpp
Return to \ref tutdaytime6
*/
/**
\page tutdaytime7 Daytime.7 - A combined TCP/UDP asynchronous server
This tutorial program shows how to combine the two asynchronous servers that we
have just written, into a single server application.
\section tutdaytime7funcmain The main() function
\dontinclude daytime7/server.cpp
\skip int main()
\until boost::asio::io_service
We will begin by creating a server object to accept a TCP client connection.
\until tcp_server
We also need a server object to accept a UDP client request.
\until udp_server
We have created two lots of work for the boost::asio::io_service object to do.
\until return 0;
\until }
\section tutdaytime7classtcp The tcp_connection and tcp_server classes
The following two classes are taken from \ref tutdaytime3 "Daytime.3".
\dontinclude daytime7/server.cpp
\skip class tcp_connection
\until };
\until };
\section tutdaytime7classudp The udp_server class
Similarly, this next class is taken from the
\ref tutdaytime6 "previous tutorial step".
\dontinclude daytime7/server.cpp
\skip class udp_server
\until };
See the \ref tutdaytime7src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tutdaytime6
*/
/**
\page tutdaytime7src Source listing for Daytime.7
\include daytime7/server.cpp
Return to \ref tutdaytime7
*/
Reference in New Issue View Git Blame Copy Permalink