Boost logo

Boost :

From: Joseph Berrios (jsberrios_at_[hidden])
Date: 2000-12-31 21:35:30


Your points are well taken. But the design criteria on why I used
Socket can shed a light on why I stuck with the concept of Sockets.
My work that lead to the development of the Socket library came as a
result of my Ph.D. disseration work. For a little while I used Java.
What I found is that the restricted model of Java (including the
Socket library) was counter productive. This motivated me to go back
to C++ and the Socket library in the UNIX API. The Socket library is
a pain to use, but it gave me the flexibility that the Java Socket API
didn't have. From this exercise, I decided to design a Socket

I kept the term Socket because in the research community and in
academia the term socket is widely accepted and I don't like to
invent new terms.

The design criteria for the socket library is:
1. To be an abstraction with ease of use similar to Java's Socket
2. To retain the flexibility of the UNIX Socket API.

My suggestion to provide the net connection and socket connection is
the following. Have a Socket class, which can be a parent class and
a specialized tcpstream class, which can act similar to the Java
Socket API.

--- In boost_at_[hidden], Daryle Walker <darylew_at_m...> wrote:
> on 12/29/00 10:34 AM, Beman Dawes at beman_at_e... wrote:
> > At 11:54 PM 12/28/2000 +0000, Michael D. Crawford wrote:
> >
> >> I agree that whatever you call your network endpoint in a
> >> library, you shouldn't call it a socket. It's too loaded with
> >> to people who don't know how other platforms work.
> >>
> >> In Unix, TCP sockets are file descriptors and are inherited by
> >> processes after a fork. It's a great technique, but it's
> >> become assumed by a lot of people that that's just how TCP works
> >> though it's highly platform specific.
> >
> > You may be missing the point. There are existence proofs that it
> > possible to design a sockets interface that works uniformly across
> > platforms. It doesn't behave exactly like Unix, or any other
> > platform. Rather it defines its own behavior, and it is up to the
> > platform specific implementations to meet that behavior.
> AFAIK, UNIX uses sockets for these things:
> 1. Internet connections
> 2. Files
> 3. Other devices (UNIX-defined or provided by 3rd-party
> Option [1] can be covered by my proposed tcpipstream class. (Other
> connections usually don't form a stream.) Option [2] is already
covered by
> fstream. Option [3] involves connecting to platform-specific items,
> they're not portable and may not be suitable for Boost.
> For the Windows family of operating systems, UNIX-style sockets are
> used for Internet connections. The tcpipstream class can be done
> Files are still covered by fstream, even though Windows doesn't use
> for files. Other devices (which may differ from UNIX's other
devices) don't
> use sockets, but aren't portable anyway and may not be suitable for
> For the pre-NeXT (i.e. "classic") Mac OS, the System V STREAMS
system is
> used for Internet connections. The tcpipstream class can be done
for this,
> but a socket-emulating class is not necessary! The implementation
is hidden
> and optimized for each platform, so there's no reason to not use the
> Internet APIs directly instead of kludging them though a third-party
> library. Files and other devices are like the Windows case,
although the
> actual implementation (and nature for other devices) is totally
> Other operating systems would be similar to these cases. I guess
I'm asking
> to think about the actual thing we're connecting to (files, TCP/IP,
> and not how the connection is done (sockets, etc.). You can still
make a
> socket connection class, but I don't think that there are any
general things
> that use sockets that can't be provided with a socket-agnostic
> (for socket-less platforms), so why bother?
> --
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com

Boost list run by bdawes at, gregod at, cpdaniel at, john at