rfcrfc951.txt

本程序为在linux下实现FTP传输文件的实现

	
	      'op'设置成'1'，BOOTREQUEST（引导请求）。'htype'设置成在"Assigned
	      Numbers" RFC ARP章节中分配的硬件地址类型。
	      'hlen'设置成硬件地址长度，例如，10M以太网是'6'。
	
	      'xid'设置成一个'随机'事务ID。'secs'设置成客户端引导开始后过去的秒数。
	      这个让服务器知道客户端已经试了多长时间了。
	      当数字变大，某些服务器可能更多注意这个客户端提供不同的服务。
	      如果客户端缺少一个适当的时钟，它可以使用循环定时器建立一个粗略的估计值。
	      或者它可以选择简单发送使用一个固定值如100秒的字段。
	
	      如果客户端知道IP地址，'ciaddr'（和IP源地址）设置成这个值。
	      'chaddr'使用客户端硬件地址填写。
	
	      如果客户端希望限制从一个特定服务器名引导，就可以在'sname'中放一个空结束的字符
串。
	      使用的名字应该是对应的主机的正当的名字或别名。
	
	      客户端在填写'file'文件名字段是有许多选择。
	      如果设置成空，意味着'我向使用默认的文件来引导我的机器'。一个空文件名也意味着
	      '我只对找到客户端/服务器/网关的IP地址感兴趣，我不在乎文件名'。
	
	      这个字段也可以是一个'通用'名字入'unix'或'gateway'；这意味着
	
	      '使用命名的程序配置来引导我的机器'。最后这个字段可以是确切的目录路径名字。
	
	      'vend'字段可以由客户端填写卖主的字符串或结构。例如可以填写机器硬件类型或序列
号。
	      但BOOTP服务器的操作应该不依赖与这些存在的信息。
	
	      如果使用了'vend'，推荐在'vend'中第一个项目为一个4字节的'魔术字(magic number)'。
	      这让服务器确定在这个字段中它看到什么类型的信息。
	      数值可以由通常的'魔术字'过程分配，你挑一个，它就成为魔术字。
	      引导应答使用一个与引导请求不同的魔术字以允许客户端按照应答信息进行特殊的动
作。
	
	      [UDP校验和]
	
6.2   客户端重传策略
	
	      在一长段时间内没有收到应答，客户端应该重传请求。
	      时间间隔必须仔细选择不要引起网络风暴。
	      可以考虑一个包含100台机器的网络在电源故障后发生的情况。
	      简单的每四秒重传请求将淹没网络。
	
	      一个可能的策略，你可能考虑指数级的补偿，象以太网在碰撞时那样。
	      例如第一个包在0:00，第二个在:04，接着:08，接着:16，:32，:64。
	      你应该随机化每个时间；这就象以太网规格那样以一个掩码'与'一个随机数进入第一次补
偿。
	      在每次后续的补偿中，掩码增长一个比特。
	      这样在每次补偿中平均延迟加倍。
	
	      在'平均'补偿到达60秒后，就不再增长了，但仍然随机化。
	
	      在每次重传前，客户端应该修改'secs'字段。[UDP校验和]
	
6.3  服务器接收BOOTREQUEST（引导请求）
	
	      [UDP校验和]  如果UDP目的端口不匹配'BOOTP服务器'端口，丢弃这个包。
	
	      如果服务器名字字段(sname)是空（没有指定特定的服务器），或者sname是指定的并且
