Re: Sockets vs. net connection

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

Hi, 

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.  

Joseph
--- 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 
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