| <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: <a rel="next" accesskey="n" href="Communication-Styles.html#Communication-Styles">Communication Styles</a>, |
| Up: <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—you make a |
| <dfn>connection</dfn> with one remote socket and then exchange data |
| freely. Other styles are like mailing letters—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 (“address”) 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 “domains”, 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 ‘<samp><span class="samp">PF_</span></samp>’. |
| A corresponding symbolic name starting with ‘<samp><span class="samp">AF_</span></samp>’ 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 ‘<samp><span class="samp">PF_</span></samp>’. |
| |
| <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—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> |
| |
