📄 ch12.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 12 -- Using Sockets</TITLE>
<META NAME="GENERATOR" CONTENT="Mozilla/3.0b5aGold (WinNT; I) [Netscape]">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 12</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>Using Sockets</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#AVeryBriefIntroductiontoSockets" >A Very Brief Introduction to Sockets</A>
<LI><A HREF="#PerlFunctionsforWorkingwithProtocol" >Perl Functions for Working with Protocols</A>
<LI><A HREF="#SocketPrimitives" >Socket Primitives</A>
<UL>
<LI><A HREF="#socket" >socket()</A>
<LI><A HREF="#ThebindSystemCall" >The bind() System Call</A>
<LI><A HREF="#ThelistenandacceptSystemCalls" >The listen() and accept() System Calls</A>
<LI><A HREF="#TheconnectSystemCall" >The connect() System Call</A>
</UL>
<LI><A HREF="#ConnectionOrientedServersinPerl" >Connection-Oriented Servers in Perl</A>
<LI><A HREF="#Theh2phScript" >The h2ph Script</A>
<LI><A HREF="#UsingSocketpm" >Using Socket.pm</A>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
Perl offers a host of functions for accessing the socket-based
interprocess communication facilities. The system facilities on
UNIX systems are available to the Perl programmer and, thus, can
be called directly from Perl scripts. Given the information in
this chapter, you should be able to write your own client/server
Perl applications using sockets.
<H2><A NAME="AVeryBriefIntroductiontoSockets"><FONT SIZE=5 COLOR=#FF0000>A
Very Brief Introduction to Sockets</FONT></A></H2>
<P>
Perl offers a host of functions for accessing the socket functions
on a UNIX-based system. It's essential to cover some of the important
features of interprocess communications in order to understand
how the model fits in with Perl. Given the limited amount of space
in a chapter, I cannot hope to possibly cover all the bases for
socket programming. However, I will cover the basics, and you
should have enough information from this chapter to develop your
own client/server model using Perl.
<P>
The absolutely best reference to doing <I>anything</I> with network
programming is<I> UNIX Network Programming</I> by W. Richard Stevens
(Prentice Hall, ISBN 0-13-949876-1). The book provides programs
and C code samples in excruciating detail that cover all aspects
of network programming. BSD UNIX gives many ways to open, use,
and close sockets, and this book covers them all. The examples
presented in this chapter are derived from the C code in this
book. Perl is great in that often you can do a line-by-line mapping
of cookbook socket and network function calls in C to equivalent
calls in Perl. (Someone ought to write an interpreter!) Please
refer to Stevens's book for a more detailed discussion on internetworking
with sockets.
<P>
In general, socket programming is based on the client/server model.
A <I>client</I> is a program that makes requests to the server
to get responses. A <I>server</I> is simply another program that
responds to these requests. The server either can reside on the
same computer as the client or can be a computer somewhere on
a connecting network. Sending requests and receiving replies to
transfer the data between clients and servers is the <I>protocol</I>
with which they communicate.
<P>
A common protocol in the UNIX world is the TCP/IP protocol. The
Internet Protocol (IP) handles the transfer of data from one computer
to another over a network. The Transport Control Protocol (TCP)
offers a set of reliability and connection functions that IP does
not offer. Messages sent via TCP/IP from one computer are acknowledged
by the other computer. The acknowledgment of sent messages increases
reliability, but at the cost of efficiency. The User Datagram
Protocol (UDP) is like TCP in sending messages, but has no acknowledge
feature as such. This makes UDP faster when receiving acknowledgments
is not as high of a priority as sending acknowledgments back.
UDP tends to be less reliable than TCP because the sender UDP
does not have a guarantee that the sent message even made it to
the remote site. Think of UDP as the regular U.S. Mail service
and TCP/IP as a registered letter service. Although the U.S. Mail
is generally very reliable, a sender does not really know if the
recipient did indeed receive the letter. As far as you are concerned,
the letter got to its destination, and if it didn't the recipient
will request another. This is similar to UDP. Send a message,
and if it doesn't make it over to the destination-no problem-the
recipient will ask again. When sending important documents though,
you would most likely want to get a confirmation from the recipient.
In this case, you'd normally use a registered letter service,
which will return a signed receipt. The signed receipt is your
"acknowledgment" in TCP/IP.
<P>
Most applications using TCP or UDP have a port number that they
talk on to get the service they want. A machine assigns one unique
port number to an application. Port numbers are standardized enough
to identify the type of service being used. On UNIX systems, the
file <TT><FONT FACE="Courier">/etc/services</FONT></TT> maintains
a list of services offered on each port. Port numbers between
1 and 255 are reserved for standard, well-known applications.
There are well-known port numbers that everyone recognizes: for
example, port 80 for the World Wide Web's server daemons, the
<TT><FONT FACE="Courier">nameserver</FONT></TT> on port 42, <TT><FONT FACE="Courier">sendmail</FONT></TT>
at port 25, and so on. In all cases, avoid using socket 0, since
it's interpreted differently on different systems.
<P>
Two computers talk to each other via a network <I>circuit</I>.
Each circuit is uniquely identified by a combination of two numbers
called a <I>socket</I>. Basically a socket is the IP address of
the machine plus the port number used by the TCP software.
<P>
There are two ways of defining the address: If two processes talking
to each other are on the same machine, the "family"
of protocols is referred to as <TT><FONT FACE="Courier">AF_UNIX</FONT></TT>.
If the communicators are on different machines, this is referred
to as the <TT><FONT FACE="Courier">AF_INET</FONT></TT> family.
In the <TT><FONT FACE="Courier">AF_UNIX</FONT></TT> family, sockets
are assigned a pathname in the directory tree. In the <TT><FONT FACE="Courier">AF_INET</FONT></TT>
family, they are assigned a port number and application number.
Using <TT><FONT FACE="Courier">AF_INET</FONT></TT>, you can talk
to processes on the same machine, but <TT><FONT FACE="Courier">AF_UNIX</FONT></TT>
is reserved for the same machine.
<P>
There are two types of sockets about which you should know:
<UL>
<LI><TT><FONT FACE="Courier">SOCK_STREAM</FONT></TT>. This type
of socket utilizes TCP and provides a reliable way of transferring
data across a network. The <TT><FONT FACE="Courier">SOCK_STREAM</FONT></TT>
process requires the establishment of a connection before the
transfer of data and the disestablishment of the connection after
all transfers are complete. While connected, the client and server
can send data to and receive data from each other. Thus, <TT><FONT FACE="Courier">SOCK_STREAM</FONT></TT>
is a connection-oriented protocol.
<LI><TT><FONT FACE="Courier">SOCK_DGRAM</FONT></TT>. This type
of socket utilizes UDP and provides a faster way of transmitting
than TCP, but does not require the establishment of a connection
for it to be able to transfer data. The destination socket may
not even exist. The <TT><FONT FACE="Courier">SOCK_DGRAM</FONT></TT>
is referred to as a connectionless protocol.
</UL>
<P>
There is a socket on both the sending and receiving machine. Clients
send on their sockets, and servers listen on their sockets and
accept connections when necessary. The IP address of each machine
is guaranteed to be unique by design, and the port numbers are
unique to each machine. This implies the socket numbers, which
are a combination of these two unique numbers, will also be unique
across the network. This allows two applications to communicate
using unique socket numbers.
<P>
With Perl, it's possible to get access to these socket and network
functions. Most of this chapter has a UNIX slant to it. On NT
machines, you'll be dealing with the Remote Access Server and
WinSock under Windows. Please refer to the technical notes from
Microsoft for more information on WinSock programming.
<H2><A NAME="PerlFunctionsforWorkingwithProtocol"><FONT SIZE=5 COLOR=#FF0000>Perl
Functions for Working with Protocols</FONT></A></H2>
<P>
The protocols available on your UNIX system are located in the
<TT><FONT FACE="Courier">/etc/protocols</FONT></TT> file. You
have to use three functions to read this file. The function <TT><FONT FACE="Courier">setprotoent()</FONT></TT>
starts the listing process. The Perl function <TT><FONT FACE="Courier">getprotoent()</FONT></TT>
reads one line from the <TT><FONT FACE="Courier">/etc/protocols</FONT></TT>
file and lists it for you. Successive calls to the function read
successive lines. Finally, a call to <TT><FONT FACE="Courier">endprotoent()</FONT></TT>
stops the listening process. A simple way to have all the protocols
available to your Perl script is to use the script shown in Listing
12.1.
<HR>
<BLOCKQUOTE>
<B>Listing 12.1. Showing available protocols.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">1 #!/usr/bin/perl<BR>
2 #<BR>
3 # List all the protocols in this machine<BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -