Subject: [boost] ASIO in the Standard (was Re: C++ committee meeting report)
From: Dean Michael Berris (dberris_at_[hidden])
Date: 2014-07-03 09:16:43
Cross-posting to networking_at_[hidden] and c++std-lib-ext.
On Wed, Jun 25, 2014 at 12:47 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
> * The Library Evolution Working Group (LEWG) voted to base the Networking
> TS on Boost.ASIO. That was a major surprise, as a Networking Study Group
> had been trying to build up a Networking TS from many small proposals. But
> in LEWG polls, support for ASIO was overwhelming, with no one at all voting
> against. This was a major vote of confidence for Boost.ASIO and Chris
> Kohlhoff. And several ASIO supporters were not even in the room at the time
> because Filesystem issues were being worked on elsewhere.
FWIW, I was in the room when the Boost.Asio proposal was being
discussed way back in Kona. I haven't seen the most recent update to
the proposal, but if my original concerns were addressed, mainly:
- The io_service type was trying to be too many things at the same
time (executor, ran in thread-pools, implementing IO-specific hooks,
etc.) and was too prominent in the interfaces of primitive types (i.e.
- There were too many leaking abstractions crossing boundaries --
being able to reach in to get native handles, buffer lifetimes
crossing in-and-out, etc.
- The fact that it seems the only implementation of the networking
parts (and inter-operating bits implied by the interface) would be
through a proactor -- how the API was only proactive, no support for
just purely reactive applications.
- There's no means for doing "zero-copy" I/O which is a
platform-specific but modern way of doing data transfer through
... then this I think is *good news*!
Having worked with quite a few network applications now in the past
few years, I'm happy with what Boost.Asio provides. However I think
there are other systems/libraries we can learn from to inform the
design here (I tried getting a comprehensive survey paper in, but that
proved a little harder than I originally thought and ended up with
just doing a poor job for HTTP).
A few that come to mind for potential approaches here are:
- Transport-level abstractions. Considering whether looking at
policy-driven transport protocol abstractions (say, an http
connection, a raw TCP connection, an SCTP connection with multiple
streams, etc.) would be more suitable higher-level abstractions than
sockets and write/read buffers.
- Agent-based models. More precisely explicitly having an agent of
sorts, or an abstraction of a client/server where work could be
delegated, composed with executors and schedulers.
I admit I haven't exactly been following through on attending the
Networking SG meetings and sending in papers myself. I sincerely hope
though that our collective love for Boost.Asio doesn't preclude us
from thinking at higher levels of abstractions and in broadening our
view/understanding of the network-programming landscape.
I say this with all due respect -- while network programming sounds
like it's all about sockets, buffers, event loops, and such there are
the "boring" bits like addressing, network byte ordering,
encoding/decoding algorithms (for strings and blobs of data), framing
algorithms, queueing controls, and even back-off algorithms,
congestion control, traffic shaping. There's more things to think
about too like data structures for efficiently representing frames,
headers, network buffers, routing tables, read-write buffer halves, ip
address tries, network topologies, protocol encodings (ASN.1, MIME and
friends), and a whole host of network-related concepts we're not even
touching in the networking discussions.
Having said this, I'm happy that we're willing to start with Boost.Asio. :)
> The next C++ committee meeting is November 3rd to 8th in Urbana-Champaign,
> IL, USA. As always, Boosters welcome.
Would really love to go, or at least be able to send comments to
papers in time for that one.
Thanks for the report Beman!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk