Re: [boost] Re: Sockets vs. net connection

From: Gregory Seidman (gseidman_at_[hidden])
Date: 2001-01-01 13:16:04

Joseph Berrios sez:
} 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.

What was it about Java's "Sockets" that you found restrictive or counter
productive? For a TCP connection, the API is pretty much complete. Of
course, various unix-y things like setsockopt() and ioctl() and fnctl() are
not available. Did you need these for what you were doing? And couldn't the
appropriately cross-platform, TCP-related be added to something that is
specifically a TCP connection?

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

It's widely accepted, but it means different things to different people in
different contexts.

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

You are missing one of Boost's design criteria:
3. To support the majority of OS platforms (and compilers).

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

Unix file descriptors are already a fairly object-oriented concept. There
are several methods which can be applied to them (close(), write(), send(),
recv(), and more), there are subclasses (e.g. files and sockets) for which
other methods are valid (fnctl(), setsockopt(), etc.), there are factory
methods (open(), socket(), etc.), and they even hide their internal data
(by keeping it in kernel-owned memory); the only thing they aren't is type
safe (you can even subclass yourself, though that tends to involve writing
a kernel module or the like and having a separate piece of code).

If we want to write an OO framework in C++ around the already OO framework
in C then we can, and pretty easily, but it won't be cross-platform. Java
has done a reasonably good job of identifying platform-independent concepts
such as files, TCP connections and UDP sockets, etc., but sockets (and file
descriptors) are very much not platform-independent.

What do you imagine as a socket that is both platform-independent and not
covered by a TCP connection (or perhaps an additional UDP socket class)?

--Greg