一种文件传输方法 【技术领域】
本 发 明 涉 及 文 件 传 输 方 法， 特 别 涉 及 基 于 简 单 文 件 传 输 协 议 (Trivial FileTransfer Protocol， TFTP) 优化的文件传输方法。背景技术
TFTP 是一个传输文件的简单协议 ( 参考 RFC(Request For Comments)1350)， 其实 现基于用户数据包协议 (User Datagram Protocol， UDP)， 可以在不同网络的主机间进行文 件传送。
下面对 TFTP 进行详细说明。
TFTP 基于 UDP 实现， 其协议分层从下至上依次为物理层、 数据链路层、 互联网协议 (Internet Protocol， IP) 层、 UDP 层、 TFTP 层。TFTP 使用端口 69 作为服务器端口， 其所支 持的指令有如下 5 种。 opcode operation
1 Read request(RRQ)
2 Write request(WRQ)
3 Data(DATA)
4 Acknowledgment(ACK)
5 Error(ERROR)
其中， opcode 为 1、 2、 3、 5 的报文是 TFTP 客户端所使用的报文， 而 opcode 为 3、 4、 5 的报文是 TFTP 服务器所使用的报文。
更具体地， TFTP 指令的 opcode 为 1(RRQ)、 2(WRQ) 时， 指令的报文格式如下。
opcode
filename0mode0其中， opcode 表示指令， 占两个字节， 具体地为 “1” 或 “2” 。filename 表示文件名， 是以 0 为终止符的 ascii 字符串。filename 后紧接一个值为 0 的字节。mode 表示传输模 式， 是以 0 为终止符的 ascii 字符串。TFTP 支持两种传输模式， mode 为字符串 “netascii” ， 则表示数据是 8 位的 ASCII 码形式， 而 mode 为字符串 “octet” ， 则表示数据是 8 位的源数据 类型。mode 后紧接一个值为 0 的字节。
RRQ 指令或 WRQ 指令只能由 TFTP 客户端发起。
TFTP 指令的 opcode 为 3(DATA) 时， 指令的报文格式如下。
opcode
block#data其中， opcode 表示指令， 占两个字节， 具体地为 “3” 。Block# 表示文件数据块号， 占 2 个字节， 且 1 ＜＝ Block# ＜＝ 65535。data 表示文件数据， 占 0 ～ 512 字节。如果不 是最后一个数据块， 则 data 必须为 512 字节， 如果是最后一个数据块， data 必须小于 512 字节 ( 可以为 0)。
如果 TFTP 客户端发起 RRQ( 读文件 )， 则由 TFTP 服务器发送 DATA。
如果 TFTP 客户端发起 WRQ(， 写文件 )， 则由 TFTP 客户端发送 DATA。
TFTP 指令的 opcode 为 4(ACK) 时， 指令的报文格式如下。
opcode
block#其中， opcode 表示指令， 占两个字节， 具体地为 “4” 。Block# 表示文件数据块号， 占 2 个字节， 且 1 ＜＝ Block# ＜＝ 65535， 用于对 opcode 为 1 或 2 的读或写文件指令进行 确认。
每一个 RRQ 或 WRQ 指令必须对应一个确认字符、 即 ACK。如果 TFTP 客户端发起 RRQ( 读文件 )， 则 TFTP 服务器发送 DATA， TFTP 客户端回应 ACK。如果 TFTP 客户端发起 WRQ( 写文件 )， 则 TFTP 客户端发送 DATA， TFTP 服务器回应 ACK。
TFTP 指令的 opcode 为 5(ERROR) 时， 指令的报文格式如下。
opcode
errorcodeerrmsg0其中， opcode 表示指令， 占两个字节， 具体地为 “5” 。errorcode 表示错误号， 占2 个字节， errorcode 的值以及其相应的含义如下。
0 未定义错误， 错误原因参考 errmsg
1 指定的文件不存在
2 指定的文件不允许访问
3 磁盘空间满
4 不可识别的 TFTP opcode
5 IP 报文的传输 ID 错误
6 指定的文件已经存在
7 没有指定的用户
errmsg 表示错误消息， 是以 0 为终止符的 ascii 字符串， 用以提示用户有关错误的 消息。errmsg 后紧接一个值为 0 的字节。
图 1 为表示现有的典型的 TFTP 客户端从 TFTP 服务器获取文件的过程的图。
在步骤 1010， TFTP 客户端向 TFTP 服务器发送读文件指令， 即 opcode 为 1(RRQ) ； filename 为指定要读取的文件名 ； mode 为 “octet” 表示以二进制方式传输。
在步骤 1021， TFTP 服务器收到 TFTP 客户端的读指令后， TFTP 服务器向 TFTP 客户 端发送数据， 即 opcode 为 3(DATA) ； block# 为 1， 表示本次发送的数据是指定文件的第一块 512 字节的数据 ； data 为指定文件的第一块 512 字节的数据。
在步骤 1022， TFTP 客户端收到 TFTP 服务器发送的数据后， TFTP 客户端向 TFTP 服 务器发送确认指令， 即 opcode 为 4(ACK) ； block# 为 1， 表示 TFTP 客户端已经收到步骤 1021 的数据。
在步骤 1031， TFTP 服务器收到 TFTP 客户端的确认指令后， TFTP 服务器向 TFTP 客户端发送数据， 即 opcode 为 3(DATA) ； block# 为 2， 表示本次发送的数据是指定文件的第二 块 512 字节的数据 ； data 为指定文件的第二块 512 字节的数据。
在步骤 1032， TFTP 客户端收到 TFTP 服务器发送的数据后， TFTP 客户端向 TFTP 服 务器发送确认指令， 即 opcode 为 4(ACK) ； block# 为 2， 表示 TFTP 客户端已经收到步骤 1031 的数据。
以此类推， TFTP 服务器与 TFTP 客户端依次发送第 3 块至第 n-1 块的数据及确认 指令。每一个数据块的大小为 512 字节。这里， n 为指定的要读取的文件的数据块数。
接着， 在步骤 10n1， TFTP 服务器向 TFTP 客户端发送数据， 即 opcode 为 3(DATA) ； block# 为 n， 表示本次发送的数据是指定文件的第 n 块数据 ( 也是最后一块数据 )， 数据长 度小于 512 字节 ( 也可以为 0) ； data 为指定文件的第 n 块数据 (， 也是最后一块数据 )。
在步骤 10n2， TFTP 客户端向 TFTP 服务器发送确认指令， 即 opcode 为 4(ACK) ； block# 为 n， 表示 TFTP 客户端已经收到步骤 10n1 的数据 ； 整个文件传输过程结束。
TFTP 协议设计的初旨是进行小文件的传输， 因此很容易实现， 但不具备通常的文 件传输协议 (File Transfer Protocol， FTP) 所具有的许多功能， 例如 TFTP 只能从文件服 务器上下载文件或向文件服务器上载文件， 而不能像 FTP 那样列出目录， 也不具有 FTP 所具 有的认证功能。尤其， 最早的 TFTP 协议因太过简单， 而有很多限制。比如， 文件块只能是 512 字节， 传输效率低， 再则没有约定超时机制。 为解决这些问题， 对 TFTP 协议进行了扩展， 具体地， RFC2347 允许扩展选项， RFC2348 允许文件块大小协商， RFC2349 允许超时协商。
具体地， 当 TFTP 指令的 opcode 为 1、 2 时， 指令的报文格式如下。 opcode filename 0 mode 0 op 0 value 0其中， opcode、 filename 及 mode 的含义不变。mode 后可以跟多个选项对。每个选 项对由一个 op 和一个 value 构成， op 和 value 后紧跟一个值为 0 的字节。op 为自定义选 项名称， 是以 “0” 为终止符的 ascii 字符串。value 为自定义选项值， 是以 “0” 为终止符的 ascii 字符串。
比如在 RFC2348 中， 允许协商 data 的大小， 此时， op 为 “blksize” ， value 为字符 串， 该字符串为数字， 单位为字节， 比如 “1428” 表示 1428 字节。
而在 RFC2349 中， 则允许协商重传时间。此时， op 为 “timeout” ， value 为字符串， 该字符串表示数字， 单位为秒， 比如 “30” 表示 30 秒。并且， 在 RFC2349 中， 允许通告文件大 小， 此时， op 为 “tsize” ， value 为字符串， 该字符串表示数字， 单位为字节， 比如 “234567” 表示 234567 字节。
而且， 新增如下的 TFTP 指令。
opcode operation
6 acknowledge the options(OACK)
上述 OACK 指令、 即选项确认字符指令的报文格式如下
opcodeop0value0其中， opcode 表示指令， 占两个字节， 具体地为 “6” 。 opcode 后可以跟多个选项对。 每个选项对由一个 op 和一个 value 构成， op 和 value 后紧跟一个值为 0 的字节。op 为自 定义选项名称， 是以 “0” 为终止符的 ascii 字符串。value 为自定义选项值， 是以 “0” 为终 止符的 ascii 字符串。
TFTP 服务器收到携带选项的 RRQ 或 WRQ 后， 回应 OACK。 如果 TFTP 服务器支持 TFTP 客户端指定的选项， 则 OACK 中携带对应的选项对， op 为 TFTP 客户端发送的选项名， value 为 TFTP 服务器支持的相应 op 选项的值。
通过 TFTP 客户端携带自定义选项， TFTP 服务器回应 OACK， TFTP 服务器和客户端 可以协商具体的选项。TFTP 客户端收到 TFTP 服务器的 OACK 后， 回应 ACK(black# 为 0)， 表 示接受 TFTP 服务器的选项值。
以下， 将 RFC2347、 RFC2348、 RFC2349 中带有扩展选项 op 及 value 的 TFTP 指令称 为 TFTP 扩展指令。
图 2 为以支持文件传输块大小协商的 RFC2348 为例， 示出 TFTP 客户端从 TFTP 服 务器获取文件的过程的图。
在步骤 2011， TFTP 客户端向 TFTP 服务器发送读文件指令， 即 opcode 为 1(RRQ) ； filename 为指定要读取的文件名 ； mode 为 “octet” 表示以二进制方式传输 ； 第一个自定义 选项关键字 (op) 为 “blksize” ， 第一个自定义选项值 (value) 为 1432。 在步骤 2012， TFTP 服务器收到步骤 2011 中由 TFTP 发送的指令后， 发现有自定 义选项 “blksize” ， TFTP 服务器本身支持这个自定义选项 (“blksize” ) 和自定义选项值 (1432)， 则回应 TFTP 客户端 OACK， 即 opcode 为 6(OACK) ； 第一个自定义选项关键字 (op) 为 “blksize” ， 第一个自定义选项值 (value) 为 1432， 表示确认支持 TFTP 客户端指定的自定义 选项。
在步骤 2013， TFTP 客户端收到 TFTP 服务器发送的 OACK， 发现 TFTP 服务器支持自 己 (TFTP 客户端 ) 指定的自定义选项 “blksize” 及选项值 “1432” ， 说明选项协商成功， 回应 TFTP 服务器 ACK， 即 opcode 为 4(ACK) ； block# 为 0， 表示选项协商成功。
在步骤 2021， TFTP 服务器收到 TFTP 客户端的选项协商成功确认后， 向 TFTP 客户 端发送第一块数据， 即 opcode 为 3(DATA) ； block# 为 1， 表示本次发送的数据是指定文件的 第一块 1432 字节的数据 ； data 为指定文件的第一块 1432 字节的数据。
在步骤 2022， TFTP 客户端向 TFTP 服务器发送确认指令， 即 opcode 为 4(ACK) ； block# 为 2， 表示 TFTP 客户端已经收到步骤 2021 的数据。
接着， TFTP 服务器与 TFTP 客户端依次发送第二块至第 n-1 块的数据及确认指令。 每一个数据块的大小为 1432 字节。这里， n 为指定的要读取的文件的数据块数。
接着， 在步骤 20n1， TFTP 服务器向 TFTP 客户端发送数据， 即 opcode 为 3(DATA) ； block# 为 n， 表示本次发送的数据是指定文件的第 n 块数据 ( 也是最后一块数据 )， 数据长 度小于 1432 字节 ( 也可以为 0) ； data 为指定文件的第 n 块数据 ( 也是最后一块数据 )。
在步骤 20n2， TFTP 客户端向 TFTP 服务器发送确认指令， 即 opcode 为 4(ACK) ； block# 为 n， 表示 TFTP 客户端已经收到步骤 20n1 的数据 ； 整个文件传输过程结束。
上述的 RFC2347、 RFC2348、 RFC2349 只是对 TFTP 协议进行扩展， 优化了传输效率， 但本质上还是客户机 / 服务器 (Client/Server， CS) 结构， 无法消除 TFTP 服务器性能瓶颈
的隐患。 发明内容 鉴于现有 TFTP 中存在的问题， 本发明提供了一种文件传输方法， 能够消除由于 CS 结构导致的 TFTP 服务器性能瓶颈。
为了实现上述目的， 根据本发明的一种文件传输方法， 其特征在于， 包括步骤 ： 所 述客户端向固定服务器端请求下载指定文件 ； 所述固定服务器指示所述客户端从固定服务 器或临时服务器下载所述指定文件， 其中， 所述临时服务器是指曾经作为客户端下载过并 保存有所述指定文件而且能够向所述客户端提供文件下载服务的其他客户端 ； 所述固定服 务器保存有临时服务器列表， 所述临时服务器列表记录有所有构成临时服务器的所述其他 客户端的互联网协议地址。
并且， 上述的文件传输方法中， 其特征在于， 所述固定服务器指示所述客户端从一 个固定服务器或临时服务器下载所述指定文件的全部， 或从多个固定服务器或临时服务器 分别下载所述指定文件的一部分， 而组成整个所述指定文件。
并且， 上述的文件传输方法中， 其特征在于， 所述客户端向所述固定服务器发送的 简单文件传输协议 (TFTP) 的文件下载请求 (RRQ) 包含一对由自定义选项名称 (op) 和自定 义选项值 (value) 构成的自定义选项对， 所述自定义选项名称为 “p2p” ， 用于表示所述客户 端支持点对点文件传输机制 ； 所述固定服务器向所述客户端回应选项确认指令 (OACK)， 所 述选项确认指令 (OACK) 包含所述自定义选项对， 所述自定义选项名称为 “p2p” ， 则表示所 述固定服务器支持点对点文件传输机制。
并且， 上述的文件传输方法中， 其特征在于， 所述文件下载请求 (RRQ) 中所包含自 定义选项值 (value) 包含文件模式 (file-mode) 位， 用于表示所述客户端可以从一个固定 服务器或临时服务器下载所述指定文件的全部， 或可以从多个固定服务器或临时服务器分 别下载所述指定文件的一部分， 而组成整个所述指定文件， 或表示该两种模式均支持 ； 所述 选项确认指令 (OACK) 中所包含自定义选项值 (value) 包含文件模式 (file-mode) 位， 用于 指示所述客户端从一个固定服务器或临时服务器下载所述指定文件的全部， 或从多个固定 服务器或临时服务器分别下载所述指定文件的一部分， 而组成整个所述指定文件， 或指示 任意选择该两种模式之一。
并且， 上述的文件传输方法中， 其特征在于， 所述文件下载请求 (RRQ) 中所包含自 定义选项值 (value) 还包含第一互联网地址 (first-ip)， 所述第一互联网地址 (first-ip) 为所述固定服务器的互联网协议地址 ； 所述选项确认指令 (OACK) 中所包含自定义选项值 (value) 还包含第一互联网地址 (first-ip)， 所述第一互联网地址 (first-ip) 为所述固定 服务器的互联网协议地址。
并且， 上述的文件传输方法中， 其特征在于， 所述选项确认指令 (OACK) 中所包含 自定义选项值 (value) 还包含计数 (count) 位， 用于表示所述固定服务器指示所述客户端 用于下载文件的固定服务器或临时服务器的个数。
并且， 上述的文件传输方法中， 其特征在于， 当所述计数 (count) 位为 “0” ， 表示所 述固定服务器指示所述客户端从所述固定服务器下载完整的所述指定文件。
并且， 上述的文件传输方法中， 其特征在于， 当所述计数 (count) 位为 “1” ， 所述选
项确认指令 (OACK) 中所包含自定义选项值 (value) 还包含一个第二互联网协议地址 (ip) 时， 表示所述固定服务器指示所述客户端可以从所述固定服务器或所述第二互联网协议地 址 (ip) 的临时服务器下载完整的所述指定文件。
并且， 上述的文件传输方法中， 其特征在于， 当所述计数 (count) 位的值大于 1， 所 述选项确认指令 (OACK) 中所包含自定义选项值 (value) 还包含多个第二互联网协议地址 (ip) 及多个下载开始位置 (begin)、 下载结束位置 (end) 时， 表示所述固定服务器指示所述 客户端从所述多个互联网协议地址 (ip) 的临时服务器分别下载所述指定文件的所述下载 开始位置 (begin) 和下载结束位置 (end) 之间所对应的部分。
并且， 上述的文件传输方法中， 其特征在于， 所述文件下载请求 (RRQ) 中所包含自 定义选项值 (value) 包含工作模式 (work-mode) 位， 使用值 “1” 表示所述客户端只能工作 在客户端模式， 或使用值 “2” 表示所述客户端在下载完毕所述指定文件后， 还可以作为临时 服务器向其他客户端提供文件下载服务 ； 所述文件下载请求 (RRQ) 中所包含自定义选项值 (value) 包含工作模式 (work-mode) 位表示所述客户端在下载完毕所述指定文件后作为临 时服务器工作时， 所述固定服务器将所述客户端作为与所述指定文件相对应的临时服务器 记录到所述临时服务器列表中。
并且， 上述的文件传输方法中， 其特征在于， 所述选项确认指令 (OACK) 中所包含 自定义选项值 (value) 还包含工作模式 (work-mode) 位， 使用值 “3” 表示所述固定服务器 的工作模式为固定服务器。
并且， 上述的文件传输方法中， 其特征在于， 所述文件下载请求 (RRQ) 中所包含自 定义选项值 (value) 包含时间 (time) 位， 用于表示所述客户端能够工作在临时服务器模式 的时间长度 ； 所述固定服务器将所述时间 (time) 作为所述临时服务器的信息记录到所述 临时服务器列表中。
并且， 上述的文件传输方法中， 其特征在于， 所述选项确认指令 (OACK) 中所包含 自定义选项值 (value) 还包含时间 (time) 位， 使用无限大值表示所述固定服务器工作在固 定服务器模式。
根据本发明的文件传输方法， 文件传输设备并非固定为客户端或服务器端， 而是 即可以工作于客户端模式或服务器模式， 也可以工作在客户端模式的同时， 支持作为临时 的服务器。因此能够实现点对点文件传输机制， 消除了由于 CS 结构导致的 TFTP 服务器性 能瓶颈。 附图说明
通过下面结合附图进行的描述， 本发明的上述和其他目的和特点将会变得更加清 楚， 其中 ：
图 1 为表示现有的典型的 TFTP 客户端从 TFTP 服务器获取文件的过程的图 ；
图 2 为以支持文件传输块大小协商的 RFC2348 为例， 示出 TFTP 客户端从 TFTP 服 务器获取文件的过程的图 ；
图 3 为表示根据本发明实施方式的 TFTP 客户端 1 下载文件 A 的具体过程的图 ；
图 4 为表示根据本发明实施方式的 TFTP 客户端 2 下载文件 A 的具体过程的图 ；
图 5 为示出了根据本发明实施方式的 TFTP 客户端 2 从 TFTP 客户端 1 下载文件的具体过程的图 ；
图 6 为示出了根据本发明实施方式的 TFTP 客户端 3 从 TFTP 服务器 1 下载文件 A 的具体过程的图 ；
图 7 为示出了根据本发明实施方式的 TFTP 客户端 3 从临时服务器 ( 即 TFTP 客户 端 1) 下载文件的一部分的具体过程的图 ；
图 8 为示出了根据本发明实施方式的 TFTP 客户端 3 从临时服务器 ( 即 TFTP 客户 端 2) 下载文件 A 的剩余部分数据的具体过程的图。 具体实施方式
以下， 参照附图及表格详细说明本发明的实施方式。
( 实施方式 )
根据本发明的实施方式的文件传输方法， 是基于 RFC2347 对 TFTP 进行的优化， 具 体地， 扩展 TFTP 选项， 引入点对点 (Peer-to-Peer， p2p) 机制。
通过在文件传输设备之间引入 p2p 机制， 文件传输设备并非固定为客户端或服务 器端， 而是即可以工作于客户端模式或服务器模式， 也可以工作在客户端模式的同时， 支持 作为临时的服务器。 具体地， p2p 机制是指客户端先从一个服务器 ( 这里称为 first) 获取文件信息， 文件信息中包含 “文件大小” 以及 “表示哪些其它服务器 ( 这里称为 second， 可能是多个 ) 可以提供指定的下载文件的信息” 等。
此时， 自定义选项名称、 即 op 为 “p2p” ， 是以 0 为终止符的 ascii 字符串。该 op 选 项只支持 RRQ( 即下载文件 ) 和 OACK 指令指令。相应地， 自定义选项值、 即 value 为变长字 节数值， 其构成为 work-mode+file-mode+first-ip+time+count+info-list。
work-mode 表示工作模式， 为 1 字节数值， 数值为 “1” 则表示文件传输设备工作 在客户端模式， 数值为 “2” 则表示文件传输设备工作在客户端模式， 同时支持作为临时的 TFTP 服务器。数值为 “3” 则表示设备工作在服务器模式， 即固定作为 TFTP 服务器。
fle-mode 表示文件获取模式， 为 1 字节数值。 bit0， 对于 TFTP 客户端， 表示支持从 指定的一个 TFTP 服务器 ( 包括临时或固定的 TFTP 服务器 ) 下载完整文件， 而对于 TFTP 服 务器， 表示允许一个 TFTP 客户端从自己这里下载指定的完整的文件。bit1， 对于 TFTP 客户 端， 表示支持从指定的多个 TFTP 服务器 ( 包括临时或固定的 TFTP 服务器 ) 下载所述指定 文件的不同部分 ； 而对于 TFTP 服务器， 表示允许一个 TFTP 客户端从自己这里下载所述指定 文件的一部分数据， 其它位保留。
bit0 和 bit1 不冲突， 可以同时置位， bit0 和 bit1 同时置位时， 对于 TFTP 客户端， 表示既可以从指定的一个 TFTP 服务器 ( 包括临时或固定的 TFTP 服务器 ) 下载完整文件， 也可以从指定的多个 TFTP 服务器 ( 包括临时或固定的 TFTP 服务器 ) 下载所述指定文件的 不同部分。而对于 TFTP 服务器， 则表示既允许一个 TFTP 客户端从自己这里下载指定的完 整的文件， 也允许一个 TFTP 客户端从自己这里下载所述指定文件的一部分数据。
first-ip 表示 TFTP 服务器 IP 地址， 为 4 字节数值。
(1) 当 TFTP 客户端向 frst 发起 RRQ 请求时， first-ip 为 first 的 IP 地址。first 收到 TFTP 客户端的 RRQ 请求后可以校验 first-ip 是否为自己的 IP 地址。Second 收到 TFTP 客户端的 RRQ 请求后可以校验 first-ip 是否是自己信任的 first 推荐过来的。
(2) 当 TFTP 服务器 ( 包括临时 TFTP 服务器 ) 回应 OACK 时， first-ip 为前面 RRQ 请求中相应的 first-ip。