Re: [boost] Sockets vs. net connection

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

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

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

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, 
but
 >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 
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?

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

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

--Beman