免费无码国产欧美久久18,精品久久久无码人妻中文字幕,久久精品国产亚洲av麻豆蜜芽

[转] C++扫盲�p�d��--�W�一个服务器�E�序

ngaut — Sun, 06 Sep 2009 03:26:00 GMT

摘要: 来自�Q�http://blog.csdn.net/NewNebuladream/archive/2009/08/12/4437888.aspx C++扫盲�p�d��--�W�一个服务器�E�序收藏关于需�?nbsp; �q�行�E�序开发，对于需求的把握是至关重要的。可以说�Q�我之前没有��M��开发服... 阅读全文

ngaut 2009-09-06 11:26 发表评论

asio工程向boost.asio转换注意事项

ngaut — Tue, 21 Oct 2008 03:50:00 GMT

What are the differences in the source code?

�?Asio is in a namespace called asio::, whereas Boost.Asio puts everything under boost::asio::.

�?The main Asio header file is called asio.hpp. The corresponding header in Boost.Asio is boost/asio.hpp. All other headers are similarly changed.

�?Any macros used by or defined in Asio are prefixed with ASIO_. In Boost.Asio they are prefixed with BOOST_ASIO_.

�?Asio includes a class for launching threads, asio::thread. Boost.Asio does not include this class, to avoid overlap with the Boost.Thread library

�?Boost.Asio uses the Boost.System library to provide support for error codes (boost::system::error_code and boost::system::system_error). Asio includes these under its own namespace (asio::error_code and asio::system_error). The Boost.System version of these classes currently supports better extensibility for user-defined error codes. 需要包�?lt;boost/system/system_error.hpp> 头文�?/p>

�?Asio is header-file-only and for most uses does not require linking against any Boost library. Boost.Asio always requires that you link against the Boost.System library, and also against Boost.Thread if you want to launch threads using boost::thread.需要包�?lt;boost/thread.hpp>

ngaut 2008-10-21 11:50 发表评论

asio�l�于随boost一起发布了

ngaut — Tue, 01 Apr 2008 10:46:00 GMT

摘要: 阅读全文

ngaut 2008-04-01 18:46 发表评论

asio:如何正确关闭socket

ngaut — Fri, 22 Feb 2008 11:31:00 GMT

> Also now I am confused and it will be helpful to know in asio sockets:
> 1. In what situation we need to use both
> "basic_stream_socket::shutdown()" & "basic_stream_socket::close()"
> functions?

If you want graceful closure of the socket, and you want it to work
consistently on Windows, use shutdown() before close(). There are
circumstances where just calling close() can result in the Windows TCP
stack sending a RST to the peer, which means possible data loss (i.e.
anything but a graceful closure).

> 2. In what situation we need to use just "basic_stream_socket::close()"
> function?

When you just want to close the connection as soon as possible and don't
care about possible loss of data under Windows.

ngaut 2008-02-22 19:31 发表评论

使用asio需要注意的两个问题

ngaut — Thu, 14 Feb 2008 13:52:00 GMT

Message: 2
Date: Wed, 6 Feb 2008 23:43:09 -0000
From: "Roger Austin"
Subject: Re: [asio-users] asio::async_write & WriteHander
To:
Message-ID:
<0CEE50132F7DB142AA8632D6FB1BE982E7E462@bob.internal.wallingfordsoftware.co.uk>

Content-Type: text/plain; charset="us-ascii"

If there is ever an asio FAQ, the correct use of async_write will be at
the top of the list

Cliff is correct in what he says but the key clause is "when the first
async_write completes". If you start your second async_write before the
first has completed, you risk interleaving the data. Thus if you want to
write code like:

DoAsyncWrite("Message 1");

DoAsyncWrite("Message 2");

Then your implementation of DoAsyncWrite (which will call async_write
internally) must check if there is already an async_write pending and,
if so, put the message somewhere (i.e. in a queue), ready to be sent
when the pending async_write has completed. The asio chat example does
this.

This is not a limitation of asio as such. The underlying socket
functions (send or equivalent) make no guarantee that the entire message
can be transferred to the TCP stream in a single asynchronous operation
- the write handler will be told how many bytes were actually
transferred and the application is responsible for issuing a new call to
send the remaining bytes. The asio async_write function does this for
you via one or more calls to async_write_some, but in doing so it tends
to hide the fact that the second and later calls to async_write_some
(needed to complete sending the first message) may happen later in the
thread than the first call to async_write_some for the second message.

