"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">     <html
xmlns="http://www.w3.org/1999/xhtml"> <head>
    <link            rel="stylesheet"             type="text/css"
href="../../../style.css" title="style" />
    <link  rel="stylesheet"  type="text/css"  href="../style.css"
title="style" />
    <meta             http‐equiv="content‐type"              con‐
tent="text/html;charset=utf‐8" />

    <title>sys_socket.h.0p ‐ Linux manual page</title> </head>


<div        class="page‐top"><a       id="top_of_page"></a></div>
<!‐‐%%%TOP_BAR%%%‐‐> <!‐‐%%%PAGE_START%%%‐‐>

<table class="sec‐table"> <tr>
        <p class="section‐dir"> <a href="#PROLOG">PROLOG</a> | <a
href="#NAME">NAME</a>  |  <a  href="#SYNOPSIS">SYNOPSIS</a>  | <a
NALE</a>   |   <a    href="#FUTURE_DIRECTIONS">FUTURE&nbsp;DIREC‐
TIONS</a>    |   <a   href="#SEE_ALSO">SEE&nbsp;ALSO</a>   |   <a
    <td class="search‐box">
        <div class="man‐search‐box">

            <form                method="get"                 ac‐
                <fieldset class="man‐search">
                    <input    type="text"    name="q"   size="10"
maxlength="255" value="" />
                    <input type="hidden"  name="sitesearch"  val‐
ue="man7.org/linux/man‐pages" />
                    <input  type="submit" name="sa" value="Search
online pages" />

    <td> </td> </tr> </table>

<pre> <span class="headline">sys_socket.h(0P)          POSIX Pro‐
grammer’s  Manual          sys_socket.h(0P)</span>  </pre> <h2><a
id="PROLOG" href="#PROLOG"></a>PROLOG  &nbsp; &nbsp; &nbsp;  &nb‐
sp;        <a        href="#top_of_page"><span        class="top‐
       This manual page is part of the POSIX Programmer’s Manual.
The Linux
       implementation of this interface may differ (consult the
       corresponding  Linux  manual page for details of Linux be‐
havior), or
       the interface may not be  implemented  on  Linux.   </pre>
<h2><a id="NAME" href="#NAME"></a>NAME  &nbsp; &nbsp; &nbsp; &nb‐
sp;        <a        href="#top_of_page"><span        class="top‐
       sys/socket.h  — main sockets header </pre> <h2><a id="SYN‐
OPSIS" href="#SYNOPSIS"></a>SYNOPSIS  &nbsp; &nbsp; &nbsp; &nbsp;
<a              href="#top_of_page"><span             class="top‐
       #include &lt;sys/socket.h&gt; </pre>  <h2><a  id="DESCRIP‐
TION"  href="#DESCRIPTION"></a>DESCRIPTION   &nbsp; &nbsp; &nbsp;
&nbsp;       <a       href="#top_of_page"><span       class="top‐
       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
<b>socklen_t </b>type, which is
       an integer type of width of at least 32 bits; see APPLICA‐

       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
<b>sa_family_t </b>unsigned
       integer type.

       The <i>&lt;sys/socket.h&gt;</i> header  shall  define  the
<b>sockaddr </b>structure, which
       shall include at least the following members:

           <b>sa_family_t  sa_family  </b>Address family.
           char           sa_data[]   Socket  address  (variable‐
length data).

       The <b>sockaddr </b>structure is used to define  a  socket
address which is
       used  in  the <i>bind</i>(), <i>connect</i>(), <i>getpeer‐
name</i>(), <i>getsockname</i>(),
       <i>recvfrom</i>(), and <i>sendto</i>() functions.

       The <i>&lt;sys/socket.h&gt;</i> header  shall  define  the
       structure, which shall be:

        *   Large  enough  to accommodate all supported protocol‐
           address structures

        *  Aligned at an appropriate boundary so that pointers to
it can be
           cast  as  pointers to protocol‐specific address struc‐
tures and used
           to access  the  fields  of  those  structures  without

       The  <b>sockaddr_storage  </b>structure  shall  include at
least the following

           <b>sa_family_t   ss_family</b>

       When a pointer to a <b>sockaddr_storage  </b>structure  is
cast as a pointer
       to a <b>sockaddr </b>structure, the <i>ss_family</i> field
of the <b>sockaddr_storage</b>
       structure shall map onto the <i>sa_family</i> field of the
       structure.   When   a  pointer  to  a  <b>sockaddr_storage
</b>structure is cast as
       a pointer to a protocol‐specific  address  structure,  the
       field  shall map onto a field of that structure that is of
       <b>sa_family_t </b>and that identifies the protocol’s  ad‐
dress family.

       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
<b>msghdr </b>structure, which
       shall include at least the following members:

           <b>void           *msg_name         </b>Optional   ad‐
           socklen_t      msg_namelen     Size of address.
           struct iovec  *msg_iov         Scatter/gather array.
           int                 msg_iovlen          Members     in
           void          *msg_control     Ancillary data; see be‐
           socklen_t       msg_controllen   Ancillary data buffer
           int            msg_flags       Flags on received  mes‐

       The <b>msghdr </b>structure is used to minimize the number
of directly
       supplied   parameters   to   the   <i>recvmsg</i>()    and
<i>sendmsg</i>() functions. This
       structure  is used as a <i>value</i>‐<i>result</i> parame‐
ter in the <i>recvmsg</i>()
       function and <i>value</i> only  for  the  <i>sendmsg</i>()

       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
<b>iovec </b>structure as
       described in <i>&lt;sys/uio.h&gt;</i>.

       The <i>&lt;sys/socket.h&gt;</i> header  shall  define  the
<b>cmsghdr </b>structure, which
       shall include at least the following members:

           <b>socklen_t  cmsg_len    </b>Data byte count, includ‐
ing the <b>cmsghdr</b>.
           int        cmsg_level  Originating protocol.
           int        cmsg_type   Protocol‐specific type.

       The <b>cmsghdr </b>structure is used for storage of ancil‐
lary data object

       Ancillary  data consists of a sequence of pairs, each con‐
sisting of a
       <b>cmsghdr </b>structure followed by a data array. The da‐
ta array contains
       the  ancillary data message, and the <b>cmsghdr </b>struc‐
ture contains
       descriptive information that allows an application to cor‐
rectly parse
       the data.

       The values for <i>cmsg_level</i> shall be legal values for
the <i>level</i>
       argument  to  the  <i>getsockopt</i>()   and   <i>setsock‐
opt</i>() functions. The system
       documentation  shall  specify the <i>cmsg_type</i> defini‐
tions for the
       supported protocols.

       Ancillary data is also possible at the socket level. The
       <i>&lt;sys/socket.h&gt;</i> header shall define  the  fol‐
lowing symbolic constant
       for  use  as  the <i>cmsg_type</i> value when <i>cmsg_lev‐
el</i> is SOL_SOCKET:

       SCM_RIGHTS    Indicates that the data array  contains  the
                     rights to be sent or received.

       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
following macros to gain
       access to the data arrays in the ancillary data associated
with a
       message header:

             If  the  argument  is  a  pointer  to  a  <b>cmsghdr
</b>structure, this macro
             shall return an unsigned character  pointer  to  the
data array
             associated with the <b>cmsghdr </b>structure.

             If  the  first  argument is a pointer to a <b>msghdr
</b>structure and
             the second argument is a  pointer  to  a  <b>cmsghdr
</b>structure in the
             ancillary  data pointed to by the <i>msg_control</i>
field of that
             <b>msghdr </b>structure, this macro shall  return  a
pointer to the next
             <b>cmsghdr  </b>structure, or a null pointer if this
structure is the
             last <b>cmsghdr </b>in the ancillary data.

             If  the  argument  is  a  pointer  to  a   <b>msghdr
</b>structure, this macro
             shall  return  a  pointer  to  the  first <b>cmsghdr
</b>structure in the
             ancillary  data  associated  with   this   <b>msghdr
</b>structure, or a null
             pointer  if  there  is  no ancillary data associated
with the
             <b>msghdr </b>structure.

       The <i>&lt;sys/socket.h&gt;</i> header  shall  define  the
<b>linger </b>structure, which
       shall include at least the following members:

           <b>int   l_onoff   </b>Indicates whether linger option
is enabled.
           int  l_linger  Linger time, in seconds.

       The <i>&lt;sys/socket.h&gt;</i> header  shall  define  the
following symbolic
       constants with distinct values:

       SOCK_DGRAM    Datagram socket.

       SOCK_RAW      Raw Protocol Interface.

                     Sequenced‐packet socket.

       SOCK_STREAM   Byte‐stream socket.

       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
