Re: Sockets vs. net connection

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

Daryle, 

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

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
API.
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
portable
> >> library, you shouldn't call it a socket.  It's too loaded with
meaning
> >> to people who don't know how other platforms work.
> >> 
> >> In Unix, TCP sockets are file descriptors and are inherited by
child
> >> processes after a fork.  It's a great technique, but it's
unfortunately
> >> become assumed by a lot of people that that's just how TCP works
even
> >> though it's highly platform specific.
> > 
> > You may be missing the point.  There are existence proofs that it
is
> > possible to design a sockets interface that works uniformly across
> > platforms. It doesn't behave exactly like Unix, or any other
specific
> > platform.  Rather it defines its own behavior, and it is up to the
various
> > 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
libraries)
> 
> Option [1] can be covered by my proposed tcpipstream class.  (Other
IP
> connections usually don't form a stream.)  Option [2] is already
covered by
> fstream.  Option [3] involves connecting to platform-specific items,
so
> they're not portable and may not be suitable for Boost.
> 
> For the Windows family of operating systems, UNIX-style sockets are
only
> used for Internet connections.  The tcpipstream class can be done
here.
> Files are still covered by fstream, even though Windows doesn't use
sockets
> 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
Boost.
> 
> 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
Mac's
> Internet APIs directly instead of kludging them though a third-party
sockets
> library.  Files and other devices are like the Windows case,
although the
> actual implementation (and nature for other devices) is totally
different.
> 
> 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,
etc.)
> 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
alternative
> (for socket-less platforms), so why bother?
> 
> -- 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com