[boost] ASIO in the Standard (was Re: C++ committee meeting report)

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.
sockets, etc.).

- 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
existing interfaces.

... 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!