Re: Sockets library requirements

From: craigp98072 (craigp98072_at_[hidden])
Date: 2002-02-23 23:46:08

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

Sorry if any of this is redundant. I'm just throwing out some ideas.

If you haven't seen ACE yet, I suggest you take a look. 
http://www.cs.wustl.edu/~schmidt/ACE.html. They have some very good 
design patterns for concurrent network programming. Even in terms of 
a minimalist design, I think they have a lot to contribute. 

I like the idea (from ACE) of separating the acception/connection 
strategies from socket streams. A passive accept_socket will return 
a socket_stream when it has accepted a connection, and active 
connect_socket will also return a socket_stream when it successfully 
connects. Only socket_streams can send and recieve data, and they 
behave the same regardless of how they were connected.

A library which doesn't handle non-blocking sockets and timeouts is 
practically useless (IMHO) - except for the most trivial of 
applications.

It would be very useful to support multicasting.

It should be relatively easy to plug-in and/or layer additional 
protocols, such as SSL over TCP/IP.

I think that marshalling should be left to a separate serialization 
library, or at least, the mechanism should be generic enough so that 
other schemes can be plugged in painlessly. There was some talk 
earlier about a persistence library. I hope that effort is going 
forward.

cheers!
--craig