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

Subject: Re: [boost] ASIO in the Standard (was Re: C++ committee meeting report)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-04 07:18:45

On 3 Jul 2014 at 23:16, Dean Michael Berris wrote:

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

Some would call that the low-level interfacing necessary to achieve 
bare metal performance.

> - There were too many leaking abstractions crossing boundaries --
> being able to reach in to get native handles, buffer lifetimes
> crossing in-and-out, etc.

Ditto.

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

Kinda hard to do true async without.

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

I don't know what you refer to here. ASIO doesn't copy data being 
sent or received. It passes through literally what it receives from 
the OS.

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

These are all outside the remit of a core C++ networking library.

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

I'm personally not unsympathetic to this sentiment. However, it would 
surely need POSIX to move on it first before C++ could.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/