following symbolic
       constant for use as the <i>level</i> argument  of  <i>set‐
sockopt</i>() and

       SOL_SOCKET     Options to be accessed at socket level, not

       The <i>&lt;sys/socket.h&gt;</i> header  shall  define  the
following symbolic
       constants  with  distinct  values  for  use  as the <i>op‐
tion_name</i> argument in
       <i>getsockopt</i>() or <i>setsockopt</i>() calls (see  the
System Interfaces volume
       of  POSIX.1‐2008,  <i>Section  2.10.16</i>,  <i>Use of Op‐

       SO_ACCEPTCONN Socket is accepting connections.

       SO_BROADCAST  Transmission of broadcast messages  is  sup‐

       SO_DEBUG      Debugging information is being recorded.

       SO_DONTROUTE  Bypass normal routing.

       SO_ERROR      Socket error status.

       SO_KEEPALIVE   Connections  are  kept  alive with periodic

       SO_LINGER     Socket lingers on close.

       SO_OOBINLINE  Out‐of‐band data is transmitted in line.

       SO_RCVBUF     Receive buffer size.

       SO_RCVLOWAT   Receive ‘‘low water mark’’.

       SO_RCVTIMEO   Receive timeout.

       SO_REUSEADDR  Reuse of local addresses is supported.

       SO_SNDBUF     Send buffer size.

       SO_SNDLOWAT   Send ‘‘low water mark’’.

       SO_SNDTIMEO   Send timeout.

       SO_TYPE       Socket type.

       The <i>&lt;sys/socket.h&gt;</i> header  shall  define  the
following symbolic
       constant  for  use  as  the  maximum  <i>backlog</i> queue
length which may be
       specified by  the  <i>backlog</i>  field  of  the  <i>lis‐
ten</i>() function:

       SOMAXCONN     The maximum <i>backlog</i> queue length.

       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
following symbolic
       constants with distinct values for use as the valid values
for the
       <i>msg_flags</i>  field in the <b>msghdr </b>structure, or
the <i>flags</i> parameter in
       <i>recv</i>(),    <i>recvfrom</i>(),     <i>recvmsg</i>(),
<i>send</i>(), <i>sendmsg</i>(), or <i>sendto</i>() calls:

       MSG_CTRUNC    Control data truncated.

       MSG_DONTROUTE Send without using routing tables.

       MSG_EOR        Terminates  a  record  (if supported by the

       MSG_OOB       Out‐of‐band data.

       MSG_NOSIGNAL  No SIGPIPE generated when an attempt to send
is made on
                     a  stream‐oriented  socket that is no longer

       MSG_PEEK      Leave received data in queue.

       MSG_TRUNC     Normal data truncated.

       MSG_WAITALL   Attempt to fill the read buffer.

       The <i>&lt;sys/socket.h&gt;</i> header  shall  define  the
following symbolic
       constants with distinct values:

       AF_INET        Internet  domain  sockets for use with IPv4

       AF_INET6      Internet domain sockets for  use  with  IPv6

       AF_UNIX       UNIX domain sockets.

       AF_UNSPEC     Unspecified.

       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
following symbolic
       constants with distinct values:

       SHUT_RD       Disables further receive operations.

       SHUT_RDWR     Disables further  send  and  receive  opera‐

       SHUT_WR       Disables further send operations.

       The  <i>&lt;sys/socket.h&gt;</i>  header  shall define the
<b>size_t </b>and <b>ssize_t </b>types
       as described in <i>&lt;sys/types.h&gt;</i>.

       The following shall be declared as functions and may  also
be defined
       as macros. Function prototypes shall be provided.

           <b>int       accept(int,  struct  sockaddr  *restrict,
socklen_t *restrict);</b>
           <b>int      bind(int,   const   struct   sockaddr   *,
           <b>int       connect(int,  const  struct  sockaddr  *,
           <b>int     getpeername(int, struct sockaddr *restrict,
socklen_t *restrict);</b>
           <b>int     getsockname(int, struct sockaddr *restrict,
socklen_t *restrict);</b>
           <b>int     getsockopt(int, int, int,  void  *restrict,
socklen_t *restrict);</b>
           <b>int     listen(int, int);</b>
           <b>ssize_t recv(int, void *, size_t, int);</b>
           <b>ssize_t   recvfrom(int,   void  *restrict,  size_t,
                   <b>struct sockaddr *restrict,  socklen_t  *re‐
           <b>ssize_t recvmsg(int, struct msghdr *, int);</b>
           <b>ssize_t send(int, const void *, size_t, int);</b>
           <b>ssize_t   sendmsg(int,   const   struct  msghdr  *,
           <b>ssize_t sendto(int, const void *, size_t, int, con‐
st struct sockaddr *,</b>
           <b>int      setsockopt(int,  int,  int,  const void *,
           <b>int     shutdown(int, int);</b>
           <b>int     sockatmark(int);</b>
           <b>int     socket(int, int, int);</b>
           <b>int     socketpair(int, int, int, int [2]);</b>

       Inclusion of  <i>&lt;sys/socket.h&gt;</i>  may  also  make
visible all symbols from

       <i>The  following  sections  are  informative.</i>  </pre>
PLICATION    USAGE     &nbsp;    &nbsp;    &nbsp;    &nbsp;    <a
href="#top_of_page"><span                             class="top‐
       To forestall portability problems, it is recommended that
       applications  not  use  values  larger than 231 −1 for the

       The <b>sockaddr_storage </b>structure solves  the  problem
of declaring
       storage for automatic variables which is both large enough
       aligned enough for storing the socket address data  struc‐
ture of any
       family. For example, code with a file descriptor and with‐
out the
       context of the address family can  pass  a  pointer  to  a
variable of
       this  type,  where a pointer to a socket address structure
is expected
       in calls such as <i>getpeername</i>(), and  determine  the
address family by
       accessing the received content after the call.

       The  example  below  illustrates  a  data  structure which
aligns on a
       64‐bit   boundary.   An    implementation‐defined    field
<i>_ss_align</i> following
       <i>_ss_pad1</i>  is used to force a 64‐bit alignment which
covers proper
       alignment good enough for needs  of  at  least  <b>sockad‐
dr_in6 </b>(IPv6) and
       <b>sockaddr_in  </b>(IPv4)  address  data  structures. The
size of padding field
       <i>_ss_pad1</i> depends on the chosen alignment  boundary.
The size of
       padding  field  <i>_ss_pad2</i>  depends  on  the value of
overall size chosen
       for the total size of the structure. This size and  align‐
ment are
       represented in the above example by implementation‐defined
       required) constants _SS_MAXSIZE  (chosen  value  128)  and
       (with  chosen  value  8).  Constants _SS_PAD1SIZE (derived
value 6) and
       _SS_PAD2SIZE (derived value 112) are also for illustration
and not
       required.   The   implementation‐defined  definitions  and
structure field
       names above start with an &lt;underscore&gt; to denote im‐
       private  name  space. Portable code is not expected to ac‐
cess or
       reference those fields or constants.

            <b>*  Desired  design  of  maximum  size  and  align‐
           <b>#define _SS_MAXSIZE 128</b>
               <b>/* Implementation‐defined maximum size. */</b>
           <b>#define _SS_ALIGNSIZE (sizeof(int64_t))</b>
               <b>/*  Implementation‐defined  desired  alignment.

            *  Definitions used  for  sockaddr_storage  structure
paddings design.
           #define  _SS_PAD1SIZE (_SS_ALIGNSIZE − sizeof(sa_fami‐
           #define _SS_PAD2SIZE (_SS_MAXSIZE  −  (sizeof(sa_fami‐
ly_t)+                                  _SS_PAD1SIZE + _SS_ALIGN‐
           struct sockaddr_storage {
               sa_family_t  ss_family;  /* Address family. */
            *  Following fields are implementation‐defined.
               char _ss_pad1[_SS_PAD1SIZE];
                   /* 6‐byte pad; this is to make implementation‐
                      pad  up to alignment field that follows ex‐
plicit in
                      the data structure. */
               int64_t _ss_align;   /*  Field  to  force  desired
                                      storage alignment. */
               char _ss_pad2[_SS_PAD2SIZE];
                   /* 112‐byte pad to achieve desired size,
                      _SS_MAXSIZE value minus size of ss_family
                      __ss_pad1, __ss_align fields is 112. */
           };    </pre>   <h2><a   id="RATIONALE"   href="#RATIO‐
NALE"></a>RATIONALE    &nbsp;    &nbsp;    &nbsp;    &nbsp;    <a
href="#top_of_page"><span                             class="top‐
       None.   </pre>  <h2><a  id="FUTURE_DIRECTIONS"  href="#FU‐
TURE_DIRECTIONS"></a>FUTURE DIRECTIONS  &nbsp; &nbsp; &nbsp; &nb‐
sp;        <a        href="#top_of_page"><span        class="top‐
       None.     </pre>   <h2><a   id="SEE_ALSO"   href="#SEE_AL‐
SO"></a>SEE   ALSO     &nbsp;    &nbsp;    &nbsp;    &nbsp;    <a
href="#top_of_page"><span                             class="top‐
       <a href="../man0/sys_types.h.0p.html">sys_types.h(0p)</a>,
<a href="../man0/sys_uio.h.0p.html">sys_uio.h(0p)</a>

       The   System   Interfaces   volume   of  POSIX.1‐2008,  <a
href="../man3/accept.3p.html">accept(3p)</a>,                  <a
       <a    href="../man3/connect.3p.html">connect(3p)</a>,   <a
href="../man3/getpeername.3p.html">getpeername(3p)</a>,        <a
href="../man3/getsockname.3p.html">getsockname(3p)</a>,        <a
       <a    href="../man3/listen.3p.html">listen(3p)</a>,     <a
href="../man3/recv.3p.html">recv(3p)</a>,                      <a
href="../man3/recvfrom.3p.html">recvfrom(3p)</a>,              <a
href="../man3/recvmsg.3p.html">recvmsg(3p)</a>,                <a
       <a   href="../man3/sendmsg.3p.html">sendmsg(3p)</a>,    <a
href="../man3/sendto.3p.html">sendto(3p)</a>,                  <a
href="../man3/setsockopt.3p.html">setsockopt(3p)</a>,          <a
       <a   href="../man3/sockatmark.3p.html">sockatmark(3p)</a>,
<a        href="../man3/socket.3p.html">socket(3p)</a>,        <a
href="../man3/socketpair.3p.html">socketpair(3p)</a>       </pre>
<h2><a  id="COPYRIGHT"  href="#COPYRIGHT"></a>COPYRIGHT    &nbsp;
&nbsp;  &nbsp;  &nbsp;  <a  href="#top_of_page"><span class="top‐
       Portions of this text  are  reprinted  and  reproduced  in
electronic form
       from  IEEE Std 1003.1, 2013 Edition, Standard for Informa‐
       Technology ‐‐ Portable Operating System Interface (POSIX),
The Open
       Group  Base  Specifications Issue 7, Copyright (C) 2013 by
       Institute of Electrical and Electronics Engineers, Inc and
The Open
       Group.  (This is POSIX.1‐2008 with the 2013 Technical Cor‐
rigendum 1
       applied.) In the event of  any  discrepancy  between  this
version and
       the  original IEEE and The Open Group Standard, the origi‐
nal IEEE and
       The Open Group Standard is the referee document. The orig‐
       Standard     can     be     obtained    online    at    <a
line.html</a> .

       Any typographical or formatting errors that appear in this
page are
       most likely to have been introduced during the  conversion
of the
       source  files  to  man page format. To report such errors,
       <a      href="https://www.kernel.org/doc/man‐pages/report‐
ing_bugs.html</a> .

<span class="footline">IEEE/The Open  Group                  2013
sys_socket.h(0P)</span> </pre>

<hr class="end‐man‐text" />

<hr class="start‐footer" />

<div class="footer">

<table class="colophon‐table">
    <td class="pub‐info">
            HTML rendering created 2019‐08‐02
            by  <a  href="http://man7.org/mtk/index.html">Michael
            author of
            <a  href="http://man7.org/tlpi/"><em>The  Linux  Pro‐
gramming Interface</em></a>,
            maintainer of the
            <a href="https://www.kernel.org/doc/man‐pages/">Linux
<em>man‐pages</em> project</a>.
            For details of in‐depth
            <strong>Linux/UNIX system programming training  cour‐
            that  I  teach,  look <a href="http://man7.org/train‐
            Hosting   by    <a    href="http://www.jambit.com/in‐
dex_en.html">jambit GmbH</a>.
            <a href="http://validator.w3.org/check?uri=referer">
            <img src="http://www.w3.org/Icons/valid‐xhtml11"
                alt="Valid XHTML 1.1" height="31" width="88" />
    <td class="colophon‐divider">
    <td class="tlpi‐cover">
        <a                      href="http://man7.org/tlpi/"><img
alt="Cover of TLPI" /></a>
    </tr> </table>


<hr class="end‐footer" />

</body> </html>