📄 92.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://apue.dhs.org"><font face="黑体"><big><big>123</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> ● UNIX网络编程 (BM: clown) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="index.htm">回到开始</a>][<a href="54.htm">上一层</a>][<a href="93.htm">下一篇</a>]
<hr><p align="left"><small>发信人: eepaul (阿龙), 信区: UNP <br>
标 题: Re: 帮我调试一下吧 <br>
发信站: UNIX编程 (2001年10月02日23:10:11 星期二), 站内信件 <br>
<br>
Article: 49920 of comp.protocols.tcp-ip <br>
From: ddl@harvard.edu (Dan Lanciani) <br>
Newsgroups: comp.protocols.tcp-ip <br>
Subject: Re: sockets: AF_INET vs. PF_INET <br>
Message-ID: <3561@news.IPSWITCH.COM> <br>
Date: 10 Apr 96 01:27:20 GMT <br>
<br>
In article <3169B256.41C6@engr.sgi.com>, sam@engr.sgi.com (Sam Leffler) writ <br>
es: <br>
| Dan Lanciani wrote: <br>
|> <br>
<br>
|> In article <4k1grt$5gq@noao.edu>, rstevens@noao.edu (W. Richard Stevens) <br>
writes: <br>
|> | > So why the difference? <br>
|> | > AF vs PF? <br>
|> | > What does the difference mean? <br>
|> | <br>
|> | AF = address family. These constants go into the sin_family member of <br>
the <br>
|> | socket address structure. <br>
|> | <br>
|> | PF = protocol family. These constants are the first argument to socket <br>
(). <br>
|> <br>
<br>
|> There is a little more to it than that. Although I don't have the ancien <br>
t <br>
|> sources handy to check (and my memory of this particular aspect is fading <br>
), <br>
|> I recall that the original socket code (4.1c/2.8/2.9BSD) employed a proto <br>
col <br>
|> structure similar in concept to the sockaddr structure. The protocol <br>
|> structure contained a family element and a family-specific protocol numbe <br>
r. <br>
|> The PF_ constants were used for the family element of the protocol struct <br>
ure. <br>
|> A protocol structure (or, rather, the address of one) could be passed to <br>
the <br>
|> socket() call to serve a purpose similar to that of the last (integer) <br>
|> argument <br>
|> argument <br>
|> of the current socket() call. (Keep in mind that the old socket() call d <br>
id <br>
|> not <br>
|> take a family/domain argument at all, so interpretation of the protocol <br>
|> number <br>
|> would not have been possible without the PF_ cue.) Originally, then, the <br>
PF_ <br>
|> and AF_ constants had a much more parallel purpose as structure tags. Wh <br>
en <br>
|> socket() started requiring a family/domain argument, the protocol structu <br>
re <br>
|> was dropped. <br>
| <br>
| Well, actually your memory is a bit off. <br>
While that may well be true in general, I was correct on this issue. :) <br>
| The original socket design included <br>
| a concept termed a "communications domain" (or "communication domain", nev <br>
er <br>
| could decide which was correct :-)). A domain encapsulated many aspects o <br>
f <br>
| communication including the protocol family and address format. Sockets w <br>
ere <br>
ere <br>
| to be created "within a domain" and carried with them the semantics of the <br>
<br>
| domain. This was originally to be carried out using a domain() system cal <br>
l <br>
| that <br>
| returned a descriptor that was then passed as the first argument to socket <br>
(). <br>
The above may describe the original *concept*, but it was not the implementa <br>
tion <br>
in 4.1c/2.9BSD. Whether what you describe ever existed in an implementation <br>
, I <br>
can't say. I do remember that early 4.2 manuals described all sorts of neat <br>
<br>
IPC mechanisms that did not exist in the operating system. Something about <br>
``portals'' comes to mind. <br>
| Along the way we decided this was not worthwhile and replaced the descript <br>
or <br>
| with a manifest constant (PF_*) that referenced a fixed set of domains wit <br>
h <br>
| the associated semantics. <br>
No, the evolution really did include the version I described. It did not <br>
jump from the (hypothetical?) domain() semantics to the current state. <br>
Here is an excerpt from the socket() man page of old: <br>
---------------------------------------------------------------------------- <br>
- <br>
SOCKET(2X) UNIX Programmer's Manual SOCKET(2X) <br>
NAME <br>
socket - create an endpoint for communication <br>
SYNOPSIS <br>
#include <sys/socket.h> <br>
s = socket(type, pf, addr, options); <br>
int type; <br>
struct sockproto *pf; <br>
struct sockaddr *addr; <br>
int options; <br>
---------------------------------------------------------------------------- <br>
- <br>
The type is what you would expect. The pf is the object of interest. <br>
The addr was used in place of a separate bind() and the options argument <br>
encoded bits similar to those used in current setsockopt() calls (plus <br>
the important SO_ACCEPTCONN which pre-dated listen()). <br>
Here is the interesting section from sys/socket.h: <br>
---------------------------------------------------------------------------- <br>
- <br>
- <br>
struct sockproto { <br>
short sp_family; /* protocol family */ <br>
short sp_protocol; /* protocol within family */ <br>
}; <br>
#define PF_UNSPEC 0 /* unspecified */ <br>
#define PF_UNIX 1 /* UNIX internal protocol */ <br>
#define PF_INET 2 /* internetwork: UDP, TCP, etc. */ <br>
#define PF_IMPLINK 3 /* imp link protocols */ <br>
#define PF_PUP 4 /* pup protocols: e.g. BSP */ <br>
#define PF_CHAOS 5 /* mit CHAOS protocols */ <br>
#define PF_OISCP 6 /* ois communication protocols */ <br>
#define PF_NBS 7 /* nbs protocols */ <br>
#define PF_ECMA 8 /* european computer manufacturers */ <br>
#define PF_DATAKIT 9 /* datakit protocols */ <br>
#define PF_CCITT 10 /* CCITT protocols, X.25 etc */ <br>
---------------------------------------------------------------------------- <br>
- <br>
I programmed to these interfaces extensively; I assure you they were/are rea <br>
l. <br>
[...] <br>
|> Now, I would argue that the AF_ family is the correct set of constants <br>
|> for the first argument of socket(). My reason is simply that the constan <br>
ts <br>
|> in the tables in the socket code itself are AF_ values, and the first <br>
|> argument <br>
|> of socket() is compared to these to find the correct domain structure for <br>
<br>
|> the request. <br>
| <br>
| The correct parameter is a PF_foo. <br>
Why? <br>
| In practice however AF_foo = PF_foo and <br>
| at this point any implementation that does not maintain this will break lo <br>
ts <br>
|of code. FWIW my fingers automatically type AF_ when making a socket call <br>
:-). <br>
Good, you are doing the right thing. :) <br>
Dan Lanciani <br>
ddl@harvard.* <br>
<br>
<br>
【 在 eepaul (阿龙) 的大作中提到: 】 <br>
: 【 在 jieer (bbs.dqpi.edu.cn) 的大作中提到: 】 <br>
: : AF_INET和PF_INET有什么区别呀？改成GET也不行 <br>
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <br>
: 在www.kohala.com/start上的paper有一篇就是作者在 <br>
: usenet上关于这个问题的讨轮。 <br>
: http://www.kohala.com/start/lanciani.96apr10.txt <br>
<br>
<br>
-- <br>
Rather than Love...Wealth... <br>
or Fame... <br>
Gave me Truth. <br>
-Walden <br>
※ 修改:·guru 於 10月03日16:14:47 修改本文·[FROM: 202.114.36.210] <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 202.120.224.18] <br>
</small><hr>
<p align="center">[<a href="index.htm">回到开始</a>][<a href="54.htm">上一层</a>][<a href="93.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -