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

From: Gregory Seidman (gseidman_at_[hidden])
Date: 2001-01-03 00:01:26

I'm replying to two messages simultaneously here. Bear with me.

Joseph Berrios sez:
} First on my note was that I found the computational model of Java as a 
} whole restrictive.

I can't argue with that. I used Java with great success for a long time,
but find that I program faster in C++ (i.e. produce working results in a
shorter period of time).

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

If I understand you correctly, you wanted to use both sendto() and
sendmsg() on the same socket. Am I right? There's no reason why you can't
at the Unix level, but most protocols choose one or the other rather than
mixing and matching. I will assume that your research requires such oddity
and leave it at that (lord knows I've done some odd things with
memory-mapped I/O for my research).

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

While TCP sockets can be wrapped in appropriate higher-level constructs
(streams, in particular) with some utility, UDP is deliberately at a lower
level and it is unlikely that any wrapper created around it can be both
sufficiently flexible to be useful and sufficiently simple to be helpful.
(For example, Java chooses to make very little of UDP available (datagrams
both ways, binding, multicast, and not much else), and this oversimplifies
things.)

I think it is a mistake to talk about sockets when talking about
cross-platform network programming. TCP connections can certainly be
embodied in a class or family of classes, and UDP might even be wrapped
usefully, but they are worlds apart and should not share a common ancestor
class (whether it is called Socket or not).

[...]

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

Not strictly true. Connecting to a remote (or local) TCP socket causes an
implicit bind to a random port if the socket has not been explicitly bound
to a local port. It is possible (and sometimes desirable) to bind to a
local port before connecting. Regardless, once a TCP socket is successfully
connected, it has a port assigned to it and upon terminating (i.e.
close()) the socket the port will be free for use by other sockets.

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

There does not seem to be any unbind in Unix. The bind() call will fail if
the socket is already bound, so it cannot be used to implicitly rebind. I
believe that one must create a new socket to bind to a new port.

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

The socketpair() call does something very different from what Daryle is
asking. The pipe() call is essentially a special case of socketpair() with
a default protocol; either one produces a pair of file descriptors which
can be used to communicate with each other (this is usually used for
interprocess or interthread communication).

What I believe Daryle is asking is whether a a socket can simultaneously or
sequentially accept incoming connections and connect to a remote socket.
Of course, this only makes sense for a TCP socket; there is no concept of
connection in UDP (and any other protocols are pretty obscure). I can't
find any documentation mentioning it one way or the other, but a bit of
testcode reveals that, at least on Solaris 8, it cannot be used as both an
accepting server socket and a connecting client socket. In particular, the
listen() call (which must precede the accept() call) cannot precede the
connect() call, and vice versa.

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

An excellent book. I mostly use the man pages, though.

--Greg