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
> > 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
> > 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
> looking into this for a few weeks now (he has his own socket
> library :) ), hopefully he can contribute here, too. Following
> 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
> 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.
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk