Re: Sockets vs. net connection

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-01-02 15:49:29

on 1/1/01 2:35 AM, Joseph Berrios at jsberrios_at_[hidden] wrote:

[SNIP rationale of making a socket library]
> 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.
> 
> 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.
[SNIP past replies]

The socket class would be a parent to what class(es)?  It shouldn't be a
parent of the TCP/IP stream(buf) class; the concepts aren't that coupled and
using hard-coding sockets as the implementation for TCP/IP forces platforms
that don't use sockets to take a performance hit by having to use a
third-party library.  They should be separate classes with separate
interfaces and implementations.  (Maybe sockets could be used in the default
implementation of the TCP/IP class.)

Some concerns about the sockets interface right now:

1.  It seems that you differentiate between an UNIX-object socket and an
Internet socket by the port number.  However the accept methods treat their
arguments very differently depending on what kind of socket is needed.
Maybe these should be separated to different methods.
2.  I have a Java (1.2) book lying around, and I wonder if the socket class
should remove its stream-like interface and return an iostream (pointer?)
for reading and writing, like the java.net.SocketImpl class.  If a pointer
is returned, then we could have NULL mean no acceptance/connection is
opened.  We would have to develop socketbuf and socketstream classes (and
maybe isocketstream and osocketstream too) to do this.
3.  This question is more to the Boost guys like Beman and Dave: right now
the UNIX and Windows versions are in separate archives.  Should they be
unified?  If so, should the source files be unified to a "socket.cpp" file
with #defines separating the versions?  Or should they be kept in separate
files like "socket_unix.cpp" and "socket_win.cpp", maybe with a "socket.cpp"
file that #includes the appropriate version?

I have some other thoughts about the socket class, but I need some questions
answered:

1.  What is binding?  Is it required before accepting and/or connecting?
Does terminating a point affect binding?  Can a re-bind or an un-bind be
done?
2.  Can a socket simultaneously be a server (accept) and a client (connect)?
If so, can the two points be unrelated, or do they have to go to the same
remote location?

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com