unx40.htm

来自「Unix Unleashed, Third Edition is written」· HTM 代码 · 共 1,873 行 · 第 1/5 页

<BR>-l &lt;<I>ttylabel</I>&gt; specifies the label of the desired record in the /etc/ttydefs file described earlier in this section



<BR>-s specifies the name of the service provider program on the tty port (for example, login, cu, and so on)</PRE>

<P>At this point, all of the necessary elements that you will need to implement terminal and modem connections have been covered. If you are anxious to try implementing, you may jump right ahead to the section titled &quot;Connecting Terminals and 
Modems.&quot; Otherwise, continue reading the next section, which explains the listen port monitor.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I27" NAME="I27">

<FONT SIZE=4><B>The</B><B><I> listen</I></B><B> Port Monitor</B>

<BR></FONT></A></CENTER></H3>

<P>listen is a network port monitoring process that is invoked and controlled by sac. It runs on any transport provider (most commonly TCP), and supports two classes of service: a class of general services, such as RFS and network printing; and terminal 
login services for terminals trying to access the system by connecting directly to the network. Like ttymon, listen can support and monitor multiple ports, with each assigned a network service to take care of. Once invoked, the listen port monitor 
initializes port services as defined in its /etc/saf/&lt;<I>pmtag</I>&gt;/_pmtab file. It then monitors the ports for service connection requests. Once a request is received on a listen port, the associated service (for example, printing) is invoked and 
the user is connected to it.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I28" NAME="I28">

<FONT SIZE=3><B>Port Service Addressing</B>

<BR></FONT></A></CENTER></H4>

<P>During TCP/IP setup (refer to Chapter 37 for more on TCP/IP), your system will have been assigned an Internet address that is 8 hexadecimal digits long, with each pair of digits represented by one octet. Stations shipping requests across the network to 

your system use this address to reach your machine's doorstep only. Because your machine is more likely to be configured to respond to a variety of service requests, there arises the requirement to assign unique addresses to port services. This allows the 

listen port monitor to support multiple port services. Upon adding a listen port service, you are required to provide the applicable address to nlsadmin (the listen port monitor administrative command). For this reason, you are provided with the address 
format shown in Figure 40.2.

<BR></P>

<P>

<BR><B><A HREF="40unx02.gif">Figure 40.2. </B><B><I>listen</I></B><B>'s port service address </B><B>format.</A></B>

<BR></P>

<P>The elements of the address format are as follows:

<BR></P>

<PRE>

<BR><I>Family address</I>: This is four digits long. It is always set to 0020.



<BR><I>Port address</I>: This is four digits long and is the port service-specific address. For example, listenS5 print server is assigned x0ACE, whereas listenBSD print server is assigned x0203.



<BR><I>Internet address</I>: This is the IP address you assigned to the system upon installing TCP/IP. It is eight digits long.



<BR><I>Reserved</I>: This is 16 digits long and is reserved for future use. Currently, it is set to 16 zeros.</PRE>

<P>As an example, assume that the IP address of your system is 100.0.0.1 and that you want to set up a listen port to take care of print service requests sent across the network by BSD systems. The port address in hexadecimal notation then becomes

<BR></P>

<PRE>00020203640000010000000000000000</PRE>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP:</B> To avoid dealing with decimal-to-hex conversions to figure out the hexadecimal equivalent to your host IP address, you can use the lpsystem -A. Figure 40.3 demonstrates the use of lpsystem -A output in 

order to figure out the host's IP address in hexadecimal notation.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>

<BR><B><A HREF="40unx03.gif">Figure 40.3. Using </B><B><I>lpsystem -A </I></B><B>to find the </B><B>hexadecimal equivalent of the  host's IP address.</A></B>

<BR></P>

<P>It will be shown later in this section how to pass this address to pmadm when creating the port service.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I29" NAME="I29">

<FONT SIZE=3><B>The </B><B><I>listen</I></B><B> Port Monitor Administrative Command </B><B><I>nlsamdin</I></B>

<BR></FONT></A></CENTER></H4>

<P>nlsadmin is the administrative command specific to the listen port monitor. nlsadmin can be used to add, configure, and change the status of a port monitor. Also, it can be used to start or kill the listener process. Mostly it will be used in command 
substitution mode, in order to supply some of the required arguments to both sacadm (the sac administrative command) and pmadm. Options that you specify on the command line will determine which arguments to pass, and in what format.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I30" NAME="I30">

<FONT SIZE=3><B>Creating a </B><B><I>listen</I></B><B> Port Monitor</B>

<BR></FONT></A></CENTER></H4>

<P>To create a ttymon port monitor, you use the sacadm command. The same applies to creating a listen port monitor. Instead of using ttyadm, however, you must use nlsadmin in command substitution mode in order to pass some of the required information to 
sacadm. The use of sacadm in creating a listen port monitor is as follows:

<BR></P>

<PRE>#sacadm -a -p&lt;pmtag&gt; -t listen -c&lt;&quot;command&quot;&gt; -v`nlsadmin -V`\

[-n&lt;count&gt;] [-fd|x] [-y&lt;&quot;comment&quot;&gt;]</PRE>

<P>All options bear the same significance described in earlier sections (refer back to the &quot;Creating a Port Monitor&quot; section for a review). Note in particular, the use of `nlsadmin -V` in order to pass the port monitor's version to sacadm. Also 
note that the -c option specifies the program invoked to bring up the listen port monitor. The program is /usr/lib/saf/listen. Once a port monitor is created, an entry pertaining to it is added to sac's administrative file /etc/saf/_sactab.

<BR></P>

<P>As an example, the following sacadm command creates a listen port monitor with pmtag tcp. Note that the program filename to invoke is /usr/lib/saf/listen, and sac is required to try up to three times to bring up the port monitor, should it ever fail 
respond to sac's polls.

<BR></P>

<PRE>sacadm -a -t listen -p tcp -c &quot;/usr/lib/saf/listen&quot; \

-v'nlsadmin - V' -n3</PRE>

<H4 ALIGN="CENTER">

<CENTER><A ID="I31" NAME="I31">

<FONT SIZE=3><B>Managing </B><B><I>listen</I></B><B> Port Monitors</B>

<BR></FONT></A></CENTER></H4>

<P>To check on the availability of listen port monitors, enter

<BR></P>

<PRE>#sacadm -l -t listen</PRE>

<P>As a result, you see a listing of all listen port monitors currently controlled by sac on your system. The listing looks like the following:

<BR></P>

<PRE>PMTAG    PMTYPE    FLGS    RCNT    STATUS    COMMAND

tcp        listen    -    3    ENABLED    /usr/lib/saf/listen -m inet/tcp0 tcp</PRE>

<P>For a review of the interpretation of the preceding listing, refer to the &quot;Checking the Status of the Port Monitor&quot; section.

<BR></P>

<P>In order to enable, disable, or remove a port monitor, enter sacadm with -e, -d, or -r respectively, as described earlier in this chapter.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I32" NAME="I32">

<FONT SIZE=3><B>Creating a </B><B><I>listen</I></B><B> Port Service</B>

<BR></FONT></A></CENTER></H4>

<P>To create a listen port service, use the pmadm command. The syntax follows.

<BR></P>

<PRE>#pmadm -a -p&lt;pmtag&gt; -s&lt;svctag&gt; [-i id] -v 'nlsadmin -V'\

 -m&quot;'nlsadmin options'&quot; -y&quot;comment&quot;</PRE>

<P>The following command adds a new port service to a port monitor with pmtag tcp:

<BR></P>

<PRE>#pmadm -a -p tcp -s lpd -i root -v 'nlsadmin -V'\

 -m&quot;'nlsadmin -o /var/spool/lp/fifos/listenBSD -A \

\x00020203640000020000000000000000'&quot;</PRE>

<P>The preceding command demonstrates the use of the port address discussed earlier. The port address described in the preceding example configures the port to accept printing requests sent by BSD clients across the network.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I33" NAME="I33">

<FONT SIZE=3><B>Managing Port Services</B>

<BR></FONT></A></CENTER></H5>

<P>To check on the status of a port service, enter

<BR></P>

<PRE>#pmadm -p&lt;pmtag&gt; -s&lt;svctag&gt; -l</PRE>

<P>To enable it, enter

<BR></P>

<PRE>#pmadm -p&lt;pmtag&gt; -s&lt;svctag&gt; -e</PRE>

<P>whereas to disable it, enter

<BR></P>

<PRE>#pmadm -p&lt;pmtag&gt; -s&lt;svctag&gt; -d</PRE>

<P>and to remove it, enter

<BR></P>

<PRE>#pmadm -p&lt;pmtag&gt; -s&lt;svctag&gt; -r</PRE>

<H3 ALIGN="CENTER">

<CENTER><A ID="I34" NAME="I34">

<FONT SIZE=4><B>Connecting Terminals and Modems</B>

<BR></FONT></A></CENTER></H3>

<P>UNIX has very powerful built-in serial communications capabilities. Administrators can make use of them in order to offer local terminal connection services, as well as across-the-telephone wire services. Services across the wire include remote terminal 

login, file transfer capabilities, and electronic mail exchange. Those services are provided by utilities such as uucp and cu, which are part of the Basic Networking Utilities (BNU) that comes with your UNIX operating system. A full treatment of UUCP 
utilities is provided in Chapter 43.

<BR></P>

<P>In this section, the concepts and steps to set up for both modem and terminal connections are presented. A properly wired and configured serial interface is a basic requirement that is common to both types of services. Once this requirement is 
fulfilled, you can proceed to implementing the necessary additional steps to take care of modem and terminal connections.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I35" NAME="I35">

<FONT SIZE=3><B>Making the Connection</B>

<BR></FONT></A></CENTER></H4>

