JTC1/SC22/WG21
N3491
Doc. No.: N3491=12-0181
Date: 2012-11-01
Reply to: Alex Fabijanic
Title: Minutes: SG4 Networking, October 2012
Study Group 4: Networking Study Group
Meeting in the Planning Room Tuesday, October 16th, 2012 1:45 - 5:00pm
Attendees:
Niklas Gustaffson (acting chair)
Matt Austern
Marshall Clow
Jens Maurer
Christof Meerwald
Dietmar Kühl
Alex Fabijanic (notes taker)
Meeting opened by Niklas Gustaffson Oct 16 2012 @ 1:45
Discussing following proposals:
N3388 "Using Asio with C++11"
N3389 "Urdl: A simple library for accessing web content"
N3420 "A URI Library for C++"
N3477 "C++ Internet Protocol Address Class"
N3388 "Using Asio with C++11"
========================
Consensus is that there is no enough people in the room who have in-depth knowledge about the proposal.
Niklas walks through and comments document content.
Understanding, Chaining Async operations, Error Handling
------------------------------------------------------------------------------
Jens asks why is aync write not a member (that is surprising); no answer at this time. Niklas asks whether
Asio raises exceptions or is it all return codes. Matt comments that all the cases where errors are reported
through error_code. Google will be proposing a common policy in this regard which should be used by libraries.
Matt proposes a feedback to Asio it should adhere to established policy, whatever the accepted one is eventually.
Jens comments there are already exceptions and they should be fixed retroactively.
Managing Object Lifetimes
------------------------------------
Niklas comments that Asio has no explicit support for it. Capturing this pointer in lambdas is dangerous.
Optimizing Memory Allocation
----------------------------------------
Jens likes that there is no ongoing memory allocations in the library. Dietmar suggests custom allocators for
all library types. Matt asks whether Asio is bigger than necessary? Niklas asks whether we have to standardize
the whole library at once or do it gradually. Jens thinks we need a complete library. Niklas praises Asio not
reinventing the wheel on Windows but abstract native facilities but does not think that necessarily means it should
be standardized as networking library. Jens is concerned about integration with general executor and, if Asio
is to be considered/accepted, it must be seamless. Matt would find the paper easier to understand if there were
complete examples included.
Concurrency
-----------------
Matt raises doubts about the existence/public exposure of IO service - if needs to exist and be exposed, suggests
coordinating with concurrency group (executor proposal). Jens, Marshal and Alex agree. Niklas: from MS perspective,
executor use depends on scenarios. Jens would like to have a std library scheduler interface and does not want to be
forced in multithreaded world if not necessary.
Passing the buck: developing efficient abstractions
-------------------------------------------------------------------
Matt and Niklas understand the motivation, not the solution implementation. Marshall explains from the standpoint of
Asio async I/O standpoint. Feedback to clarify further and provide some examples. Matt is not clear on the overall
purpose of the paper. Niklas emailed Chris in that regards but didn't get response. Jens explains the paper is response
to request from Kona to clarify Asio. Dietmar agrees.
N3389 "Urdl: a simple library for accessing web content"
===========================================
Niklas: it was discussed in Bellevue, let's go through discussion again.
1. Implementation
------------------------
2. Downloading
---------------------
Marshall comments that proposal does not say whether it only does HTTP or is it generic (FTP, HHTPS, ...).
Need clarification. All agree.
3. Checking errors
------------------------
Jens states that this is another example where common error reporting is needed.
4. Setting options to perform an HTTP POST
------------------------------------------------------------
Niklas comments on strange chapter numbering.
1. Specifying Timeouts
-------------------------------
Niklas states that a more elaborate timeout control, interaction with proxies, etc, is needed; i.e. simple library is not sufficient,
it must have more options. All agree.
2. Working with URLs
-----------------------------
Dietmar suggests collaboration with URI proposal. All agree.
3. Integration with Asio
-------------------------------
General notes: Jens would prefer to see detailed description of the async layer, rather than seeing something like Urdl. There
are two layers; Niklas does not think there is a need for two layers. Jens is shocked to see POST request embedded in the
stream. All agree. Niklas elaborates on proper design of the HTTP client, distinguishing between header, body, request/response,
etc ... All agree. Matt would like to see simple functionality that seamlessly integrates with complex facilities.
Matt proposes feedback: HTTP library would have to be cognizant of the protocol parts. All agree.
N3420 "A URI Library for C++"
=======================
In order to be able to cover everything, due to the size of the paper and limited amount of time, Niklas proposes to go over slides
provided to him by authors prior to the meting ; all agree. Brief discussion/clarification on general complicated issue of IRI and
related issues of dealing with strings in the context of std library follows. The goal is to implement the RFCs.
Jens objects to string and wstring only. Niklas (MS) proposes leaving the type of string unspecified.
Jens comments on exception during construction; he would like to see throw/non-throw options, with no-throw returning error_code.
Jens thinks URI class should not exist if it is not valid. All agree, but Marshall points out that this will not allow default construction.
Dietmar points out that approach is not scalable. There should be distinction between syntactic and semantic validity. Asking for
clarification from authors.
It is agreed that it is better to store the string as a whole, rather than separate parts. More discussion on the underlying string ensues.
Jens and Marshall propose just specifying the value type of the iterators. There should be range function similar to get_scheme().
Asking for begin()/end() to be contiguous could be over constraining.
In regards to text encoding and I18n, Jens objects to "implementation is required to use the encoding type defined by the platform"
Jens thinks that string_type native() const noexcept is wrong specification - it will throw because it returns by value; native does not
seem like the right name; replace by uri::all_part() accessor returning the whole underlying string.
Niklas and Jens point out the inconsistency in accessors naming. Dietmar points empty() is consistent with std lib; suggestion: other
accessors should have the same naming convention. All agree.
A question is raised about std::network::normalize(const uri&): why is it a free function? Group asks authors to elaborate and rationalize
the reason.
Jens and Niklas suggest a mechanism that alleviates the burden on operator==(); asking for a proposal on mechanism to extend
comparison to scheme and potentially protocol-specific steps without modifying the semantics of operator == ().
Authors are asked to specify the semantics of relational operators.
Matt and Niklas ask authors to precisely define what equivalence means. Which steps of the comparison ladder are used? This should be
addressed in the normative section.
In regards to references/resolution, SG4 has a question for the convener: can we normatively refer from C++ ISO standard to RFCs?
For std::network::resolve a more detailed specification (with specific references to RFC) is needed.
While examining equality operator, a non-explicit constructor ws found. Constructor taking string should be explicit.
Extension example implies that begin iterator of one range and end operator of another part form one range.
Percent encoding functions are useful and needed but naming is unanimously disliked (suggestion to drop 'pct_' portion); moreover, functions
should take iterators and there should separate function for each part because URI parts have different encoding rules.
Since different parts of a URI have different percent encoding rules, we propose six different functions of the form:
template <typename InputIterator, typename OutputIterator>
OutputIterator encode_XXX ( InputIterator first, InputIterator last, OutputIterator out );
Note: values of type InputIterator::value_type will be written to out
The six functions are:
encode_user_info
encode_host
encode_port
encode_path
encode_query
encode_fragment
template <typename InputIterator, typename OutputIterator>
OutputIterator decode ( InputIterator first, InputIterator last, OutputIterator out );
Note: values of type InputIterator::value_type will be written to out
Building URIs: builder should be named uri_builder and return the uri (through e.g. network::uri_builder::uri() )
N3477 "C++ Internet Protocol Address Classes"
====================================
"C++ Internet Protocol and Socket Address Classes" was the title of the proposal that did not make it to pre-Portland emailing but was
discussed at the SG4 session. As a result of this meeting, the paper has been numbered (N3477 / 12-0167) and renamed to
"C++ Internet Protocol Address Class".
There was a discussion on the networking reflector in regards to this proposal. The main dilemma was whether (a) there is a need for two
separate classes (IPv4 and IPv6) or (b) IP address should be handled by a single class handling both cases. The main rationale for (a)
is the concern for size (IPv6 address requires 4 times more storage space than IPv4 ) or performance (in case when implemented using
pImpl idiom); the downside of (a) is introduction into the C++ standard of a class for entity known to become obsolete in the future
(the last batch of IP addresses has been given to Regional Internet Registries in February of 2011 and IPv4 feature deprecation
process has started).
Dietmar states that Problem with memory allocation in a pImpl implementation can be alleviated through small object optimization.
Jens wants to know if we care about other kinds of networking schemes (Token Ring, etc). Matt thinks that this could be the case but IP
address is so widespread and important that it deserves its own abstraction. All agree.
Jens asks, given that IPv4 addresses have special embedding into IPV6 addresses, do we need a special IPv4 version, or IPv4 can
be embedded in IPv6 and interface provide is_v4, etc functions? Matt pointed out that this has round-trip implications for conversions
to/from string. Maybe need a to_stringv6 ()? Jens mentioned that this would make IPv4 address 4x bigger than necessary; but he does
not think that was a showstopper; consensus is that a single IP address class suffices.
The constructor ( void*, socklen_t ) is platform specific and should be removed; (allow implementations to create platform-specific extensions?).
Marshall asked if we want to conflate the IP address and network mask type, since they share a representation, but are not the same thing.
Niklas and Jens pointed out that users expect to type in a network mask using dotted decimal (ipv4).
Marshall asks, what do we use ip addresses for? We pass them to connect, and we don't use masks for that. Niklas suggests that we eliminate
the whole idea of network masks from the proposal, until we find out whether there is a use case for it.
The constructor ip_address(const struct sockaddr& sockaddr) should be removed.
Since it can be deduced from the string itself, remove family from ip_address(const std::string& addr, family family) constructor.
Jens thinks that scope needs a better documentation (referencing the appropriate RFC - see also comment for URI proposal, we are not yet certain
whether C++ standard can reference RFCs?)
Comments on to_string() function:
- return an IPv4 string if possible, and a maximally compressed IPv6 string if not (add optional argument to specify the returned format?).
- follow existing practice and provide wide strings on Windows.
At this time, there is no sufficient evidence that socket_address is needed and, even if it is needed, name resolving does not belong in it.