August 2015 - Boost - lists.boost.org

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Lee Clagett 09 Aug '15

09 Aug '15

On Sat, Aug 8, 2015 at 5:16 AM, Vinícius dos Santos Oliveira < vinipsmaker(a)users.sf.net> wrote: > 2015-08-08 0:10 GMT-03:00 Lee Clagett <forum(a)leeclagett.com>: > >> FWIW it should be possible to do client and server side pipelining with >> this design right now. The reads and writes of the HTTP Socket concept >> should be (and currently are by `basic_socket`) handled independently. >> Since the notification for a write completion is based on the lower layer >> write completion, and NOT whether a HTTP response was received, multiple >> (pipelined) requests should be possible by a client. Similarly, this design >> should allow servers to handle pipelined requests in parrallel. Providing a >> framework for client or server pipelining will require more work, and >> should probably not be a part of the Socket concept. In fact - >> > > The current design **does** support pipelining. Some HTTP clients disable > pipelining because some buggy servers will get confuse. This won't happen > with Boost.Http (there are tests to ensure pipelning is working). > > What the current design does **not** support is handling pipelined > requests concurrently. When you starting read a request, the write_state[1] > will change to finished until the fully request is received, so you can't > get multiple request while you don't issue the replies. This behaviour is > explained in the ServerSocket concept[2]. > > There are just too many ways to allow HTTP concurrent pipeline that would > be transparent for the user, but all of them are heavier. If I was to allow > handling multiple concurrent HTTP pipelined requests, I'd expose user > cooperation, so the abstraction doesn't become so heavy. The user would > need to be aware if the reply for some request can already be delivered or > not. Of course this means the socket will need to remember order and attach > some id to the request messages. It can be problematic in alternative > backends because the id could be of a different type and makes it difficult > to use the same message type with different HTTP backends. What do you > think? The design would just be more complex for not much gain. HTTP/2.0 > allow real multiplexing and doesn't show this problem. > I agree that providing any pipelining framework in the library is probably unnecessary right now. However, the design should not inhibit such functionality from being added (which I do not think is a problem with this design). > I think the ServerSocket concept should be removed entirely. The >> `http::basic_socket<...>` models both concepts, so theres lots of server >> specific code in it, which seems confusing to me (is this really a "basic" >> socket?). >> > > basic_socket uses basic_ prefix just like basic_string. > I was asking whether basic_socket should NOT model the http::ServerSocket concept. I understood the naming convention, and the decision to provide the implementation as a configurable template. The problem is the lack of composability. If a different http::Socket concept is desired (someone not using ASIO, etc.), then the http::ServerSocket concept has to be re-implemented also since there is no other implementation. The obvious way is to achieve composability is to use inheritance with: `http::basic_server_socket<Socket>` where `Socket` is a http::Socket concept. Inheritance in this situation has its drawbacks, for sure (a virtual destructor should be considered). > I think standalone functions for typical client and server operations can >> be implemented as "composed" operations similar to `asio::async_write`. The >> documentation will have to be explicit on what the composed function is >> doing so that users know whether the Socket concept has outstanding reads >> or writes (and therefore cannot do certain operations until the handler is >> invoked). In fact, if there is a server operation that _cannot_ be done >> with the Socket concept, then the concept probably needs to be re-designed. >> > > About "users know whether..." seems like a bad idea if I want to deliver > multiple backends. Some implementation details should just be abstracted > away. > > http::SocketServer implementations manipulate the state of the http::Socket (and indirectly the asio::tcp::socket), making some actions unavailable after invoking those functions. For example, after invoking `async_write_response`, no writes on the http::Socket/http::ServerSocket or asio::ip::tcp::socket can occur until the callback is invoked because it calls asio::write on the asio::ip::tcp::socket directly. So unless I am incorrect, it is important for the users to know whats being manipulated (the effects). I don't understand what you mean by "if there is a server operation that > cannot be done with the Socket concept [...]". Boost.Http has two concepts, > ServerSocket and Socket. Socket concept will be useful to client-side HTTP > and that's the reason why there are two concepts. > > The http::ServerSocket concept requires a http::Socket to write its messages, but does the http::ServerSocket concept need to be a refinement of the http::Socket concept? This implies a strong relationship. The current specification looks like a http::ServerTraits concept - its specifying how a http::Socket is being used in situations specific to servers. There doesn't appear to be any additional state tracking needed for the http::ServerSocket functions, which is why I suggested standalone functions (I didn't see the FileServer section). In fact implementation can be inverted; make all of the current implementations for http::ServerSocket standalone functions, and then have the default http::ServerTraits implementation call the standalone versions of the functions. The http::ServerTraits should then take a http::Socket as an argument for each of the functions. This complete de-coupling would allow someone to independently change the behavior of any related server functions, even while using the same http::Socket object. [1] https://boostgsoc14.github.io/boost.http/reference/write_state.html > [2] "The ServerSocket object MUST prevent the user from issuing new > replies while [...]", > https://boostgsoc14.github.io/boost.http/reference/server_socket_concept.ht… > > Lee

2 3

[Utility] intuitive scoping with BOOST_WITH
by Marcel Ebmer 08 Aug '15

08 Aug '15

Hi Everyone, What if you could do std::mutex the_mutex; using Lock = std::unique_lock<std::mutex>; void f() { with(Lock{the_mutex}) { do_something(); do_other_thing(); } } *...or...* struct Pushed_matrix { Pushed_matrix() { glPushMatrix(); } ~Pushed_matrix() { glPopMatrix(); } }; void f() { with(Pushed_matrix{}) draw_something(); } At C++Now (2015), I presented this idea of mine and a macro implementation (BOOST_WITH) in a lightning talk. Since reception was good and more serious than the talk itself, I continued to work on it. I would appreciate informal review and opinions: https://github.com/maysl/BOOST_WITH Marcel

3 3

1.59.0 rc2 is now available
by Marshall Clow 08 Aug '15

08 Aug '15

Release candidate files for 1.59.0 are available at: http://boost.cowic.de/rc/ (rc1 failed a smoke test) As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_59_0_rc2.7z) = 1854999b8d32ba89acbf4384fe55e0ab MD5 (boost_1_59_0_rc2.tar.bz2) = 1783f07dd4736ffd9fc97874ce4ef4bf MD5 (boost_1_59_0_rc2.tar.gz) = 47e6db09fd7e1265b9b7046f654e9a72 MD5 (boost_1_59_0_rc2.zip) = 9061c5bbc3399f3f220036e896c202aa Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_59_0.html

3 2

[1.59] Still unmerged changes in the super-project
by John Maddock 08 Aug '15

08 Aug '15

There are a number of unmerged changes in develop of the super-project that look like they should really be in release, in particular: * Jamroot, contains amongst other things a very old fix for Oracle C++ support, without which building with Oracle is more or less broken. In fact unmerged commits on this file go back to....wait for it... 2011 ! * bootstrap.bat has fixes for some rather embarrassing typos. * bootstrap.sh has lots of fixes, also going back to 2011. Those were the "highlights" that stood out to me, the full list with unmerged changes is: .gitmodules | 613 ++++++++++++++++++------------------ .travis.yml | 6 +- Jamroot | 32 +- boostcpp.jam | 47 +-- boostcpp.py | 459 --------------------------- bootstrap.bat | 4 +- bootstrap.sh | 24 +- doc/Jamfile.v2 | 2 - doc/src/boost.xml | 2 - libs/libraries.htm | 10 +- libs/maintainers.txt | 5 +- status/Jamfile.v2 | 4 - status/explicit-failures-markup.xml | 41 +-- tools/Jamfile.v2 | 2 +- 14 files changed, 336 insertions(+), 915 deletions Best, John.

3 2

[iostreams] Ticket #5237 - Chance to get fix applied into Boost 1.59?
by Deniz Bahadir 08 Aug '15

08 Aug '15

Hi everyone, in our application we use Boost.Iostreams with GZip functionality to write some data into gzipped output-files. Eventually we realized, that we would get corrupted output-files if no data was available that could be written to the output-file By looking for a patch we stumbled across an issue-report [1] which seems to be open for more than 4 years, although a simple fix was already provided in its comments 3,5 years ago. My question is: Can somebody apply that fix to the development branch and could it still make it into the upcoming Boost 1.59 release? Thanks, Deniz [1] https://svn.boost.org/trac/boost/ticket/5237

4 4

Getting started with Boost
by Prathamesh Dahale 08 Aug '15

08 Aug '15

Hello, I am Prathamesh Dahale, third year computer engineering student. I am interested in contributing to Boost through gsoc 2016. I know c and c++, I am familiar with c++ STL and I have very good programming skills. I participate in many online programming contests. my handle on codechef.com is 'miracle003'. I would like to utilize my skills for contributing to Boost and I am interested in doing some project with Boost in gsoc 2016. from where i should start?

2 1

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Lee Clagett 08 Aug '15

08 Aug '15

