CN1655550A - 用于包括广播功能的简化文件传输协议的系统和方法 - Google Patents

用于包括广播功能的简化文件传输协议的系统和方法 Download PDF

Info

Publication number
CN1655550A
CN1655550A CNA2005100067572A CN200510006757A CN1655550A CN 1655550 A CN1655550 A CN 1655550A CN A2005100067572 A CNA2005100067572 A CN A2005100067572A CN 200510006757 A CN200510006757 A CN 200510006757A CN 1655550 A CN1655550 A CN 1655550A
Authority
CN
China
Prior art keywords
client computer
server
broadcast
option
response message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CNA2005100067572A
Other languages
English (en)
Inventor
白承学
崔炳求
朴容奭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of CN1655550A publication Critical patent/CN1655550A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种用于简化传输扩展协议(TFTP)的系统和方法包括其中将新选项添加到TFTP中以允许多个客户机与一个服务器相连来同时下载文件的广播功能。该方法包括：第一步骤，由第一客户机将扩展读请求消息发送到服务器，以请求广播文件传输；第二步骤，由服务器将通知第一客户机是主客户机的选项应答消息发送到第一客户机；第三步骤，由第二客户机将扩展读请求消息发送到服务器，以请求广播文件传输；第四步骤，由服务器将通知第二客户机不是主客户机的选项应答消息发送到第二客户机；第五步骤，由服务器广播数据，然后等待接收来自第一客户机的应答消息；以及第六步骤，如果服务器接收到来自第一客户机的应答消息，则由服务器来重复进行第五步骤，直到服务器发送了所有剩余的数据。

Description

用于包括广播功能的简化文件传输协议的系统和方法
技术领域
本发明涉及一种简化文件传输协议的系统和方法(以下称作“TFTP”)，更具体地，涉及一种用于包括广播功能的TFTP的系统和方法，其中将新选项添加到TFTP中，以允许多个客户机与一个服务器相连，从而同时下载文件。
背景技术
在大多数系统中，将数据表示为被称作文件的单元。需要传送文件和部分文件，以便在系统之间传送数据。
在通过网络互连的系统中，在一个系统的用户希望从其它系统接收数据到他或她的系统，或从他或她的系统向其它系统传送数据的情况下，即，当系统希望彼此进行通信的情况下，需要规则和规章来允许这些系统彼此进行通信。将所述规则和规章称作协议。
此时，将请求数据传输的系统称作客户机系统，而将响应这种请求来提供服务的系统称作服务器系统。通常，多个客户机系统与一个服务器系统相连。
在计算机网络中专用的语言是传输控制协议/因特网协议(TCP/IP)。基于TCP/IP的协议包括文件传输协议(FTP)、终端仿真协议(Telnet)、超文本传输协议(HTTP)等。
这里，文件传输协议(FTP)的目的是在FTP用户的指令下，将一个文件或部分文件从一个系统传送到其它系统。
大部分FTP被在线用户交互的使用。由操作系统来仲裁FTP用户之间的通信。该操作系统具有输入/输出(I/O)驱动器。如果系统A的用户希望访问系统B中的文件，则系统A中的FTP建立与系统B中FTP的连接。当然，这是逻辑连接。通过协议栈的各个层来形成用于控制信息和用户数据的实际路径。
同时，简化文件传输协议(TFTP)是一种FTP。将其设计为比FTP更简单并且只能由小型代码来实现。在只读存储器(ROM)中能够容易地实现TFTP，并且通常用作在无盘系统中下载操作系统图像的协议。
一般地，FTP是一种利用TCP来按照可靠且面向连接的方式来发和接收文件的协议，而TFTP是一种利用用户数据报协议(UDP)的非连接文件传输协议。当路由器下载配置文件和IOS图像时主要使用TFTP。由于没有安全选项，TFTP展示了比FTP更快的速度。
通过检查两个协议的内容可以理解TCP和UDP之间传输的差异。如上所述，TCP是一种面向连接的可靠协议，并且通过滑动窗口(sliding window)来控制流量。
此外，TCP利用序列号和批准号来进行控制。TCP重新发送没有接收到应答(ACK)的所述数据，并且只有当接收到通知已经接收到数据的信号时，才发送下一个数据，以保证数据传输中的可靠性。
然而，与TCP不同，由于不具有检查数据是否完好到达的功能(检验和(checksum))，UDP具有更快的传输速度，并且由于其不具有连接，因此UDP不必传送控制帧，由此减小了网络负荷。
由于UDP不具有确认过程或流量控制，应用程序必须充当以代替执行。可以认为UDP是单向传输。这是因为没有通知数据成功到达的ACK(应答)码的重新传输。
很久以前，设计上述TFTP协议来传送小规模的文件。与因特网FTP相比，这很容易实现，具有服务器—客户机配置并使用了IP/UDP。IETF RFC1350(Internet engineering task force request for comments1350)中已经定义了相关协议。
到目前为止，由于其易于传送小规模程序的文件，正在广泛使用利用该协议的多种系统。然而，由于512字节的固定数据传输和最大65535的块大小的限制，不可能传送32M字节(百万字节)或更多的数据。
为了克服这些限制，后来添加了选项功能。通过允许这种功能来调整数据的传输大小，TFTP协议变得更有价值。该内容被标准化为RFC(请求评论)2347 TFTP选项扩展，RFC 2348Blocksize选项。
此外，RFC2090是使能多播的多播选项。然而，RFC2090是一种实验版本而并没有标准化。可以在服务器中实现，但不能在大多数客户机中实现。
当前，Berkeley Software Distribution(Berkeley Software Design；BSD)、UNIX和Linux系列中均基本地提供了TFTP服务器—客户机程序。在Windows系列中，有作为免费软件的多个可用程序。
在较好实现了网络功能的情况下，不能较好地使用该TFTP协议，但在按照基本方式启动之后个人计算机(PC)或多个系统(即，几乎具有网络功能的所有设备)必须下载分组而没有需首先需要操作系统(OS)的情况下，其有着广泛应用。
由于采用了TFTP协议，基本上，服务器和客户机按照一对一的方式进行操作，这不适于多个客户机从一个服务器下载文件。
在PC(个人计算机)群环境中，或一个设备有多个模块构成且在电源打开时每一个模块必须从主模块下载基本文件的环境中，网络负荷增大且文件传送错误也增大，这是由于如果多个客户机试图同时从服务器下载文件，则服务器试图按照一对一的方式传送文件。
为了克服此问题，RFC2090中定义了多播TFTP。然而，其处于实验状态且并没有标准化，并且对于在客户机实现非常复杂。
在RFC2090中定义的多播功能中，需要当传输时使用的多播IP地址，此外，由于如果客户机进行连接的同时其它客户机下载文件，则客户机会从文件的中部下载文件，客户机本身必须具有重新组合文件块的功能。
然而，由于TFTP通常用于初始化启动而不是正常网络功能已经建立时，采用客户机中已实现的程序只能进行最简单的操作。
因此，在大多数TFTP功能中，即时增强了服务器程序使其具有复杂的功能也不存在问题。然而，由于作为客户机的TFTP功能非常简单，很难处理例如块重新组合的功能。
在这种情况下，TFTP客户功能按照块数目(#)顺序提供并提取数据分组和ACK分组，其中如果在传输期间丢失任意分组，则阻塞了客户机的操作。文件传输本身停止或有定时器重新启动。
此外，尽管采用了RFC2090来支持TFTP的多播，根据情况不必使用多播的可能性很高。在一个设备中建立内部网络的环境中进行用于正常操作的文件传输的情况下，其中一个主要部分充当TFTP服务器且剩余部分充当TFTP客户机，存在一对一传输花费过多时间并引起传输错误的高可能性。
然而，不必在内部分析并操作多播组。
发明内容
因此，设想本发明来解决上述和其它问题，本发明的目的是提供一种用于包括广播功能的简化文件传输协议的系统和方法，其中定义用于广播的TFTP选项以添加广播功能，当多个客户机同时向一个服务器请求文件传输时，通过广播来传送文件，与使用多播相比，导致了简单的操作。
本发明的另一个目的是提供一种利用广播TFTP的方法和设备，使传输速度快于现有的一对一传输方式，这使得多个客户机可以按照快而有效的方式从一个服务器下载文件。
本发明的另一个目的是除了广播选项扩展以外，提供当添加块大小选项时，块大小大于之前的块大小，以允许更快的文件传输。
本发明的另一个目的是提供最有效的文件传输，其中子网络是广播网络，存在多个客户机且需要同步文件传输。
本发明的另一个目的是提供最大传输操作效率，同时使所添加的功能最少，这是由于TFTP不用于其中所有网络功能都实质上有效的设备。
本发明的另一个目的是提供一种用于包括广播功能的简化文件传输协议的系统和方法，所述功能易于实现、成本有效、安全且可靠。
根据本发明的一方面，为了实现上述和其它目的，提供了一种用于具有广播功能的简化文件传输协议(TFTP)的系统，所述系统包括多个客户机系统，用于发送包括广播选项的TFTP扩展读请求消息，并且如果客户机系统接收到通知客户机系统是主客户机的选项应答消息，则只要客户机系统接收到数据就发送应答消息；以及服务器系统，用于响应接收到来自客户机系统的扩展读请求消息，发送选项应答消息，所述消息包括通知客户机系统是否是主客户机的扩展，广播数据，然后，如果服务器系统接收到来自多个客户机中被设置为主客户机的客户机系统的应答消息，则顺序地广播数据。
如果服务器系统在预定时间内没有接收到来自主客户机的应答消息，则服务器系统指定另一个客户机作为主客户机并发送通知另一个客户机是主客户机的应答消息，广播数据，然后，如果服务器系统接收到来自新主客户机的应答消息，则顺序地广播数据。
扩展读请求消息包括操作码字段，指示了用于消息类型的数值；文件名字段，具有利用ASCII(美国信息交换标准码)编码的文件名；模式字段，定义了传输模式；选项字段，用于支持广播；以及掩码位字段，用于定义选项字段的数值。
由服务器系统发送的选项应答消息包括操作码字段，指示了用于消息类型的字段；广播字段，用于支持广播；以及通知掩码位、端口号和是否是主客户机的字段。
选择首先发送读请求消息的客户机作为主客户机。
根据实现上述目的的本发明的另一方面，提供了一种用于包括广播功能的简化传输扩展协议的方法，该方法包括第一步骤，由第一客户机将扩展读请求消息发送到服务器，以请求广播文件传输；第二步骤，由服务器将通知第一客户机是主客户机的选项应答消息发送到第一客户机；第三步骤，由第二客户机将扩展读请求消息发送到服务器，以请求广播文件传输；第四步骤，由服务器将通知第二客户机不是主客户机的选项应答消息发送到第二客户机；第五步骤，由服务器广播数据，然后等待接收来自第一客户机的应答消息；以及第六步骤，如果服务器接收到来自第一客户机的应答消息，则由服务器重复进行第五步骤，直到服务器发送了所有剩余的数据。
该方法还包括第七步骤，如果服务器在一定时间内，没有接收到响应从第一客户机接收的数据的应答消息，则由服务器指定第二客户机作为主客户机；以及第八步骤，发送通知将第二客户机指定为主客户机的选项应答消息到第二客户机，然后执行数据传输。
该方法还包括第九步骤，如果预定时间过去之后，服务器接收到来自另一个客户机的扩展读请求消息以请求广播，由服务器通过新的简化文件传输程序来按照一对一的方式进行处理，或分配新的广播端口。
该方法还包括第十步骤，当在服务器中出现故障时，发送错误消息到每一个客户机。
如果服务器不支持广播选项功能，当服务器接收到来自任意客户机的扩展读请求消息以请求广播文件传输时，服务器发送错误消息到相关客户机。
根据本发明的另一方面，为了实现上述目的，提供了一种用于具有广播功能的简化文件传输协议(TFTP)的系统，所述系统包括多个客户机系统，用于发送包括广播选项和/或块大小选项的TFTP扩展读请求消息，并且如果客户机系统接收到通知客户机系统是主客户机的选项应答消息，则只要客户机系统接收到数据就发送应答消息；以及服务器系统，用于响应接收到来自客户机系统的扩展读请求消息，发送选项应答消息，所述消息包括通知客户机系统是否是主客户机的扩展和添加的块大小信息，广播数据，然后，如果服务器系统接收到来自多个客户机中被设置为主客户机的客户机系统的应答消息，则顺序地广播数据。
如果服务器系统在预定时间内没有接收到来自主客户机的应答消息，则服务器系统指定另一个客户机作为主客户机并发送通知另一个客户机是主客户机的应答消息，广播数据，然后，如果服务器系统接收到来自新主客户机的应答消息，则顺序地广播数据。
扩展读请求消息包括操作码字段，指示了用于消息类型的数值；文件名字段，具有利用ASCII码编码的文件名；模式字段，定义了传输模式；一选项字段，用于支持广播；掩码位字段，用于定义选项字段的数值；以及第二选项字段和块大小数值字段，用于支持块大小。
由服务器系统发送的选项应答消息包括操作码字段，指示了用于消息类型的数值；广播字段，用于支持广播；通知掩码位、端口号和是否是主客户机的字段；以及选项字段和块大小数值字段，用于支持块大小。
选择首先发送读请求消息的客户机作为主客户机。
根据实现上述目的的本发明的另一方面，提供了一种用于包括广播功能的简化传输扩展协议的方法，该方法包括第一步骤，由第一客户机将扩展读请求消息发送到服务器，以请求广播文件传输；第二步骤，由服务器将通知第一客户机是主客户机并且包括块大小信息的选项应答消息发送到第一客户机；第三步骤，由第二客户机将扩展读请求消息发送到服务器，以请求广播文件传输；第四步骤，由服务器将通知第二客户机不是主客户机并且包括重新定义的块大小信息的选项应答消息发送到第二客户机；第五步骤，由服务器按照重新定义的块大小单位广播数据，然后等待接收来自第一客户机的应答消息；以及第六步骤，如果服务器接收到来自第一客户机的应答消息，则由服务器重复进行第五步骤，直到服务器发送了所有剩余的数据。
该方法还包括第七步骤，如果服务器在一定时间内，没有接收到响应从第一客户机接收的数据的应答消息，则由服务器指定第二客户机作为主客户机；以及第八步骤，发送通知将第二客户机指定为主客户机的选项应答消息到第二客户机，然后执行数据传输。
该方法还包括第九步骤，如果预定时间过去之后，服务器接收到来自另一个客户机的扩展读请求消息以请求广播，由服务器通过新的简化文件传输程序来按照一对一的方式进行处理，或分配新的广播端口。
该方法还包括第十步骤，当在服务器中出现故障时，发送错误消息到每一个客户机。
如果服务器不支持广播选项功能和/或块大小选项功能，当服务器接收到来自任意客户机的扩展读请求消息以请求广播文件传输时，服务器发送错误消息到相关客户机。
附图说明
当结合其中相同参考符号表示相同或相似组件的附图时，参考以下详细说明能够使本发明的更彻底的理解和许多附加优点易于显而易见并变得能够更好地理解，其中：
图1是示出了用于包括广播功能的简化文件传输协议的系统配置的图，将所述功能应用于本发明；
图2a是示出了本发明实施例中使用的重新定义的读请求(RRQ)消息的结构图；
图2b是示出了将实际数字数值应用到图2a的消息格式中的情况的图；
图3a是示出了由本发明中使用的服务器系统发送的选项应答(OACK)消息的结构图；
图3b是示出了将实际数字数值应用到图3a的消息格式中的情况的图；
图4是根据本发明实施例的用于包括广播功能的简化文件传输协议的方法的流程图；
图5是示出了在根据本发明实施例的用于包括广播功能的简化文件传输协议的方法中，当出现错误时的处理过程的流程图；
图6a是示出了在本发明的另一个实施例中，将实际数字数值应用到重新定义使用的读请求(RRQ)消息的情况的图；
图6b是示出了在本发明的另一个实施例中，将实际数字数值应用到由服务器系统发送的重新定义使用的选项应答(OACK)消息的情况的图；以及
图7是根据本发明另一个实施例的用于包括广播功能的简化文件传输协议的方法的流程图。
具体实施方式
下面，将参考附图详细说明本发明的优选实施例，以使本发明所属领域的普通技术人员能够容易地执行本发明。
图1是示出了用于包括广播功能的简化文件传输协议的系统配置的图，将所述功能应用于本发明。
参考图1，用于包括广播功能的简化文件传输协议的系统包括服务器系统10和多个客户机系统20a到20n。
作为示例，结合服务器系统10和客户机20a来讨论通常在简化文件传输协议系统(TFTP)中进行的文件传输过程。
服务器系统10和客户机20a通过网络30互连，以提供并提取文件40。
此时，在服务器系统10上运行的TFTP系统14和在客户机系统20a上运行的TFTP客户机24a利用使用TCP的UDP和UDP的因特网协议(IPs)12和22a在以太网11上进行操作。
TFTP客户机24a运行在系统20a上，其中系统20a中嵌入了TFTP客户机24a，以开始与TFTP服务器14相连。TFTP客户机24a发送读/写请求消息(RRQ：Read ReQuest/WRQ：Write ReQuest)到TFTP服务器14，以建立与TFTP服务器14的连接。
此时，TFTP客户机24a在TFTP客户机侧选择用于TCP/UDP 23a的UDP端口，并将包含其自身IP地址和所选择的端口号的读/写请求消息(RRQ/WRQ)通过该所选择端口发送到TFTP服务器14。
TFTP服务器14在TFTP服务器侧，通过用于TCP/UDP 13的UDP的端口69，选择从TFTP客户机24a发送的读/写请求消息(RRQ/WRQ)。
当接收到请求消息时，TFTP服务器14注册TFTP客户的IP(因特网协议)地址和端口号，并利用已注册的IP地址和端口号将响应请求的应答消息(ACK)通过与当接收请求消息时所使用的相同的端口发送到TFTP客户机24a。
TFTP客户机24a通过之前选择的用于TFTP客户机侧UDP 23的端口，接收由TFTP服务器14发送的应答消息(ACK)，以建立两个系统之间的连接。
如果建立了TFTP服务器14和TFTP客户机24a之间的连接，通过两个UDP端口在系统之间发送读/写请求消息(RRQ/WRQ)中由TFTP客户机24a请求的文件40。
TFTP服务器14和TFTP客户机24a保持相连，直到文件40的传输完成，并在传输完成之后关闭连接以端口TFTP服务器14和TFTP客户机24a。
同时，对于这种典型的简化文件传输协议系统，为了包括本发明的广播功能，需要根据在RFC(请求评论)2347中定义的协议来定义新的选项并重新定义消息类型。
通常，读请求消息(RRQ)是用于建立客户机所需的连接以便从服务器读取数据的消息。即，是用于下载文件的请求消息。此时，“1”是用于操作码(OPC)的数值，这是RRQ的第一字段，并且文件名包括具有可变长度的字符串，伴随着传输模式的定义字段。
写请求消息(WRQ)是用于建立客户机所需的连接以便向服务器写入数据的消息。即，是用于上传文件的请求消息。此时，“2”是用于作为WRQ中第一字段的OPC的数值。
同时，“3”是用于消息的OPC数值，用于传输数据块，并且“4”是用于响应接收到数据块的应答(ACK)消息的OPC数值。
当出现错误时，“5”是用于消息的OPC数值。当将选项添加到扩展TFTP的RRQ和WRQ消息中时，建议将“6”用于选项ACK消息的OPC数值(OACK；选项接受或不接受)。
图2a是示出了本发明实施例中使用的重新定义的RRQ消息的结构图。
参考图2a，RRQ消息包括操作码(OPC)字段31、文件名字段32、模式字段34、选项字段36和掩码位字段38。
操作码字段31的操作码数值是1，文件名字段32的文件名包括具有可变长度的字符串。利用ASCII码对文件名进行编码，1字节字段33指示了其结束点。
模式字段34用于定义传输模式。在ASCII模式的情况下，用于模式字段的字符串是“netascii”，而在二进制文件的情况下是“octet”。1字节字段35指示了模式字段的结束点。
选项字段36是新定义的字段，用于支持广播功能。使用的选项字符串是“broadcast”，1字节字段37指示了选项字段的结束点。
掩码位字段38是新定义的字段，用于支持广播功能。其定义了用于广播选项的数值，并根据客户机的广播地址进行确定。对于各个类别，数值是8、16、24等。
因此，在按照广播模式发送文件且广播选项属于类别C的情况下，可以如图2b所示来定义RRQ消息。
图2b是示出了将实际数字数值应用到图2a的消息格式中的情况的图。
参考图2b，将操作码定义为“1”，将文件名定义为“foofile”，将传输模式定义为octet，将选项字段定义为字符串“Broadcast”，将掩码位字段定义为24位。
接下来，将说明服务器系统和客户机之间的OACK消息。
图3a是示出了由本发明中使用的服务器系统发送的OACK消息的结构图。
参考图3a，OACK消息包括操作码(OPC)字段41、广播字段42，1字节字段43，掩码位、端口号和主客户机(Mask bit，Port，和MC)字段44和1字节字段45。
操作码字段41的操作码数值是6。在广播字段42中定义字符串“broadcast”，且1字节字段43指示了结束点。
掩码位、端口号和主客户机(Mask bit，Port，和MC)字段44定义了用于广播选项的数值。其定义了由服务器系统10确定的广播掩码位、UDP端口号和主客户机位。
如果该数值是可接受的，则掩码位接受来自客户机20a到20n的读请求消息(RRQ)。否则，根据服务器系统10的广播地址来确定掩码位。
对于已经首先发送了读请求消息(RRQ)并变为主机的客户机24a到24n中的任意一个，将主客户机(MC)位设为1，并对于其它客户机设为0。主客户机用于响应数据分组，发送应答消息。
这里，主客户机是首先发送读请求消息(RRQ)的客户机。主客户机向数据分组发送应答消息。其它客户机不发送应答消息。
建议使用在RFC2347中重新定义的选项之一1768作为广播UDP端口。将该端口号添加到从服务器发送到客户机的OACK消息中，以便由客户机进行解译。客户机能够接受由服务器提供的其它端口号。
在响应从客户机接收的包括广播选项的消息(RRQ)发送应答广播选项的OACK消息的情况下，可以如图3b所示来定义OACK消息，其中选项包括广播模式、类别C、1768的端口号和被设置位主机的对应客户机(1：主机，0：非主机)。
作为参考，多播TFTP使用1758。
图3b是示出了将实际数字数值应用到图3a的消息格式中的情况的图。
参考图3b，可以将操作码定义为“6”，将广播选项字段定义为“broadcast”，以及将掩码位和MC字段定义为“24,1768,1”，其中24是掩码位，1768是UDP端口，以及1是MC字段。
在配置包括广播功能的文件传输系统并且如上定义消息格式的情况下来说明实际的文件传输过程。
在讨论操作之前，将客户机系统24a定义为主客户机，并将接收到来自主客户机24a的读请求消息(RRQ)之后，服务器系统10等待接收来自其它客户机24b到24n的读请求消息的时间定义为“T”。
此外，作为操作所需参数的“Ts”是向主客户机24a发送数据之后，服务器系统10进行等待直到主客户机24a应答数据的超时时间。当服务器系统10此时没有接收到应答时，服务器系统10重新发送数据。
此外，作为操作所需的另一个参数，“n”是指示了服务器系统10向客户机系统24a到24n重新发送广播消息的次数的参数，“a”是指示了客户机系统24a到24n等待接收来自服务器系统10的数据分组的临界(marginal)时间的参数。
由于“n*A”是服务器系统10等待客户机系统24a到24n的时间，设置客户机系统24a到24n的等待超时时间比“n*A”大“a”。
如果主客户机24a发送了包括“broadcast”选项字段的读请求消息以通过广播接收文件，服务器系统10响应接收到消息，返回OACK以接受“broadcast”选项，然后在“T”时间内等待来自其它客户机系统24b到24n的文件传输请求。
主客户机24a接收其中主客户机位被设为“1”的OACK，识别主客户机24a是用于广播传输的主客户机，发送ACK，然后等待数据。
如果来自其它客户机系统24b到24n的读请求消息在“T”时间之内到达服务器系统10，则服务器系统10发送OACK消息。经过“T”时间之后，服务器系统10接收来自其它客户机系统24b到24n的应答(ACK)消息，并广播数据。
此时，则主客户机24a响应数据，发送应答消息，同时其它客户机系统24b到24n不发送应答消息。当来自主客户机24a的应答消息到达服务器系统时，服务器系统10发送下一个数据。
同时，如果当服务器系统10广播正常数据时，停止了主客户机24a，则服务器系统10在“A”时间内等待来自主客户机24a的应答消息并且当没有应答消息时，重新发送。
如果直到发送了“n”次数据仍没有应答消息，则服务器系统10发送OACK，以授权另一个第二客户机24b作为主客户机。之后，服务器确认从新主客户机24b发送的应答消息，从而继续进行过程。
图4是根据本发明实施例的用于包括广播功能的简化文件传输协议的方法的流程图。
参考图4，第一客户机51a发送读请求消息(RRQ)到服务器系统，以便下载文件。此时，消息分组已经新定义了具有“broadcast”选项的选项字段(100)。
服务器系统50接收第一读请求消息，作为响应，发送OACK以接受这种“broadcast”选项(101)。然后，服务器系统50等待“T”时间，以查看是否出现了其它客户机。此时，已经将OACK分组中的掩码位、端口和主客户机(MC)字段设置为“1”，以通知客户机51a是主客户机。
第一客户机51a接收其中已经将主客户机(MC)字段设为“1”的OACK，以识别51a是用于广播传输的主客户机，返回应答消息以响应OACK消息(104)，并等待数据。
同时，第二客户机51b在“T”时间内发送读请求消息到服务器系统50(102)，服务器系统50返回其中已经将主客户机(MC)字段设为“0”的OACK(103)。作为响应，第二客户机51b发送应答消息(105)。此时，由于已经将主客户机(MC)字段设为“0”，第二客户机51b识别第二客户机51b不是主客户机，并因此当接收到数据时，不发送应答消息。
接下来，服务器系统50在经过“T”时间之后广播数据(106)。作为响应，只有作为主客户机的第一客户机51a发送应答消息(107)，当接收到应答消息时，服务器系统50发送后续分组(108)。
同时，如果服务器系统在经过“T”时间之后接收到读请求消息，则服务器系统利用新的TFTP程序，按照一对一的方式对其进行处理，或进行新的广播TFTP过程，与传统方式相同。
图5是示出了在根据本发明实施例的用于包括广播功能的简化文件传输协议的方法中，当出现错误时的处理过程的流程图。
参考图5，与图4相同，如果当广播正常数据时，主客户机停止，则服务器系统50在“A”时间内等待来自作为主客户机的第一客户机51a的应答，并当没有接收到应答时，重新发送数据。
如果即使到服务器系统重新发送数据n次之后，服务器系统还没有接收到应答，则服务器系统50发送OACK以授权第二客户机51b作为主客户机(208)。
此时，在客户机侧，客户机接收到数据之后，具有n*(A+a)时间的定时器开始操作，由于第二客户机已经接收到块#(块编号)，则第二客户机51b确认并放弃重新发送的数据分组。
同时，当接收到OACK时，第二客户机51b确认第二客户机51b是主客户机，然后，重新发送应答消息(209，211和213)。
如果服务器系统50出现故障且客户机不能接收任何分组，则在客户机的n*(A+a)定时器超时的时刻，停止TFTP操作并输出错误消息。
之后，将说明通过根据选项扩展协议重新定义块大小和广播选项以更快发送分组的实施例。
图6a是示出了在本发明的另一个实施例中，将实际数字数值应用到重新定义使用的读请求(RRQ)消息的情况的图。
参考图6a，将操作码定义为“1”，将文件名定义为“foofile”，将传输模式定义为octet，将第一选项字段定义为字符串“Broadcast”，将掩码位字段定义为24位，将第二选项字段定义为用于块大小的字符串“blksize”，并且将块大小字段定义为块大小数值“1428”。
尽管在上述实施例中，当在服务器和客户机之间使用利用广播选项字段扩展的消息来发送和接收文件时，已经将块大小固定为“512”并且已经发送和接收了512octet(字节)，但由于在其它实施例中重新将块大小定义为“1428”，因此当在服务器和客户机之间使用发送和接收文件时的数据传输单位变为1428octet(字节)。
图6b是示出了在本发明的另一个实施例中，将实际数字数值应用到由服务器系统发送的重新定义使用的选项应答(OACK)消息的情况的图。
参考图6b，可以将操作码定义为“6”，将第一选项字段定义为“broadcast”，以及将掩码位和MC字段定义为“24,1768,1”，将第二选项字段定义为“blksize”，以及将块大小字段定义为“1428”。
因此，将对以下情况的实际文件传输过程进行说明：已经配置了用于包括广播功能的文件传输协议的系统并且已经如上所述重新定义了消息格式中的块大小。
图7是根据本发明另一个实施例的用于包括广播功能的简化文件传输协议的方法的流程图。
参考图7，第一客户机51a发送读请求消息(RRQ)到服务器系统，以便下载文件。此时，消息分组具有“broadcast”选项的新定义的选项字段(300)。
服务器系统50接收第一读请求消息，接受“broadcast”选项，发送具有作为数据传输单位的重新定义为1428 octet的块大小的OACK(301)，然后，等待“T”时间，以查看是否出现了其它客户机。此时，已经将OACK分组中的掩码位、端口和主客户机(MC)字段设置为“1”，以通知客户机51a是主客户机。
第一客户机51a接收其中已经将主客户机(MC)字段设为“1”的OACK，以识别51a是用于广播传输的主客户机并且已经将数据传输单位重新定义为1428octet，返回应答消息(ACK)以响应OACK消息(304)，并等待数据。
同时，第二客户机51b在“T”时间内发送读请求消息(RRQ)到服务器系统50(302)，服务器系统50发送其中已经将掩码位、端口和MC字段的MC值设为“0”并且已经将块大小重新定义为1428octet的OACK(303)。作为响应，第二客户机51b发送应答消息ACK(305)。
此时，由于已经将主客户机(MC)值设为“0”，第二客户机51b不是主客户机，并因此当接收到数据时，客户机51b不发送应答消息。此外，由于第二客户机51b已经识别了块大小1428 octet信息，当接收到以1428 octet为单位的数据时，第二客户机51b确定这是正常状态。
之后，服务器系统50在经过“T”时间之后广播以1428 octet为单位的数据(306)，并且只有作为主客户机的第一客户机51a发送应答消息(307)，当接收到来自作为主客户机的第一客户机51a的应答消息时，服务器系统50广播写一个分组(308)。
在第二实施例的情况下，由于可以重新定义广播的块大小，其优点在于实际的文件传输速度变得更快。
因此，如果服务器或客户机支持如上所述的TFTP广播选项，多个客户机能够从一个服务器快速下载文件。
然而，如果服务器不支持这种广播选项，则可以出现以下操作。
首先，客户机发送具有经检查是广播的选项字段的读/写(RRQ)消息到服务器，由于服务器不支持由该消息指示的广播选项功能，服务器发送错误消息到相关客户机。可选地，相关服务器可以发送选项应答(OACK)消息到添加了可支持功能的客户机。此时，如果客户机不接受这种功能，则服务器发送错误消息。
与上述不同，如果客户不支持广播选项，则会出现以下操作。
在这种情况下，由于当开始向服务器发送读/写(RRQ)消息时，客户机不能自己选择广播选项，按照与已有技术相同的方式进行消息交换，而与服务器是否支持广播选项无关。
同时，应当注意，尽管已经利用以下示例说明了本发明：选择多个客户机中首先发送读/写消息(RRQ)的客户机作为主机，并在接收到来自主客户机的应答(ACK)消息之后顺序地发送接下来的数据，本发明还可以应用到以下情况：如果接收到来自多个客户机的应答(ACK)消息或即时没有接收到来自多个客户机的应答(ACK)消息，仍然根据系统操作员的操作计划来无条件地操作网络，而无需选择主客户机。
尽管已经详细地说明了本发明的优选实施例，本发明所属领域的普通技术人员可以理解的是，在不脱离由所附权利要求限定的本发明的技术实质和范围的前提下，可以对本发明进行多种修改或改变。因此，本发明的技术中包含了本发明将来变化的实施例。
如上所述，根据本发明，其优点在于利用广播TFTP使传输速度快于现有的一对一传输方式，这使得对于多个客户机可以按照快而有效的方式从一个服务器下载文件。
此外，在除了广播选项扩展之外还添加了块大小选项的情况下，比之前块大小更大的块大小允许更快的文件传输。
有利地，通过将本发明的方法应用到子网络是广播网络、存在多个客户机且需要同时文件传输的情况中，可以实现最有效的文件传输。
此外，有利地，由于TFTP没有用于其中所有网络功能都实质上有效的设备，因此可以使传输操作效率最大，同时使所添加的功能最少。

Claims (30)

1.一种用于具有广播功能的简化文件传输协议的系统，所述系统包括：
多个客户机系统，用于发送包括广播选项的所述简化文件传输协议的扩展读请求消息，并且当响应所述读请求消息，接收到选项应答消息时，则只要客户机系统接收到数据就发送应答消息；以及
服务器系统，用于响应接收到来自所述客户机系统的所述扩展读请求消息，发送所述选项应答消息到所述客户机系统，广播所述数据，然后，当所述服务器系统接收到来自所述多个客户机系统的所述应答消息，则顺序地广播所述数据。
2.一种用于具有广播功能的简化文件传输协议的系统，所述系统包括：
多个客户机系统，用于发送包括广播选项的所述简化文件传输协议的扩展读请求消息，并且当响应所述读请求消息，接收到选项应答消息之后，顺序地接收作为广播的数据；以及
服务器系统，用于响应接收到来自所述客户机系统的所述扩展读请求消息，发送所述选项应答消息到所述客户机系统，并顺序地广播所述数据。
3.一种用于具有广播功能的简化文件传输协议的系统，所述系统包括：
多个客户机系统，用于发送包括广播选项的所述简化文件传输协议的扩展读请求消息，并且当所述客户机系统接收到通知所述客户机系统是主客户机的选项应答消息时，只要所述客户机系统接收到数据，就发送应答消息；以及
服务器系统，用于响应接收到来自所述客户机系统的所述扩展读请求消息，发送所述选项应答消息，所述消息包括通知客户机系统是否是主客户机的扩展，广播所述数据，然后，当所述服务器系统接收到来自所述多个客户机中被设置为主客户机的客户机系统的所述应答消息时，顺序地广播所述数据。
4.根据权利要求3所述的系统，其特征在于当所述服务器系统在预定时间内没有接收到来自所述主客户机的所述应答消息时，所述服务器系统指定另一个客户机作为主客户机并发送通知所述另一个客户机是主客户机的应答消息，广播所述数据，然后，当所述服务器系统接收到来自所述新主客户机的所述应答消息时，顺序地广播所述数据。
5.根据权利要求3所述的系统，其特征在于所述扩展读请求消息包括：
操作码字段，指示了用于消息类型的数值；
文件名字段，具有利用美国信息交换标准码来编码的文件名；
模式字段，定义了传输模式；
选项字段，用于支持广播；以及
掩码位字段，用于定义选项字段的数值。
6.根据权利要求3所述的系统，其特征在于由所述服务器系统发送的所述选项应答消息包括：
操作码字段，指示了用于消息类型的数值；
广播字段，用于支持广播；以及
通知掩码位、端口号和是否是主客户机的字段。
7.根据权利要求3所述的系统，其特征在于选择首先发送所述读请求消息的客户机作为所述主客户机。
8.一种用于包括广播功能的简化传输扩展协议的方法，该方法包括：
由多个客户机将扩展读请求消息发送到服务器，以请求广播文件传输；
由所述服务器将选项应答消息发送到所述多个客户机；
由所述服务器广播数据，然后等待接收来自所述多个客户机的应答消息；以及
当所述服务器接收到来自所述多个客户机的所述应答消息时，所述服务器重复进行所述广播步骤，直到服务器发送了剩余数据。
9.一种用于包括广播功能的简化传输扩展协议的方法，该方法包括：
由多个客户机将扩展读请求消息发送到服务器，以请求广播文件传输；
由所述服务器将选项应答消息发送到所述多个客户机；以及
所述服务器顺序地广播数据到所述多个客户机。
10.一种用于包括广播功能的简化传输扩展协议的方法，该方法包括：
由第一客户机将扩展读请求消息发送到服务器，以请求广播文件传输；
由所述服务器将通知所述第一客户机是主客户机的选项应答消息发送到所述第一客户机；
由第二客户机将扩展读请求消息发送到所述服务器，以请求广播文件传输；
由所述服务器将通知所述第二客户机不是主客户机的选项应答消息发送到所述第二客户机；
由所述服务器广播数据，然后等待接收来自所述第一客户机的应答消息；以及
如果所述服务器接收到来自所述第一客户机的所述应答消息，则由服务器重复进行所述广播步骤，直到所述服务器发送了剩余的数据。
11.根据权利要求10所述的方法，其特征在于还包括：
当所述服务器在一定时间内，没有接收到响应从所述第一客户机接收所述数据的应答消息，则由所述服务器指定所述第二客户机作为所述主客户机；以及
发送通知将所述第二客户机指定为所述主客户机的选项应答消息到所述第二客户机，然后执行数据传输。
12.根据权利要求10所述的方法，其特征在于还包括：
当预定时间过去之后，所述服务器接收到来自另一个客户机的所述扩展读请求消息以请求广播时，由所述服务器通过新的简化文件传输程序来按照一对一的方式进行处理，或分配新的广播端口。
13.根据权利要求10所述的方法，其特征在于还包括：
当在所述服务器中出现故障时，发送错误消息到每一个客户机。
14.根据权利要求10所述的方法，其特征在于当所述服务器不支持所述广播选项功能，当所述服务器接收到来自任意客户机的所述扩展读请求消息以请求广播文件传输时，所述服务器发送错误消息到相关客户机。
15.根据权利要求10所述的方法，其特征在于当所述服务器不支持所述广播选项功能，当所述服务器接收到来自任意客户机的所述扩展读请求消息以请求广播文件传输时，所述服务器发送经检查只具有可支持功能的选项应答消息到所述客户机。
16.一种用于具有广播功能的简化文件传输协议的系统，所述系统包括：
多个客户机系统，用于发送至少包括广播选项和块大小选项之一的TFTP扩展读请求消息，并且当接收到通知所述客户机系统是主客户机的选项应答消息时，则只要接收到数据就发送应答消息；以及
服务器系统，用于响应接收到来自所述客户机系统的所述扩展读请求消息，发送所述选项应答消息到所述客户机系统，然后，当所述服务器系统接收到来自所述多个客户机的所述应答消息时，则以相关的块大小单位来广播所述数据。
17.一种用于具有广播功能的简化文件传输协议的系统，所述系统包括：
多个客户机系统，用于发送至少包括广播选项和块大小选项之一的TFTP扩展读请求消息，并且当接收到通知所述客户机系统是主客户机的选项应答消息之后，顺序地接收作为广播的数据；以及
服务器系统，用于响应接收到来自所述客户机系统的所述扩展读请求消息，发送具有所添加的块大小信息的所述选项应答消息到所述客户机系统，并以相关的块大小单位来广播所述数据。
18.一种用于具有广播功能的简化文件传输协议的系统，所述系统包括：
多个客户机系统，用于发送至少包括广播选项和块大小选项之一的TFTP扩展读请求消息，并且当所述客户机系统接收到通知所述客户机系统是主客户机的选项应答消息时，则只要所述客户机系统接收到数据就发送应答消息；以及
服务器系统，用于响应接收到来自所述客户机系统的所述扩展读请求消息，发送所述选项应答消息到所述客户机系统，所述应答消息包括通知所述客户机系统是主客户机以及所添加的块大小信息的扩展，然后，当所述服务器系统接收到来自所述多个客户机中被设为所述主客户机的所述客户机系统的所述应答消息时，则以相关的块大小单位来广播所述数据。
19.根据权利要求18所述的系统，其特征在于当所述服务器系统在预定时间内没有接收到来自所述主客户机的应答消息时，所述服务器系统指定另一个客户机作为所述主客户机并发送通知所述另一个客户机是主客户机的应答消息，广播所述数据，并当所述服务器系统接收到来自所述新主客户机的所述应答消息时，顺序地广播所述数据。
20.根据权利要求18所述的系统，其特征在于所述扩展读请求消息包括：
操作码字段，指示了用于消息类型的数值；
文件名字段，具有利用ASCII码编码的文件名；
模式字段，定义了传输模式；
第一选项字段，用于支持广播；
掩码位字段，用于定义选项字段的数值；以及
第二选项字段和块大小数值字段，用于支持块大小。
21.根据权利要求18所述的系统，其特征在于由所述服务器系统发送的所述选项应答消息包括：
操作码字段，指示了用于消息类型的数值；
广播字段，用于支持广播；
通知掩码位、端口号和是否是主客户机的字段；以及
选项字段和块大小数值字段，用于支持块大小。
22.根据权利要求18所述的系统，其特征在于选择首先发送读请求消息的客户机作为主客户机。
23.一种用于包括广播功能的简化传输扩展协议的方法，该方法包括：
由多个客户机将扩展读请求消息发送到服务器，以请求广播文件传输；
由所述服务器将包括块大小信息的选项应答消息发送到所述多个客户机；
由所述服务器以重新定义的块大小单位来广播数据，然后等待接收来自所述多个客户机的应答消息；以及
当所述服务器接收到来自所述多个客户机的所述应答消息时，所述服务器重复进行所述广播步骤，直到所述服务器发送了剩余数据。
24.一种用于包括广播功能的简化传输扩展协议的方法，该方法包括：
由多个客户机将扩展读请求消息发送到服务器，以请求广播文件传输；
由所述服务器将包括块大小信息的选项应答消息发送到所述多个客户机；以及
所述服务器以重新定义的块大小来广播数据。
25.一种用于包括广播功能的简化传输扩展协议的方法，该方法包括：
由第一客户机将扩展读请求消息发送到服务器，以请求广播文件传输；
由所述服务器将通知所述第一客户机是主客户机并且包括块大小信息的选项应答消息发送到所述第一客户机；
由第二客户机将所述扩展读请求消息发送到所述服务器，以请求广播文件传输；
由所述服务器将通知所述第二客户机不是所述主客户机并且包括重新定义的块大小信息的选项应答消息发送到所述第二客户机；
由所述服务器按照重新定义的块大小单位来广播数据，然后等待接收来自所述第一客户机的应答消息；以及
当所述服务器接收到来自所述第一客户机的应答消息时，由所述服务器重复进行所述广播步骤，直到所述服务器发送了所有剩余的数据。
26.根据权利要求25所述的方法，其特征在于还包括：
当所述服务器在一定时间内，没有接收到响应从所述第一客户机接收的数据的应答消息，则由所述服务器指定所述第二客户机作为主客户机；以及
发送通知将所述第二客户机指定为所述主客户机的选项应答消息到所述第二客户机，然后执行数据传输。
27.根据权利要求25所述的方法，其特征在于还包括：
当预定时间过去之后，所述服务器接收到来自所述另一个客户机的扩展读请求消息以请求广播时，由所述服务器通过新的简化文件传输程序来按照一对一的方式进行处理，或分配新的广播端口。
28.根据权利要求25所述的方法，其特征在于还包括：
当在所述服务器中出现故障时，发送错误消息到每一个客户机。
29.根据权利要求25所述的方法，其特征在于当所述服务器不支持至少所述广播选项功能和块大小选项功能之一时，当所述服务器接收到来自任意客户机的所述扩展读请求消息以请求广播文件传输时，所述服务器发送错误消息到相关客户机。
30.根据权利要求25所述的方法，其特征在于当所述服务器不支持至少所述广播选项功能和块大小选项功能之一时，当所述服务器接收到来自任意客户机的所述扩展读请求消息以请求广播文件传输时，所述服务器发送经检查只具有可支持功能的选项应答消息到所述客户机。
CNA2005100067572A 2004-02-10 2005-02-04 用于包括广播功能的简化文件传输协议的系统和方法 Pending CN1655550A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20040008815A KR100542368B1 (ko) 2004-02-10 2004-02-10 브로드캐스팅 기능이 구비된 간단한 파일전송시스템 및 그방법
KR20048815 2004-02-10

Publications (1)

Publication Number Publication Date
CN1655550A true CN1655550A (zh) 2005-08-17

Family

ID=34698968

Family Applications (1)

Application Number Title Priority Date Filing Date
CNA2005100067572A Pending CN1655550A (zh) 2004-02-10 2005-02-04 用于包括广播功能的简化文件传输协议的系统和方法

Country Status (6)

Country Link
US (1) US20050177625A1 (zh)
EP (1) EP1564959B1 (zh)
JP (1) JP2005228313A (zh)
KR (1) KR100542368B1 (zh)
CN (1) CN1655550A (zh)
DE (1) DE602005004315D1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109257442A (zh) * 2018-11-09 2019-01-22 南方电网科学研究院有限责任公司 基于tftp的文件传输方法、系统及终端与存储介质
CN111694593A (zh) * 2020-05-22 2020-09-22 中国航空工业集团公司西安航空计算技术研究所 一种基于改进arinc615a协议的目标程序在线升级方法
CN114448970A (zh) * 2021-12-27 2022-05-06 天翼云科技有限公司 一种数据传输方法、装置及设备

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100953004B1 (ko) * 2005-03-05 2010-04-14 인텔 코오퍼레이션 서버측 ｔｆｔｐ 흐름 제어
JP4449931B2 (ja) * 2006-03-30 2010-04-14 ブラザー工業株式会社 管理装置、および管理システム
KR101389928B1 (ko) * 2007-01-30 2014-04-30 삼성전자주식회사 상호 배제 기능을 수행하기 위한 방법 및 이를 이용한ｄｒｍ 디바이스
US20100217889A1 (en) * 2009-02-26 2010-08-26 Honeywell International Inc. Accelerated block option for trivial file transfer protocol (tftp)
US7984166B2 (en) * 2009-09-02 2011-07-19 Honeywell International Inc. Trivial file transfer protocol (TFTP) file segment and file address options
KR20120018717A (ko) * 2010-08-23 2012-03-05 (주)엡볼 파일 전송 방법 및 이의 방법을 수행하는 장치들
US9049175B2 (en) 2010-12-02 2015-06-02 Microsoft Technology Licensing, Llc Client-adjustable window size for connectionless transfer protocols
US8521902B2 (en) 2010-12-02 2013-08-27 Microsoft Corporation Shared buffer for connectionless transfer protocols
US8769137B2 (en) 2011-06-23 2014-07-01 Honeywell International Inc. Systems and methods for negotiated accelerated block option for trivial file transfer protocol (TFTP)
TW201416873A (zh) * 2012-10-19 2014-05-01 Apacer Technology Inc 網路儲存系統的檔案分享方法
US9143553B2 (en) 2013-02-26 2015-09-22 Honeywell International Inc. Trivial file transfer protocol (TFTP) accelerated file retry option
US9634982B2 (en) 2013-07-18 2017-04-25 Cisco Technology, Inc. Utilizing multiple interfaces when sending data and acknowledgement packets
JP2016116195A (ja) 2014-12-18 2016-06-23 富士通株式会社 情報処理装置、情報処理装置の制御方法及び情報処理装置の制御プログラム
US10594771B2 (en) 2017-02-09 2020-03-17 International Business Machines Corporation Distributed file transfer with high performance
US11381634B1 (en) 2021-08-03 2022-07-05 International Business Machines Corporation TFTP (trivial file transfer protocol) broadcast controller

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6308061B1 (en) * 1996-08-07 2001-10-23 Telxon Corporation Wireless software upgrades with version control
US6185623B1 (en) * 1997-11-07 2001-02-06 International Business Machines Corporation Method and system for trivial file transfer protocol (TFTP) subnet broadcast
US6539422B1 (en) * 1998-05-04 2003-03-25 Intermec Ip Corp. Automatic data collection device having a network communications capability
KR100590186B1 (ko) * 1999-11-09 2006-06-14 삼성전자주식회사 Ｈｔｔｐ을 사용한 ｔｆｔｐ파일 전송 시스템
GB0006096D0 (en) * 2000-03-15 2000-05-03 Pace Micro Tech Plc Improvements to control system for network servers
GB0108791D0 (en) * 2001-04-07 2001-05-30 Pace Micro Tech Plc Improvements to control systems for network servers
KR20030016740A (ko) * 2001-08-21 2003-03-03 엘지전자 주식회사 Ｔｆｔｐ 파일 전송 시스템 및 그 시스템에서의소프트웨어 업그레이드 방법
US7051112B2 (en) * 2001-10-02 2006-05-23 Tropic Networks Inc. System and method for distribution of software
US6983334B2 (en) * 2001-11-07 2006-01-03 International Business Machines Corporation Method and system of tracking missing packets in a multicast TFTP environment
KR20030037917A (ko) * 2001-11-07 2003-05-16 엘지전자 주식회사 티에프티피 파일 다운로드 방법

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109257442A (zh) * 2018-11-09 2019-01-22 南方电网科学研究院有限责任公司 基于tftp的文件传输方法、系统及终端与存储介质
CN109257442B (zh) * 2018-11-09 2021-10-22 南方电网科学研究院有限责任公司 基于tftp的文件传输方法、系统及终端与存储介质
CN111694593A (zh) * 2020-05-22 2020-09-22 中国航空工业集团公司西安航空计算技术研究所 一种基于改进arinc615a协议的目标程序在线升级方法
CN111694593B (zh) * 2020-05-22 2023-05-12 中国航空工业集团公司西安航空计算技术研究所 一种基于改进arinc615a协议的目标程序在线升级方法
CN114448970A (zh) * 2021-12-27 2022-05-06 天翼云科技有限公司 一种数据传输方法、装置及设备

Also Published As

Publication number Publication date
KR100542368B1 (ko) 2006-01-10
JP2005228313A (ja) 2005-08-25
DE602005004315D1 (de) 2008-03-06
EP1564959B1 (en) 2008-01-16
US20050177625A1 (en) 2005-08-11
EP1564959A1 (en) 2005-08-17
KR20050080707A (ko) 2005-08-17

Similar Documents

Publication Publication Date Title
CN1655550A (zh) 用于包括广播功能的简化文件传输协议的系统和方法
CN1241451C (zh) 向移动通信终端提供数据业务的方法,系统及移动通信终端
CN1742473A (zh) 用于在不同网络协议之间传输数据的通用协议层体系结构和方法、以及通用协议分组
CN1633647A (zh) 用于管理网络中的数据传送的系统、方法和产品
CN1943170A (zh) 通信控制方法和无线通信装置
CN1574719A (zh) 用于网络通信的知道时间的最大努力的填孔再试方法和系统
CN1273727A (zh) 漫游的转换器或路由器
CN1816011A (zh) 数据传输装置、多播系统和程序
CN1392706A (zh) 一种利用串行总线实现多点通信的方法
CN1248453C (zh) 网元与电信网管系统的实时数据同步方法
CN1451219A (zh) 在通信系统中提供可配置的层和协议的方法和装置
CN1951052A (zh) 用于增强um rlc数据处理的装置和方法
CN100340072C (zh) 无线电台和输出防止方法
CN1889464A (zh) 一种实现通信接管的方法及装置
CN1404266A (zh) 网络系统和网络构成方法
CN1095299C (zh) 通过无线分组通信进行一对多数据传输的传输控制系统
CN1819593A (zh) 信息处理器和数据传输系统及方法
CN1492716A (zh) 信息包通信终端、通信系统、通信方法以及通信程序
CN1881939A (zh) 终端适配设备及其支持从无线局域网拨号接入的方法
CN1645969A (zh) 信息发送/接收系统及其方法，信息发送装置及接收装置
CN1234705A (zh) 无线电数据通信方法和系统
CN1661980A (zh) 无线接入点装置、无线lan系统、无线通信方法
CN1874301A (zh) 快速响应ip分片报文的方法和系统
CN1783872A (zh) 用于移动通信服务开通的网络配置接口的实现方法
CN1878414A (zh) 通信方法和无线通信终端

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication