diff --git a/en_US.ISO8859-1/books/arch-handbook/Makefile b/en_US.ISO8859-1/books/arch-handbook/Makefile index acf0c62b67..2c1d61d0e6 100644 --- a/en_US.ISO8859-1/books/arch-handbook/Makefile +++ b/en_US.ISO8859-1/books/arch-handbook/Makefile @@ -1,38 +1,42 @@ # -# $FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/Makefile,v 1.3 2001/05/11 10:27:00 murray Exp $ +# $FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/Makefile,v 1.4 2001/05/14 02:52:41 murray Exp $ # # Build the FreeBSD Developers' Handbook. # MAINTAINER=asmodai@FreeBSD.org DOC?= book FORMATS?= html-split INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= +# Images +IMAGES= sockets/layers.eps sockets/sain.eps sockets/sainfill.eps sockets/sainlsb.eps sockets/sainmsb.eps sockets/sainserv.eps sockets/serv.eps sockets/serv2.eps sockets/slayers.eps + # # SRCS lists the individual SGML files that make up the document. Changes # to any of these files will force a rebuild # # SGML content SRCS= book.sgml SRCS+= tools/chapter.sgml SRCS+= secure/chapter.sgml SRCS+= locking/chapter.sgml +SRCS+= sockets/chapter.sgml +SRCS+= ipv6/chapter.sgml SRCS+= isa/chapter.sgml SRCS+= pci/chapter.sgml SRCS+= usb/chapter.sgml SRCS+= scsi/chapter.sgml SRCS+= x86/chapter.sgml SRCS+= vm/chapter.sgml SRCS+= dma/chapter.sgml -SRCS+= ipv6/chapter.sgml # Entities DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/en_US.ISO8859-1/books/arch-handbook/book.sgml b/en_US.ISO8859-1/books/arch-handbook/book.sgml index a9c8c3212b..aa8d19ac6f 100644 --- a/en_US.ISO8859-1/books/arch-handbook/book.sgml +++ b/en_US.ISO8859-1/books/arch-handbook/book.sgml @@ -1,518 +1,511 @@ %bookinfo; %man; %chapters; %authors; %mailing-lists; ]> FreeBSD Developers' Handbook The FreeBSD Documentation Project August 2000 2000 2001 The FreeBSD Documentation Project &bookinfo.legalnotice; Welcome to the Developers' Handbook. This manual is a work in progress and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the &a.doc;. The latest version of this document is always available from the FreeBSD World Wide Web server. It may also be downloaded in a variety of formats and compression options from the FreeBSD FTP server or one of the numerous mirror sites. Introduction Developing on FreeBSD This will need to discuss FreeBSD as a development platform, the vision of BSD, architectural overview, layout of /usr/src, history, etc. Thank you for considering FreeBSD as your development platform! We hope it will not let you down. The BSD Vision Architectural Overview The Layout of /usr/src The complete source code to FreeBSD is available from our public CVS repository. The source code is normally installed in /usr/src which contains the following subdirectories. Directory Description bin/ Source for files in /bin contrib/ Source for files from contributed software. crypto/ DES source etc/ Source for files in /etc games/ Source for files in /usr/games gnu/ Utilities covered by the GNU Public License include/ Source for files in /usr/include kerberosIV/ Source for Kerbereros version IV kerberos5/ Source for Kerbereros version 5 lib/ Source for files in /usr/lib libexec/ Source for files in /usr/libexec release/ Files required to produce a FreeBSD release sbin/ Source for files in /sbin secure/ FreeSec sources share/ Source for files in /sbin sys/ Kernel source files tools/ Tools used for maintenance and testing of FreeBSD usr.bin/ Source for files in /usr/bin usr.sbin/ Source for files in /usr/sbin Basics &chap.tools; &chap.secure; Kernel History of the Unix Kernel Some history of the Unix/BSD kernel, system calls, how do processes work, blocking, scheduling, threads (kernel), context switching, signals, interrupts, modules, etc. &chap.locking; Memory Management &chap.vm; &chap.dma; I/O System UFS UFS, FFS, Ext2FS, JFS, inodes, buffer cache, labeling, locking, metadata, soft-updates, LFS, portalfs, procfs, vnodes, memory sharing, memory objects, TLBs, caching Interprocess Communication Signals Signals, pipes, semaphores, message queues, shared memory, ports, sockets, doors Networking - - Sockets - - Sockets, bpf, IP, TCP, UDP, ICMP, OSI, bridging, - firewalling, NAT, switching, etc - - - + &chap.sockets; &chap.ipv6; Network Filesystems AFS AFS, NFS, SANs etc] Terminal Handling Syscons Syscons, tty, PCVT, serial console, screen savers, etc Sound OSS OSS, waveforms, etc Device Drivers &chap.driverbasics; &chap.isa; &chap.pci; &chap.scsi; &chap.usb; NewBus This chapter will talk about the FreeBSD NewBus architecture. Architectures &chap.x86; Alpha Talk about the architectural specifics of FreeBSD/alpha. Explanation of allignment errors, how to fix, how to ignore. Example assembly language code for FreeBSD/alpha. IA-64 Talk about the architectural specifics of FreeBSD/ia64. Debugging Truss various descriptions on how to debug certain aspects of the system using truss, ktrace, gdb, kgdb, etc Compatibility Layers Linux Linux, SVR4, etc Appendices Dave A Patterson John L Hennessy 1998Morgan Kaufmann Publishers, Inc. 1-55860-428-6 Morgan Kaufmann Publishers, Inc. Computer Organization and Design The Hardware / Software Interface 1-2 W. Richard Stevens 1993Addison Wesley Longman, Inc. 0-201-56317-7 Addison Wesley Longman, Inc. Advanced Programming in the Unix Environment 1-2 Marshall Kirk McKusick Keith Bostic Michael J Karels John S Quarterman 1996Addison-Wesley Publishing Company, Inc. 0-201-54979-4 Addison-Wesley Publishing Company, Inc. The Design and Implementation of the 4.4 BSD Operating System 1-2 Aleph One Phrack 49; "Smashing the Stack for Fun and Profit" Chrispin Cowan Calton Pu Dave Maier StackGuard; Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks Todd Miller Theo de Raadt strlcpy and strlcat -- consistent, safe string copy and concatenation. diff --git a/en_US.ISO8859-1/books/arch-handbook/chapters.ent b/en_US.ISO8859-1/books/arch-handbook/chapters.ent index 044535d282..618db82b44 100644 --- a/en_US.ISO8859-1/books/arch-handbook/chapters.ent +++ b/en_US.ISO8859-1/books/arch-handbook/chapters.ent @@ -1,61 +1,62 @@ + diff --git a/en_US.ISO8859-1/books/developers-handbook/Makefile b/en_US.ISO8859-1/books/developers-handbook/Makefile index acf0c62b67..2c1d61d0e6 100644 --- a/en_US.ISO8859-1/books/developers-handbook/Makefile +++ b/en_US.ISO8859-1/books/developers-handbook/Makefile @@ -1,38 +1,42 @@ # -# $FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/Makefile,v 1.3 2001/05/11 10:27:00 murray Exp $ +# $FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/Makefile,v 1.4 2001/05/14 02:52:41 murray Exp $ # # Build the FreeBSD Developers' Handbook. # MAINTAINER=asmodai@FreeBSD.org DOC?= book FORMATS?= html-split INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= +# Images +IMAGES= sockets/layers.eps sockets/sain.eps sockets/sainfill.eps sockets/sainlsb.eps sockets/sainmsb.eps sockets/sainserv.eps sockets/serv.eps sockets/serv2.eps sockets/slayers.eps + # # SRCS lists the individual SGML files that make up the document. Changes # to any of these files will force a rebuild # # SGML content SRCS= book.sgml SRCS+= tools/chapter.sgml SRCS+= secure/chapter.sgml SRCS+= locking/chapter.sgml +SRCS+= sockets/chapter.sgml +SRCS+= ipv6/chapter.sgml SRCS+= isa/chapter.sgml SRCS+= pci/chapter.sgml SRCS+= usb/chapter.sgml SRCS+= scsi/chapter.sgml SRCS+= x86/chapter.sgml SRCS+= vm/chapter.sgml SRCS+= dma/chapter.sgml -SRCS+= ipv6/chapter.sgml # Entities DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/en_US.ISO8859-1/books/developers-handbook/book.sgml b/en_US.ISO8859-1/books/developers-handbook/book.sgml index a9c8c3212b..aa8d19ac6f 100644 --- a/en_US.ISO8859-1/books/developers-handbook/book.sgml +++ b/en_US.ISO8859-1/books/developers-handbook/book.sgml @@ -1,518 +1,511 @@ %bookinfo; %man; %chapters; %authors; %mailing-lists; ]> FreeBSD Developers' Handbook The FreeBSD Documentation Project August 2000 2000 2001 The FreeBSD Documentation Project &bookinfo.legalnotice; Welcome to the Developers' Handbook. This manual is a work in progress and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the &a.doc;. The latest version of this document is always available from the FreeBSD World Wide Web server. It may also be downloaded in a variety of formats and compression options from the FreeBSD FTP server or one of the numerous mirror sites. Introduction Developing on FreeBSD This will need to discuss FreeBSD as a development platform, the vision of BSD, architectural overview, layout of /usr/src, history, etc. Thank you for considering FreeBSD as your development platform! We hope it will not let you down. The BSD Vision Architectural Overview The Layout of /usr/src The complete source code to FreeBSD is available from our public CVS repository. The source code is normally installed in /usr/src which contains the following subdirectories. Directory Description bin/ Source for files in /bin contrib/ Source for files from contributed software. crypto/ DES source etc/ Source for files in /etc games/ Source for files in /usr/games gnu/ Utilities covered by the GNU Public License include/ Source for files in /usr/include kerberosIV/ Source for Kerbereros version IV kerberos5/ Source for Kerbereros version 5 lib/ Source for files in /usr/lib libexec/ Source for files in /usr/libexec release/ Files required to produce a FreeBSD release sbin/ Source for files in /sbin secure/ FreeSec sources share/ Source for files in /sbin sys/ Kernel source files tools/ Tools used for maintenance and testing of FreeBSD usr.bin/ Source for files in /usr/bin usr.sbin/ Source for files in /usr/sbin Basics &chap.tools; &chap.secure; Kernel History of the Unix Kernel Some history of the Unix/BSD kernel, system calls, how do processes work, blocking, scheduling, threads (kernel), context switching, signals, interrupts, modules, etc. &chap.locking; Memory Management &chap.vm; &chap.dma; I/O System UFS UFS, FFS, Ext2FS, JFS, inodes, buffer cache, labeling, locking, metadata, soft-updates, LFS, portalfs, procfs, vnodes, memory sharing, memory objects, TLBs, caching Interprocess Communication Signals Signals, pipes, semaphores, message queues, shared memory, ports, sockets, doors Networking - - Sockets - - Sockets, bpf, IP, TCP, UDP, ICMP, OSI, bridging, - firewalling, NAT, switching, etc - - - + &chap.sockets; &chap.ipv6; Network Filesystems AFS AFS, NFS, SANs etc] Terminal Handling Syscons Syscons, tty, PCVT, serial console, screen savers, etc Sound OSS OSS, waveforms, etc Device Drivers &chap.driverbasics; &chap.isa; &chap.pci; &chap.scsi; &chap.usb; NewBus This chapter will talk about the FreeBSD NewBus architecture. Architectures &chap.x86; Alpha Talk about the architectural specifics of FreeBSD/alpha. Explanation of allignment errors, how to fix, how to ignore. Example assembly language code for FreeBSD/alpha. IA-64 Talk about the architectural specifics of FreeBSD/ia64. Debugging Truss various descriptions on how to debug certain aspects of the system using truss, ktrace, gdb, kgdb, etc Compatibility Layers Linux Linux, SVR4, etc Appendices Dave A Patterson John L Hennessy 1998Morgan Kaufmann Publishers, Inc. 1-55860-428-6 Morgan Kaufmann Publishers, Inc. Computer Organization and Design The Hardware / Software Interface 1-2 W. Richard Stevens 1993Addison Wesley Longman, Inc. 0-201-56317-7 Addison Wesley Longman, Inc. Advanced Programming in the Unix Environment 1-2 Marshall Kirk McKusick Keith Bostic Michael J Karels John S Quarterman 1996Addison-Wesley Publishing Company, Inc. 0-201-54979-4 Addison-Wesley Publishing Company, Inc. The Design and Implementation of the 4.4 BSD Operating System 1-2 Aleph One Phrack 49; "Smashing the Stack for Fun and Profit" Chrispin Cowan Calton Pu Dave Maier StackGuard; Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks Todd Miller Theo de Raadt strlcpy and strlcat -- consistent, safe string copy and concatenation. diff --git a/en_US.ISO8859-1/books/developers-handbook/chapters.ent b/en_US.ISO8859-1/books/developers-handbook/chapters.ent index 044535d282..618db82b44 100644 --- a/en_US.ISO8859-1/books/developers-handbook/chapters.ent +++ b/en_US.ISO8859-1/books/developers-handbook/chapters.ent @@ -1,61 +1,62 @@ + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.sgml new file mode 100644 index 0000000000..2444ee40af --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.sgml @@ -0,0 +1,1786 @@ + + Sockets + + This chapter was written by + &a.stanislav; + + + Synopsis + + BSD sockets take interprocess + communications to a new level. It is no longer necessary for the + communicating processes to run on the same machine. They still + can, but they do not have to. + + Not only do these processes not have to run on the same + machine, they do not have to run under the same operating + system. Thanks to BSD sockets, your FreeBSD + software can smoothly cooperate with a program running on a + Macintosh, another one running on a Sun workstation, yet another + one running under Windows 2000, all connected with an + Ethernet-based local area network. + + But your software can equally well cooperate with processes + running in another building, or on another continent, inside a + submarine, or a space shuttle. + + It can also cooperate with processes that are not part of a + computer (at least not in the strict sense of the word), but of + such devices as printers, digital cameras, medical equipment. + Just about anything capable of digital communications. + + + + + Networking and Diversity + + We have already hinted on the diversity + of networking. Many different systems have to talk to each + other. And they have to speak the same language. They also have + to understand the same language the same + way. + + People often think that body language + is universal. But it is not. Back in my early teens, my father + took me to Bulgaria. We were sitting at a table in a park in + Sofia, when a vendor approached us trying to sell us some + roasted almonds. + + I had not learned much Bulgarian by then, so, instead of + saying no, I shook my head from side to side, the + universal body language for + no. The vendor quickly started serving us + some almonds. + + I then remembered I had been told that in Bulgaria shaking + your head sideways meant yes. Quickly, I + started nodding my head up and down. The vendor noticed, took + his almonds, and walked away. To an uninformed observer, I did + not changed the body language: I continued using the language of + shaking and nodding my head. What changed was the + meaning of the body language. At first, the + vendor and I interpreted the same language as having completely + different meaning. I had to adjust my own interpretation of that + language so the vendor would understand. + + It is the same with computers: The same symbols may have + different, even outright opposite meaning. Therefore, for + two computers to understand each other, they must not only + agree on the same language, but on the + same interpretation of the language. + + + + + Protocols + + While various programming languages tend to have complex + syntax and use a number of multi-letter reserved words (which + makes them easy for the human programmer to understand), the + languages of data communications tend to be very terse. Instead + of multi-byte words, they often use individual + bits. There is a very convincing reason + for it: While data travels inside your + computer at speeds approaching the speed of light, it often + travels considerably slower between two computers. + + Because the languages used in data communications are so + terse, we usually refer to them as + protocols rather than languages. + + As data travels from one computer to another, it always uses + more than one protocol. These protocols are + layered. The data can be compared to the + inside of an onion: You have to peel off several layers of + skin to get to the data. This is best + illustrated with a picture: + + + + + + + + +----------------+ +| Ethernet | +|+--------------+| +|| IP || +||+------------+|| +||| TCP ||| +|||+----------+||| +|||| HTTP |||| +||||+--------+|||| +||||| PNG ||||| +|||||+------+||||| +|||||| Data |||||| +|||||+------+||||| +||||+--------+|||| +|||+----------+||| +||+------------+|| +|+--------------+| ++----------------+ + + + + Protocol Layers + + + + In this example, we are trying to get an image from a web + page we are connected to via an Ethernet. + + The image consists of raw data, which is simply a sequence + of RGB values that our software can process, + i.e., convert into an image and display on our monitor. + + Alas, our software has no way of knowing how the raw data is + organized: Is it a sequence of RGB values, or + a sequence of grayscale intensities, or perhaps of + CMYK encoded colors? Is the data represented + by 8-bit quanta, or are they 16 bits in size, or perhaps 4 bits? + How many rows and columns does the image consist of? Should + certain pixels be transparent? + + I think you get the picture... + + To inform our software how to handle the raw data, it is + encoded as a PNG file. It could be a + GIF, or a JPEG, but it is + a PNG. + + And PNG is a protocol. + + At this point, I can hear some of you yelling, + No, it is not! It is a file + format! + + Well, of course it is a file format. But from the + perspective of data communications, a file format is a protocol: + The file structure is a language, a terse + one at that, communicating to our process + how the data is organized. Ergo, it is a + protocol. + + Alas, if all we received was the PNG + file, our software would be facing a serious problem: How is it + supposed to know the data is representing an image, as opposed + to some text, or perhaps a sound, or what not? Secondly, how is + it supposed to know the image is in the PNG + format as opposed to GIF, or + JPEG, or some other image format? + + To obtain that information, we are using another protocol: + HTTP. This protocol can tell us exactly that + the data represents an image, and that it uses the + PNG protocol. It can also tell us some other + things, but let us stay focused on protocol layers here. + + + So, now we have some data wrapped in the PNG + protocol, wrapped in the HTTP protocol. + How did we get it from the server? + + By using TCP/IP over Ethernet, that is + how. Indeed, that is three more protocols. Instead of + continuing inside out, I am now going to talk about Ethernet, + simply because it is easier to explain the rest that way. + + Ethernet is an interesting system of connecting computers in + a local area network + (LAN). Each computer has a network + interface card (NIC), which has a + unique 48-bit ID called its + address. No two Ethernet + NICs in the world have the same address. + + + These NICs are all connected with each + other. Whenever one computer wants to communicate with another + in the same Ethernet LAN, it sends a message + over the network. Every NIC sees the + message. But as part of the Ethernet + protocol, the data contains the address of + the destination NIC (among other things). So, + only one of all the network interface cards will pay attention + to it, the rest will ignore it. + + But not all computers are connected to the same + network. Just because we have received the data over our + Ethernet does not mean it originated in our own local area + network. It could have come to us from some other network (which + may not even be Ethernet based) connected with our own network + via the Internet. + + All data is transfered over the Internet using + IP, which stands for Internet + Protocol. Its basic role is to let us know where in + the world the data has arrived from, and where it is supposed to + go to. It does not guarantee we will + receive the data, only that we will know where it came from + if we do receive it. + + Even if we do receive the data, IP does + not guarantee we will receive various chunks of data in the same + order the other computer has sent it to us. So, we can receive + the center of our image before we receive the upper left corner + and after the lower right, for example. + + It is TCP (Transmission Control + Protocol) that asks the sender to resend any lost + data and that places it all into the proper order. + + All in all, it took five different + protocols for one computer to communicate to another what an + image looks like. We received the data wrapped into the + PNG protocol, which was wrapped into the + HTTP protocol, which was wrapped into the + TCP protocol, which was wrapped into the + IP protocol, which was wrapped into the + Ethernet protocol. + + Oh, and by the way, there probably were several other + protocols involved somewhere on the way. For example, if our + LAN was connected to the Internet through a + dial-up call, it used the PPP protocol over + the modem which used one (or several) of the various modem + protocols, et cetera, et cetera, et cetera... + + As a developer you should be asking by now, + How am I supposed to handle it + all? + + Luckily for you, you are not supposed + to handle it all. You are supposed to + handle some of it, but not all of it. Specifically, you need not + worry about the physical connection (in our case Ethernet and + possibly PPP, etc). Nor do you need to handle + the Internet Protocol, or the Transmission Control + Protocol. + + In other words, you do not have to do anything to receive + the data from the other computer. Well, you do have to + ask for it, but that is almost as simple as + opening a file. + + Once you have received the data, it is up to you to figure + out what to do with it. In our case, you would need to + understand the HTTP protocol and the + PNG file structure. + + To use an analogy, all the internetworking protocols become + a gray area: Not so much because we do not understand how it + works, but because we are no longer concerned about it. The + sockets interface takes care of this gray area for us: + + + + + + + + +----------------+ +|xxxxEthernetxxxx| +|+--------------+| +||xxxxxxIPxxxxxx|| +||+------------+|| +|||xxxxxTCPxxxx||| +|||+----------+||| +|||| HTTP |||| +||||+--------+|||| +||||| PNG ||||| +|||||+------+||||| +|||||| Data |||||| +|||||+------+||||| +||||+--------+|||| +|||+----------+||| +||+------------+|| +|+--------------+| ++----------------+ + + + + Sockets Covered Protocol Layers + + + + We only need to understand any protocols that tell us how to + interpret the data, not how to + receive it from another process, nor how to + send it to another process. + + + + + The Sockets Model + + BSD sockets are built on the basic Unix + model: Everything is a file. In our + example, then, sockets would let us receive an HTTP + file, so to speak. It would then be up to us to + extract the PNG file + from it. + + + Because of the complexity of internetworking, we cannot just + use the open system call, or + the open() C function. Instead, we need to + take several steps to opening a socket. + + Once we do, however, we can start treating the + socket the same way we treat any + file descriptor: We can + read from it, write to + it, pipe it, and, eventually, + close it. + + + + + Essential Socket Functions + + While FreeBSD offers different functions to work with + sockets, we only need four to + open a socket. And in some cases we only need + two. + + + The Client-Server Difference + + Typically, one of the ends of a socket-based data + communication is a server, the other is a + client. + + + The Common Elements + + + <function>socket</function> + + The one function used by both, clients and servers, is + &man.socket.2;. It is declared this way: + + +int socket(int domain, int type, int protocol); + + + The return value is of the same type as that of + open, an integer. FreeBSD allocates + its value from the same pool as that of file handles. + That is what allows sockets to be treated the same way as + files. + + The domain argument tells the + system what protocol family you want + it to use. Many of them exist, some are vendor specific, + others are very common. They are declared in + sys/socket.h. + + Use PF_INET for + UDP, TCP and other + Internet protocols. + + Five values are defined for the + type argument, again, in + sys/socket.h. All of them start with + SOCK_. The most + common one is SOCK_STREAM, which + tells the system you are asking for a reliable + stream delivery service. + + If you asked for SOCK_DGRAM, you + would be requesting a connectionless datagram + delivery service. + + If you wanted to be in charge of the low-level + protocols (such as IP), or even network + interfaces (e.g., the Ethernet), you would need to specify + SOCK_RAW. + + Finally, the protocol argument + depends on the previous two arguments, and is not always + meaningful. In that case, use 0 for + its value. + + + The Unconnected Socket + + Nowhere, in the socket function + have we specified to what other system we should be + connected. Our newly created socket remains + unconnected. + + This is on purpose: To use a telephone analogy, we + have just attached a modem to the phone line. We have + neither told the modem to make a call, nor to answer if + the phone rings. + + + + + + <varname>sockaddr</varname> + + Various functions of the sockets family expect the + address of (or pointer to, to use C terminology) a small + area of the memory. The various C declarations in the + sys/socket.h refer to it as + struct sockaddr. This structure is + declared in the same file: + + +/* + * Structure used by kernel to store most + * addresses. + */ +struct sockaddr { + u_char sa_len; /* total length */ + sa_family_t sa_family; /* address family */ + char sa_data[14]; /* actually longer; address value */ +}; +#define SOCK_MAXADDRLEN 255 /* longest possible addresses */ + + + Please note the vagueness with + which the sa_data field is declared, + just as an array of 14 bytes, with + the comment hinting there can be more than + 14 of them. + + This vagueness is quite deliberate. Sockets is a very + powerful interface. While most people perhaps think of it + as nothing more than the Internet interface—and most + applications probably use it for that + nowadays—sockets can be used for just about + any kind of interprocess + communications, of which the Internet (or, more precisely, + IP) is only one. + + The sys/socket.h refers to the + various types of protocols sockets will handle as + address families, and lists them + right before the definition of + sockaddr: + + +/* + * Address families. + */ +#define AF_UNSPEC 0 /* unspecified */ +#define AF_LOCAL 1 /* local to host (pipes, portals) */ +#define AF_UNIX AF_LOCAL /* backward compatibility */ +#define AF_INET 2 /* internetwork: UDP, TCP, etc. */ +#define AF_IMPLINK 3 /* arpanet imp addresses */ +#define AF_PUP 4 /* pup protocols: e.g. BSP */ +#define AF_CHAOS 5 /* mit CHAOS protocols */ +#define AF_NS 6 /* XEROX NS protocols */ +#define AF_ISO 7 /* ISO protocols */ +#define AF_OSI AF_ISO +#define AF_ECMA 8 /* European computer manufacturers */ +#define AF_DATAKIT 9 /* datakit protocols */ +#define AF_CCITT 10 /* CCITT protocols, X.25 etc */ +#define AF_SNA 11 /* IBM SNA */ +#define AF_DECnet 12 /* DECnet */ +#define AF_DLI 13 /* DEC Direct data link interface */ +#define AF_LAT 14 /* LAT */ +#define AF_HYLINK 15 /* NSC Hyperchannel */ +#define AF_APPLETALK 16 /* Apple Talk */ +#define AF_ROUTE 17 /* Internal Routing Protocol */ +#define AF_LINK 18 /* Link layer interface */ +#define pseudo_AF_XTP 19 /* eXpress Transfer Protocol (no AF) */ +#define AF_COIP 20 /* connection-oriented IP, aka ST II */ +#define AF_CNT 21 /* Computer Network Technology */ +#define pseudo_AF_RTIP 22 /* Help Identify RTIP packets */ +#define AF_IPX 23 /* Novell Internet Protocol */ +#define AF_SIP 24 /* Simple Internet Protocol */ +#define pseudo_AF_PIP 25 /* Help Identify PIP packets */ +#define AF_ISDN 26 /* Integrated Services Digital Network*/ +#define AF_E164 AF_ISDN /* CCITT E.164 recommendation */ +#define pseudo_AF_KEY 27 /* Internal key-management function */ +#define AF_INET6 28 /* IPv6 */ +#define AF_NATM 29 /* native ATM access */ +#define AF_ATM 30 /* ATM */ +#define pseudo_AF_HDRCMPLT 31 /* Used by BPF to not rewrite headers + * in interface output routine + */ +#define AF_NETGRAPH 32 /* Netgraph sockets */ + +#define AF_MAX 33 + + + The one used for IP is + AF_INET. It is a symbol for the constant + 2. + + It is the address family listed + in the sa_family field of + sockaddr that decides how exactly the + vaguely named bytes of sa_data will be + used. + + Specifically, whenever the address + family is AF_INET, we can use + struct sockaddr_in found in + netinet/in.h, wherever + sockaddr is expected: + + +/* + * Socket address, internet style. + */ +struct sockaddr_in { + u_char sin_len; + u_char sin_family; + u_short sin_port; + struct in_addr sin_addr; + char sin_zero[8]; +}; + + + We can visualize its organization this way: + + + + + + + + 0 1 2 3 + +--------+--------+-----------------+ + 0 | 0 | Family | Port | + +--------+--------+-----------------+ + 4 | IP Address | + +-----------------------------------+ + 8 | 0 | + +-----------------------------------+ +12 | 0 | + +-----------------------------------+ + + + + sockaddr_in + + + + The three important fields are + sin_family, which is byte 1 of the + structure, sin_port, a 16-bit value + found in bytes 2 and 3, and sin_addr, a + 32-bit integer representation of the IP + address, stored in bytes 4-7. + + Now, let us try to fill it out. Let us assume we are + trying to write a client for the + daytime protocol, which simply states + that its server will write a text string representing the + current date and time to port 13. We want to use + TCP/IP, so we need to specify + AF_INET in the address family + field. AF_INET is defined as + 2. Let us use the + IP address of 192.43.244.18, which is the time + server of US federal government (time.nist.gov). + + + + + + + + 0 1 2 3 + +--------+--------+-----------------+ + 0 | 0 | 2 | 13 | + +-----------------+-----------------+ + 4 | 192.43.244.18 | + +-----------------------------------+ + 8 | 0 | + +-----------------------------------+ +12 | 0 | + +-----------------------------------+ + + + + Specific example of sockaddr_in + + + + By the way the sin_addr field is + declared as being of the struct in_addr + type, which is defined in + netinet/in.h: + + +/* + * Internet address (a structure for historical reasons) + */ +struct in_addr { + in_addr_t s_addr; +}; + + + In addition, in_addr_t is a 32-bit + integer. + + The 192.43.244.18 is + just a convenient notation of expressing a 32-bit integer + by listing all of its 8-bit bytes, starting with the + most significant one. + + So far, we have viewed sockaddr as + an abstraction. Our computer does not store + short integers as a single 16-bit + entity, but as a sequence of 2 bytes. Similarly, it stores + 32-bit integers as a sequence of 4 bytes. + + Suppose we coded something like this: + + + sa.sin_family = AF_INET; + sa.sin_port = 13; + sa.sin_addr.s_addr = (((((192 << 8) | 43) << 8) | 244) << 8) | 18; + + + What would the result look like? + + Well, that depends, of course. On a Pentium, or other + x86, based computer, it would look like this: + + + + + + + + 0 1 2 3 + +--------+--------+--------+--------+ + 0 | 0 | 2 | 13 | 0 | + +--------+--------+--------+--------+ + 4 | 18 | 244 | 43 | 192 | + +-----------------------------------+ + 8 | 0 | + +-----------------------------------+ +12 | 0 | + +-----------------------------------+ + + + + sockaddr_in on an Intel system + + + + On a different system, it might look like this: + + + + + + + + + 0 1 2 3 + +--------+--------+--------+--------+ + 0 | 0 | 2 | 0 | 13 | + +--------+--------+--------+--------+ + 4 | 192 | 43 | 244 | 18 | + +-----------------------------------+ + 8 | 0 | + +-----------------------------------+ +12 | 0 | + +-----------------------------------+ + + + + sockaddr_in on an MSB system + + + + And on a PDP it might look different yet. But the + above two are the most common ways in use today. + + Ordinarily, wanting to write portable code, + programmers pretend that these differences do not + exist. And they get away with it (except when they code in + assembly language). Alas, you cannot get away with it that + easily when coding for sockets. + + Why? + + Because when communicating with another computer, you + usually do not know whether it stores data most + significant byte (MSB) or + least significant byte + (LSB) byte first. + + You might be wondering, So, will + sockets not handle it for me? + + It will not. + + While that answer may surprise you at first, remember + that the general sockets interface only understands the + sa_len and sa_family + fields of the sockaddr structure. You + do not have to worry about the byte order there (of + course, on FreeBSD sa_family is only 1 + byte anyway, but many other Unix systems do not have + sa_len and use 2 bytes for + sa_family, and expect the data in + whatever order is native to the computer). + + But the rest of the data is just + sa_data[14] as far as sockets + goes. Depending on the address + family, sockets just forwards that data to its + destination. + + Indeed, when we enter a port number, it is because we + want the other computer to know what service we are asking + for. And, when we are the server, we read the port number + so we know what service the other computer is expecting + from us. Either way, sockets only has to forward the port + number as data. It does not interpret it in any way. + + Similarly, we enter the IP address + to tell everyone on the way where to send our data + to. Sockets, again, only forwards it as data. + + That is why, we (the programmers, + not the sockets) have to distinguish + between the byte order used by our computer and a + conventional byte order to send the data in to the other + computer. + + We will call the byte order our computer uses the + host byte order, or just the + host order. + + There is a convention of sending the multi-byte data + over IP + MSB first. This, + we will refer to as the network byte + order, or simply the network + order. + + Now, if we compiled the above code for an Intel based + computer, our host byte order would + produce: + + + + + + + + 0 1 2 3 + +--------+--------+--------+--------+ + 0 | 0 | 2 | 13 | 0 | + +--------+--------+--------+--------+ + 4 | 18 | 244 | 43 | 192 | + +-----------------------------------+ + 8 | 0 | + +-----------------------------------+ +12 | 0 | + +-----------------------------------+ + + + + Host byte order on an Intel system + + + + But the network byte order + requires that we store the data MSB + first: + + + + + + + + 0 1 2 3 + +--------+--------+--------+--------+ + 0 | 0 | 2 | 0 | 13 | + +--------+--------+--------+--------+ + 4 | 192 | 43 | 244 | 18 | + +-----------------------------------+ + 8 | 0 | + +-----------------------------------+ +12 | 0 | + +-----------------------------------+ + + + + Network byte order + + + + Unfortunately, our host order is + the exact opposite of the network + order. + + We have several ways of dealing with it. One would be + to reverse the values in our code: + + + + sa.sin_family = AF_INET; + sa.sin_port = 13 << 8; + sa.sin_addr.s_addr = (((((18 << 8) | 244) << 8) | 43) << 8) | 192; + + + This will trick our compiler + into storing the data in the network byte + order. In some cases, this is exactly the way + to do it (e.g., when programming in assembly + language). In most cases, however, it can cause a + problem. + + Suppose, you wrote a sockets-based program in C. You + know it is going to run on a Pentium, so you enter all + your constants in reverse and force them to the + network byte order. It works + well. + + Then, some day, your trusted old Pentium becomes a + rusty old Pentium. You replace it with a system whose + host order is the same as the + network order. You need to recompile + all your software. All of your software continues to + perform well, except the one program you wrote. + + You have since forgotten that you had forced all of + your constants to the opposite of the host + order. You spend some quality time tearing out + your hair, calling the names of all gods you ever heard + of (and some you made up), hitting your monitor with a + nerf bat, and performing all the other traditional + ceremonies of trying to figure out why something that has + worked so well is suddenly not working at all. + + Eventually, you figure it out, say a couple of swear + words, and start rewriting your code. + + Luckily, you are not the first one to face the + problem. Someone else has created the &man.htons.3; and + &man.htonl.3; C functions to convert a + short and long + respectively from the host byte + order to the network byte + order, and the &man.ntohs.3; and &man.ntohl.3; + C functions to go the other way. + + On MSB-first + systems these functions do nothing. On + LSB-first systems + they convert values to the proper order. + + So, regardless of what system your software is + compiled on, your data will end up in the correct order + if you use these functions. + + + + + + + Client Functions + + Typically, the client initiates the connection to the + server. The client knows which server it is about to call: + It knows its IP address, and it knows the + port the server resides at. It is akin + to you picking up the phone and dialing the number (the + address), then, after someone answers, + asking for the person in charge of wingdings (the + port). + + + <function>connect</function> + + Once a client has created a socket, it needs to + connect it to a specific port on a remote system. It uses + &man.connect.2;: + + +int connect(int s, const struct sockaddr *name, socklen_t namelen); + + + The s argument is the socket, i.e., + the value returned by the socket + function. The name is a pointer to + sockaddr, the structure we have talked + about extensively. Finaly, namelen + informs the system how many bytes are in our + sockaddr structure. + + If connect is successful, it + returns 0. Otherwise it returns + -1 and stores the error code in + errno. + + There are many reasons why + connect may fail. For example, with + an attempt to an Internet connection, the + IP address may not exist, or it may be + down, or just too busy, or it may not have a server + listening at the specified port. Or it may outright + refuse any request for specific + code. + + + + + Our First Client + + We now know enough to write a very simple client, one + that will get current time from 192.43.244.18 and print it to + stdout. + + +/* + * daytime.c + * + * Programmed by G. Adam Stanislav + */ +#include <stdio.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> + +int main() { + register int s; + register int bytes; + struct sockaddr_in sa; + char buffer[BUFSIZ+1]; + + if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { + perror("socket"); + return 1; + } + + bzero(&sa, sizeof sa); + + sa.sin_family = AF_INET; + sa.sin_port = htons(13); + sa.sin_addr.s_addr = htonl((((((192 << 8) | 43) << 8) | 244) << 8) | 18); + if (connect(s, (struct sockaddr *)&sa, sizeof sa) < 0) { + perror("connect"); + close(s); + return 2; + } + + while ((bytes = read(s, buffer, BUFSIZ)) > 0) + write(1, buffer, bytes); + + close(s); + return 0; +} + + + Go ahead, enter it in your editor, save it as + daytime.c, then compile and run + it: + + +&prompt.user; cc -O3 -o daytime daytime.c +&prompt.user; ./daytime + +52079 01-06-19 02:29:25 50 0 1 543.9 UTC(NIST) * +&prompt.user; + + + In this case, the date was June 19, 2001, the time was + 02:29:25 UTC. Naturally, your results + will vary. + + + + + + + Server Functions + + The typical server does not initiate the + connection. Instead, it waits for a client to call it and + request services. It does not know when the client will + call, nor how many clients will call. It may be just sitting + there, waiting patiently, one moment, The next moment, it + can find itself swamped with requests from a number of + clients, all calling in at the same time. + + The sockets interface offers three basic functions to + handle this. + + + <function>bind</function> + + Ports are like extensions to a phone line: After you + dial a number, you dial the extension to get to a specific + person or department. + + There are 65535 IP ports, but a + server usually processes requests that come in on only one + of them. It is like telling the phone room operator that + we are now at work and available to answer the phone at a + specific extension. We use &man.bind.2; to tell sockets + which port we want to serve. + + +int bind(int s, const struct sockaddr *addr, socklen_t addrlen); + + + Beside specifying the port in addr, + the server may include its IP + address. However, it can just use the symbolic constant + INADDR_ANY to indicate it will serve all + requests to the specified port regardless of what its + IP address is. This symbol, along with + several similar ones, is declared in + netinet/in.h + + +#define INADDR_ANY (u_int32_t)0x00000000 + + + Suppose we were writing a server for the + daytime protocol over + TCP/IP. Recall that + it uses port 13. Our sockaddr_in + structure would look like this: + + + + + + + + 0 1 2 3 + +--------+--------+--------+--------+ + 0 | 0 | 2 | 0 | 13 | + +--------+--------+--------+--------+ + 4 | 0 | + +-----------------------------------+ + 8 | 0 | + +-----------------------------------+ +12 | 0 | + +-----------------------------------+ + + + + Example Server sockaddr_in + + + + + + <function>listen</function> + + To continue our office phone analogy, after you have + told the phone central operator what extension you will be + at, you now walk into your office, and make sure your own + phone is plugged in and the ringer is turned on. Plus, you + make sure your call waiting is activated, so you can hear + the phone ring even while you are talking to someone. + + The server ensures all of that with the &man.listen.2; + function. + + +int listen(int s, int backlog); + + + In here, the backlog variable tells + sockets how many incoming requests to accept while you are + busy processing the last request. In other words, it + determines the maximum size of the queue of pending + connections. + + + + + <function>accept</function> + + After you hear the phone ringing, you accept the call + by answering the call. You have now established a + connection with your client. This connection remains + active until either you or your client hang up. + + The server accepts the connection by using the + &man.accept.2; function. + + +int accept(int s, struct sockaddr *addr, socklen_t *addrlen); + + + Note that this time addrlen is a + pointer. This is necessary because in this case it is the + socket that fills out addr, the + sockaddr_in structure. + + The return value is an integer. Indeed, the + accept returns a new + socket. You will use this new socket to + communicate with the client. + + What happens to the old socket? It continues to listen + for more requests (remember the backlog + variable we passed to listen?) until + we close it. + + Now, the new socket is meant only for + communications. It is fully connected. We cannot pass it + to listen again, trying to accept + additional connections. + + + + + Our First Server + + Our first server will be somewhat more complex than + our first client was: Not only do we have more sockets + functions to use, but we need to write it as a + daemon. + + This is best achieved by creating a child + process after binding the port. The main + process then exits and returns control to the + shell (or whatever program + invoked it). + + The child calls listen, then + starts an endless loop, which accepts a connection, serves + it, and eventually closes its socket. + + +/* + * daytimed - a port 13 server + * + * Programmed by G. Adam Stanislav + * June 19, 2001 + */ +#include <stdio.h> +#include <time.h> +#include <unistd.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> + +#define BACKLOG 4 + +int main() { + register int s, c; + int b; + struct sockaddr_in sa; + time_t t; + struct tm *tm; + FILE *client; + + if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { + perror("socket"); + return 1; + } + + bzero(&sa, sizeof sa); + + sa.sin_family = AF_INET; + sa.sin_port = htons(13); + + if (INADDR_ANY) + sa.sin_addr.s_addr = htonl(INADDR_ANY); + + if (bind(s, (struct sockaddr *)&sa, sizeof sa) < 0) { + perror("bind"); + return 2; + } + + switch (fork()) { + case -1: + perror("fork"); + return 3; + break; + default: + close s; + return 0; + break; + case 0: + break; + } + + listen(s, BACKLOG); + + for (;;) { + b = sizeof sa; + + if ((c = accept(s, (struct sockaddr *)&sa, &b)) < 0) { + perror("daytimed accept"); + return 4; + } + + if ((client = fdopen(c, "w")) == NULL) { + perror("daytimed fdopen"); + return 5; + } + + if ((t = time(NULL)) < 0) { + perror("daytimed time"); + + return 6; + } + + tm = gmtime(&t); + fprintf(client, "%.4i-%.2i-%.2iT%.2i:%.2i:%.2iZ\n", + tm->tm_year + 1900, + tm->tm_mon + 1, + tm->tm_mday, + tm->tm_hour, + tm->tm_min, + tm->tm_sec); + + fclose(client); + } +} + + + We start by creating a socket. Then we fill out the + sockaddr_in structure in + sa. Note the conditional use of + INADDR_ANY: + + + if (INADDR_ANY) + sa.sin_addr.s_addr = htonl(INADDR_ANY); + + + Its value is 0. Since we have + just used bzero on the entire + structure, it would be redundant to set it to + 0 again. But if we port our code to + some other system where INADDR_ANY is + perhaps not a zero, we need to assign it to + sa.sin_addr.s_addr. Most modern C + compilers are clever enough to notice that + INADDR_ANY is a constant. As long as it + is a zero, they will optimize the entire conditional + statement out of the code. + + After we have called bind + successfully, we are ready to become a + daemon: We use + fork to create a child process. In + both, the parent and the child the s + variable is our socket. The parent process will not need + it, so it calls close, then it + returns 0 to inform its own parent it + had terminated successfully. + + Meanwhile, the child process continues working in the + background. It calls listen and sets + its backlog to 4. It does not need a + large value here because daytime is + not a protocol many clients request all the time, and + because it can process each request instantly anyway. + + Finally, the daemon starts an endless loop, which + performs the following steps: + + + Call accept. It waits + here until a client contacts it. At that point, it + receives a new socket, c, which it + can use to communicate with this particular client. + + + It uses the C function + fdopen to turn the socket from a + low-level file descriptor to a + C-style FILE pointer. This will allow + the use of fprintf later on. + + + It checks the time, and prints it in the + ISO 8601 format + to the client file. It + then uses fclose to close the + file. That will automatically close the socket as well. + + + + + We can generalize this, and use + it as a model for many other servers: + + + + + + + + +-----------------+ +| Create Socket | ++-----------------+ + | ++-----------------+ +| Bind Port | Daemon Process ++-----------------+ + | +--------+ + +-------------+-->| Init | + | | +--------+ ++-----------------+ | | +| Exit | | +--------+ ++-----------------+ | | Listen | + | +--------+ + | | + | +--------+ + | | Accept | + | +--------+ + | | + | +--------+ + | | Serve | + | +--------+ + | | + | +--------+ + | | Close | + |<--------+ + + + + Sequential Server + + + + This flowchart is good for sequential + servers, i.e., servers that can serve one + client at a time, just as we were able to with our + daytime server. This is only possible + whenever there is no real conversation + going on between the client and the server: As soon as the + server detects a connection to the client, it sends out + some data and closes the connection. The entire operation + may take nanoseconds, and it is finished. + + The advantage of this flowchart is that, except for + the brief moment after the parent + forks and before it exits, there is + always only one process active: Our + server does not take up much memory and other system + resources. + + Note that we have added initialize + daemon in our flowchart. We did not need to + initialize our own daemon, but this is a good place in the + flow of the program to set up any + signal handlers, open any files we + may need, etc. + + Just about everything in the flow chart can be used + literally on many different servers. The + serve entry is the exception. We + think of it as a black + box, i.e., something you design + specifically for your own server, and just plug it + into the rest. + + Not all protocols are that simple. Many receive a + request from the client, reply to it, then receive another + request from the same client. Because of that, they do not + know in advance how long they will be serving the + client. Such servers usually start a new process for each + client. While the new process is serving its client, the + daemon can continue listening for more connections. + + Now, go ahead, save the above source code as + daytimed.c (it is customary to end + the names of daemons with the letter + d. After you have compiled it, try + running it: + + +&prompt.user; ./daytimed +bind: Permission denied +&prompt.user; + + + What happened here? As you will recall, the + daytime protocol uses port 13. But + all ports below 1024 are reserved to the superuser + (otherwise, anyone could start a daemon pretending to + serve a commonly used port, while causing a security + breach). + + Try again, this time as the superuser: + + +&prompt.root; ./daytimed +&prompt.root; + + + What... Nothing? Let us try again: + + +&prompt.root; ./daytimed + +bind: Address already in use +&prompt.root; + + + Every port can only be bound by one program at a + time. Our first attempt was indeed successful: It started + the child daemon and returned quietly. It is still running + and will continue to run until you either kill it, or any + of its system calls fail, or you reboot the system. + + Fine, we know it is running in the background. But is + it working? How do we know it is a proper + daytime server? Simple: + + +&prompt.user; telnet localhost 13 + +Trying ::1... +telnet: connect to address ::1: Connection refused +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +2001-06-19T21:04:42Z +Connection closed by foreign host. +&prompt.user; + + + telnet tried the new + IPv6, and failed. It retried with + IPv4 and succeeded. The daemon + works. + + If you have access to another Unix system via + telnet, you can use it to test + accessing the server remotely. My computer does not have a + static IP address, so this is what I + did: + + +&prompt.user; who + +whizkid ttyp0 Jun 19 16:59 (216.127.220.143) +xxx ttyp1 Jun 19 16:06 (xx.xx.xx.xx) +&prompt.user; telnet 216.127.220.107 13 + +Trying 216.127.220.143... +Connected to r47.bfm.org. +Escape character is '^]'. +2001-06-19T21:31:11Z +Connection closed by foreign host. +&prompt.user; + + + Again, it worked. Will it work using the domain name? + + + +&prompt.user; telnet r47.bfm.org 13 + +Trying 216.127.220.143... +Connected to r47.bfm.org. +Escape character is '^]'. +2001-06-19T21:31:40Z +Connection closed by foreign host. +&prompt.user; + + + By the way, telnet prints + the Connection closed by foreign host + message after our daemon has closed the socket. This shows + us that, indeed, using + fclose(client); in our code works as + advertised. + + + + + + + + + + + Helper Functions + + FreeBSD C library contains many helper functions for sockets + programming. For example, in our sample client we hard coded + the time.nist.gov + IP address. But we do not always know the + IP address. Even if we do, our software is + more flexible if it allows the user to enter the + IP address, or even the domain name. + + + + <function>gethostbyname</function> + + While there is no way to pass the domain name directly to + any of the sockets functions, the FreeBSD C library comes with + the &man.gethostbyname.3 and &man.gethostbyname2.3 functions, + declared in netdb.h. + + +struct hostent * gethostbyname(const char *name); +struct hostent * gethostbyname2(const char *name, int af); + + + Both return a pointer to the hostent + structure, with much information about the domain. For our + purposes, the h_addr_list[0] field of the + structure points at h_length bytes of the + correct address, already stored in the network byte + order. + + This allows us to create a much more flexible—and + much more useful—version of our + daytime program: + + +/* + * daytime.c + * + * Programmed by G. Adam Stanislav + * 19 June 2001 + */ +#include <stdio.h> +#include <string.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <netdb.h> + +int main(int argc, char *argv[]) { + register int s; + register int bytes; + struct sockaddr_in sa; + struct hostent *he; + char buf[BUFSIZ+1]; + char *host; + + if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { + perror("socket"); + return 1; + } + + bzero(&sa, sizeof sa); + + sa.sin_family = AF_INET; + sa.sin_port = htons(13); + + host = (argc > 1) ? (char *)argv[1] : "time.nist.gov"; + + if ((he = gethostbyname(host)) == NULL) { + herror(host); + return 2; + } + + bcopy(he->h_addr_list[0],&sa.sin_addr, he->h_length); + + if (connect(s, (struct sockaddr *)&sa, sizeof sa) < 0) { + perror("connect"); + return 3; + } + + while ((bytes = read(s, buf, BUFSIZ)) > 0) + write(1, buf, bytes); + + close(s); + return 0; +} + + + We now can type a domain name (or an IP + address, it works both ways) on the command line, and the + program will try to connect to its + daytime server. Otherwise, it will still + default to time.nist.gov. However, even in + this case we will use gethostbyname + rather than hard coding 192.43.244.18. That way, even if its + IP address changes in the future, we will + still find it. + + Since it takes virtually no time to get the time from your + local server, you could run daytime + twice in a row: First to get the time from time.nist.gov, the second time from + your own system. You can then compare the results and see how + exact your system clock is: + + +&prompt.user; daytime ; daytime localhost + + +52080 01-06-20 04:02:33 50 0 0 390.2 UTC(NIST) * +2001-06-20T04:02:35Z +&prompt.user; + + + As you can see, my system was two seconds ahead of the + NIST time. + + + + + <function>getservbyname</function> + + Sometimes you may not be sure what port a certain service + uses. The &man.getservbyname.3; function, also declared in + netdb.h comes in very handy in those + cases: + + +struct servent * getservbyname(const char *name, const char *proto); + + + The servent structure contains the + s_port, which contains the proper port, + already in network byte order. + + Had we not known the correct port for the + daytime service, we could have found it + this way: + + + struct servent *se; + ... + if ((se = getservbyname("daytime", "tcp")) == NULL { + fprintf(stderr, "Cannot determine which port to use.\n"); + return 7; + } + sa.sin_port = se->s_port; + + + You usually do know the port. But if you are developing a + new protocol, you may be testing it on an unofficial + port. Some day, you will register the protocol and its port + (if nowehere else, at least in your + /etc/services, which is where + getservbyname looks). Instead of + returning an error in the above code, you just use the + temporary port number. Once you have listed the protocol in + /etc/services, your software will find + its port without you having to rewrite the code. + + + + + + + Concurrent Servers + + Unlike a sequential server, a concurrent + server has to be able to serve more than one client + at a time. For example, a chat server may + be serving a specific client for hours—it cannot wait till + it stops serving a client before it serves the next one. + + This requires a significant change in our flowchart: + + + + + + + + +-----------------+ +| Create Socket | ++-----------------+ + | ++-----------------+ +| Bind Port | Daemon Process ++-----------------+ + | +--------+ + +-------------+-->| Init | + | | +--------+ ++-----------------+ | | +| Exit | | +--------+ ++-----------------+ | | Listen | + | +--------+ + | | + | +--------+ + | | Accept | + | +--------+ + | | +------------------+ + | +------>| Close Top Socket | + | | +------------------+ + | +--------+ | + | | Close | +------------------+ + | +--------+ | Serve | + | | +------------------+ + |<--------+ | + +------------------+ + | Close Acc Socket | + +--------+ +------------------+ + | Signal | | + +--------+ +------------------+ + | Exit | + +------------------+ + + + + Concurrent Server + + + + We moved the serve from the + daemon process to its own server + process. However, because each child process inherits + all open files (and a socket is treated just like a file), the + new process inherits not only the accepted + handle, i.e., the socket returned by the + accept call, but also the top + socket, i.e., the one opened by the top process right + at the beginning. + + However, the server process does not + need this socket and should close it + immediately. Similarly, the daemon process + no longer needs the accepted socket, and + not only should, but must + close it—otherwise, it will run out + of available file descriptors sooner or + later. + + After the server process is done + serving, it should close the accepted + socket. Instead of returning to + accept, it now exits. + + + Under Unix, a process does not really + exit. Instead, it + returns to its parent. Typically, a parent + process waits for its child process, and + obtains a return value. However, our daemon + process cannot simply stop and wait. That would + defeat the whole purpose of creating additional processes. But + if it never does wait, its children will + become zombies—no loger functional + but still roaming around. + + For that reason, the daemon process + needs to set signal handlers in its + initialize daemon phase. At least a + SIGCHLD signal has to be processed, so the + daemon can remove the zombie return values from the system and + release the system resources they are taking up. + + That is why our flowchart now contains a process + signals box, which is not connected to any other box. + By the way, many servers also process SIGHUP, + and typically interpret as the signal from the superuser that + they should reread their configuration files. This allows us to + change settings without having to kill and restart these + servers. + + + + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/layers.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/layers.eps new file mode 100644 index 0000000000..77b977b1fa --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/layers.eps @@ -0,0 +1,92 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: -10 -10 110 102 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +%%EndProlog + +%%BeginSetup +%%EndSetup + +% Outer layer - Ethernet +0 0 moveto +0 92 rlineto +100 0 rlineto +0 -92 rlineto +closepath + +2 90 moveto +0 -88 rlineto +96 0 rlineto +0 88 rlineto +closepath +fill + +% IP + +4 4 moveto +0 72 rlineto +92 0 rlineto +0 -72 rlineto +closepath +stroke + +% TCP + +7 7 moveto +0 58 rlineto +86 0 rlineto +0 -58 rlineto +closepath +stroke + +% HTTP + +10 10 moveto +0 44 rlineto +80 0 rlineto +0 -44 rlineto +closepath +stroke + +% PNG + +13 13 moveto +0 30 rlineto +74 0 rlineto +0 -30 rlineto +closepath +stroke + +% Data + +16 16 moveto +0 16.5 rlineto +68 0 rlineto +0 -16.5 rlineto +closepath +fill + +/Courier findfont 10 scalefont setfont +26 81 moveto +(Ethernet) show + +43 68 moveto +(IP) show + +40 57 moveto +(TCP) show + +37 46 moveto +(HTTP) show + +39.6 35 moveto +(PNG) show + +1 setcolor +28 22 moveto +(D A T A) show +%%Trailer +showpage +%%EOF + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/sain.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/sain.eps new file mode 100644 index 0000000000..ac754bc651 --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/sain.eps @@ -0,0 +1,88 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: -20 -10 290 85 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +/box { + moveto + 0 70 rlineto + 280 0 rlineto + 0 -70 rlineto + closepath +} bind def + +/bits32 { + moveto + 276 0 rlineto + 0 15 rlineto + -276 0 rlineto + closepath +} bind def + +/bits16 { + moveto + 137 0 rlineto + 0 15 rlineto + -137 0 rlineto +} bind def + +/bits8 { + moveto + 67.5 0 rlineto + 0 15 rlineto + -67.5 0 rlineto +} bind def + +%%EndProlog + +%%BeginSetup +%%EndSetup + +5 7 div setcolor +1 1 moveto +0 34 rlineto +278 0 rlineto +0 -34 rlineto +closepath + +1 52 moveto +0 16 rlineto +68.5 0 rlineto +0 -16 rlineto +closepath + +fill +0 setcolor + +0 0 box +2 2 bits32 +2 19 bits32 +2 36 bits32 +2 53 bits8 +71.5 53 bits8 +141 53 bits16 +fill + +/Courier findfont 10 scalefont setfont +32 72 moveto (0) show +240 72 moveto (3) show +171.5 72 moveto (2) show +101.5 72 moveto (1) show + +-10 57 moveto (0) show +-10 40 moveto (4) show +-10 23 moveto (8) show +-16 6 moveto (12) show + +/Helvetica-bold findfont 10 scalefont setfont +110 40 moveto (IP Address) show +196 57 moveto (Port) show +90 57 moveto (Family) show +32 57 moveto (0) show +138 23 moveto (0) show +138 6 moveto (0) show + +%%Trailer +showpage +%%EOF + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/sainfill.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/sainfill.eps new file mode 100644 index 0000000000..6d5331ed2e --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/sainfill.eps @@ -0,0 +1,88 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: -20 -10 290 85 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +/box { + moveto + 0 70 rlineto + 280 0 rlineto + 0 -70 rlineto + closepath +} bind def + +/bits32 { + moveto + 276 0 rlineto + 0 15 rlineto + -276 0 rlineto + closepath +} bind def + +/bits16 { + moveto + 137 0 rlineto + 0 15 rlineto + -137 0 rlineto +} bind def + +/bits8 { + moveto + 67.5 0 rlineto + 0 15 rlineto + -67.5 0 rlineto +} bind def + +%%EndProlog + +%%BeginSetup +%%EndSetup + +5 7 div setcolor +1 1 moveto +0 34 rlineto +278 0 rlineto +0 -34 rlineto +closepath + +1 52 moveto +0 16 rlineto +68.5 0 rlineto +0 -16 rlineto +closepath + +fill +0 setcolor + +0 0 box +2 2 bits32 +2 19 bits32 +2 36 bits32 +2 53 bits8 +71.5 53 bits8 +141 53 bits16 +fill + +/Courier findfont 10 scalefont setfont +32 72 moveto (0) show +240 72 moveto (3) show +171.5 72 moveto (2) show +101.5 72 moveto (1) show + +-10 57 moveto (0) show +-10 40 moveto (4) show +-10 23 moveto (8) show +-16 6 moveto (12) show + +/Helvetica-bold findfont 10 scalefont setfont +108 40 moveto (192.43.244.18) show +204 57 moveto (13) show +102 57 moveto (2) show +32 57 moveto (0) show +138 23 moveto (0) show +138 6 moveto (0) show + +%%Trailer +showpage +%%EOF + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/sainlsb.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/sainlsb.eps new file mode 100644 index 0000000000..5b2bec6384 --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/sainlsb.eps @@ -0,0 +1,96 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: -20 -10 290 85 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +/box { + moveto + 0 70 rlineto + 280 0 rlineto + 0 -70 rlineto + closepath +} bind def + +/bits32 { + moveto + 276 0 rlineto + 0 15 rlineto + -276 0 rlineto + closepath +} bind def + +/bits16 { + moveto + 137 0 rlineto + 0 15 rlineto + -137 0 rlineto +} bind def + +/bits8 { + moveto + 67.5 0 rlineto + 0 15 rlineto + -67.5 0 rlineto +} bind def + +%%EndProlog + +%%BeginSetup +%%EndSetup + +5 7 div setcolor +1 1 moveto +0 34 rlineto +278 0 rlineto +0 -34 rlineto +closepath + +1 52 moveto +0 16 rlineto +68.5 0 rlineto +0 -16 rlineto +closepath + +fill +0 setcolor + +0 0 box +2 2 bits32 +2 19 bits32 +2 36 bits8 +71.5 36 bits8 +141 36 bits8 +210.5 36 bits8 +2 53 bits8 +71.5 53 bits8 +141 53 bits8 +210.5 53 bits8 +fill + +/Courier findfont 10 scalefont setfont +32 72 moveto (0) show +240 72 moveto (3) show +171.5 72 moveto (2) show +101.5 72 moveto (1) show + +-10 57 moveto (0) show +-10 40 moveto (4) show +-10 23 moveto (8) show +-16 6 moveto (12) show + +/Helvetica-bold findfont 10 scalefont setfont +27 40 moveto (18) show +95 40 moveto (244) show +168 40 moveto (43) show +234 40 moveto (192) show +168 57 moveto (13) show +240 57 moveto (0) show +102 57 moveto (2) show +32 57 moveto (0) show +138 23 moveto (0) show +138 6 moveto (0) show + +%%Trailer +showpage +%%EOF + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/sainmsb.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/sainmsb.eps new file mode 100644 index 0000000000..279bb5b37f --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/sainmsb.eps @@ -0,0 +1,96 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: -20 -10 290 85 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +/box { + moveto + 0 70 rlineto + 280 0 rlineto + 0 -70 rlineto + closepath +} bind def + +/bits32 { + moveto + 276 0 rlineto + 0 15 rlineto + -276 0 rlineto + closepath +} bind def + +/bits16 { + moveto + 137 0 rlineto + 0 15 rlineto + -137 0 rlineto +} bind def + +/bits8 { + moveto + 67.5 0 rlineto + 0 15 rlineto + -67.5 0 rlineto +} bind def + +%%EndProlog + +%%BeginSetup +%%EndSetup + +5 7 div setcolor +1 1 moveto +0 34 rlineto +278 0 rlineto +0 -34 rlineto +closepath + +1 52 moveto +0 16 rlineto +68.5 0 rlineto +0 -16 rlineto +closepath + +fill +0 setcolor + +0 0 box +2 2 bits32 +2 19 bits32 +2 36 bits8 +71.5 36 bits8 +141 36 bits8 +210.5 36 bits8 +2 53 bits8 +71.5 53 bits8 +141 53 bits8 +210.5 53 bits8 +fill + +/Courier findfont 10 scalefont setfont +32 72 moveto (0) show +240 72 moveto (3) show +171.5 72 moveto (2) show +101.5 72 moveto (1) show + +-10 57 moveto (0) show +-10 40 moveto (4) show +-10 23 moveto (8) show +-16 6 moveto (12) show + +/Helvetica-bold findfont 10 scalefont setfont +236 40 moveto (18) show +166 40 moveto (244) show +99 40 moveto (43) show +27 40 moveto (192) show +236 57 moveto (13) show +172 57 moveto (0) show +102 57 moveto (2) show +32 57 moveto (0) show +138 23 moveto (0) show +138 6 moveto (0) show + +%%Trailer +showpage +%%EOF + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/sainserv.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/sainserv.eps new file mode 100644 index 0000000000..33bb86b83e --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/sainserv.eps @@ -0,0 +1,90 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: -20 -10 290 85 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +/box { + moveto + 0 70 rlineto + 280 0 rlineto + 0 -70 rlineto + closepath +} bind def + +/bits32 { + moveto + 276 0 rlineto + 0 15 rlineto + -276 0 rlineto + closepath +} bind def + +/bits16 { + moveto + 137 0 rlineto + 0 15 rlineto + -137 0 rlineto +} bind def + +/bits8 { + moveto + 67.5 0 rlineto + 0 15 rlineto + -67.5 0 rlineto +} bind def + +%%EndProlog + +%%BeginSetup +%%EndSetup + +5 7 div setcolor +1 1 moveto +0 34 rlineto +278 0 rlineto +0 -34 rlineto +closepath + +1 52 moveto +0 16 rlineto +68.5 0 rlineto +0 -16 rlineto +closepath + +fill +0 setcolor + +0 0 box +2 2 bits32 +2 19 bits32 +2 36 bits32 +2 53 bits8 +71.5 53 bits8 +141 53 bits8 +210.5 53 bits8 +fill + +/Courier findfont 10 scalefont setfont +32 72 moveto (0) show +240 72 moveto (3) show +171.5 72 moveto (2) show +101.5 72 moveto (1) show + +-10 57 moveto (0) show +-10 40 moveto (4) show +-10 23 moveto (8) show +-16 6 moveto (12) show + +/Helvetica-bold findfont 10 scalefont setfont +236 57 moveto (13) show +172 57 moveto (0) show +102 57 moveto (2) show +32 57 moveto (0) show +138 40 moveto (0) show +138 23 moveto (0) show +138 6 moveto (0) show + +%%Trailer +showpage +%%EOF + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/serv.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/serv.eps new file mode 100644 index 0000000000..4d95eca137 --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/serv.eps @@ -0,0 +1,160 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: 0 -230 255 190 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +/box { + moveto + 0 30 rlineto + 100 0 rlineto + 0 -30 rlineto + closepath + 2 28 rmoveto + 0 -26 rlineto + 96 0 rlineto + 0 26 rlineto + closepath + fill +} bind def + +/down { + moveto + 0 -10 rlineto + -5 0 rlineto + 10 -10 rlineto + 10 10 rlineto + -5 0 rlineto + 0 10 rlineto + closepath + fill +} bind def + +/bigdown { + moveto + 0 -30 rlineto + -5 0 rlineto + 10 -10 rlineto + 10 10 rlineto + -5 0 rlineto + 0 30 rlineto + closepath + fill +} bind def + +/right { + moveto + 70 0 rlineto + 0 -5 rlineto + 10 10 rlineto + -10 10 rlineto + 0 -5 rlineto + -70 0 rlineto + closepath + fill +} bind def +%%EndProlog + +%%BeginSetup +/Helvetica-bold findfont 10 scalefont setfont +%%EndSetup + +[5 3] 0 setdash +115 190 moveto +115 -230 lineto +stroke + +newpath +25 165 15 90 270 arc +95 165 15 270 90 arc +closepath +25 152 moveto +25 165 13 270 90 arcn +95 165 13 90 270 arcn +fill + +48 162 moveto (Start) show + +55 150 down + +10 100 box +15 112 moveto (Create Top Socket) show + +55 100 down + +10 50 box +35 62 moveto (Bind Port) show + +55 50 bigdown + +10 -20 box +16.7 -8 moveto (Close Top Socket) show + +55 -20 down + +newpath +25 -55 15 90 270 arc +95 -55 15 270 90 arc +closepath +25 -68 moveto +25 -55 13 270 90 arcn +95 -55 13 90 270 arcn +fill + +48 -58 moveto (Exit) show + +65 30 right + +145 20 box +154 32 moveto (Initialize Daemon) show + +190 20 down +145 -30 box +181 -18 moveto (Listen) show + +190 -30 bigdown + +145 -100 box +177 -88 moveto (Accept) show + +190 -100 down + +145 -150 moveto +0 30 rlineto +100 0 rlineto +0 -30 rlineto +closepath +fill + +190 -150 down + +145 -200 box +156 -183 moveto (Close Accepted) show +178 -194 moveto (Socket) show + +190 -200 moveto +0 -10 rlineto +-60 0 rlineto +0 160 rlineto +50 0 rlineto +0 -5 rlineto +10 10 rlineto +-10 10 rlineto +0 -5 rlineto +-60 0 rlineto +0 -180 rlineto +80 0 rlineto +0 20 rlineto +closepath +fill + +/Helvetica-bold findfont 20 scalefont setfont +158 82 moveto (Daemon) show +158 60 moveto (Process) show +1 setcolor +166 -143 moveto (Serve) show + + +%%Trailer +showpage +%%EOF + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/serv2.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/serv2.eps new file mode 100644 index 0000000000..7bd7fa62ef --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/serv2.eps @@ -0,0 +1,211 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: 0 -305 435 190 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +/box { + moveto + 0 30 rlineto + 100 0 rlineto + 0 -30 rlineto + closepath + 2 28 rmoveto + 0 -26 rlineto + 96 0 rlineto + 0 26 rlineto + closepath + fill +} bind def + +/down { + moveto + 0 -10 rlineto + -5 0 rlineto + 10 -10 rlineto + 10 10 rlineto + -5 0 rlineto + 0 10 rlineto + closepath + fill +} bind def + +/bigdown { + moveto + 0 -30 rlineto + -5 0 rlineto + 10 -10 rlineto + 10 10 rlineto + -5 0 rlineto + 0 30 rlineto + closepath + fill +} bind def + +/right { + moveto + 70 0 rlineto + 0 -5 rlineto + 10 10 rlineto + -10 10 rlineto + 0 -5 rlineto + -70 0 rlineto + closepath + fill +} bind def + +/process { + moveto + 135 0 rlineto + 0 -245 rlineto + -135 0 rlineto + closepath + gsave + 5 7 div setcolor + fill + grestore + stroke +} bind def +%%EndProlog + +%%BeginSetup +/Helvetica-bold findfont 10 scalefont setfont +%%EndSetup + +[5 3] 0 setdash +115 190 moveto +115 -305 lineto +250 190 moveto +250 -305 lineto +stroke + +290 -15 process +285 -20 process +280 -25 process +275 -30 process +270 -35 process +265 -40 process +260 -45 process + +newpath +25 165 15 90 270 arc +95 165 15 270 90 arc +closepath +25 152 moveto +25 165 13 270 90 arcn +95 165 13 90 270 arcn +fill + +48 162 moveto (Start) show + +55 150 down + +10 100 box +15 112 moveto (Create Top Socket) show + +55 100 down + +10 50 box +35 62 moveto (Bind Port) show + +55 50 bigdown + +10 -20 box +16.7 -8 moveto (Close Top Socket) show + +55 -20 down + +newpath +25 -55 15 90 270 arc +95 -55 15 270 90 arc +closepath +25 -68 moveto +25 -55 13 270 90 arcn +95 -55 13 90 270 arcn +fill + +48 -58 moveto (Exit) show + +65 30 right + +145 20 box +154 32 moveto (Initialize Daemon) show + +190 20 down +145 -30 box +181 -18 moveto (Listen) show + +190 -30 bigdown + +145 -100 box +177 -88 moveto (Accept) show + +190 -100 bigdown +200 -120 right + +280 -130 box +286.7 -118 moveto (Close Top Socket) show + +325 -130 down + +280 -180 moveto +0 30 rlineto +100 0 rlineto +0 -30 rlineto +closepath +fill + +325 -180 down + +280 -230 box +291 -213 moveto (Close Accepted) show +313 -224 moveto (Socket) show + +325 -230 down + +newpath +295 -265 15 90 270 arc +365 -265 15 270 90 arc +closepath +295 -278 moveto +295 -265 13 270 90 arcn +365 -265 13 90 270 arcn +fill + +318 -268 moveto (Exit) show + +145 -170 box +156 -153 moveto (Close Accepted) show +178 -164 moveto (Socket) show + +190 -170 moveto +0 -10 rlineto +-60 0 rlineto +0 130 rlineto +50 0 rlineto +0 -5 rlineto +10 10 rlineto +-10 10 rlineto +0 -5 rlineto +-60 0 rlineto +0 -150 rlineto +80 0 rlineto +0 20 rlineto +closepath +fill + +145 -250 box +155 -238 moveto (Process Signals) show + +/Helvetica-bold findfont 20 scalefont setfont +158 82 moveto (Daemon) show +158 60 moveto (Process) show +293 -68 moveto (Server) show +293 -90 moveto (Process) show +1 setcolor +301 -173 moveto (Serve) show + + +%%Trailer +showpage +%%EOF + diff --git a/en_US.ISO8859-1/books/developers-handbook/sockets/slayers.eps b/en_US.ISO8859-1/books/developers-handbook/sockets/slayers.eps new file mode 100644 index 0000000000..7b0ab84346 --- /dev/null +++ b/en_US.ISO8859-1/books/developers-handbook/sockets/slayers.eps @@ -0,0 +1,113 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%BoundingBox: -10 -10 110 102 +%%Creator: G. Adam Stanislav +%%EndComments +%%BeginProlog +%%EndProlog + +%%BeginSetup +%%EndSetup + +% Gray area - Sockets +5 7 div setcolor +0 0 moveto +0 92 rlineto +100 0 rlineto +0 -92 rlineto +closepath + +10 54 moveto +0 -44 rlineto +80 0 rlineto +0 44 rlineto +closepath +fill +7 11 div setcolor + +% Outer layer - Ethernet +0 0 moveto +0 92 rlineto +100 0 rlineto +0 -92 rlineto +closepath + +2 90 moveto +0 -88 rlineto +96 0 rlineto +0 88 rlineto +closepath +fill + +% IP + +4 4 moveto +0 72 rlineto +92 0 rlineto +0 -72 rlineto +closepath +stroke + +% TCP + +7 7 moveto +0 58 rlineto +86 0 rlineto +0 -58 rlineto +closepath +stroke + +0 setcolor + +% HTTP + +10 10 moveto +0 44 rlineto +80 0 rlineto +0 -44 rlineto +closepath +stroke + +% PNG + +13 13 moveto +0 30 rlineto +74 0 rlineto +0 -30 rlineto +closepath +stroke + +% Data + +16 16 moveto +0 16.5 rlineto +68 0 rlineto +0 -16.5 rlineto +closepath +fill + +/Courier findfont 10 scalefont setfont +7 11 div setcolor + +26 81 moveto +(Ethernet) show + +43 68 moveto +(IP) show + +40 57 moveto +(TCP) show + +0 setcolor +37 46 moveto +(HTTP) show + +39.6 35 moveto +(PNG) show + +1 setcolor +28 22 moveto +(D A T A) show +%%Trailer +showpage +%%EOF +