From: asio-users-bounces@lists.sourceforge.net
[mailto:asio-users-bounces@lists.sourceforge.net] On Behalf Of X Wang
Sent: Thursday, 7 February 2008 9:37 AM
To: asio-users@lists.sourceforge.net
Subject: Re: [asio-users] asio::async_write & WriteHander

"Green, Cliff" wrote:

> Sender sends out 2 messages back to back (on the same end-to-end
socket
> connection), message 1 is 10 MB, message 2 is 10 bytes, with no
receiver
> ACK in between.

Assuming the two messages are generated in order (e.g. in a single
thread), there is not an issue - one async_write of 10 MB, followed by
an async_write of 10 bytes (when the first async_write completes). Since
the actual "buffer" passed to Asio async_write does not copy the 10 MB /
10 b, you will need to manage the lifetime of the two original message
buffers. If the "message generation" is completely independent of the
thread invoking the async_writes, you need to manage the coordination
(this could be a queue, as previously mentioned, or some other form of
coordination).

You will be guaranteed that the data gets to the receiver in the same
order - 10 MB followed by 10 b (however, the receiver will need to take
responsibility for the message delimiter handling).

Am I missing something?

(Asio experts, please correct any of my mistakes on the Asio aspects.)

Much of this explanation is not dependent on async concepts and designs
- it would need to be similar whether your app is blocking, non-blocking
(polling), non-blocking (reactive), multi-threaded, etc.

Cliff

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
asio-users mailing list
asio-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users

Yeah, you are right. What I said about TCP did not make much sense...
need some coffee :)

ngaut 2008-02-14 21:52 发表评论

ngaut — Fri, 28 Dec 2007 12:43:00 GMT

Wednesday, August 08, 2007

Time Travel

Many event-driven programs involve state changes that are triggered according to the system clock. You might be coding for:

A share market that opens at 10:00am and closes at 4:00pm.
An off-peak phone billing rate that starts after 7:00pm.
An interest calculation that is run on the last day of every month.

The asio::deadline_timer class lets you handle this easily. For example:

using namespace boost::posix_time;
typedef boost::date_time::c_local_adjustor local_adj;

...

asio::deadline_timer timer(io_service);

ptime open_time(second_clock::local_time().date(), hours(10));
timer.expires_at(local_adj::local_to_utc(open_time));
timer.async_wait(open_market);

There's a catch: to test that your timer events work correctly, you have to run your program at the right time of day. It usually isn't practical to sit around all day (or, worse, all year) waiting for the timers to expire.

Time Traits

You may have noticed that the asio::deadline_timer class is actually a typedef:

typedef basic_deadline_timer
  deadline_timer;

where the basic_deadline_timer class template is declared as follows:

template <
    typename Time,
    typename TimeTraits
      = asio::time_traits,
    typename TimerService
      = deadline_timer_service >
class basic_deadline_timer;

In the context of our problem, the most interesting template parameter is the second one: TimeTraits. An implementation of TimeTraits lets us customise the treatment of the template's Time parameter, and consequently the behaviour of the timer itself.

A TimeTraits class must implement an interface that matches the following:

class TimeTraits
{
public:
  // The type used to represent an absolute time, i.e. the same
  // as the Time template parameter to basic_deadline_timer.
  typedef ... time_type;

  // The type used to represent the difference between two
  // absolute times.
  typedef ... duration_type;

  // Returns the current time.
  static time_type now();

  // Returns a new absolute time resulting from adding the
  // duration d to the absolute time t.
  static time_type add(time_type t, duration_type d);

  // Returns the duration resulting from subtracting t2 from t1.
  static duration_type subtract(time_type t1, time_type t2);

  // Returns whether t1 is to be treated as less than t2.
  static bool less_than(time_type t1, time_type t2);

  // Returns a "posix" duration corresponding to the duration d.
  static boost::posix_time::time_duration to_posix_duration(
      duration_type d);
};

As you can see from the declaration of the basic_deadline_timer class template, Asio provides a default TimeTraits implementation called asio::time_traits<>.

Offsetting Now

To test our timer events at any time of our choosing, we simply need to change the definition of "now" using a custom TimeTraits class.

Since we want to use the same time types as the regular deadline_timer class, we'll start by reusing the default traits implementation:

class offset_time_traits
  : public asio::deadline_timer::traits_type
{
};

