socket
SOCKET(T)           Linux Programmer's Manual           SOCKET(T)



NAME
       socket - create an endpoint for communication

SYNOPSIS
       #include <sys/types.h>
       #include <sys/socket.h>

       int socket(int domain, int type, int protocol);

DESCRIPTION
       Socket creates an endpoint for communication and returns a
       descriptor.

       The domain parameter  specifies  a  communication  domain;
       this  selects  the  protocol family which will be used for
       communication.    These   families    are    defined    in
       <sys/socket.h>.  The currently understood formats include:

       tab(:); l l l.  Name:Purpose:Man page T{  PF_UNIX,PF_LOCAL
       T}:T{  Local  communication  T}:T{  unix(x)  T} T{ PF_INET
       T}:IPv4 Internet protocols:T{ ip(p) T} T{ PF_INET6 T}:IPv6
       Internet  protocols:  T{ PF_IPX T}:IPX - Novell protocols:
       T{ PF_NETLINK T}:T{ Kernel  user  interface  device  T}:T{
       netlink(k)  T}  T{  PF_X25 T}:ITU-T X.25 / ISO-8208 proto-
       col:T{ x25(5) T} T{ PF_AX25 T}:T{ Amateur radio AX.25 pro-
       tocol  T}:  T{  PF_ATMPVC  T}:Access  to  raw ATM PVCs: T{
       PF_APPLETALK T}:Appletalk:T{ ddp(p) T} T{ PF_PACKET  T}:T{
       Low level packet interface T}:T{ packet(t) T}

       The  socket  has  the  indicated type, which specifies the
       communication semantics.  Currently defined types are:

       SOCK_STREAM
              Provides sequenced, reliable, two-way,  connection-
              based  byte streams.  An out-of-band data transmis-
              sion mechanism may be supported.

       SOCK_DGRAM
              Supports datagrams (connectionless, unreliable mes-
              sages of a fixed maximum length).

       SOCK_SEQPACKET
              Provides a sequenced, reliable, two-way connection-
              based data transmission path for datagrams of fixed
              maximum  length;  a consumer is required to read an
              entire packet with each read system call.

       SOCK_RAW
              Provides raw network protocol access.

       SOCK_RDM
              Provides a reliable datagram layer  that  does  not
              guarantee ordering.

       SOCK_PACKET
              Obsolete  and  should  not be used in new programs;
              see packet(t).

       Some socket types may not be implemented by  all  protocol
       families;  for  example, SOCK_SEQPACKET is not implemented
       for AF_INET.

       The protocol specifies a particular protocol  to  be  used
       with  the  socket.  Normally only a single protocol exists
       to support a particular socket type within a given  proto-
       col  family.   However, it is possible that many protocols
       may exist, in which case a  particular  protocol  must  be
       specified  in  this manner.  The protocol number to use is
       specific to the "communication domain" in which communica-
       tion  is  to  take  place;  see protocols(s).  See getpro-
       toent(t) on how to map protocol name strings  to  protocol
       numbers.

       Sockets  of type SOCK_STREAM are full-duplex byte streams,
       similar to pipes.  They do not preserve record boundaries.
       A  stream  socket  must be in a connected state before any
       data may be sent or  received  on  it.   A  connection  to
       another  socket  is  created with a connect(t) call.  Once
       connected, data  may  be  transferred  using  read(d)  and
       write(e)  calls or some variant of the send(d) and recv(v)
       calls.  When a session has been completed a  close(e)  may
       be performed.  Out-of-band data may also be transmitted as
       described in send(d) and received as described in recv(v).

       The communications protocols which implement a SOCK_STREAM
       ensure that data is not lost or duplicated.  If a piece of
       data  for  which the peer protocol has buffer space cannot
       be successfully transmitted within a reasonable length  of
       time,  then the connection is considered to be dead.  When
       SO_KEEPALIVE is enabled on the socket the protocol  checks
       in  a  protocol-specific  manner if the other end is still
       alive.  A SIGPIPE signal is raised if a process  sends  or
       receives  on a broken stream; this causes naive processes,
       which do not handle the signal, to  exit.   SOCK_SEQPACKET
       sockets  employ the same system calls as SOCK_STREAM sock-
       ets.  The only  difference  is  that  read(d)  calls  will
       return  only the amount of data requested, and any remain-
       ing in the arriving packet will  be  discarded.  Also  all
       message boundaries in incoming datagrams are preserved.

       SOCK_DGRAM and SOCK_RAW sockets allow sending of datagrams
       to correspondents named in send(d) calls.   Datagrams  are
       generally  received  with  recvfrom(m),  which returns the
       next datagram with its return address.

       SOCK_PACKET is an obsolete  socket  type  to  receive  raw
       packets  directly  from  the  device driver. Use packet(t)
       instead.

       An fcntl(l) call with the the  F_SETOWN  argument  can  be
       used to specify a process group to receive a SIGURG signal
       when the out-of-band data arrives or SIGPIPE signal when a
       SOCK_STREAM  connection  breaks unexpectedly.  It may also
       be used to set the process or process group that  receives
       the  I/O  and  asynchronous notification of I/O events via
       SIGIO.  Using F_SETOWN is equivalent to an  ioctl(l)  call
       with the SIOSETOWN argument.

       When  the network signals an error condition to the proto-
       col module (e.g.  using a ICMP message for IP) the pending
       error  flag  is set for the socket.  The next operation on
       this socket will return the  error  code  of  the  pending
       error.  For some protocols it is possible to enable a per-
       socket error queue to retrieve detailed information  about
       the error; see IP_RECVERR in ip(p).

       The  operation  of  sockets  is controlled by socket level
       options.  These options  are  defined  in  <sys/socket.h>.
       The  functions setsockopt(t) and getsockopt(t) are used to
       set and get options, respectively.

RETURN VALUE
       -1 is returned if an error occurs;  otherwise  the  return
       value is a descriptor referencing the socket.

ERRORS
       EPROTONOSUPPORT
              The  protocol type or the specified protocol is not
              supported within this domain.

       EAFNOSUPPORT
              The implementation does not support  the  specified
              address family.

       ENFILE Not  enough  kernel memory to allocate a new socket
              structure.

       EMFILE Process file table overflow.

       EACCES Permission to create a socket of the specified type
              and/or protocol is denied.

       ENOBUFS or ENOMEM
              Insufficient  memory is available.  The socket can-
              not  be  created  until  sufficient  resources  are
              freed.

       EINVAL Unknown protocol, or protocol family not available.

       Other errors may be generated by the  underlying  protocol
       modules.

CONFORMING TO
       4.4BSD (the socket function call appeared in 4.2BSD). Gen-
       erally portable to/from non-BSD systems supporting  clones
       of the BSD socket layer (including System V variants).

NOTE
       The  manifest  constants  used  under BSD 4.* for protocol
       families are PF_UNIX, PF_INET, etc.,  while  AF_UNIX  etc.
       are  used  for  address families. However, already the BSD
       man page promises: "The protocol family generally  is  the
       same  as the address family", and subsequent standards use
       AF_* everywhere.

BUGS
       SOCK_UUCP is not implemented yet.

SEE ALSO
       accept(t), bind(d), connect(t),  getprotoent(t),  getsock-
       name(e),   getsockopt(t),  ioctl(l),  listen(n),  read(d),
       recv(v), select(t), send(d),  shutdown(n),  socketpair(r),
       write(e)

       "An  Introductory 4.3 BSD Interprocess Communication Tuto-
       rial" is reprinted in UNIX Programmer's Supplementary Doc-
       uments Volume 1.

       "BSD  Interprocess Communication Tutorial" is reprinted in
       UNIX Programmer's Supplementary Documents Volume 1.



Linux Man Page              1999-04-24                  SOCKET(T)