Very Computer

I have 2 questions about sockets. Btw, my system is FreeBSD.

1- When I create a socket, I'm a little confused with the options.
Suppose I create a socket with the following options:

AF_INET, SOCK_xxx: I know what means AF_INET, but I'm confused about
the second one. What do they mean. I know what is a stream and
what is a packet. Does SOCK_STREAM means that there is a stream (maybe
buffered), like stdout and other file streams. Do I have to tell the
other end (the reading end) that I'm finished by closing the socket
(like in a pipe)? That is not the behavior I'm looking for.
I want to write a server that will manage a program that could have
multiple instances and to occasionnally send messages when particular
events occur (an instance has made a change somewhere and the server
would tell the other instances on the LAN, and things like that).
Would it be better to use datagrams? I thought that it would be better
to use TCP/IP sockets, since they provide part of what I'm expecting
from this network communication (reliable connections).

Also, is there a way to know from which machine an incoming connection
comes from?

Btw, if you could point me to a Web Page that tells the relationships
between the 3 parameters of the socket function, I would appreciate it.

2- What happens when Out-of-Band data arrives? On FreeBSD, is it
put on the top of the receiving queue or is it put on another one. I've
read a book ("The design and implementation of the 4.3BSD UNIX OS")
that Out-of-Band data is not placed in the normal queue.

Tx.

--
Michel Prvost
lectro-Conception
Qubec, Canada

http://www.ec.camitel.com/~mprevost

BY SENDING UNSOLLICITED, COMMERCIAL SPAM E-MAIL TO THIS ADDRESS,
YOU HEREBY AGREE TO RECEIVE UP TO 20 MEGABYTES OF
RANDOM CORE DUMP INFORMATION.

 Michel> I have 2 questions about sockets. Btw, my system is FreeBSD.
 Michel> 1- When I create a socket, I'm a little confused with the
 Michel> options.  Suppose I create a socket with the following
 Michel> options:

 Michel> AF_INET, SOCK_xxx: I know what means AF_INET, but I'm
 Michel> confused about the second one. What do they mean. I know what
 Michel> is a stream and what is a packet. Does SOCK_STREAM means that
 Michel> there is a stream (maybe buffered), like stdout and other
 Michel> file streams. Do I have to tell the other end (the reading
 Michel> end) that I'm finished by closing the socket (like in a
 Michel> pipe)? That is not the behavior I'm looking for.

SOCK_STREAM sockets behave like bidirectional pipes.

More precisely, SOCK_STREAM implies that the socket is:

  - connection-oriented
  - reliable (no data will be lost other than by termination of the link)
  - ordered (all data is received in the exact sequence it was sent)
  - flow-controlled (the receiver and network cannot be overrun)
  - byte-stream (no record boundaries exist at the transport level)

The term "stream" in SOCK_STREAM has nothing to do with the use of the
term for stdio streams (FILE*s).

 Michel> I want to write a server that will manage a program that
 Michel> could have multiple instances and to occasionnally send
 Michel> messages when particular events occur (an instance has made a
 Michel> change somewhere and the server would tell the other
 Michel> instances on the LAN, and things like that).  Would it be
 Michel> better to use datagrams? I thought that it would be better to
 Michel> use TCP/IP sockets, since they provide part of what I'm
 Michel> expecting from this network communication (reliable
 Michel> connections).

Datagrams are unreliable, but there are some things you can do with them
that you can't do with TCP, notably broadcasting/multicasting.

The general rule is, "don't try and reimplement TCP". In other words, if
you end up needing reliability, sequencing and flow-control, then use TCP
rather than implement equivalents over UDP.

Without knowing what the performance and synchronisation constraints are
in the scenario you describe, it's difficult to advise.

 Michel> Also, is there a way to know from which machine an incoming
 Michel> connection comes from?

Easy. See accept() and getpeername(), both of which return the address of
the peer.

 Michel> 2- What happens when Out-of-Band data arrives? On FreeBSD, is
 Michel> it put on the top of the receiving queue or is it put on
 Michel> another one. I've read a book ("The design and implementation
 Michel> of the 4.3BSD UNIX OS") that Out-of-Band data is not placed
 Michel> in the normal queue.

There are two modes of handling OOB data. By default, when the TCP Urgent
pointer is advanced, it's assumed that it means that a single OOB byte
has been sent; when that byte is received, it is extracted from the TCP
stream and queued separately. (It can be read only by specifying MSG_OOB
to recv().) This can fail if multiple OOB bytes are sent too rapidly;
they can appear in the normal data flow in this case. The place in the
stream where the OOB byte was extracted is marked; see the SIOCATMARK
ioctl.

If you set SO_OOBINLINE on the socket, then urgent data is left in the
normal stream, but the marks are still set. This is closer to the TCP
model of urgent data. (The out-of-line OOB mechanism is more like the
concept of "expedited flow" found in other protocol families, but which
is completely foreign to TCP.)

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>