From: Beman Dawes (beman_at_[hidden])
Date: 2000-12-28 17:47:47
At 03:52 PM 12/28/2000 -0500, Gregory Seidman wrote:
>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
>} >supported through third-party libraries, but that maybe Boost
>} >have a platform-specific library like sockets at all. As you found
>} >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
>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,
>sometimes, depending on domains and protocols and such).
That was what I was talking about. Python socket constructors take family,
type, and (optional) protocol arguments. Family can be AF_INET or
AF_UNIX. Type can be SOCK_STREAM (for TCP), SOCK_DGRAM (for UDP), SOCK_RAW,
or SOCK_SEQPACKET. So "although it is based on Unix, this module is
available on all platforms," to quote Python Essential Reference by David M
> 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
I'm not familiar with Java, so don't know if their model is superior.
> 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,
>I'm sure it's something still slightly different.
Apparently it is possible to provide the BSD Unix functionality on those
and other non-Unix platforms.
>The essential lesson is that, unlike the Java core API, we should
>not be using a loaded word like "socket" for something which is intended
>be nothing more than a TCP connection. Would calling it a tcpConnection
>something make everyone happy?
If the design is new, then a new name would make sense. But if the design
is a C++ wrapper for a tried-and-true and well-known interface, then using
that interface's name would make sense.
>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
>and have it just work in C++ with no greater difficulty than I can in
>That's really a pipe dream at the moment, though.)
Presumably an eventual Boost Network Programming domain library would
contain libraries for sockets, URL handling, and similar layers built on
top of one another. I've used the Python urllib a couple of times, and it
was really amazing how quickly and easily it was to get the apps going. A
few minutes, literally. And I'm a Python novice.
>P.S. I bring up Java as an attempt at a platform-independent class
> to provide *lots* of functionality. There are lessons to be learned
> from the Java core APIs, boths DOs and DON'Ts.
Well, please let keep an eye on boost's efforts, and let us know if we
start repeating other's mistakes.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk