From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-02-25 05:42:53
--- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> --- In boost_at_y..., "jelco78" <marcojez_at_h...> wrote:
> > Only one thing: I can't understand the purpose of "Layer 2" in
> > proposed design. The library I wrote was composed of only 2
> > a first, low-level, portable wrapper class set for sockets and
> > addresses (which show a 100% ISO C++ interface, and a portable
> > implementation), and then an higher-level stream interface (based
> > a std::basic_streambuf derivation).
> > So, what is the purpose and structure of "Layer 2" as described
> > the guidelines?
> "Layer 2" (which talks about ~mysterious~ connector/acceptor
> is supposed to provide compile-time checks for the correctness of
> socket operations (especially the order of calls).
> Anyway, we already have a couple of socket libraries in the files
> section (I suspect many of have attempted this kind of thing
> I know I did). Perhaps it's time to consolidate our efforts and
> to come up with reasonable design. I know that David Moore has been
> looking into this for a few weeks now (he has his own socket
> library :) ), hopefully he can contribute here, too. Following are
> my thoughts on this, as always comments are much appreciated.
> - I guess we want our library to work with at least a couple of
> popular protocols from the TCP/IP family. I am thinking IP proper
> & v6), TCP & UDP (over IPv4 & IPv6). Is that reasonable?
> - I guess one important question is how to categorize different
> protocols, and how to deal with their differences. I suggest as a
> first step we consider all protocols to be either connection-
> or connectionless. This is important because the operations defined
> for a connectionless socket are quite different from those of a
> connected one. There are other ways to classify protocols, but I
> think "connectivity" is the most important one, at least from the
> application usage viewpoint.
> - Based on the above classification we would have two sets of
> 1) (connection-oriented): class acceptor_socket<>, class
> 2) (connectionless): class bound_socket<>
> All of these would be parametrized on the protocol type;
> instantiation with a "wrong" protocol type (e.g.,
> connected_socket<udp_ip4>) would result in a compile-time error.
> - Now regarding things like protocol and address families, I think
> should leave them alone, at least for now. My understanding is that
> there is a 1:1 mapping between a protocol and an address family for
> most cases (including IP/TCP/UDP -- am I wrong?), so there is no
> to worry about them (we can just assume that each protocol has an
> associated address type).
> - Each protocol (and it's category!) would be described by a type
> that will be used as the template selector for sockets. The
> type would be required to have certain members: `category'
> (connectionless or not), `address_type', `state_type' (aka socket
> descriptor). Plus, depending on category, it would also implement
> operations that make sense for that category (like connect(), accept
> (), send(), etc)
> Following are some examples of what I am thinking of:
> // -------- Connection-oriented -----------
> // An acceptor bound to a local address
> acceptor_socket< tcp_ip4 > server( "localhost:80" );
> // Wait for a connection
> connected_socket< tcp_ip4 > client( server );
> // Initiate a connection on "some_interface:80"
> // to "some_host:80"
> connected_socket< tcp_ip4 >
> client2 ("some_interface:2000", "some_host:80" );
> // Connected socket operations
> // -------- Connectionless -----------
> // Bind a connectionless socket to a local address
> bound_socket< udp_ip4 > bsock( "localhost:1000" );
> // Operations
> ------- [END EXAMPLES] --------------------
> I would like to keep the interface minimal, at least initially. I'm
> determined to get the design going so I would REALLY appreciate any
> suggestions you might have, especially considering that socket
> libraries never seem to be quite good enough to satisfy everybody!
> Comments, suggestions?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk