Boost logo

Boost :

From: Joseph Berrios (jsberrios_at_[hidden])
Date: 2001-01-02 21:27:19


First on my note was that I found the computational model of Java as a
whole restrictive. Anyways on the socket part the Socket API in Java
is well designed for what was designed for. But as everything there
is no such thing as a silver bullet. I don't even claim that my
socket library is a panacea, but for what I wanted it, it served me
well. One of the things I wanted to do is with the same socket send
socket messages and datagrams. In java I have to declare a socket and
a datagramsocket object, which involves more overhead. For general
purpose programming thats fine, but for the research I am conducting I
want to be able to send both with the same object.

--- In boost_at_[hidden], Gregory Seidman <gseidman_at_a...> wrote:
> 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
> } My work that lead to the development of the Socket library came as
> } result of my Ph.D. disseration work. For a little while I used
> } What I found is that the restricted model of Java (including the
> } Socket library) was counter productive. This motivated me to go
> } to C++ and the Socket library in the UNIX API. The Socket library
> } a pain to use, but it gave me the flexibility that the Java Socket
> } 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
> productive? For a TCP connection, the API is pretty much complete.
> 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
> 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
> } the following. Have a Socket class, which can be a parent class
> } a specialized tcpstream class, which can act similar to the Java
> } Socket API.
> Unix file descriptors are already a fairly object-oriented concept.
> are several methods which can be applied to them (close(), write(),
> recv(), and more), there are subclasses (e.g. files and sockets) for
> other methods are valid (fnctl(), setsockopt(), etc.), there are
> methods (open(), socket(), etc.), and they even hide their internal
> (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
> 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
> in C then we can, and pretty easily, but it won't be cross-platform.
> has done a reasonably good job of identifying platform-independent
> 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
> --Greg

Boost list run by bdawes at, gregod at, cpdaniel at, john at