- Shopping Bag ( 0 items )
So you've learned Perl, but you're getting frustrated. Perhaps you've taken on a larger project than the ones you're used to. Or you want to add a user interface or a networking component. Or you need to do more complicated error trapping.Whether your knowledge of Perl is casual or deep, this book will make you a more accomplished programmer. Here you can learn the complex techniques for production-ready Perl programs. This book explains methods for manipulating data and objects that may have looked like magic ...
Ships from: Austin, TX
Usually ships in 1-2 business days
Ships from: fallbrook, CA
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
So you've learned Perl, but you're getting frustrated. Perhaps you've taken on a larger project than the ones you're used to. Or you want to add a user interface or a networking component. Or you need to do more complicated error trapping.Whether your knowledge of Perl is casual or deep, this book will make you a more accomplished programmer. Here you can learn the complex techniques for production-ready Perl programs. This book explains methods for manipulating data and objects that may have looked like magic before. Furthermore, it sets Perl in the context of a larger environment, giving you the background you need for dealing with networks, databases, and GUIs. The discussion of internals helps you program more efficiently and embed Perl within C or C within Perl.Major topics covered include:
This publication advances your Perl scripting. skills beyond the bounds of elementary script constructs, and into the realm of production-ready scripts within the context of network, database and GUI environments. Covers such advanced features as run-time evaluation, persistence, code generation, and the innards of the Perl interpreter. Discusses data references, complex data structure implementation, typeglobs, symbol tables, structure references and closures. Reviews object-oriented programming, then dives into the essence of this publication, sockets networking, RPC implementation, and Perl/Tk user interface scripting. Examines template driven code generation, and shows how to extend Perl and embed scripts.
Networking is the second of four important technologies that we discuss in this book; the others are user interfaces, persistence, and code generation. This chapter, like the other three, is as much about the technology as it is about Perl's support for it. Andrew Tanenbaum's textbook on computer networks [21 is a wonderful introduction to computer networking. 0 also rate it as one of the best computer books ever written.) This chapter provides just enough introduction to networks to work with Perl, sockets, and TCP/IP.
Mail (paper and electronic) and telephones are two distinct forms of communication. A telephone conversation is connection-oriented, because the caller and the called "own" the line (have a continuous link) until the end of the conversation. Connection-oriented communication guarantees message delivery, preserves the order in which messages are sent, and allows a stream of data to be sent. Mail, in contrast, is a connectionless mode of transfer, which transports information in packets (or datagrams) and gives no guarantees about message delivery and the order in which the packets are received. It has a higher overhead because each packet identifies its sender and the intended receiver; in contrast, a connectionoriented conversation proceeds without further ado, once the parties have identified themselves. Computer networks offer you a similar choice of connection versus connectionless mode of data transfer. It must be mentioned that there are connectionless protocols such as reliable UDP that do offer guaranteed delivery and sequence integrity.
The networking world assigns each computer an internet address, also called an IP address (short for Internet Protocol), a sequence of four bytes typically written in a dot sequence, like this: 184.108.40.206. (This will change with IPv6, because the world is fast running out of four-byte IP addresses.) just as you have convenient phone aliases such as 1-800-FLOWERS, computers are often given unique aliases, such as www.yahoo.com. Now, many programs can run on one machine, and it is not enough to deliver a message to the machine: it has to be handed over to the appropriate application program running on that machine. A program can ask for one or more ports to be opened, the equivalent of a private mailbox or telephone extension. To send a message to a program, you need its full address: its machine name and the port on which it is listening. Standard applications such as ftp, telnet, and mail actually come in pairs; for example, the ftp program you use talks to a counterpart server program called ftpd (ftp daemon) on the remote computer. Such server programs listen on standard port numbers; when you type www.yahoo.com on your web browser, the browser automatically connects to port 80 on that machine, where it assumes the corresponding web server to be listening. Port numbers 1-1024 are reserved for standard, well-known Internet applications. Many platforms reserve the name "localhost" (and the address 127.0.0.1) to mean the machine on which the program is running.
Once assigned a socket, your program has a choice of using a connectionoriented protocol called TCP/IP (Transport Control Protocol/IP) or a connectionless one, UDP/IP (User Datagram Protocol). Clearly, sender and receiver must use the same protocol. The TCP/IP model is usually preferred over UDP because it provides for data sequencing, end-to-end reliability (checksums, positive acknowledgments, time-outs), and end-to-end flow control (if the sender is sending data faster than the receiver can handle it, it will block the sender when the receiver's buffers are full). If the communications medium is very good, such as a LAN, UDP may perform much better because it doesn't spend time accounting for the worst case. In a production system, however, you can never really take a chance, so we will stick to TCP in this chapter.
The socket abstraction and API were introduced in BSD 4.2 to provide a uniform interface over different types of protocols (there are others besides TCP and UDP), and, depending on the protocol used, a socket behaves like either a telephone receiver or a mailbox. In either case, it takes one socket on each side to make a conversation (which is why sockets are also known as communications endpoints). The socket API allows you to specify the domain of the communicating entities-the "Unix domain" is 'used for processes on the same machine, and the "Internet domain" is used for processes on different machines. This chapter examines the more generally accepted (and useful) "Internet domain" option.
TLI (Transport Layer Interface), another API introduced in System V (Release 3.0, 1986), provides a very similar-looking alternative to the socket abstraction, but because it is not as widely used as the BSD socket interface, we will not discuss it in this chapter.
Socket API and IO::Socket
Perl provides native support for sockets and a module called Socket to smooth some of the rough edges associated with the native socket call. It turns out that there are still a large number of options to deal with, and since most applications use a fairly standard set of options, we instead use a truly convenient module called I0::Socket, which is built on Socket.
This section uses this module to build a sending and receiving program.
just as you would ask the phone company for a telephone number and a physical handset, both sender and receiver ask the module to create sockets. Sockets, like telephones, are bidirectional endpoints: once a connection is established, either side can send and receive data, as long as there is an understanding between the two programs about the direction of communication.
Because only the receiving side needs to have a well-known address, we create a receiving socket as follows:
Chapter 1: Data References and Anonymous Storage
Chapter 2: Implementing Complex Data Structures
Chapter 3: Typeglobs and Symbol Tables
Chapter 4: Subroutine References and Closures
Chapter 5: Eval
Chapter 6: Modules
Chapter 7: Object-Oriented Programming
Chapter 8: Object Orientation: The Next Few Steps
Chapter 9: Tie
Chapter 10: Persistence
Chapter 11: Implementing Object Persistence
Chapter 12: Networking with Sockets
Chapter 13: Networking: Implementing RPC
Chapter 14: User Interfaces with Tk
Chapter 15: GUI Example: Tetris
Chapter 16: GUI Example: Man Page Viewer
Chapter 17: Template-DrivenCode Generation
Chapter 18: Extending Perl: A First Course
Chapter 19: Embedding Perl:The Easy Way
Chapter 20: Perl Internals
Tk Widget Reference