📄 0600-0602.html
字号:
<HTML>
<HEAD>
<TITLE>Developer.com - Online Reference Library - 0672311739:RED HAT LINUX 2ND EDITION:Network Programming</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311739 //-->
<!-- TITLE=RED HAT LINUX 2ND EDITION //-->
<!-- AUTHOR=DAVID PITTS ET AL //-->
<!-- PUBLISHER=MACMILLAN //-->
<!-- IMPRINT=SAMS PUBLISHING //-->
<!-- PUBLICATION DATE=1998 //-->
<!-- CHAPTER=28 //-->
<!-- PAGES=0583-0604 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0597-0599.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0603-0606.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-600"><P>Page 600</P></A>
<P>
This process is called multiplexing and is the loop at the core of many network-aware
applications, although the actual mechanics can be concealed by sophisticated
dispatchers or notifiers that trigger events based on which connection is ready to be read from or written to.
Something else lacking in Listing 28.10 is the minimum amount of error checking and signal
handling that cleans up connections when a quit signal is received.
</P>
<H3><A NAME="ch28_ 12">
I/O Multiplexing with TCP
</A></H3>
<P>In order to demonstrate TCP multiplexing, it is necessary to create different programs for
the client and server. The server, tcplisten, is shown in Listing 28.11 and is the one that
requires the most scrutiny. The client, tcptalk, is on the book's CD-ROM and won't be reprinted
here because it resembles the server so closely. I'll explain how the client works as I cover the server.
</P>
<P>Listing 28.11. tcplisten.
</P>
<!-- CODE //-->
<PRE> 1: #!/usr/bin/perl
2:
3: use Socket;
4: require "./network.pl";
5:
6: $NETFD = makelisten($ARGV[0]);
7:
8: while (1) {
9:
10: $paddr = accept(NEWFD, $NETFD);
11:
12: ($port, $iaddr) = sockaddr_in($paddr);
13:
14: print "Accepted connection from ", inet_ntoa($iaddr),
15: " on port number ", $port, "\n";
16:
17: $rin = "";
18: vec($rin, fileno(STDIN), 1) = 1;
19: vec($rin, fileno(NEWFD), 1) = 1;
20:
21: while (1)
22:
23: select $ready = $rin, undef, undef, undef;
24:
25: if (vec($ready, fileno(STDIN), 1) == 1) {
26: sysread STDIN, $mesg, 256;
27: syswrite NEWFD, $mesg, length($mesg);
28: }
29: if (vec($ready, fileno(NEWFD), 1) == 1) {
30: $bytes = sysread NEWFD, $netmsg, 256;
31: if ($bytes == 0) { goto EXIT; }
32: print "$netmsg";
33: $netmsg = "";
34: }
35: }
36: EXIT: close NEWFD;
37: print "Client closed connection\n";
</PRE>
<!-- END CODE //-->
<A NAME="PAGENUM-601"><P>Page 601</P></A>
<!-- CODE SNIP //-->
<PRE>
38: }
39:
40: close $NETFD;
</PRE>
<!-- END CODE SNIP //-->
<P>The server creates a listening socket in line 6 and then immediately enters a
while loop. At the top of the loop is a call to
accept(). By placing this in a loop, the server can repeatedly
accept client connections, like our other TCP server. The listen socket,
$NETFD, can accept more than one connection, regardless of the state of any file descriptors cloned from it using
accept().
</P>
<P>accept() returns the address of the connecting client. You use this address in lines 12 and
14 to print out some information about the client. In line 12, you use
sockaddr_in() to reverse engineer the fully qualified address back into a network address and a service port. Then
you use print to display it on the terminal. S the call to
inet_ntoa() embedded in the print command.
</P>
<P>Then you set up for a select() loop using almost the same code as Listing 28.10. There
is, however, a key difference in the way the network connection is handled. You are reading
with sysread() again, but you are saving the return value.
</P>
<P>When a peer closes a TCP connection, the other program receives an end-of-file (EOF)
indication. This is signified by marking the socket as ready for reading and returning zero
bytes when it is read. By saving the number of bytes returned by
sysread(), you are able to detect a closed connection and record it and then return to
accept() at the top of the outer while loop.
</P>
<P>The following is a server session, followed by the client session that is communicating with
it. The client is tcptalk, which is included on the CD-ROM, as is a copy of
tcplisten.
</P>
<!-- CODE //-->
<PRE>$ ./tcplisten test
Accepted connection from 10.8.100.20 on port number 29337
Hello, world.
Goodbye, cruel....
Client closed connection
$ ./tcptalk iest test
Hello, world.
Goodbye, cruel....
^C
</PRE>
<!-- END CODE //-->
<H3><A NAME="ch28_ 13">
Advanced Topics
</A></H3>
<P>During the course of this chapter, I've alluded to a few advanced topics. Let's take some
time out to touch on a few of them individually.
</P>
<P>One of the biggest issues for TCP applications is
queueing messages. Depending on the nature of the data being transferred, the network bandwidth available, and the rate at which
clients can keep pace with the data being delivered, data can queue up. Experienced application
designers generally specify a queueing mechanism and the rules associated with it as part of
the initial product description.
</P>
<A NAME="PAGENUM-602"><P>Page 602</P></A>
<P>UDP applications have to wrestle with data reliability, and some schemes rely on message
sequence numbers. All nodes involved in a transaction (or a series of transactions) keep track
of a numbering scheme. When a node receives a message out of order, it sends a negative
acknowledgment for the message that it missed. This sort of scheme greatly reduces traffic when
everything goes well but can become very expensive when things fall out of sequence.
</P>
<P>Some applications can use asynchronous I/O in order to service network traffic and other
tasks in a single application. This scheme registers interest in a signal that can be delivered
whenever a file descriptor has data ready to be read. This method is not recommended, though,
because only one signal can be delivered for all file descriptors (so
select() would still be needed) and because signals are not reliable.
</P>
<P>Security is always a big issue, regardless of the protocols being used. UDP is being used less
and less over the Internet, essentially because it is very easy to impersonate a host when no
connections are required. Even TCP connections, however, can be "spoofed" by someone who has
an understanding of the Internet Protocol and WAN technology. For that reason,
applications that require a high level of security don't rely on TCP to keep them secure and tend to
use encryption and authentication technology.
</P>
<H3><A NAME="ch28_ 14">
Summary
</A></H3>
<P>This chapter covers a lot of ground in a short time. I introduced essential networking
concepts, such as the components of a network address and how an application can form one
from symbolic host and service names by looking them up with the resolver functions.
</P>
<P>Sockets, the most commonly used network programming interface, are used throughout
the chapter. This API enables us to treat network connections and data streams like files,
which shortens the network programming learning curve and also makes applications easy to
design and maintain.
</P>
<P>I also discussed the two most commonly used protocols on the Internet, TCP and UDP.
TCP, a connection-oriented protocol, has very robust reliability mechanisms that allow an
application to use the network without worrying too much about whether the messages it is
sending are reaching the other end. This reliability does carry a price, however, because TCP
comes with a certain degree of overhead in terms of speed and bandwidth. TCP also supports
only two-way communication, so clients and servers that need to communicate with more than
one node have to maintain multiple connections, which can be expensive.
</P>
<P>UDP, on the other hand, is a connectionless, datagram-oriented protocol. It comes with
virtually no overhead, but applications have to provide their own reliability mechanisms. UDP
also supports broadcast, which can be convenient, but also represents a potential problem for
some networks.
</P>
<P><CENTER>
<a href="0597-0599.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0603-0606.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -