Sockets vs. net connection

From: Gregory Seidman (gseidman_at_[hidden])
Date: 2000-12-28 15:52:19

Beman Dawes sez:
} At 01:13 PM 12/28/2000 -0500, Daryle Walker wrote:
}  >The main point I was making wasn't that socket-less platforms should be
}  >supported through third-party libraries, but that maybe Boost shouldn't
}  >have a platform-specific library like sockets at all.  As you found out,
}  >sockets are not an universal concept.
} 
} While sockets are not universal, it is possible to specify a portable 
} socket interface which can be widely implemented via platform-specific 
} techniques.

The issue seems to be one of naming rather than functionality. What is a
"socket" to you? A socket in the Unix world is a complicated concept
involving domains (not DNS domains, domains like AF_INET and AF_UNIX),
transport-level protocols (e.g. TCP or UDP), etc. plus a kind of odd
polymorphism which makes a socket a kind of file descriptor (kinda, sorta,
sometimes, depending on domains and protocols and such). A socket in the
Java core API is a TCP connection (with other classes/APIs to represent a
bound TCP socket which can listen for incoming connections and UDP datagram
sockets). Sockets don't even really exist from the point of view of
(classic, not OS X) MacOS. I'm not sure what goes on in the win32 API, but
I'm sure it's something still slightly different.

The essential lesson is that, unlike the Java core API, we should probably
not be using a loaded word like "socket" for something which is intended to
be nothing more than a TCP connection. Would calling it a tcpConnection or
something make everyone happy?

} Boost shouldn't be afraid of such libraries.  If they are useful, meet the 
} other boost criteria, and can be implemented on both Unix and Windows, that 
} is enough, IMO.

TCP/IP is a cross-platform concept and, therefore, is at least candidate
functionality for Boost. (Then again, on that basis a windowing/widget
toolkit is candidate functionality. Ugh!) It would be highly desirable to
have the level of functionality and ease of use provided by the Java
core API as a cross-platform C++ library, Boost or otherwise.

(If we're going that route, I'd really love to have URL/URI handling as
powerful as Java's. I want to be able to invent my own protocol, make a
handler known to the runtime, and use myprotocol://foo.org/stuff as an URL
and have it just work in C++ with no greater difficulty than I can in Java.
That's really a pipe dream at the moment, though.)

} --Beman
--Greg
P.S. I bring up Java as an attempt at a platform-independent class library
     to provide *lots* of functionality. There are lessons to be learned
     from the Java core APIs, boths DOs and DON'Ts.