[asio-users] suggestions for improvement in the networking APIs

[Miika Komu]

Howdy,

we investigated the networking APIs of Boost::Asio (1.47.0) and
published our findings in Ottawa Linux Symposium 2012:

http://nw.dreamhosters.com/ols/ols2012/ols2012-komu.pdf

We propose two types of improvements to the framework described in full
detail in section 4.3.1 of the publication. First, we suggest security
bug fixes. Second, we suggest improvements that can improve either the
user experience (i.e. by improving latency in IPv6 environments) or
developers (after all, frameworks are a conveniency for the developers).
The suggestions for improvements are briefly summarized below.

Security issues
---------------
* R3.2: Server-side multihoming for UDP does not work properly. The
framework should use SO_BINDTODEVICE option or sendmsg()/recvmsg()
interfaces in a proper way.
* (R5.3): The framework does not initialize the SSL/TLS implementation
automatically

Suggested improvements (for better end-user or developer experience)
--------------------------------------------------------------------
* R1.1: The framework does not support symbolic host names in its APIs,
i.e., does not hide the details of hostname-to-address resolution from
the application
* R3.3: The framework does not support parallel connect() over IPv4 and
IPv6 to minimize the latency for connection set-up
* R2.2: The framework does not support parallel DNS look ups over IPv4
and IPv6 to optimize latency

Please refer to section 4.3.3 in the publication for a more elaborate
discussion of the improvements.

[Miika Komu]

Hi,

Post by Miika Komu
* R3.2: Server-side multihoming for UDP does not work properly. The
framework should use SO_BINDTODEVICE option or sendmsg()/recvmsg()
interfaces in a proper way.

clarification... strictly speaking, R3.2 could be categorized as a
non-security bug (it results in failed connectivity).

[Marat Abrarov]

Post by Miika Komu
Suggested improvements (for better end-user or developer experience)
--------------------------------------------------------------------
* R1.1: The framework does not support symbolic host names in its APIs,
i.e., does not hide the details of hostname-to-address resolution from the
application

Asio supports basic operations those can be effectively combined by the user
of library. I think this feature is not necessary (really, Asio is low level
and it will be better for it to stay low level to be the most effective and
agile).

[Miika Komu]

Hi Marat,

Post by Marat Abrarov

Post by Miika Komu
Suggested improvements (for better end-user or developer experience)
--------------------------------------------------------------------
* R1.1: The framework does not support symbolic host names in its APIs,
i.e., does not hide the details of hostname-to-address resolution from the
application

Asio supports basic operations those can be effectively combined by the user
of library. I think this feature is not necessary (really, Asio is low level
and it will be better for it to stay low level to be the most effective and
agile).

I am not suggesting to remove low-level operations. To support backward
compatibility, I would suggest to merely add another method to
complement the existing, e.g, as follows:

* boost::asio::connect(socket, endpoint_iterator);
* boost::asio::resolve_and_connect_by_name(socket, hostname_string);

The use of the second function would reduce the complexity away from the
developer, which is the main reason for using a framework instead of
Sockets API directly. The library could do the following things on
behalf of the developer:

* Hide IPv4 vs. IPv6 selection (pick anything that works)
* Parallel connect to multiple destination addresses (just pick the one
that responds first)
* Automated source address selection (when multiple addresses are available)

The alternative to this is that each developer implements these features
separately and redundantly, and repeats all of the mistakes done by
others (we describe some in the report). I think this rather gloomy
alternative can be avoided with great frameworks such as Boost (which
btw faired quite well in our comparison!). Naturally, low-level access
is required sometimes, but connect(hostname) API is already supported in
ACE, java.net and partially Twisted, so why not in Boost?