Re: Sockets vs. net connection

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-12-31 15:16:57

on 12/29/00 10:34 AM, Beman Dawes at beman_at_[hidden] 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