匹配我们的名字或别名，
	      继续包的处理。
	
	      如果sname字段是指定的，但不匹配'我们'，那么有多种选择：
	
	         1.你可以选择简单丢弃这个包。
	
	         2.如果查询sname的名称显示它在一个网络中，丢弃这个包。
	
	         3.如果sname在不同的网络中，你可以选择转发这个包到那个地址。
	         如果这样，检查'giaddr'(网关地址）字段。如果'giaddr'是0，填入我的地址或可以用来
到达那个网络的网关的地址。
	         然后转发这个包。
	
	      如果客户端IP地址（ciaddr）是0，那么客户端不知道自己的IP地址。
	      尝试在我们的数据库中查找客户端的硬件地址(chaddr, hlen, htype)。
	      如果没有匹配，丢弃这个包。否则我们现在对这个客户端有一个IP地址；填入'yiaddr'（你
的IP地址）字段。
	
	      我们现在检查引导文件名字段（文件）。如果客户端不关注文件名或想要默认引导文件，
这个字段是空。
	      如果这个字段非空，可以将它和客户端的IP地址做为数据库的查询关键字。
	      如果有默认的文件或通用文件（可能由客户端地址做为索引）或一个匹配的指定的路径
名称，
	      然后在'file'字段中填入选择的引导文件的指定的路径名称。
	      如果字段是非空并且没有匹配，那么客户端要一个我们没有的文件，丢弃这个包，也许
其它BOOTP服务器有这个文件。
	
	      卖主指定的数据字段'vend'现在应该检查了。如果提供一种可识别类型的数据，
	      应该进行客户端指定的动作，并且回应要填入应答包中的'vend'数据字段。
	      例如，一个工作站客户端可能提供一个验证字，并从服务器接收一个访问远端文件的权
限，
	
	      或一套配置选项传给马上就要引导入的操作系统。
	
	      我的（服务器）IP地址填入'siaddr'字段。设置'op'字段为BOOTREPLY（引导应答）。
	      UDP目的端口设置成'BOOTP客户端'。如果客户端地址'ciaddr'非0，把包发送到那里；
	      否则如果网关地址'giaddr'非0，设置UDP目的端口为'BOOTP服务器'并把包发送到
'giaddr'。
	      否则客户端在我们的一个网络中但它还不知道自己的IP地址，使用在上面'蛋'章节中描述
的方法来传送它到客户端。
	      如果使用'蛋'并且我们在主机上有许多接口，使用'yiaddr'（你的IP地址）字段指出发送包
到哪个网络（网络/接口）。
	      [UDP校验和]
	
6.4  服务器/网关接收BOOTREPLY（引导应答）
	
	      [UDP校验和] 如果'yiaddr' (你的[客户端的]IP地址)指向我们的一个网络，使用上述'蛋'方
法来将它转发到客户端。
	      确认将它传送到'BOOTP客户端'UDP目的端口。
	
6.5   客户端接收
	
	      不要忘记为我自己的IP地址（如果我知道）处理ARP请求。[UDP校验和]
	      客户端应该丢弃以下进入的包：不是定位到引导端口的IP/UDP；不是BOOTREPLY（引
导应答）；
	      不匹配我的IP地址（如果我知道）或我的硬件地址；不匹配我的事务ID。
	      否则我们就收到一个成功的应答。如果我以前不知道的话，'yiaddr'包含我的IP地址。
	      'file'是TFTP'读请求'的文件名。服务器地址在'siaddr'中。如果'giaddr'（网关地址）非0，
	      那么包应该先转发到那里，然后到达服务器。
	
7	 通过网关引导
	
	   这部分协议是可选的并要求许多网关和服务器配合的额外的代码，但它允许跨越网关引导。
	   这主要在网关是无盘机器时有用。
	   带盘网关（例如，一个做为网关的UNIX机器）可能运行它们自己的BOOTP/TFTP服务器。
	
	   侦听BOOTREQUEST（引导请求）广播的网关可能确定转发还是适当地再广播这些请求。
	
	   例如，做为配置表格的一部分，网关可以有一个接收任意BOOTREQUEST（引导请求）广
播的其它网络或主机的列表。
	   即使考虑有一个'hops'字段，简单全部再广播请求仍是一个差的方法，因为广播循环几乎肯
定会发生。
	
	   转发可以立即开始，或等'secs'（客户端尝试的秒数）字段超过某个阀值。
	
	   如果一个网关确定转发请求，它应该查看'giaddr' （网关IP地址）字段。
	   如果是0，它就在这个字段中加入自己的IP地址（在接收的网络中）。
	   也可以使用'hops'字段来可选控制包可以转发多远。每次转发应该增加跳数。
	   例如，如果跳数超过'3'，包应该被丢弃。
	   [UDP校验和]
	
	   这里我们推荐在网关中增加这个特殊的转发功能。
	   但不总是这样子的。
	   在网上存在一些'BOOTP转发代理'引导客户端，这些代理可以适当地转发。
	   这样这些服务可以和网关在一起，也可以不在一起。
	
	   当转发代理不和网关在一起时，代理可以通过在接收的引导请求中'giaddr'字段加上接口的广
播地址节省一些工作。
	   这样应答就可以使用普通的网关来转发，而不包含转发代理。
	   当然劣势是你失去了使用'蛋'非广播方式来发送应答的能力，导致在客户端网上的每个主机
的额外的花费。
	
8	 样例BOOTP服务器数据库
	
	   做为一个建议，我们提供一个BOOTP服务器查询可以使用的样例文本文件数据库。
	   数据库有两个节，使用第一列使用一个百分符的行做为定界符。
	   第一个节包含一个'默认目录'，和从通用名称到目录/路径的映射。
	   这个节中第一个通用名称是当引用请求包含空'file'字符串是你使用的'默认文件'。
	
	   第二节映射硬件地址类型/地址到IP地址。可选的，你可以使用一个特定IP地址的通用名称
来忽略默认通用名称。
	   一个'后缀'项目也是可选的；如果提供，可以访问任意客户端特定的通用名称对应的'路径名
称'加上'后缀'。
	
	   如果那个文件没有找到，就尝试简单的'路径名称'。
	   这个'后缀'选项允许轻而易举建立整套用户通用（配置）。
	   
	   下面显示通用格式；一个或多个空格或TAB来定界字段；后面的空字段被省略；空行和以'#'
开始的行忽略。
	
	      # comment line
	
	      homedirectory
	      genericname1    pathname1
	      genericname2    pathname2
	      ...
	
	      % end of generic names, start of address mappings
	
	      hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
	      hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
	      ...
	
	   这是一个特定的样例。注意'硬件类型'数值同'Assigned Numbers' RFC中ARP章节。
	   '硬件类型'和'IP地址'数值是十进制；'硬件地址'是十六进制的。
	
	      # last updated by smith
	
	      /usr/boot
	      vmunix          vmunix
	      tip             ethertip
	      watch           /usr/diag/etherwatch
	      gate            gate.
	
	      % end of generic names, start of address mappings
	
	      hamilton        1 02.60.8c.06.34.98     36.19.0.5
	      burr            1 02.60.8c.34.11.78     36.44.0.12
	      101-gateway     1 02.60.8c.23.ab.35     36.44.0.32      gate 101
	      mjh-gateway     1 02.60.8c.12.32.bc     36.42.0.64      gate mjh
	      welch-tipa      1 02.60.8c.22.65.32     36.47.0.14      tip
	      welch-tipb      1 02.60.8c.12.15.c8     36.46.0.12      tip
	
	   在上述样例中，如果'mjh-gateway'是一个默认的引导程序，它将得到文件'/usr/boot/gate.mjh'。
	
9	 致谢
	
	   Ross Finlayson等早先提出了两个使用讨论RARP[1]的TFTP引导的RFC。
	   
	   我们感谢Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, 和David Plummer的前期工作和
注解。
	
10	参考文献
	
	   1.  Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer.  A
	       Reverse Address Resolution Protocol.  RFC 903, NIC, June, 1984.
	
	   2.  Ross Finlayson.  Bootstrap Loading using TFTP.  RFC 906, NIC,
	       June, 1984.
	
	   3.  Mark Lottor.  Simple File Transfer Protocol.  RFC 913, NIC,
	       September, 1984.
	
	   4.  Jeffrey Mogul.  Broadcasting Internet Packets.  RFC 919, NIC,
	       October, 1984.
	
	   5.  David Plummer.  An Ethernet Address Resolution Protocol.  RFC
	       826, NIC, September, 1982.
	
	   6.  Jon Postel.  File Transfer Protocol.  RFC 765, NIC, June, 1980.
	
	   7.  Jon Postel.  User Datagram Protocol.  RFC 768, NIC, August, 1980.
	
	   8.  Jon Postel.  Internet Protocol.  RFC 791, NIC, September, 1981.
	
	   9.  K. R. Sollins, Noel Chiappa.  The TFTP Protocol.  RFC 783, NIC,
	       June, 1981.
	
	
RFC951——RFC951-BOOTSTRAP PROTOCOL (BOOTP)                    引导协议(BOOTP)


1
RFC文档中文翻译计划