Re: Sockets vs. net connection

From: Joseph Berrios (jsberrios_at_[hidden])
Date: 2001-01-02 22:04:03

Daryle, 

thanks for your response and thoughts.  To be honest with you I have 
no idea how the streambuf works.  I am currently looking for a 
tutorial on the iostreams and specially the streambuf.   Is there any 
book or a gentle tutorial that explains the streambuf library and how 
can it be used to extend it for a new type?

answering your questions:

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

The bind command is used to let the application specify the local IP 
address and local port, for both TCP and UDP.  By doing so this 
function assings a local protocol address to a socket.  Usually this 
command is used with the server socket.  

If the socket terminating is a client, it will not affect the 
binding.  If the server terminates, then the address and port will be 
free to be used by another program.  

I don't know if re-bind or an unbind can be done.  I checked my 
references and couldn't find any answers.  

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

as the socket class is designed now, it does not support to use one 
socket for both client and server.  There is a command in the UNIX 
API called socketpair that allows the same socket to be used by both 
the client and the server.  

My references are the following:

Title:  Linux Socket programming by example
Author:  Warren W. Gay
ISBN:  0-7897-2241-0

Title:  UNIX network programming:  VOL 1.  
        Networking API's:  Sockets and XTI
Author:  W. Richard Stevens
ISBN:  0-13-490012-X

--- In boost_at_[hidden], Daryle Walker <darylew_at_m...> wrote:
> on 1/1/01 2:35 AM, Joseph Berrios at jsberrios_at_y... 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