<P>To make the serial connection, prepare for the physical connection, determine the availability of associated resources, and create the port service.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I36" NAME="I36">

<FONT SIZE=3><B>Preparing for the Physical Connection</B>

<BR></FONT></A></CENTER></H5>

<P>In this step, you are primarily involved in readying the cable that will connect the modem, or the user's terminal to the UNIX system. RS232C/D is the standard interface that most hardware platforms use to connect devices. So that you can understand the 

how and why of different cable arrangements, a brief examination of the standard is provided.

<BR></P>

<P>RS232D/C defines the interface between so-called data circuit-terminating equipment (DTE) and data circuit communication equipment (DCE). In practical terms, and for the purposes of this section, this means that it defines the physical interface between 

a computer (the DTE) and the modem (the DCE). The interface defines four aspects of the physical layer. These are electrical, mechanical, functional, and procedural.

<BR></P>

<P>The electrical specification defines how data is electrically represented on the wire. Because computer data is binary in its raw form, the specification describes what voltage level represents which logical level.

<BR></P>

<P>The mechanical specification describes the mechanics of the connection, including the connector type and the number of pins supported. A DB-25 connector is specified for the RS232C/D interface. The industry introduced another de facto standard, however. 

This is the DB-9 connector most commonly found on PC workstations.

<BR></P>

<P>The functional specification defines the pinout of the connector (that is, what each pin stands for).

<BR></P>

<P>The procedural specification defines the handshake mechanism that should precede, accompany, and terminate the exchange of data between the DTE and DCE.

<BR></P>

<P>Figure 40.4 shows the wiring diagram and corresponding pin definition of the DB25-to-DB25 cable, which is normally used to connect a DTE to a DCE. Figure 40.5 shows the wiring diagram of a DB9-to-DB25 cable. Following is a description of the most 
commonly used circuits. Because pin definitions are not the same for both types of connectors, the description refers to the circuit name rather than the pin number.

<BR></P>

<P>

<BR><B><A HREF="40unx04.gif">Figure 40.4. Wiring diagram and corresponding pin </B><B>definition of a DB25-to-DB25 RS232C/D straight-through cable.</A></B>

<BR></P>

<P>

<BR><B><A HREF="40unx05.gif">Figure 40.5. Wiring diagram of a DB9-to-DB25 </B><B>straight-through cable.</A></B>

<BR></P>

<P>SG provides the common return path for both the transmit (TD) and receive (RD) circuits.

<BR></P>

<P>DTR and DSR are asserted by both the computer and modem, respectively, to indicate readiness to exchange data. Both circuits must be asserted before any other activity can occur across the interface. At this point, the computer may attempt to dial 
another computer by passing the dialing command string to the modem.

<BR></P>

<P>DCD is asserted by the modem if it successfully connects at the remote end. It is interpreted by the computer as an indication of a successful connection. This circuit has to remain asserted for the duration of the call.

<BR></P>

<P>TD and RD are the transmit and receive circuits, respectively.

<BR></P>

<P>Any time the computer wants to transmit it asserts the RTS circuit and waits for permission to do so from the modem, by virtue of asserting the CTS circuit. This usage of the RTS/CTS circuit pair applies to the half-duplex mode of communications. In 
full-duplex communications, RTS and CTS circuits are used to control the flow of data between the DTE and the DCE devices. The DTE drops its RTS circuit in order to request the DCE to stop sending data on DTE's receive circuit. Likewise, the CTS is dropped 

by the DCE in order to request the DTE to stop sending data on the transmit circuit.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION:</B> In cases in which one end of the cable is a DB-25 connector, whereas the opposite end is a DB-9, the cable must be wired as shown in Figure 40.6.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>

<BR><B><A HREF="40unx06.gif">Figure 40.6. Null modem wiring arrangements </B><B>corresponding to different combinations of connectors.</A></B>

<BR></P>

<P>Connecting a computer directly to a terminal (that is, a DTE-to-DTE type of connection) is a tricky business, but easy to understand. Because RS232C/D defines the interface strictly between a DTE and DCE, many vendors and users have developed variations 

on a cabling trick that allows DTE-to-DTE connection. This trick is called the null modem cable. The underlying idea is to convince both ends of the connection that they are indeed talking to modems directly connected to them. Figure 40.6 shows two 
diagrams depicting the same cabling trick corresponding to different combinations of connectors.

<BR></P>

<P>When the interface pinout was described, it was done from the DTE perspective. This means that if you look at the interface from the DCE perspective, some pins bear quite the opposite significance. For example, DTEs send and receive pins are DCEs 
receive and send, respectively. It is not, therefore, hard to imagine what would happen if you were to attempt connecting two DTEs using a direct cable. Data emerging from both devices on directly connected transmit circuits would be endlessly colliding, 
while they are hopelessly waiting for an impulse to occur on the wire connecting their receiving circuits. To remedy this situation, the send and receive circuits are cross-wired. Also, recall that whenever the computer asserts its RTS circuit, it is 
ask