On Mon, 3 Dec 2018 at 16:58, Vinnie Falco via Boost-users
It is true that there is a notable lack of authoritative tutorials and guides on all of the finer aspects of using Boost.Asio (and by extension, stand-alone Asio and Networking TS). I don't think it is fair to expect that the author of Asio (Christopher Kohlhoff) should be responsible for writing these things.
I would not expect Christopher to be responsible for writing these things. But you have already written it, if you would offer the patch to add that documentation to Asio wouldn't Christopher take it? It's likely it would reach a wider audience if it were in Asio instead of in Beast. There must be people interested in Asio but not in HTTP/Websocket who may not have bothered to look into the Beast docs.
- beast::test::stream (to be fair, it's in experimental)
Interfaces in _experimental/ are very likely to change which is why they are specially marked. They can also have bugs or lack documentation. As these things become fully baked they will be promoted to public interfaces (moved from _experimental to one of the public interface directories).
Sure, but wouldn't make sense for it to be in Asio's experimental instead of in Beast's experimental? It would have a wider audience, which would give you more feedback.
But now we even have code to work around issues in Boost.Asio which ideally would simply be fixed in Boost.Asio. For example: beast::ssl_stream.
asio::ssl::stream implementation does not handle scatter/gather I/O. When you call write() with a buffer sequences having length greater than one, it results in a separate I/O for each element of the sequence. This kills performance, especially in Beast where the implementation makes heavy use of buffers_cat. Beast's ssl_stream class is a wrapper which intelligently flattens these sequences at the expense of allocating memory.
I think there's an OpenSSL interface for handling a vector of buffers, so if it was fixed in Asio it would be better as there would be no need to allocate memory. I don't know enough to attempt a fix but maybe there is someone else who could?
Fair enough. Better to have a workaround than nothing. But until somebody with more OpenSSL knowledge comes with a proper fix, wouldn't the workaround be better in the Asio repository? To be fair, I don't know how the different Boost libraries are developed. Maybe it's too difficult for the developer of one library to contribute to another library?