Sorry for any duplicates and top posting, but I didn't reply-all, so boost got dropped (which was probably more important). And this likely ruins some mail clients (again sorry!). On Fri, Aug 7, 2015 at 11:10 PM, Lee Clagett <forum(a)leeclagett.com> wrote: > On Fri, Aug 7, 2015 at 6:29 PM, Vinícius dos Santos Oliveira < > vinipsmaker(a)users.sf.net> wrote: > >> 2015-08-07 12:53 GMT-03:00 Niall Douglas <s_sourceforge(a)nedprod.com>: >> >>> I do not believe Http is ready for peer review for these reasons, and >>> I personally would urge you withdraw it until you have fixed these >>> issues and then come back to us. If you do not withdraw it, I will >>> vote for rejection. >>> >> ...[large snip]... >> > >>> * I don't understand why you cannot issue more than one async read at >>> a time nor async write at a time. In something like pipelined HTTP >>> that seems like a very common pattern. I smell a potential design >>> flaw, and while the docs mention a "queue_socket" I can't see such a >>> thing in the reference section. >>> >> >> Too much synchronization and buffering. >> >> The pipeline has the following requests: >> >> A => B => C >> >> If I were to allow replies to request B, the design would be more >> complex, increasing the difficult to implement alternative backends and >> everyone's life. Also, the reply to request B cannot actually be sent while >> the reply to request A is on hold. This means that the whole response to >> request B would need buffering and if response B is a video live stream, >> this means an implicit (the user cannot know) crash after an unfortunate >> memory exhaustion. I couldn't claim a **lightweight** server if this >> excessive buffering was to occur. I couldn't claim the project is >> appropriate for embedded devices if I had chosen the buffering approach. >> It's a trade-off. I should write about it in the "design choice" of the >> documentation. >> >> HTTP/2.0 does have proper multiplexing and it can be more useful to >> respond several requests without "head of line blocking". >> >> A queue socket is a concept, I don't provide one. I can look into how >> make the documentation less confusing by adding a page exclusively >> dedicated to explain the problem it solves. Would that work for you? >> >> > FWIW it should be possible to do client and server side pipelining with > this design right now. The reads and writes of the HTTP Socket concept > should be (and currently are by `basic_socket`) handled independently. > Since the notification for a write completion is based on the lower layer > write completion, and NOT whether a HTTP response was received, multiple > (pipelined) requests should be possible by a client. Similarly, this design > should allow servers to handle pipelined requests in parrallel. Providing a > framework for client or server pipelining will require more work, and > should probably not be a part of the Socket concept. In fact - > > I think the ServerSocket concept should be removed entirely. The > `http::basic_socket<...>` models both concepts, so theres lots of server > specific code in it, which seems confusing to me (is this really a "basic" > socket?). I think standalone functions for typical client and server > operations can be implemented as "composed" operations similar to > `asio::async_write`. The documentation will have to be explicit on what the > composed function is doing so that users know whether the Socket concept > has outstanding reads or writes (and therefore cannot do certain operations > until the handler is invoked). In fact, if there is a server operation that > _cannot_ be done with the Socket concept, then the concept probably needs > to be re-designed. > > Lee >

2 1

Is master open for release 1.59?
by Vicente J. Botet Escriba 08 Aug '15

08 Aug '15

Hi, I was on vacations. Is the master branch open for merge? Best, Vicente

3 4

[Property Tree] Comments in info format
by Gavin McNiff 05 Aug '15

05 Aug '15

First time posting, so hopefully no grave faux pas! I have found the Property Tree info format very useful for config files. However, the in-built comment ";" can be a little limiting. In particular, I miss not being able to comment out an entire block. To this end I have being modifying the relevant header to file to allow ; // and -- as inline comments and /* */ as a block comment. These are familiar to many users. Naturally, with every Boost release I have to re-patch this file, so I thought maybe the info format could be updated to allow comments in these styles. Since the format is not any kind of official format and adding new comment styles should not break existing files, I would hope there should be no major objections. I have taken the liberty of attaching the updated header file, as well as the adapted test file. The _gmcn suffix is just for identification purposes. The changes in the code are marked with !!! GMcN !!!. The changes pass in the built-in tests and my own usage tests. Best regards Gavin McNiff

2 2

boost::asio and I2P connection handling.
by Janusz Zradomia 05 Aug '15

05 Aug '15

Hello. I would like to extend the ASIO (in boost::asio) by adding support for new virtual protocols. For example i2p, it is similar to Tor but it works with equivalent of .onion hidden servers, and is not used to connect to "normal Internet" usually. It works like this: - the end-points, equivalent of the ip4/ip6 address, is a very long string (around 500-1000 characters, it is technically the public key of data) - the end-point address is often expressed as shorter version of the address, that is around 50 characters afair, in two possible formats (b32 and b64) - user can create new i2p listening socket for TCP-like data (for stream of bytes), or for UDP-like data (message oriented). On creation of the listening socket you can get a new own "address" as above. Or, you can on creation/before creation tell it to reuse an previously created address by providing the std::string with private key of it (that you saved previously) - user can connect to an i2p address. When connecting, he is getting a new endpoint from which he connects, or he can reuse old one by loading the private key as above. - there exists naming lookup system, that allows to convert domain-name strings like "zzz.i2p" into proper i2p address Can I add such new class of protocol on top of ASIO? Which classes I need to extend (create child class)? Where exactly would each of the listed above functions go?

1 0