The value returned by the now() function will be offset from the system clock by a specified duration:

class offset_time_traits
  : public asio::deadline_timer::traits_type
{

private:
  static duration_type offset_;
};

which is simply added to the system clock:

class offset_time_traits
  : public asio::deadline_timer::traits_type
{
public:
  static time_type now()
  {
    return add(asio::deadline_timer::traits_type::now(), offset_);
  }

private:
  static duration_type offset_;
};

Of course, we will also need to provide a way to set the offset, which can be done by setting an initial value for "now":

class offset_time_traits
  : public asio::deadline_timer::traits_type
{
public:
  static time_type now()
  {
    return add(asio::deadline_timer::traits_type::now(), offset_);
  }

  static void set_now(time_type t)
  {
    offset_ =
      subtract(t, asio::deadline_timer::traits_type::now());
  }

private:
  static duration_type offset_;
};

Creating a Timer

To use our custom traits type with the basic_deadline_timer template, we simply need to add the following typedef:

typedef asio::basic_deadline_timer<
    boost::posix_time::ptime, offset_time_traits> offset_timer;

To see the offset timer in action, let's create a timer to fire precisely at the start of the coming new year. So we don't have to wait until then, we'll set "now" to be just ten seconds prior to midnight:

offset_time_traits::set_now(
    boost::posix_time::from_iso_string("20071231T235950"));

offset_timer timer(io_service);
timer.expires_at(
    boost::posix_time::from_iso_string("20080101T000000"));
timer.async_wait(handle_timeout);

io_service.run();

When the program is run, it will take just ten seconds to complete.

Jumping Through Time

One feature not supported by the above solution is the ability to change the definition of "now" after the timers have been started. However, if your timer events are spread across a long period of time, then this is likely to be something you would want.

Let's say that the next timer does not expire for several hours, but in an attempt to speed things up we call set_now() to move to just seconds before. The problem with the above traits class is that the existing asynchronous wait operation does not know about the change to "now", and so will continue to run for the remaining hours.

Fortunately, Asio provides a way around this: by customising the to_posix_duration() function in our traits class.

The to_posix_duration() function is normally used to convert from a user-defined duration type to a type that Asio knows about (namely boost::posix_time::time_duration). The key point here is that this converted duration value is used by Asio to determine how long to wait until the timer expires. Furthermore, it doesn't matter if this function returns a duration that is smaller (even substantially so) than the actual duration. The timer won't fire early, because Asio guarantees that it won't expire until the following condition holds true:

!TimeTraits::less_than(Time_Traits::now(), timer.expires_at())

So, by adding the to_posix_duration() function to our traits class:

class offset_time_traits
  : public asio::deadline_timer::traits_type
{
public:
  static time_type now()
  {
    return add(asio::deadline_timer::traits_type::now(), offset_);
  }

  static void set_now(time_type t)
  {
    offset_ =
      subtract(t, asio::deadline_timer::traits_type::now());
  }

  static boost::posix_time::time_duration to_posix_duration(
      duration_type d)
  {
    return d < boost::posix_time::seconds(5)
      ? d : boost::posix_time::seconds(5);
  }

private:
  static duration_type offset_;
};

we can ensure that Asio detects changes to the offset within seconds.

Thursday, April 26, 2007

New home heating solution

For quite some time I have wanted to take a really good look at improving Boost.Asio's scalability across multiple processors. Unfortunately, getting unlimited access to this sort of hardware has been somewhat problematic. What I really needed was a decent multiprocessor box at home :)

The arrival of Intel's Clovertown quad core CPUs gave me the opportunity. The primary goal was to maximise parallelism while minimising the cost, and the lowest spec quad cores were cheap enough for me to justify spending the money. So, after months of thinking (and weeks of waiting for parts), last week I finally completed my home-built server.

Here are the headline specs:

