?? tyt14fi.htm
字號:
<HTML>
<HEAD>
<TITLE>tyt14fi.htm</TITLE>
<LINK REL="ToC" HREF="index.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/index.htm">
<LINK REL="Index" HREF="tppmsgs/msgs0.htm#3" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/htindex.htm">
<LINK REL="Next" HREF="tytxafi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tytxafi.htm">
<LINK REL="Previous" HREF="tyt13fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt13fi.htm"></HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080"><A ID="I0" NAME="I0"></A>
<P><P ALIGN=CENTER>
<A HREF="tyt13fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt13fi.htm" TARGET="_self"><IMG SRC="blanprev.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blanprev.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Previous Page"></A>
<A HREF="index.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/index.htm" TARGET="_self"><IMG SRC="blantoc.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blantoc.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="TOC"></A>
<A HREF="tytxafi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tytxafi.htm" TARGET="_self"><IMG SRC="blannext.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blannext.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Next Page"></A>
<HR ALIGN=CENTER>
<P>
<UL>
<UL>
<UL>
<LI>
<A HREF="#E68E126" >Development of the Socket Programming Interface</A></LI>
<LI>
<A HREF="#E68E127" >Socket Services</A></LI>
<UL>
<LI>
<A HREF="#E69E178" >Transmission Control Block</A></LI>
<LI>
<A HREF="#E69E179" >Creating a Socket</A></LI>
<LI>
<A HREF="#E69E180" >Binding the Socket</A></LI>
<LI>
<A HREF="#E69E181" >Connecting to the Destination</A></LI>
<LI>
<A HREF="#E69E182" >The open Command</A></LI>
<LI>
<A HREF="#E69E183" >Sending Data</A></LI>
<LI>
<A HREF="#E69E184" >Receiving Data</A></LI>
<LI>
<A HREF="#E69E185" >Server Listening</A></LI>
<LI>
<A HREF="#E69E186" >Getting Status Information</A></LI>
<LI>
<A HREF="#E69E187" >Closing a Connection</A></LI>
<LI>
<A HREF="#E69E188" >Aborting a Connection</A></LI>
<LI>
<A HREF="#E69E189" >UNIX Forks</A></LI></UL>
<LI>
<A HREF="#E68E128" >Summary</A></LI>
<LI>
<A HREF="#E68E129" >Q&A</A></LI>
<LI>
<A HREF="#E68E130" >Quiz</A></LI></UL></UL></UL>
<HR ALIGN=CENTER>
<A ID="E66E14" NAME="E66E14"></A>
<H1 ALIGN=CENTER>
<CENTER>
<FONT SIZE=6 COLOR="#FF0000"><B>— 14 —</B>
<BR><B>The Socket Programming Interface</B></FONT></CENTER></H1>
<BR>
<P>Today I look at the last remaining aspect of TCP/IP this course covers: the socket interface for programming. This information is intended to convey the process needed to integrate an application with TCP/IP and as such involves some basic programming functions. It is not necessary to understand programming to understand this information. The functions involved in the socket programming interface help you understand the steps TCP/IP goes through when creating connections and sending data.
<BR>
<P>Understanding the socket interface is helpful even if you never intend to write a line of TCP/IP code, because all the applications you will work with use these principles and procedures. Debugging or troubleshooting a problem is much easier when you understand what is going on behind the user interface. Today I don't attempt to show the complete socket interface. Instead I deal only with the primary functions necessary to create and maintain a connection. This chapter is not intended to be a programming guide, either.
<BR>
<P>Because the original socket interface was developed for UNIX systems, today's text has a decidedly UNIX-based orientation. However, the same principles apply to most other operating systems that support TCP/IP.
<BR>
<BR>
<A ID="E68E126" NAME="E68E126"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>Development of the Socket Programming Interface</B></FONT></CENTER></H3>
<BR>
<P>TCP/IP is fortunate because it has a well-defined application programming interface (API), which dictates how an application uses TCP/IP. This solves a basic problem that has occurred on many other communications protocols, which have several approaches to the same problem, each incompatible with the other. The TCP/IP API is portable (it works across all operating systems and hardware that support TCP/IP), language-independent (it doesn't matter which language you use to write the application), and relatively uncomplicated.
<BR>
<P>The Socket API was developed at the University of California at Berkeley as part of their BSD 4.1c UNIX version. Since then the API has been modified and enhanced but still retains its BSD flavor. Not to be outdone, AT&T (BSD's rival in the UNIX market) introduced the Transport Layer Interface (TLI) for TCP and several other protocols. One of the strengths of the Socket API and TLI is that they were not developed exclusively for TCP/IP but are intended for use with several communications protocols. The Socket interface remains the most widespread API in current use, although several newer interfaces are being developed.
<BR>
<P>The basic structure of all socket programming commands lies with the unique structure of UNIX I/O. With UNIX, both input and output are treated as simple pipelines, where the input can be from anything and the output can go anywhere. The UNIX I/O system is sometimes referred to as the <I>open-read-write-close</I> system, because those are the steps that are performed for each I/O operation, whether it involves a file, a device, or a communications port.
<BR>
<P>Whenever a file is involved, the UNIX operating system gives the file a <I>file descriptor, </I>a small number that uniquely identifies the file. A program can use this file descriptor to identify the file at any time. (The same holds true for a device; the process is the same.) A file operation uses an open function to return the file descriptor, which is used for the read (transfer data to the user's process) or write (transfer data from the user process to the file) functions, followed by a close function to terminate the file operation. The open function takes a filename as an argument. The read and write functions use the file descriptor number, the address of the buffer in which to read or write the information, and the number of bytes involved. The close function uses the file descriptor. The system is easy to use and simple to work with.
<BR>
<P>TCP/IP uses the same idea, relying on numbers to uniquely identify an end point for communications (a socket). Whenever the socket number is used, the operating system can resolve the socket number to the physical connector. An essential difference between a file descriptor and a socket number is that the socket requires some functions to be performed prior to the establishment of the socket (such as initialization). In techno-speak, "a file descriptor binds to a specific file or device when the open function is called, but the socket can be created without binding them to a specific destination at all (necessary for UDP), or bind them later (for TCP when the remote address is provided)." The same open-read-write-close procedure is used with sockets.
<BR>
<P>The process was actually used literally with the first versions of TCP/IP. A special file called /dev/tcp was used as the device driver. The complexity added by networking made this approach awkward, though, so a library of special functions (the API) was developed. The essential steps of open, read, write, and close are still followed in the protocol API.
<BR>
<BR>
<A ID="E68E127" NAME="E68E127"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>Socket Services</B></FONT></CENTER></H3>
<BR>
<P>There are three types of socket interfaces defined in the TCP/IP API. A socket can be used for TCP <I>stream communications, </I>in which a connection between two machines is created. It can be used for <I>UDP datagram </I><I>communications,</I> a connectionless method of passing information between machines using packets of a predefined format. Or it can be used as a <I>raw</I> datagram process, in which the datagrams bypass the TCP/UDP layer and go straight to IP. The latter type arises from the fact that the socket API was not developed exclusively for TCP/IP.
<BR>
<P>The presence of all three types of interfaces can lead to problems with some parameters that depend exclusively on the type of interface. You must always bear in mind whether TCP or UDP is used.
<BR>
<P>There are six basic communications commands that the socket API addresses through the TCP layer:
<BR>
<UL>
<LI>open: Establishes a socket
<BR></LI>
<BR>
<LI>send: Sends data to the socket
<BR></LI>
<BR>
<LI>receive: Receives data from a socket
<BR></LI>
<BR>
<LI>status: Obtains status information about a socket
<BR></LI>
<BR>
<LI>close: Terminates a connection
<BR></LI>
<BR>
<LI>abort: Cancels an operation and terminates the connection
<BR></LI>
<BR>
</UL>
<P>All six operations are logical and used as you would expect. The details for each step can be quite involved, but the basic operation remains the same. Many of the functions have been seen in previous days when dealing with specific protocols in some detail. Some of the functions (such as open) comprise several other functions that are available if necessary (such as establishing each end of the connection instead of both ends at once).
<BR>
<P>Despite the formal definition of the functions within the API specifications, no formal method is given for how to implement them. There are two logical choices: synchronous, or <I>blocking,</I> in which the application waits for the command to complete before continuing execution; and asynchronous, or <I>nonblocking,</I> in which the application continues executing while the API function is processed. In the latter case, a function call further in the application's execution can check the API functions' success and return codes.
<BR>
<P>The problem with the synchronous or blocking method is that the application must wait for the function call to complete. If timeouts are involved, this can cause a noticeable delay for the user.
<BR>
<BR>
<A ID="E69E178" NAME="E69E178"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Transmission Control Block</B></FONT></CENTER></H4>
<BR>
<P>The Transmission Control Block (TCB) is a complex data structure that contains details about a connection. The full TCB has over fifty fields in it. The exact layout and contents of the TCB are not necessary for today's material, but the existence of the TCB and the nature of the information it holds are key to the behavior of the socket interface.
<BR>
<BR>
<A ID="E69E179" NAME="E69E179"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Creating a Socket</B></FONT></CENTER></H4>
<BR>
<P>The API lets a user create a socket whenever necessary with a simple function call. The function requires the family of the protocol to be used with the socket (so the operating system knows which type of socket to assign and how to decode information), the type of communication required, and the specific protocol. Such a function call is written as follows:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">socket(<I>family</I>, <I>type</I>, <I>protocol</I>)</FONT></PRE>
<P>The <I>family</I> of the protocol actually specifies how the addresses are interpreted. Examples of families are TCP/IP (coded as AF_INET), Apple's AppleTalk (AF_APPLETALK), and UNIX filesystems (AF_UNIX). The exact protocol within the family is specified as the protocol parameter. When used, it specifically indicates the type of service that is to be used.
<BR>
<P>The <I>type</I> parameter indicates the type of communications used. It can be a connectionless datagram service (coded as SOCK_DGRAM), a stream delivery service (SOCK_STREAM), or a raw type (SOCK_RAW). The result from the function call is an integer that can be assigned to a variable for further checking.
<BR>
<BR>
<A ID="E69E180" NAME="E69E180"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Binding the Socket</B></FONT></CENTER></H4>
<BR>
<P>Because a socket can be created without any binding to an address, there must be a function call to complete this process and establish the full connection. With the TCP/IP protocol, the socket function does not supply the local port number, the destination port, or the IP address of the destination. The bind function is called to establish the local port address for the connection.
<BR>
<P>Some applications (especially on a server) want to use a specific port for a connection. Other applications are content to let the protocol software assign a port. A specific port can be requested in the bind function. If it is available, the software allocates it and returns the port information. If the port cannot be allocated (it might be in use), a return code indicates an error in port assignment.
<BR>
<P>The bind function has the following format:
<BR>
<BR>
<PRE>
<FONT COLOR="#000080">bind(<I>socket</I>, <I>local_address</I>, <I>address_length</I>)</FONT></PRE>
<P><I>socket</I> is the integer number of the socket to which the bind is completed; <I>local_address</I> is the local address to which the bind is performed; and <I>address_length</I> is an integer that gives the length of the address in bytes. The address is not returned as a simple number but has the structure shown in Figure 14.1.
<BR>
<P><B><A HREF="14tyt01.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/14tyt01.gif">Figure 14.1. Address structure used by the socket </B><B>API.</A></B>
<BR>
<P>The address data structure (which is called usually called sockaddr for <I>socket address</I>) has a 16-bit Address Family field that identifies the protocol family of the address. The entry in this field determines the format of the address in the following field (which might contain other information than the address, depending on how the protocol has defined the field). The Address field can be up to 14 bytes in length, although most protocols do not need this amount of space.
<BR>
<BLOCKQUOTE>
<BLOCKQUOTE>
<HR ALIGN=CENTER>
<BR>
<NOTE>
<IMG SRC="note.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/note.gif" WIDTH = 75 HEIGHT = 46>The use of a data structure instead of a simple address has its roots in the UNIX operating system and the closely allied C programming language. The formal structure of the socket address enables C programs to use a union of structures for all possible address families. This saves a considerable amount of coding in applications.</NOTE>
<BR>
<HR ALIGN=CENTER>
</BLOCKQUOTE></BLOCKQUOTE>
<P>TCP/IP has a family address of 2, following which the Address field contains both a protocol port number (16 bits) and the IP address (32 bits). The remaining eight bytes are unused. This is shown in Figure 14.2. Because the address family defines how the Address field is decoded, there should be no problem with TCP/IP applications understanding the two pieces of information in the Address field.
<BR>
<P><B><A HREF="14tyt02.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/14tyt02.gif">Figure 14.2. The address structure for TCP/IP.</A></B>
<BR>
<BR>
<A ID="E69E181" NAME="E69E181"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Connecting to the Destination</B></FONT></CENTER></H4>
<BR>
<P>After a local socket address and port number have been assigned, the destination socket can be connected. A one-ended connection is referred to as being in an <I>unconnected state, </I>whereas a two-ended (complete) connection is in a <I>connected state.</I> After a bind function, an unconnected state exists. To become connected, the destination socket must be added to complete the connection.
<BR>
<BLOCKQUOTE>
<BLOCKQUOTE>
<HR ALIGN=CENTER>
<BR>
<NOTE>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -