Beej的网络编程指南：互联网套接字详解

5星 · 超过95%的资源需积分: 9 29 浏览量更新于2024-08-01 收藏 721KB PDF 举报

"Beej's Guide to Network Programming 使用互联网套接字进行网络编程" Beej的《网络编程指南》是一本专注于通过互联网套接字进行网络编程的著作，作者Brian "Beej" Jorgensen。这本书是针对那些希望理解和实现网络通信的程序员编写的。书中详细讲解了如何使用各种网络协议，特别是TCP/IP协议族，来创建网络应用程序。在本书中，Beej深入浅出地介绍了网络编程的基础概念，包括套接字API的使用、连接与监听、数据传输、错误处理以及并发编程等核心主题。读者将学习到如何在不同操作系统平台上（如Linux）构建跨平台的网络应用。书中的内容涵盖了从简单的客户端/服务器模型到更复杂的多线程和多进程网络架构。 Beej的写作风格友好且易于理解，他通过丰富的实例代码和解释帮助读者掌握网络编程的实战技巧。此外，他还对网络安全、性能优化和调试策略进行了讨论，使读者能够构建健壮和安全的网络服务。该书的创作过程中，Beej得到了许多人的帮助和支持，包括为封面设计提供建议的Ashley，以及众多开源软件和工具的开发者，如GNU、Linux、Slackware、vim、Python、Inkscape、Apache FOP、Firefox和Red Hat等。读者的反馈和建议也是书本不断改进的动力，他们共同促成了这本网络编程领域的经典参考书籍。本书的编写采用了XML语言，并借助vim编辑器、Slackware Linux系统以及一系列GNU工具完成。封面设计和图表由Inkscape制作，而XML文件则通过定制的Python脚本转换为HTML和XSL-FO格式，最后由XSL-FO生成高质量的输出。 Beej将这本书献给了他的计算机领域偶像，包括Donald Knuth、Bruce Schneier、W. Richard Stevens和The Woz，以及他的读者群体和整个自由与开源软件社区。这不仅是一本技术指南，更是对开源精神和社区协作的致敬。通过阅读《Beej's Guide to Network Programming》，读者不仅可以掌握网络编程的基础知识，还能了解到开源社区的力量，以及如何利用这些工具和技术构建自己的网络应用程序。

Beej's Guide to Network Programming

What's important is that you can see the address family in the ss_family field—check this to see

if it's AF_INET or AF_INET6 (for IPv4 or IPv6). Then you can cast it to a struct sockaddr_in or

struct sockaddr_in6 if you wanna.

3.4. IP Addresses, Part Deux

Fortunately for you, there are a bunch of functions that allow you to manipulate IP addresses. No

need to figure them out by hand and stuff them in a long with the << operator.

First, let's say you have a struct sockaddr_in ina, and you have an IP address

“10.12.110.57” or “2001:db8:63b3:1::3490” that you want to store into it. The function you

want to use, inet_pton(), converts an IP address in numbers-and-dots notation into either a struct

in_addr or a struct in6_addr depending on whether you specify AF_INET or AF_INET6. (“pton”

stands for “presentation to network”—you can call it “printable to network” if that's easier to remember.)

The conversion can be made as follows:

struct sockaddr_in sa; // IPv4

struct sockaddr_in6 sa6; // IPv6

inet_pton(AF_INET, "192.0.2.1", &(sa.sin_addr)); // IPv4

inet_pton(AF_INET6, "2001:db8:63b3:1::3490", &(sa6.sin6_addr)); // IPv6

(Quick note: the old way of doing things used a function called inet_addr() or another function

called inet_aton(); these are now obsolete and don't work with IPv6.)

Now, the above code snippet isn't very robust because there is no error checking. See,

inet_pton() returns -1 on error, or 0 if the address is messed up. So check to make sure the result is

greater than 0 before using!

All right, now you can convert string IP addresses to their binary representations. What about the

other way around? What if you have a struct in_addr and you want to print it in numbers-and-

dots notation? (Or a struct in6_addr that you want in, uh, “hex-and-colons” notation.) In this case,

you'll want to use the function inet_ntop() (“ntop” means “network to presentation”—you can call it

“network to printable” if that's easier to remember), like this:

// IPv4:

char ip4[INET_ADDRSTRLEN]; // space to hold the IPv4 string

struct sockaddr_in sa; // pretend this is loaded with something

inet_ntop(AF_INET, &(sa.sin_addr), ip4, INET_ADDRSTRLEN);

printf("The IPv4 address is: %s\n", ip4);

// IPv6:

char ip6[INET6_ADDRSTRLEN]; // space to hold the IPv6 string

struct sockaddr_in6 sa6; // pretend this is loaded with something

inet_ntop(AF_INET6, &(sa6.sin6_addr), ip6, INET6_ADDRSTRLEN);

printf("The address is: %s\n", ip6);

When you call it, you'll pass the address type (IPv4 or IPv6), the address, a pointer to a string

to hold the result, and the maximum length of that string. (Two macros conveniently hold the

size of the string you'll need to hold the largest IPv4 or IPv6 address: INET_ADDRSTRLEN and

INET6_ADDRSTRLEN.)

(Another quick note to mention once again the old way of doing things: the historical function to do

this conversion was called inet_ntoa(). It's also obsolete and won't work with IPv6.)

Lastly, these functions only work with numeric IP addresses—they won't do any nameserver DNS

lookup on a hostname, like “www.example.com”. You will use getaddrinfo() to do that, as you'll see

later on.

Beej's Guide to Network Programming

3.4.1. Private (Or Disconnected) Networks

Lots of places have a firewall that hides the network from the rest of the world for their own

protection. And often times, the firewall translates “internal” IP addresses to “external” (that everyone

else in the world knows) IP addresses using a process called Network Address Translation, or NAT.

Are you getting nervous yet? “Where's he going with all this weird stuff?”

Well, relax and buy yourself a non-alcoholic (or alcoholic) drink, because as a beginner, you don't

even have to worry about NAT, since it's done for you transparently. But I wanted to talk about the

network behind the firewall in case you started getting confused by the network numbers you were

seeing.

For instance, I have a firewall at home. I have two static IPv4 addresses allocated to me by the DSL

company, and yet I have seven computers on the network. How is this possible? Two computers can't

share the same IP address, or else the data wouldn't know which one to go to!

The answer is: they don't share the same IP addresses. They are on a private network with 24

million IP addresses allocated to it. They are all just for me. Well, all for me as far as anyone else is

concerned. Here's what's happening:

If I log into a remote computer, it tells me I'm logged in from 192.0.2.33 which is the public

IP address my ISP has provided to me. But if I ask my local computer what it's IP address is, it says

10.0.0.5. Who is translating the IP address from one to the other? That's right, the firewall! It's doing

NAT!

10.x.x.x is one of a few reserved networks that are only to be used either on fully disconnected

networks, or on networks that are behind firewalls. The details of which private network numbers are

available for you to use are outlined in RFC 1918

, but some common ones you'll see are 10.x.x.x and

192.168.x.x, where x is 0-255, generally. Less common is 172.y.x.x, where y goes between 16 and 31.

Networks behind a NATing firewall don't need to be on one of these reserved networks, but they

commonly are.

(Fun fact! My external IP address isn't really 192.0.2.33. The 192.0.2.x network is reserved for

make-believe “real” IP addresses to be used in documentation, just like this guide! Wowzers!)

IPv6 has private networks, too, in a sense. They'll start with fdxx: (or maybe in the future fcXX:),

as per RFC 4193

. NAT and IPv6 don't generally mix, however (unless you're doing the IPv6 to IPv4

gateway thing which is beyond the scope of this document)—in theory you'll have so many addresses

at your disposal that you won't need to use NAT any longer. But if you want to allocate addresses for

yourself on a network that won't route outside, this is how to do it.

15. http://tools.ietf.org/html/rfc1918

16. http://tools.ietf.org/html/rfc4193

5. System Calls or Bust

This is the section where we get into the system calls (and other library calls) that allow you to

access the network functionality of a Unix box, or any box that supports the sockets API for that matter

(BSD, Windows, Linux, Mac, what-have-you.) When you call one of these functions, the kernel takes

over and does all the work for you automagically.

The place most people get stuck around here is what order to call these things in. In that, the man

pages are no use, as you've probably discovered. Well, to help with that dreadful situation, I've tried to

lay out the system calls in the following sections in exactly (approximately) the same order that you'll

need to call them in your programs.

That, coupled with a few pieces of sample code here and there, some milk and cookies (which I fear

you will have to supply yourself), and some raw guts and courage, and you'll be beaming data around the

Internet like the Son of Jon Postel!

(Please note that for brevity, many code snippets below do not include necessary error checking.

And they very commonly assume that the result from calls to getaddrinfo() succeed and return a

valid entry in the linked list. Both of these situations are properly addressed in the stand-alone programs,

though, so use those as a model.)

5.1. getaddrinfo()—Prepare to launch!

This is a real workhorse of a function with a lot of options, but usage is actually pretty simple. It

helps set up the structs you need later on.

A tiny bit of history: it used to be that you would use a function called gethostbyname() to do

DNS lookups. Then you'd load that information by hand into a struct sockaddr_in, and use that in

your calls.

This is no longer necessary, thankfully. (Nor is it desirable, if you want to write code that works

for both IPv4 and IPv6!) In these modern times, you now have the function getaddrinfo() that does

all kinds of good stuff for you, including DNS and service name lookups, and fills out the structs you

need, besides!

Let's take a look!

#include <sys/types.h>

#include <sys/socket.h>

#include <netdb.h>

int getaddrinfo(const char *node, // e.g. "www.example.com" or IP

const char *service, // e.g. "http" or port number

const struct addrinfo *hints,

struct addrinfo **res);

You give this function three input parameters, and it gives you a pointer to a linked-list, res, of

results.

The node parameter is the host name to connect to, or an IP address.

Next is the parameter service, which can be a port number, like “80”, or the name of a particular

service (found in The IANA Port List

or the /etc/services file on your Unix machine) like “http” or

“ftp” or “telnet” or “smtp” or whatever.

Finally, the hints parameter points to a struct addrinfo that you've already filled out with

relevant information.

Here's a sample call if you're a server who wants to listen on your host's IP address, port 3490. Note

that this doesn't actually do any listening or network setup; it merely sets up structures we'll use later:

int status;

struct addrinfo hints;

struct addrinfo *servinfo; // will point to the results

memset(&hints, 0, sizeof hints); // make sure the struct is empty

hints.ai_family = AF_UNSPEC; // don't care IPv4 or IPv6

17. http://www.iana.org/assignments/port-numbers

Beej's Guide to Network Programming

hints.ai_socktype = SOCK_STREAM; // TCP stream sockets

hints.ai_flags = AI_PASSIVE; // fill in my IP for me

if ((status = getaddrinfo(NULL, "3490", &hints, &servinfo)) != 0) {

fprintf(stderr, "getaddrinfo error: %s\n", gai_strerror(status));

exit(1);

}

// servinfo now points to a linked list of 1 or more struct addrinfos

// ... do everything until you don't need servinfo anymore ....

freeaddrinfo(servinfo); // free the linked-list

Notice that I set the ai_family to AF_UNSPEC, thereby saying that I don't care if we use IPv4 or

IPv6. You can set it to AF_INET or AF_INET6 if you want one or the other specifically.

Also, you'll see the AI_PASSIVE flag in there; this tells getaddrinfo() to assign the address of

my local host to the socket structures. This is nice because then you don't have to hardcode it. (Or you

can put a specific address in as the first parameter to getaddrinfo() where I currently have NULL, up

there.)

Then we make the call. If there's an error (getaddrinfo() returns non-zero), we can print it out

using the function gai_strerror(), as you see. If everything works properly, though, servinfo will

point to a linked list of struct addrinfos, each of which contains a struct sockaddr of some kind

that we can use later! Nifty!

Finally, when we're eventually all done with the linked list that getaddrinfo() so graciously

allocated for us, we can (and should) free it all up with a call to freeaddrinfo().

Here's a sample call if you're a client who wants to connect to a particular server, say

“www.example.net” port 3490. Again, this doesn't actually connect, but it sets up the structures we'll use

later:

int status;

struct addrinfo hints;

struct addrinfo *servinfo; // will point to the results

memset(&hints, 0, sizeof hints); // make sure the struct is empty

hints.ai_family = AF_UNSPEC; // don't care IPv4 or IPv6

hints.ai_socktype = SOCK_STREAM; // TCP stream sockets

// get ready to connect

status = getaddrinfo("www.example.net", "3490", &hints, &servinfo);

// servinfo now points to a linked list of 1 or more struct addrinfos

// etc.

I keep saying that servinfo is a linked list with all kinds of address information. Let's write a

quick demo program to show off this information. This short program

will print the IP addresses for

whatever host you specify on the command line:

** showip.c -- show IP addresses for a host given on the command line

#include <stdio.h>

#include <string.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netdb.h>

#include <arpa/inet.h>

int main(int argc, char *argv[])

{

18. http://beej.us/guide/bgnet/examples/showip.c

剩余100页未读，继续阅读

ZOLoveGD

粉丝: 45
资源: 46

Beej的网络编程指南：互联网套接字详解

bee.js:网络工作者助手工具

为什么下载了GUIDE to App Designer Migration Tool for MATLAB却显示没下载

如何免费安装 GUIDE to App Designer Migration Tool for MATLAB

GUIDE to App Designer Migration Tool for MATLAB怎么使用

怎样确保 GUIDE to App Designer Migration Tool for MATLAB 已经安装

c++ socket学习网站

ilitek251 programming guide

help me Write a complete guide to writing Scientific Papers

user guide to simca.pdf

cuda programming: a developer鈥檚 guide to parallel computing with gpus

最新资源