<P><I>length</I> is the number of entries in the iovector. The format of the iovector is the same as mentioned previously and shown in Figure 14.4.

<BR>

<P>The recv function also can be used with connected sockets. It has the format

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">recv(<I>socket</I>, <I>buffer_address</I>, <I>length</I>, <I>flags</I>)</FONT></PRE>

<P>which corresponds to the send function's arguments.

<BR>

<P>The recvfrom and recvmsg functions enable data to be read from an unconnected socket. Their formats include the sender's address:

<BR>

<PRE>

<FONT COLOR="#000080">recvfrom(<I>socket</I>, <I>buffer</I>_<I>address</I>, <I>length</I>, <I>flags</I>, <I>source</I>_<I>address</I>, <I>address</I>_<I>length</I>)

recvmsg(<I>socket</I>, <I>message</I>_<I>structure</I>, <I>flags</I>)</FONT></PRE>

<P>The message structure in the recvmsg function corresponds to the structure in sendmsg. (See Figure 14.3.)

<BR>

<BR>

<A ID="E69E185" NAME="E69E185"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Server Listening</B></FONT></CENTER></H4>

<BR>

<P>A server application that expects clients to call in to it has to create a socket (using socket), bind it to a port (with bind), then wait for incoming requests for data. The listen function handles problems that could occur with this type of behavior by establishing a queue for incoming connection requests. The queue prevents bottlenecks and collisions, such as when a new request arrives before a previous one has been completely handled, or two requests arrive simultaneously.

<BR>

<P>The listen function establishes a buffer to queue incoming requests, thereby avoiding losses. The function lets the socket accept incoming connection requests, which are all sent to the queue for future processing. The function's format is

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">listen(<I>socket</I>, <I>queue_length</I>)</FONT></PRE>

<P>where <I>queue_length</I> is the size of the incoming buffer. If the buffer has room, incoming requests for connections are added to the buffer and the application can deal with them in the order of reception. If the buffer is full, the connection request is rejected.

<BR>

<P>After the server has used listen to set up the incoming connection request queue, the accept function is used to actually wait for a connection. The format of the function is

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">accept(<I>socket</I>, <I>address</I>, <I>length</I>)</FONT></PRE>

<P><I>socket</I> is the socket on which to accept requests; <I>address</I> is a pointer to a structure similar to Figure 14.1; and <I>length</I> is a pointer to an integer showing the length of the address.

<BR>

<P>When a connection request is received, the protocol places the address of the client in the memory location indicated by the address parameter, and the length of that address in the length location. It then creates a new socket that has the client and server connected together, sending back the socket description to the client. The socket on which the request was received remains open for other connection requests. This enables multiple requests for a connection to be processed, whereas if that socket was closed down with each connection request, only one client/server process could be handled at a time.

<BR>

<P>One possible special occurrence must be handled on UNIX systems. It is possible for a single process to wait for a connection request on multiple sockets. This reduces the number of processes that monitor sockets, thereby lowering the amount of overhead the machine uses. To provide for this type of process, the select function is used. The format of the function is

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">select(<I>num_desc</I>, <I>in_desc</I>, <I>out_desc</I>, <I>excep_desc</I>, <I>timeout</I>)</FONT></PRE>

<P><I>num_desc</I> is the number of sockets or descriptors that are monitored; <I>in_desc</I> and <I>out_desc</I> are pointers to a bit mask that indicates the sockets or file descriptors to monitor for input and output, respectively; <I>excep_desc</I> is a pointer to a bit mask that specifies the sockets or file descriptors to check for exception conditions; and <I>timeout</I> is a pointer to an integer that indicates how long to wait (a value of 0 indicates forever). To use the select function, a server creates all the necessary sockets first, then calls select to determine which ones are for input, output, and exceptions.

<BR>

<BR>

<A ID="E69E186" NAME="E69E186"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Getting Status Information</B></FONT></CENTER></H4>

<BR>

<P>Several status functions are used to obtain information about a connection. They can be used at any time, although they are typically used to establish the integrity of a connection in case of problems or to control the behavior of the socket.

<BR>

<P>The status functions require the name of the local connection, and they return a set of information, which might include the local and remote socket names, local connection name, receive and send window states, number of buffers waiting for an acknowledgment, number of buffers waiting for data, and current values for the urgent state, precedence, security, and timeout variables. Most of this information is read from the Transmission Control Block (TCB). The format of the information and the exact contents vary slightly, depending on the implementation.

<BR>

<P>The function getsockopt enables an application to query the socket for information. The function format is

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">getsockopt(<I>socket</I>, <I>level</I>, <I>option_id</I>, <I>option_result</I>, <I>length</I>)</FONT></PRE>

<P><I>socket</I> is the number of the socket; <I>level</I> indicates whether the function refers to the socket itself or the protocol that uses it; <I>option_id</I> is a single integer that identifies the type of information requested; <I>option_result</I> is a pointer to a memory location where the function should place the result of the query; and <I>length</I> is the length of the result.

<BR>

<P>The corresponding setsockopt function lets the application set a value for the socket. The function's format is the same as getsockopt except that <I>option_result</I> points to the value that is to be set, and <I>length</I> is the length of the value.

<BR>

<P>Two functions provide information about the local address of a socket. The getpeername function returns the address of the remote end. The getsockname function returns the local address of a socket. They have the following formats:

<BR>

<PRE>

<FONT COLOR="#000080">getpeername(<I>socket</I>, <I>destination</I>_<I>address</I>, <I>address</I>_<I>length</I>)

getsockname(<I>socket</I>, <I>local_address</I>, <I>address_length</I>)</FONT></PRE>

<P>The addresses in both functions are pointers to a structure of the format shown in Figure 14.1.

<BR>

<P>Two host name functions for BSD UNIX are gethostname and sethostname, which enable an application to obtain the name of the host and set the host name (if permissions allow). Their formats are as follows:

<BR>

<PRE>

<FONT COLOR="#000080">sethostname(<I>name</I>, <I>length</I>)

gethostname(<I>name</I>, <I>length</I>)</FONT></PRE>

<P>The <I>name</I> is the address of an array that holds the name, and the <I>length</I> is an integer that gives the name's length.

<BR>

<P>A similar set of functions provides for domain names. The functions setdomainname and getdomainname enable an application to obtain or set the domain names. Their formats are

<BR>

<PRE>

<FONT COLOR="#000080">setdomainname(<I>name</I>, <I>length</I>)

getdomainname(<I>name</I>, <I>length</I>)</FONT></PRE>

<P>The parameters are the same as with the sethostname and gethostname functions, except for the format of the name (which reflects domain name format).

<BR>

<BR>

<A ID="E69E187" NAME="E69E187"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Closing a Connection</B></FONT></CENTER></H4>

<BR>

<P>The close function closes a connection. It requires only the local connection name to complete the process. It also takes care of the TCB and releases any variable created by the connection. No output is generated.

<BR>

<P>The close function is initiated with the call

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">close(<I>socket</I>)</FONT></PRE>

<P>where the socket name is required. If an application terminates abnormally, the operating system closes all sockets that were open prior to the termination.

<BR>

<BR>

<A ID="E69E188" NAME="E69E188"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Aborting a Connection</B></FONT></CENTER></H4>

<BR>

<P>The abort function instructs TCP to discard all data that currently resides in send and receive buffers and close the connection. It takes the local connection name as input. No output is generated. This function can be used in case of emergency shutdown routines, or in case of a fatal failure of the connection or associated software.

<BR>

<P>The abort function is usually implemented by the close() call, although some special instructions might be available with different implementations.

<BR>

<BR>

<A ID="E69E189" NAME="E69E189"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>UNIX Forks</B></FONT></CENTER></H4>

<BR>

<P>UNIX has two system calls that can affect sockets: fork and exec. Both are frequently used by UNIX developers because of their power. (In fact, forks are one of the most powerful tools UNIX offers, and one that most other operating systems lack.) For simplicity, I deal with the two functions as though they perform the same task.

<BR>

<P>A fork call creates a copy of the existing application as a new process and starts executing it. The new process has all the original's file descriptors and socket information. This can cause a problem if the application programmer didn't take into account the fact that two (or more) processes try to use the same socket (or file) simultaneously. Therefore, applications that can fork have to take into account potential conflicts and code around them by checking the status of shared sockets.

<BR>

<P>The operating system itself keeps a table of each socket and how many processes have access to it. An internal counter is incremented or decremented with each process's open or close function call for the socket. When the last process using a socket is terminated, the socket is permanently closed. This prevents one forked process from closing a socket when its original is still using it.

<BR>

<BR>

<A ID="E68E128" NAME="E68E128"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Summary</B></FONT></CENTER></H3>

<BR>

<P>Today you have seen the basic functions performed by the socket API during establishment of a TCP or UDP call. You have also seen the functions that are available to application programmers. Although the treatment has been at a high level, you should be able to see that working with sockets is not a complex, confusing task. Indeed, socket programming is surprisingly easy once you have tried it.

<BR>

<P>Not everyone wants to write TCP or UDP applications, of course. However, understanding the basics of the socket API helps in understanding the protocol and troubleshooting. If you are interested in programming sockets, one of the best books on the subject is <I>UNIX Network </I><I>Programming, </I>by W. Richard Stevens (Macmillan).

<BR>

<BR>

<A ID="E68E129" NAME="E68E129"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Q&amp;A</B></FONT></CENTER></H3>

<BR>

<P><B>What is the socket interface used for?</B>

<BR>

<P>The socket interface enables you to write applications that make optimal use of the TCP/IP family of protocols. Without it, you would need another layer of application to translate your program's calls to TCP/IP calls.

<BR>

<P><B>What is the difference between blocking and nonblocking functions?</B>

<BR>

<P>A blocking function waits for the function to terminate before enabling the application to continue. A nonblocking function enables the application to continue executing while the function is performed. Both have important uses in applications.

<BR>

<P><B>What does binding do?</B>

<BR>

<P>Binding makes a logical connection between a socket and the application. Without it, the application couldn't access the socket.

<BR>

<P><B>What happens when an active </B><B>open</B><B> command is executed?</B>

<BR>

<P>An active open command creates a socket and binds it, then issues a connect call to identify the IP address and port. The active open command then tries to establish communications.

<BR>

<P><B>What is the difference between an </B><B>abort</B><B> and a </B><B>close</B><B> operation?</B>

<BR>

<P>A close operation closes a connection. An abort abandons whatever communications are currently underway and closes the connection. With an abort, any information in receive buffers is discarded.

<BR>

<BR>

<A ID="E68E130" NAME="E68E130"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Quiz</B></FONT></CENTER></H3>

<BR>

<OL>

<LI>What are the six basic socket commands?

<BR></LI>

<BR>

<LI>A Transmission Control Block performs what function?

<BR></LI>

<BR>

<LI>What is the difference between an unspecified passive open and a fully specified passive open?

<BR></LI>

<BR>

<LI>What command displays status information about a socket?

<BR></LI>

<BR>

<LI>What is a fork?

<BR></LI>

<BR>

</OL>

<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="#I0" TARGET="_self"><IMG SRC="blantop.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blantop.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Page Top"></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>




</BODY></HTML>