asio-users Mailing List for asio C++ library (Page 261)
Brought to you by:
chris_kohlhoff
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(6) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(7) |
Nov
(8) |
Dec
(11) |
2006 |
Jan
(11) |
Feb
(14) |
Mar
(8) |
Apr
(3) |
May
(27) |
Jun
(15) |
Jul
(43) |
Aug
(64) |
Sep
(19) |
Oct
(44) |
Nov
(69) |
Dec
(82) |
2007 |
Jan
(79) |
Feb
(153) |
Mar
(169) |
Apr
(148) |
May
(181) |
Jun
(114) |
Jul
(152) |
Aug
(104) |
Sep
(77) |
Oct
(128) |
Nov
(185) |
Dec
(215) |
2008 |
Jan
(100) |
Feb
(116) |
Mar
(115) |
Apr
(74) |
May
(152) |
Jun
(107) |
Jul
(117) |
Aug
(115) |
Sep
(141) |
Oct
(75) |
Nov
(31) |
Dec
(47) |
2009 |
Jan
(51) |
Feb
(65) |
Mar
(54) |
Apr
(60) |
May
(6) |
Jun
(107) |
Jul
(82) |
Aug
(133) |
Sep
(144) |
Oct
(11) |
Nov
(54) |
Dec
(26) |
2010 |
Jan
(30) |
Feb
(17) |
Mar
(93) |
Apr
(47) |
May
(93) |
Jun
(73) |
Jul
(32) |
Aug
(60) |
Sep
(59) |
Oct
(58) |
Nov
(71) |
Dec
(28) |
2011 |
Jan
(58) |
Feb
(65) |
Mar
(38) |
Apr
(83) |
May
(45) |
Jun
(70) |
Jul
(71) |
Aug
(7) |
Sep
(33) |
Oct
(65) |
Nov
(33) |
Dec
(16) |
2012 |
Jan
(13) |
Feb
(32) |
Mar
(30) |
Apr
(67) |
May
(57) |
Jun
(59) |
Jul
(8) |
Aug
(61) |
Sep
(48) |
Oct
(23) |
Nov
(29) |
Dec
(8) |
2013 |
Jan
(37) |
Feb
(20) |
Mar
(11) |
Apr
(11) |
May
(9) |
Jun
(26) |
Jul
(6) |
Aug
(18) |
Sep
(7) |
Oct
(29) |
Nov
(2) |
Dec
(17) |
2014 |
Jan
(11) |
Feb
(12) |
Mar
(6) |
Apr
(26) |
May
(17) |
Jun
(12) |
Jul
(12) |
Aug
|
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(7) |
2015 |
Jan
(3) |
Feb
(3) |
Mar
(7) |
Apr
(23) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(33) |
Sep
(16) |
Oct
(2) |
Nov
(2) |
Dec
(13) |
2016 |
Jan
(7) |
Feb
(22) |
Mar
(11) |
Apr
|
May
(10) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
(29) |
Nov
(3) |
Dec
(21) |
2017 |
Jan
(4) |
Feb
(31) |
Mar
(8) |
Apr
(4) |
May
(1) |
Jun
(4) |
Jul
(32) |
Aug
(28) |
Sep
(2) |
Oct
(11) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
|
Nov
(4) |
Dec
(20) |
2019 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(11) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2023 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
(3) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2024 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Christopher K. <ch...@ko...> - 2005-10-16 21:59:43
|
Hi Arvid, --- Arvid Norberg <c9...@cs...> wrote: > I'm still missing comparison operators on tcp::endpoint and > udp::endpoint. At least I sometimes uses endpoints as keys in maps or > as members of sets. No problem, I'll add them in for 0.3.5. Cheers, Chris |
From: Christopher K. <ch...@ko...> - 2005-10-16 21:54:02
|
Hi Ryan, --- Ryan Phillips <ry...@tr...> wrote: > I have just started studying the asio documentation. Since Doxygen > is > used to generate the documentation, I would like to make the request > to include the class inheritancy diagrams. I think it would be of > some use. I didn't turn on this option because it generated a very big distribution. However, I have just regenerated the docs with those options turned on and put it up as a separate download: http://prdownloads.sourceforge.net/asio/asio-0.3.4-doc-classdiag.tar.gz?download Cheers, Chris |
From: Ryan P. <ry...@tr...> - 2005-10-16 07:47:05
|
I have just started studying the asio documentation. Since Doxygen is used to generate the documentation, I would like to make the request to include the class inheritancy diagrams. I think it would be of some use. Regards, Ryan |
From: Arvid N. <c9...@cs...> - 2005-10-15 15:39:07
|
On Oct 15, 2005, at 14:58, Christopher Kohlhoff wrote: > asio version 0.3.4 has been released. It may be downloaded from the > asio sourceforge page at http://asio.sourceforge.net. > > The major changes in this version include support for scatter-gather > operations, an initial SSL implementation, and documentation > improvements including an HTTP 1.0 server example. Code that uses asio > will need to be updated. Very nice work! I'm still missing comparison operators on tcp::endpoint and udp::endpoint. At least I sometimes uses endpoints as keys in maps or as members of sets. -- Arvid Norberg |
From: Christopher K. <ch...@ko...> - 2005-10-15 12:58:56
|
asio version 0.3.4 has been released. It may be downloaded from the asio sourceforge page at http://asio.sourceforge.net. The major changes in this version include support for scatter-gather operations, an initial SSL implementation, and documentation improvements including an HTTP 1.0 server example. Code that uses asio will need to be updated. The changes since asio 0.3.3 include: - Added support for scatter-gather on all read and write operations. These operations now take a list of one or more "buffers" for the operation. These buffers may be created to represent raw memory, POD arrays, boost::array or std::vector. This change breaks existing code, which needs to be fixed as follows. Where one used to write: sock.read(data, length); one now needs to write: sock.read(asio::buffers(data, length)); Similar changes are needed on all read, write, send and receive operations, both synchronous and asynchronous. - Added initial SSL support using OpenSSL. This takes the form of a template, called asio::ssl::stream, which can be used with any class which supports the Sync_*_Stream and Async_*_Stream concepts, e.g.: typedef asio::ssl::stream<asio::stream_socket> my_ssl_socket; Please note that for now this only works when used with single-threaded demuxers. A big thanks to Indrek Juhani of Voipster for developing the core implementation, and to Dirk Griffioen for organising this contribution. - Exceptions in handlers are no longer suppressed using catch (...). Instead they are now allowed to propagate out of the basic_demuxer::run function so they may be caught by application code. After an exception is caught, basic_demuxer::run may be called again immediately to continue processing. - Replaced the basic_demuxer::work_started/work_finished classes with an RAII class called basic_demuxer::work. - Added iostream output operators for ipv4::address, ipv4::tcp::endpoint and ipv4::udp::endpoint. - Added an HTTP 1.0 server example. - Added a kqueue reactor implementation for Mac OS X. Thanks to Stefan Arentz for providing the initial implementation. - Improved error handling in the epoll_reactor. - TSS slot usage has been minimised to use one slot for all demuxers of a given type, rather than one slot per demuxer object. - The calls to WSAStartup and WSACleanup have been made safer with respect to global demuxer objects. - Automaticaly link in ws2_32.lib when using asio on Win32 with Visual C++ or Borland C++. - Added back missing implementation of get_remote_endpoint. - Visual C++ 6 and gcc 2.95.x are not supported in this version, due to lack of testing resources. - Many documentation improvements. |
From: Christopher K. <ch...@ko...> - 2005-10-03 07:40:32
|
Hi Cory, --- Cory Nelson <ph...@gm...> wrote: > Hello! Are there plans to make async_connect use ConnectEx when it's > available? Yep, adding AcceptEx (for all supported Win32 platforms) and ConnectEx (initially if _WIN32_WINNT >= 0x0501) is one of the things I'm going to look at after 0.3.4 is released. Cheers, Chris |
From: Cory N. <ph...@gm...> - 2005-10-03 07:12:54
|
Hello! Are there plans to make async_connect use ConnectEx when it's avail= able? -- Cory Nelson http://www.int64.org |
From: Christopher K. <ch...@ko...> - 2005-09-09 02:57:32
|
Hi Arvid, --- Arvid Norberg <c9...@cs...> wrote: > I was also thinking that maybe the address class should have an > overload of the operator<<(std::ostream&, asio::address). This would > make the type play nicely with boost::lexical_cast<std::string>() as > well as being more easily streamed out. > > Maybe the endpoint types should have stream operators too, that would > be handy, especially when debugging. Good ideas. I'll put these changes in 0.3.4. > To avoid having to include <iostream>, maybe the stream operators > could be put in a separate header file (like boost.date_time does). I could probably do the same thing as I have done for asio::error, where the << operator is a template: template <Ostream> Ostream& operator<<(Ostream& os, const address& a) { ... } This will remove any need to include iostream. Cheers, Chris |
From: Christopher K. <ch...@ko...> - 2005-09-09 02:54:29
|
Hi Arvid, --- Arvid Norberg <c9...@cs...> wrote: > I want to use one of my demuxers to poll the messages received on any > of its sockets. i.e. have the same semantics as calling select() with > a timeout of 0. I'm doing it like this: > > asio::deadline_timer t(m_demuxer, milliseconds(0)); > t.async_wait(bind(&asio::demuxer::interrupt, ref(m_demuxer))); > m_demuxer.run(); > m_demuxer.reset(); > > Does this guarantee that all pending socket events are handled before > the timer event is handled and the demuxer is aborted? No, the run will be interrupted as soon as possible, even if there are handlers ready to be called. > If, not is > there a better way of achieving what I want? If you are just waiting for data to be received on the socket, you could use the stream_socket's in_avail() function to check if there is data waiting. This function will not block, and does not require you to run a demuxer at all. However polling is generally not a scalable approach. Could you explain the larger design problem you are trying to solve? Perhaps there's another approach. > And another question, is there a reason why run doesn't call reset() > before it quits? are there any operations in the demuxer that makes > sense only when it's in the state of "just returned from run, but not > reset"? or is the reset() operation expensive so one may want to skip > it if run() is not to be called again? This is because run() can be called from multiple threads simultaneously. You can't reset the demuxer until after the last run() function has exited, therefore it is kept separate. E.g.: demuxer d; thread th1(bind(&demuxer::run, &d)); thread th2(bind(&demuxer::run, &d)); thread th3(bind(&demuxer::run, &d)); // ... th1.join(); th2.join(); th3.join(); d.reset(); Cheers, Chris |
From: Arvid N. <c9...@cs...> - 2005-09-08 23:24:24
|
I was also thinking that maybe the address class should have an overload of the operator<<(std::ostream&, asio::address). This would make the type play nicely with boost::lexical_cast<std::string>() as well as being more easily streamed out. Maybe the endpoint types should have stream operators too, that would be handy, especially when debugging. To avoid having to include <iostream>, maybe the stream operators could be put in a separate header file (like boost.date_time does). -- Arvid Norberg |
From: Arvid N. <c9...@cs...> - 2005-09-08 23:08:07
|
Hi. I want to use one of my demuxers to poll the messages received on any of its sockets. i.e. have the same semantics as calling select() with a timeout of 0. I'm doing it like this: asio::deadline_timer t(m_demuxer, milliseconds(0)); t.async_wait(bind(&asio::demuxer::interrupt, ref(m_demuxer))); m_demuxer.run(); m_demuxer.reset(); Does this guarantee that all pending socket events are handled before the timer event is handled and the demuxer is aborted? If, not is there a better way of achieving what I want? And another question, is there a reason why run doesn't call reset() before it quits? are there any operations in the demuxer that makes sense only when it's in the state of "just returned from run, but not reset"? or is the reset() operation expensive so one may want to skip it if run() is not to be called again? thanks -- Arvid Norberg |
From: Christopher K. <ch...@ko...> - 2005-09-02 12:15:23
|
asio version 0.3.3 has been released. It may be downloaded from the asio sourceforge page at http://asio.sourceforge.net. In this version there has been extensive cleanup, renaming and restructuring of the interface, aimed at improving consistency and integration with boost. Code that uses asio will need to be updated. The changes since asio 0.3.2 include: - dgram_socket has been renamed to datagram_socket - send and recv have been replaced by write and read respectively. Functions called send and receive have been retained on the socket classes with an additonal flags argument. On the datagram_socket, sendto has been renamed to send_to, and recvfrom to receive_from. - timer has been renamed to deadline_timer and redesigned to use Boost.Date_Time classes. - socket_connector has been dropped in favour of connect/async_connect functions on both stream_socket and datagram_socket. - async_get_host_by_address and async_get_host_by_name functions have been added to ipv4::host_resolver. The implementation is simple and only simulates asynchronicity (using one background thread per-demuxer to execute the corresponding blocking call). - The ipv4::host structure has been turned into a class. - The asio::arg namespace has been renamed to asio::placeholders. The bytes_recvd and bytes_sent placeholders have been replaced with bytes_transferred. Similarly, the last_bytes_recvd/sent and total_bytes_recvd/sent have been replaced with last_bytes_transferred and total_bytes_transferred. - Requires Boost 1.33. |
From: Christopher K. <ch...@ko...> - 2005-04-19 04:58:27
|
Hi Anton, --- Anton Dedov <ad...@sw...> wrote: > 1. Why it is developed as a set of header files? My goal was to make it simple to use in a project, in that all you need to do is add the asio and boost include directories to your include path. I wanted to avoid users needing to mess around with import libraries, or worrying about whether they are using the same C runtime library as the DLL (e.g. with MSVC, where mixing static vs DLL runtime library can cause problems). Note that this shouldn't prevent it from being used in libraries, either static or dynamic, as part of something else. > I thought it can > rise some > issues with multiple symbol definitiions, etc. Have you encountered > any > issues with such architecture? All the symbols should be templates or inline functions, and in these cases duplicates should be stripped out by the linker. I haven't encountered any errors with this approach on either Windows or UNIX. > 2. When the SSL support is planned to be introduced? How difficult > its > implementation; may be you could tell some tips regarding this to > allow > me to try implement it my-self. I will need SSL support some time later this year, although I wouldn't be able to start implementing it until June at the earliest. The current plan is to implement it as a template called ssl_stream (similar to the existing buffered_stream template). It would use the BIO functions in OpenSSL to "run" the SSL state machine. It would probably be something like the ACE_SSL_Asynch_Stream implementation in ACE: http://cvs.doc.wustl.edu/ace-cvs.cgi/ACE_wrappers/ace/SSL/ That's about all I know so far :) Cheers, Chris |
From: Anton D. <ad...@sw...> - 2005-04-19 03:14:54
|
Hello, I am considering this library as possible candidate for my oun to make it more portable. So I have two questions. 1. Why it is developed as a set of header files? I thought it can rise some issues with multiple symbol definitiions, etc. Have you encountered any issues with such architecture? 2. When the SSL support is planned to be introduced? How difficult its implementation; may be you could tell some tips regarding this to allow me to try implement it my-self. Regards, Anton Dedov adedov at users.sourceforge.net |
From: Christopher K. <ch...@ko...> - 2005-04-13 23:07:57
|
asio version 0.3.2 has been released. It may be downloaded from the asio sourceforge page at http://asio.sourceforge.net. The main changes in this version are new socket options for multicast, and new peek() and in_avail() operations on the Sync_Recv_Stream concept. The changes made since asio 0.3.1 are: - Added new socket options for use with multicast, namely: asio::ipv4::multicast::add_membership asio::ipv4::multicast::drop_membership asio::ipv4::multicast::time_to_live asio::ipv4::multicast::outbound_interface asio::ipv4::multicast::enable_loopback Example programs demonstrating multicast were also added. - Added new peek() and in_avail() operations to the Sync_Recv_Stream concept, which entailed the modification of the following classes: asio::basic_stream_socket asio::buffered_recv_stream asio::buffered_send_stream asio::buffered_stream - Fixed a bug in the implementation of asio::ipv4::host_resolver where the arguments to get_host_by_name were passed in the wrong order. - Added a new example program showing how to cancel a recv operation. - Fixed a race condition in the demuxer_test unit test. |
From: Christopher K. <ch...@ko...> - 2005-03-06 01:42:56
|
asio version 0.3.1 has been released. It may be downloaded from the asio sourceforge page at http://asio.sourceforge.net. The 0.3.x versions will be development releases and may introduce interface changes (although none have been made so far). The most significant change in this release is support for epoll on Linux, where the kernel version is 2.5.45 or later. This allows programs to handle tens of thousands of concurrent connections. The changes made since asio 0.2.0 are: - Added initial support for epoll on Linux where the kernel version is 2.5.45 or later. This allows support for more than 1024 file descriptors in a single server. A server written using asio has been tested with 20000 concurrent connections. - Signals are now blocked in any thread that is private to asio, and when performing I/O operations following a select() or epoll_wait(). This allows programs using asio to cleanly handle signals by blocking them in all threads and having a single thread dedicated to calling sigwait(). - Low level system resource wrapper classes now throw exceptions on failure, where appropriate. - Copyright notices updated to include 2005. |
From: Christopher K. <ch...@ko...> - 2004-11-26 06:46:43
|
asio version 0.2.0 has been released. It may be downloaded from the asio sourceforge page at http://sourceforge.net/projects/asio/. The changes made since asio 0.1.13 are: - asio now uses the Boost Software License 1.0. - Added support for building against boost 1.32.0. - Fixed a bug associated with non-blocking connection operations, where an asynchronous connection operation that was expected to fail would never complete. - Fixed a compile error that occurred with MSVC 6 when using the Platform SDK version that came with the compiler. - Cleaned up numerous compile warnings reported by MSVC 7.1. - Fixed some multiply-defined-symbol linker errors that could occur when using MSVC. - Worked around a gcc 2.95.3 compiler error related to the use of ntoh* and hton* functions in an optimised build. |
From: Christopher K. <ch...@ko...> - 2004-11-24 07:35:11
|
--- jose <jj...@ya...> wrote: > I feel some new free HTTP code should be included in > the library as this is the area where most of the > development is focused nowadays and it would certainly > help spread adoption of the asio library. Totally agree with you there :) > I actually meant the case where you issue multiple get > requests and handle the responses as they arrive, like > what you would do in a web crawler or even in a simple > app to measure web server performance. Well, obviously decoding HTTP replies is needed first, but once that's there it should be quite straightforward to do what you want. It would be similar (sort of) to the way that tests/performance/client.cpp launches multiple connections in parallel. > My final question, what new features do you plan for > 0.20 and when will it be released 0.2.0 will be released very soon. I am just doing the final changes for it now, and then i will be testing it on as many platforms as possible before making the release. I'll post a message when it's ready. Cheers, Chris |
From: jose <jj...@ya...> - 2004-11-19 17:23:45
|
Thank you for your guidance. > Although some HTTP code has been written using asio, > it is owned by a > company and can't be freely shared. However I can I feel some new free HTTP code should be included in the library as this is the area where most of the development is focused nowadays and it would certainly help spread adoption of the asio library. > outline two possible > ways for implementing it. I'll only talk about how > to receive and > decode an http message, since sending is trivial. I actually meant the case where you issue multiple get requests and handle the responses as they arrive, like what you would do in a web crawler or even in a simple app to measure web server performance. My final question, what new features do you plan for 0.20 and when will it be released I feel asio fills a very important gap in C++ libraries and want it to get broad usage. I am still at the learning stage on this but hope to start using it soon. Regards, Jose ______________________________________________ Renovamos el Correo Yahoo!: ¡100 MB GRATIS! Nuevos servicios, más seguridad http://correo.yahoo.es |
From: Christopher K. <chr...@ya...> - 2004-11-18 22:05:13
|
Hi Jose, --- jose <jj...@ya...> wrote: > I would like to get some guidance to start some real > world web examples that would make the library even > more interesting: > > - an http 1.0 get request > - a simple proxy that gets one http request and issues > multiple http requests and sends back a summary > response > > Let me know any info you have to get me started on > this or maybe you already coded something very similar Although some HTTP code has been written using asio, it is owned by a company and can't be freely shared. However I can outline two possible ways for implementing it. I'll only talk about how to receive and decode an http message, since sending is trivial. There are two approaches that I am aware of... The first approach involves using a buffered stream. This gives you the ability to peek ahead at data without removing it from the stream, something you can't do without buffering. To implement this way you break down the HTTP response into its syntactic elements, i.e.: - status line - multiple headers - body For each element you write an async_recv function, e.g.: template <typename Buffered_Stream, typename Handler> void async_recv_http_status_line(Buffered_Stream& stream, http_status_line& status_line, Handler handler) { ... } In http the status line is terminated with "\r\n", so the implementation of the above function would scan the stream's buffer for that delimiter. If it can't find it, it extracts all data from the stream, and then does an async_fill() on the stream to get more data. Once this is complete it scans for the delimiter again. Once low level functions like this have been implemented, you then implement an overall function: template <typename Buffered_Stream, typename Handler> void async_recv_http_response(Buffered_Stream& stream, http_response& response, Handler handler) { ... } This function is implemented using the functions for each element. That is, it chains them together (one async operation after another) until the whole message has been received. The second approach (and the one we have used) does not require a buffered stream, and so may be more efficient. It might also be more work to develop, but I'm not sure. In this approach you develop a standalone http message decoder that you feed data to. E.g. the class interface looks a bit like: class http_response_decoder { public: enum status_type { need_more_data, decode_complete, decode_error }; status_type decode(http_response& response, const char* begin, const char* end, const char*& new_begin); }; Here, begin and end tell the decoder what buffer it should use as input data to perform decoding. The new_begin parameter is updated to indicate how much data has been consumed by the decoder. Once data has been consumed there is no need to keep it in the buffer any more. The decoder is typically implemented using a state machine (or nested state machines). You use it by receiving a chunk of data (of any length) off the socket using async_recv, and then feed that buffer to the decoder. The decoder tells you if you need more data, in which case you issue another async_recv. If the decoder tells you that decoding is complete you can pass the response to your application and then return to receiving more data. Cheers, Chris |
From: jose <jj...@ya...> - 2004-11-17 20:30:18
|
Hi, First of all, thank you for making asio available. I would like to get some guidance to start some real world web examples that would make the library even more interesting: - an http 1.0 get request - a simple proxy that gets one http request and issues multiple http requests and sends back a summary response Let me know any info you have to get me started on this or maybe you already coded something very similar Thanks Jose ______________________________________________ Renovamos el Correo Yahoo!: ¡100 MB GRATIS! Nuevos servicios, más seguridad http://correo.yahoo.es |
From: Christopher K. <ch...@ko...> - 2004-10-29 23:46:44
|
This is a test, please ignore. |