Two Intel Xeon E5310 quad core processors (1.6 GHz)
Tyan Tempest i5000XL motherboard
2GB DDR2-667 fully buffered ECC DIMMs
OCZ GameXStream 700W power supply (OK, OK, it's a little overpowered, but it was in stock!)
Other stuff like case, hard disk, DVD drive, video card and wireless LAN card
Lots of fans to provide soothing ambient noise

So far I have installed CentOS Linux 5 on it, but also plan to try Solaris 10 and FreeBSD. It seems pretty snappy.

Monday, January 15, 2007

Unbuffered socket iostreams

Boost.Asio includes an iostreams-based interface to TCP sockets, ip::tcp::iostream, for simple use cases. However, like the file iostreams provided by the standard library, ip::tcp::iostream buffers input and output data. This can lead to problems if you forget to explicitly flush the stream. For example, consider the following code to perform an HTTP request:

ip::tcp::iostream stream("www.boost.org", "http");
stream << "GET / HTTP/1.0\r\n"
       << "Host: www.boost.org\r\n"
       << "\r\n";

std::string response_line;
std::getline(stream, response_line);
...

The code will be stuck on the getline() call waiting for the response, because the request will still be sitting stream's output buffer. The correct code looks like this:

ip::tcp::iostream stream("www.boost.org", "http");
stream << "GET / HTTP/1.0\r\n"
       << "Host: www.boost.org\r\n"
       << "\r\n"
       << std::flush;

The std::flush will cause the stream to send the entire contents of its output buffer at that point.

Boost.Asio now supports an alternative solution: turn off the stream's output buffering. This is accomplished as follows:

ip::tcp::iostream stream("www.boost.org", "http");
stream.rdbuf()->pubsetbuf(0, 0);
stream << "GET / HTTP/1.0\r\n"
       << "Host: www.boost.org\r\n"
       << "\r\n";

Now you can send and receive to your heart's content, without having to worry about whether your message is stuck in the output buffer, but be warned: an unbuffered stream is a lot less efficient in terms of system calls. Don't use this feature if you care about performance.

ngaut 2007-12-28 20:43 发表评论

[转]asio Buffer debugging

ngaut — Fri, 28 Dec 2007 12:40:00 GMT

Friday, November 10, 2006

Buffer debugging

Some standard library implementations, such as the one that ships with MSVC 8.0, provide a nifty feature called iterator debugging. What this means is that the validity of your iterators is checked at runtime. If you try to use an iterator that has been invalidated, you'll get an assertion. For example:

std::vector v(1)
std::vector::iterator i = v.begin();
v.clear(); // invalidates iterators
*i = 0; // assertion!

Boost.Asio now takes advantage of this feature to add buffer debugging. Consider the following code:

void dont_do_this()
{
 std::string msg = "Hello, world!";
 asio::async_write(sock, asio::buffer(msg), my_handler);
}

When you call an asynchronous read or write you need to ensure that the buffers for the operation are valid until the completion handler is called. In the above example, the buffer is the std::string variable msg. This variable is on the stack, and so it goes out of scope before the asynchronous operation completes. If you're lucky, your application will crash. Often you will get random failures.

With the new buffer debug checking, however, Boost.Asio stores an iterator into the string until the asynchronous operation completes, and then dereferences it to check its validity. In the above example you get an assertion failure just before Boost.Asio tries to call the completion handler.

This feature has only been tested with MSVC 8.0 so far, but it should work with any other implementation that supports iterator debugging. Obviously there's a performance cost to this checking, so it's only enabled in debug builds. You can also explicitly disable it by defining BOOST_ASIO_DISABLE_BUFFER_DEBUGGING (or ASIO_DISABLE_BUFFER_DEBUGGING if you're using standalone asio).

4 comments:

andi said...: Hi Chris!

First of all, thanks for the great library!

I just wondered about the behaviour of this buffer debugging thing if the buffer length is zero, e.g.:

[...]
string content = ...
array<asio::const_buffer, 2> buffers = {
asio::buffer(header_ptr, sizeof(header_t)),
asio::buffer(content)
};
asio::async_write(socket_, buffers, boost::bind(...));

This is what I tried to do in my prototype I'm currently building.
Well, the problem I ran into is that the content string would sometimes have length 0, and that triggered an assertion failure because (obviously) the iterator could not be dereferenced then.
So, I wondered whether this is the intended behaviour (in other words: a feature, not a bug)?; August 09, 2007 4:26 AM
chris said...: Hi Andi,

Actually I fixed this bug not so long ago:

http://asio.cvs.sourceforge.net/asio/asio/include/asio/buffer.hpp?r1=1.22&r2=1.23; August 15, 2007 11:54 PM
chris said...: Let's try that link again:

diff for bug fix; August 15, 2007 11:56 PM
andi said...: Oh! Thanks for telling and good luck with your async' arts!; August 24, 2007 1:39 AM