Re: Sockets library requirements

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 
the 
> > proposed design. The library I wrote was composed of only 2 
layers: 
> > 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 
> on 
> > a std::basic_streambuf derivation).
> > 
> > So, what is the purpose and structure of "Layer 2" as described 
in 
> > the guidelines?
> 
> "Layer 2" (which talks about ~mysterious~ connector/acceptor 
classes) 
> 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 
before --
>  I know I did). Perhaps it's time to consolidate our efforts and 
try 
> 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 
(v4 
> & 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-
oriented 
> 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 
socket 
> types:
> 1) (connection-oriented): class acceptor_socket<>, class 
> connected_socket<>
> 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 
we 
> 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 
need 
> 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 
protocol 
> 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 
the 
> 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
> client.is_connected();
> client.connect();
> client.disconnect();
> client.read();
> client.write();
> client.shutdown();
> client.address();
> client.peer_address();
> 
> // -------- Connectionless -----------
> 
> // Bind a connectionless socket to a local address
> bound_socket< udp_ip4 > bsock( "localhost:1000" );
> 
> // Operations
> bsock.send_to();
> bsock.receive_from();
> bsock.bind();
> bsock.is_bound();
> 
> ------- [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? 
> Thanks,
> D.P.