Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ socket(2) — HP-UX 5.20

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

accept(2)

bind(2)

connect(2)

getsockname(2)

getsockopt(2)

ioctl(2)

listen(2)

recv(2)

select(2)

send(2)

shutdown(2)

socket(4)

tcp(4P)

udp(4P)

     SOCKET(2)                Series 300 Only                SOCKET(2)

     NAME
          socket - create an endpoint for communication

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

          s = socket(af, type, protocol)
          int s, af, type, protocol;

     HP-UX COMPATIBILITY
          Level:    HP-UX/NON-STANDARD

          Origin:   UCB

          Remarks:  Implemented on the Series 300 only.

     DESCRIPTION
          Socket creates an endpoint for communication and returns a
          descriptor.  The socket descriptor is returned in s, and is
          used in all subsequent socket-related system calls.

          The af parameter specifies an address format with which
          addresses specified in later operations using the socket
          should be interpreted.  These formats are defined in the
          include file <sys/socket.h>.  The only currently understood
          format is

               AF_INET (ARPA Internet addresses)

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

               SOCK_STREAM
               SOCK_DGRAM

          A SOCK_STREAM type provides sequenced, reliable, two-way
          connection based byte streams.  A SOCK_DGRAM socket supports
          datagrams (connectionless, unreliable messages of a fixed,
          typically small, maximum length).

          The protocol specifies a particular protocol to be used with
          the socket.  Normally only a single protocol exists to
          support a particular socket type using a given address
          format.  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 particular to
          the communication domain in which communication is to take
          place; see services(3N) and protocols(3N).  Protocol may be
          supplied as zero, in which case the system will choose a
          protocol type to use.

     Hewlett-Packard               - 1 -             (printed 7/16/86)

     SOCKET(2)                Series 300 Only                SOCKET(2)

          Sockets of type SOCK_STREAM are full-duplex byte streams,
          similar to pipes.  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(2) or
          accept(2) call.  Once connected, data may be transferred
          using read(2) and write(2) calls or some variant of the
          send(2) and recv(2) calls.  When a session has been
          completed a close(2) may be performed.

          The communications protocols used to implement a SOCK_STREAM
          insure 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 broken and the next
          recv(2) call will indicate an error with -1 returns and with
          ETIMEDOUT as the specific code in the global variable errno.
          The protocols keep socket connections active by forcing
          transmissions roughly every minute in the absence of other
          activity.  These transmissions are not visible to users, and
          can not be read by a recv(2) call.  An error is then
          indicated if no response can be elicited on an otherwise
          idle connection for a extended period (e.g. 5 minutes).  A
          SIGPIPE signal is raised if a process sends on a broken
          stream; this causes naive processes, which do not handle the
          signal, to exit.  An end-of-file condition (zero bytes read)
          is returned if a process tries to read on a broken stream.

          SOCK_DGRAM sockets allow sending of messages to
          correspondents named in send(2) calls.  It is also possible
          to receive messages at such a socket with recv(2).

          The operation of sockets is controlled by socket level
          options.  These options are defined in the file
          <sys/socket.h> and explained below. Setsockopt and
          getsockopt(2) are used to set and get options, respectively.
          None of these options are supported for SOCK_DGRAM sockets.
          When a socket is created, none of the options are enabled
          except SO_DONTLINGER.

               SO_DEBUG                 no functionality (only for
                                        compatibility)
               SO_DONTROUTE             no functionality (only for
                                        compatibility)
               SO_REUSEADDR             allow local address reuse
               SO_KEEPALIVE             no functionality (only for
                                        compatibility)
               SO_LINGER                linger on close if data
                                        present
               SO_DONTLINGER            do not linger on close

          SO_REUSEADDR indicates the rules used in validating
          addresses supplied in a bind(2) call should allow reuse of

     Hewlett-Packard               - 2 -             (printed 7/16/86)

     SOCKET(2)                Series 300 Only                SOCKET(2)

          local addresses.  What this effectively does is to allow
          multiple SOCK_STREAM sockets to be bound to the same local
          address as long as all existing sockets at the desired
          address are in a connected state before the bind(2) is done
          on the new socket.  The SO_REUSEADDR option has no effect on
          SOCK_DGRAM sockets.

          The SO_KEEPALIVE option does nothing because the underlying
          protocol always performs this function regardless, as noted
          above.  This function has to do with the periodic
          transmission of packets on idle connections.

          SO_LINGER and SO_DONTLINGER control the actions taken when
          unsent messages are queued on a SOCK_STREAM socket and a
          close(2) is performed.  If SO_LINGER is set with a non-zero
          linger interval, the system will block the process on the
          close(2) attempt until it is able to transmit the data or
          until it decides it is unable to deliver the information
          (the linger interval is specified in the setsockopt(2) call
          when SO_LINGER is requested). If SO_LINGER is set with a
          linger interval of zero, the connection is immediately
          terminated, and any unsent data that is queued on the
          connection will be lost.  If SO_DONTLINGER is specified
          (which is the default upon socket creation) and a close(2)
          is issued, the call will return immediatly.  The system
          will, however, still gracefully bring down the connection by
          transmitting any queued data, if possible.  The setting of
          SO_LINGER and SO_DONTLINGER are mutually exclusive.  Setting
          one unsets the other.  The setting of SO_LINGER and
          SO_DONTLINGER have no effect upon the action of shutdown(2).

          The socket call fails if:

          [EHOSTDOWN]              The networking subsystem has not
                                   been started up.

          [EAFNOSUPPORT]           The specified address family is not
                                   supported in this version of the
                                   system.

          [ESOCKTNOSUPPORT]        The specified socket type is not
                                   supported in this address family.

          [EPROTONOSUPPORT]        The specified protocol is not
                                   supported.

          [EMFILE]                 The per-process descriptor table is
                                   full.

          [ENOBUFS]                No buffer space is available.  The
                                   socket cannot be created.

     Hewlett-Packard               - 3 -             (printed 7/16/86)

     SOCKET(2)                Series 300 Only                SOCKET(2)

          [ENFILE]                 The system's table of open files is
                                   full, and temporarily no more
                                   socket calls can be accepted.

          [EPROTOTYPE]             The type of socket and protocol do
                                   not match.

          [ENET]                   A hardware error is detected on the
                                   interface card.

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

     SEE ALSO
          accept(2), bind(2), connect(2), getsockname(2),
          getsockopt(2), ioctl(2), listen(2), recv(2), select(2),
          send(2), shutdown(2), socket(4), tcp(4P), udp(4P).

     HARDWARE DEPENDENCIES
          Series 300:
               The EPROTONOSUPPORT error is never given.

     Hewlett-Packard               - 4 -             (printed 7/16/86)

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026