<html lang="en">
<head>
<title>Socket Concepts - The GNU C Library</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="The GNU C Library">
<meta name="generator" content="makeinfo 4.13">
<link title="Top" rel="start" href="index.html#Top">
<link rel="up" href="Sockets.html#Sockets" title="Sockets">
<link rel="next" href="Communication-Styles.html#Communication-Styles" title="Communication Styles">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<!--
This file documents the GNU C library.

This is Edition 0.12, last updated 2007-10-27,
of `The GNU C Library Reference Manual', for version
2.8 (Sourcery G++ Lite 2011.03-41).

Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002,
2003, 2007, 2008, 2010 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being ``Free Software Needs Free Documentation''
and ``GNU Lesser General Public License'', the Front-Cover texts being
``A GNU Manual'', and with the Back-Cover Texts as in (a) below.  A
copy of the license is included in the section entitled "GNU Free
Documentation License".

(a) The FSF's Back-Cover Text is: ``You have the freedom to
copy and modify this GNU manual.  Buying copies from the FSF
supports it in developing GNU and promoting software freedom.''-->
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
  pre.display { font-family:inherit }
  pre.format  { font-family:inherit }
  pre.smalldisplay { font-family:inherit; font-size:smaller }
  pre.smallformat  { font-family:inherit; font-size:smaller }
  pre.smallexample { font-size:smaller }
  pre.smalllisp    { font-size:smaller }
  span.sc    { font-variant:small-caps }
  span.roman { font-family:serif; font-weight:normal; } 
  span.sansserif { font-family:sans-serif; font-weight:normal; } 
--></style>
<link rel="stylesheet" type="text/css" href="../cs.css">
</head>
<body>
<div class="node">
<a name="Socket-Concepts"></a>
<p>
Next:&nbsp;<a rel="next" accesskey="n" href="Communication-Styles.html#Communication-Styles">Communication Styles</a>,
Up:&nbsp;<a rel="up" accesskey="u" href="Sockets.html#Sockets">Sockets</a>
<hr>
</div>

<h3 class="section">16.1 Socket Concepts</h3>

<p><a name="index-communication-style-_0028of-a-socket_0029-1632"></a><a name="index-style-of-communication-_0028of-a-socket_0029-1633"></a>When you create a socket, you must specify the style of communication
you want to use and the type of protocol that should implement it. 
The <dfn>communication style</dfn> of a socket defines the user-level
semantics of sending and receiving data on the socket.  Choosing a
communication style specifies the answers to questions such as these:

     <ul>
<li><a name="index-packet-1634"></a><a name="index-byte-stream-1635"></a><a name="index-stream-_0028sockets_0029-1636"></a><strong>What are the units of data transmission?</strong>  Some communication
styles regard the data as a sequence of bytes with no larger
structure; others group the bytes into records (which are known in
this context as <dfn>packets</dfn>).

     <li><a name="index-loss-of-data-on-sockets-1637"></a><a name="index-data-loss-on-sockets-1638"></a><strong>Can data be lost during normal operation?</strong>  Some communication
styles guarantee that all the data sent arrives in the order it was
sent (barring system or network crashes); other styles occasionally
lose data as a normal part of operation, and may sometimes deliver
packets more than once or in the wrong order.

     <p>Designing a program to use unreliable communication styles usually
involves taking precautions to detect lost or misordered packets and
to retransmit data as needed.

     <li><strong>Is communication entirely with one partner?</strong>  Some
communication styles are like a telephone call&mdash;you make a
<dfn>connection</dfn> with one remote socket and then exchange data
freely.  Other styles are like mailing letters&mdash;you specify a
destination address for each message you send. 
</ul>

   <p><a name="index-namespace-_0028of-socket_0029-1639"></a><a name="index-domain-_0028of-socket_0029-1640"></a><a name="index-socket-namespace-1641"></a><a name="index-socket-domain-1642"></a>You must also choose a <dfn>namespace</dfn> for naming the socket.  A socket
name (&ldquo;address&rdquo;) is meaningful only in the context of a particular
namespace.  In fact, even the data type to use for a socket name may
depend on the namespace.  Namespaces are also called &ldquo;domains&rdquo;, but we
avoid that word as it can be confused with other usage of the same
term.  Each namespace has a symbolic name that starts with &lsquo;<samp><span class="samp">PF_</span></samp>&rsquo;. 
A corresponding symbolic name starting with &lsquo;<samp><span class="samp">AF_</span></samp>&rsquo; designates the
address format for that namespace.

   <p><a name="index-network-protocol-1643"></a><a name="index-protocol-_0028of-socket_0029-1644"></a><a name="index-socket-protocol-1645"></a><a name="index-protocol-family-1646"></a>Finally you must choose the <dfn>protocol</dfn> to carry out the
communication.  The protocol determines what low-level mechanism is used
to transmit and receive data.  Each protocol is valid for a particular
namespace and communication style; a namespace is sometimes called a
<dfn>protocol family</dfn> because of this, which is why the namespace names
start with &lsquo;<samp><span class="samp">PF_</span></samp>&rsquo;.

   <p>The rules of a protocol apply to the data passing between two programs,
perhaps on different computers; most of these rules are handled by the
operating system and you need not know about them.  What you do need to
know about protocols is this:

     <ul>
<li>In order to have communication between two sockets, they must specify
the <em>same</em> protocol.

     <li>Each protocol is meaningful with particular style/namespace
combinations and cannot be used with inappropriate combinations.  For
example, the TCP protocol fits only the byte stream style of
communication and the Internet namespace.

     <li>For each combination of style and namespace there is a <dfn>default
protocol</dfn>, which you can request by specifying 0 as the protocol
number.  And that's what you should normally do&mdash;use the default. 
</ul>

   <p>Throughout the following description at various places
variables/parameters to denote sizes are required.  And here the trouble
starts.  In the first implementations the type of these variables was
simply <code>int</code>.  On most machines at that time an <code>int</code> was 32
bits wide, which created a <em>de facto</em> standard requiring 32-bit
variables.  This is important since references to variables of this type
are passed to the kernel.

   <p>Then the POSIX people came and unified the interface with the words "all
size values are of type <code>size_t</code>".  On 64-bit machines
<code>size_t</code> is 64 bits wide, so pointers to variables were no longer
possible.

   <p>The Unix98 specification provides a solution by introducing a type
<code>socklen_t</code>.  This type is used in all of the cases that POSIX
changed to use <code>size_t</code>.  The only requirement of this type is that
it be an unsigned type of at least 32 bits.  Therefore, implementations
which require that references to 32-bit variables be passed can be as
happy as implementations which use 64-bit values.

   </body></html>