专利名称：发送设备、接收设备、以及文件传输系统的制作方法
技术领域：
本发明涉及用来通过网络进行文件传输的发送设备、接收设备以及文件传输系统。
背景技术：
近年来，随着xDSL、光纤等宽带环境的建立，不管是企业还是一般家庭，互联网连接都得到了迅速普及。并且，利用以太网(Ethernet，注册商标)或无线LAN等来连接家庭内的个人计算机(PC，Personal Computer)、家电设备的家庭网络环境也正在普及。在这种情况下，不仅是PC，连电视机、DVD录像机、空调、冰箱等家电也可以通过由互联网工程任务组(IETF，Internet Engineering Task Force)所定义的互联网协议(IP，Internet Protocol)来相互连接。
作为互联网或家庭网络中的应用程序之一，有在家电设备、PC间传输文件的应用程序。作为传输文件的应用程序的示例，有能提供下述复录(dubbing)功能的应用程序为了对DVD录像机中所录制的TV节目进行编辑而将TV节目传输到PC，或者在DVD录像机之间传输所录制的MPEG2文件等。
要进行这样的文件传输，其协议一般而言，要求能够准确无误地传输文件，另一方面，并不要求必须进行实时传输。作为在IP下进行文件传输的代表性协议，有由RFC2616所定义的超文本传输协议(HTTP，Hyper TextTransfer Protocol)、由RFC959所定义的文件传输协议(FTP，File TransferProtocol)等。这些协议中的任一个均可通过由RFC793所定义的传输控制协议(TCP，Transmission Control Protocol)的重新发送功能来确保传输的可靠性。
也就是说，TCP包含检测包的错误并重新发送的过程、以及检测包的丢失并重新发送的过程，因此，即使传输路径上发生错误或是包有丢失，也能够保证正确的文件传输。另一方面，TCP的重新发送过程是有限制的，例如存在以下问题当由于传输路径上的故障、或者发送端设备(以下称作“源设备”)或接收端设备(以下称作“接收设备”)的原因而造成传输长时间中断时，TCP连接会因超时而断开，从而无法进行之后的文件传输。此处所述的设备的原因，除了故障之外，还包括为了执行设备的其他功能而必须中断文件传输的情况。可以举出的例子如，DVD录像机为了执行定时录像而中断文件传输的情况等。
在HTTP中，包含用来解决上述问题的过程，并且定义了以下序列(sequence)即使传输中断了任意长时间，也可以再次进行TCP连接，并紧跟在中断前的传输位置之后重新开始文件传输。以下使用图1来说明本序列。
图1是由源设备及接收设备所构成的现有文件传输系统中重新开始传输文件的通信序列的示例图。
图1所示的通信序列，是用来从源设备1001向接收设备1002传输文件的文件传输系统中的通信序列。并且，假设在文件传输中途TCP连接断开。
首先，接收设备1002向源设备1001发送HTTP GET请求(S101)。源设备1001针对该请求而响应“200 OK”(S102)，并发送1000字节的文件(S103)。之后，发生通信故障，TCP连接断开(S104)。
此处，假设在TCP连接断开之前，接收设备1002已保存500字节的数据(S105)。接收设备1002等待通信故障的解决，并且可以在任意时刻进行TCP的重连接而重新开始进行传输。传输的重新开始是通过以下方式来进行的，即接收设备1002向源设备1001发送添加了Range头的HTTP GET请求(S106)，请求从作为传输对象的文件的开头起第500个字节以后的数据。
源设备1001根据由接收设备1002所指定的Range(此处是第500-第999字节)来发送数据(S107、S108)，接收设备1002保存所接收的数据(S109)。这样，无须重新发送已传输完毕的数据，就可以通过重新开始传输而仅获取未传输的数据。这样的过程，可以使用在例如以下所述的应用程序中，即当配置在互联网上的服务器中的数兆字节以上的文件下载失败时，从已获取的数据之后继续获取数据，从而高效地获取文件。
现有技术中也公开有利用HTTP的GET方法来进行数据提供的技术(例如，参照专利文献1)。
日本专利特开2002-288162号公报然而，存在以下问题虽然所述现有的HTTP文件传输的中断、重新开始过程可以在HTTP的GET方法中使用，但无法在POST方法中使用。在从互联网上的服务器将文件下载到PC时，由于使用的是HTTP的GET方法，因此这样的限制并不会造成问题。
但是，当连接在网络上的任意设备之间传输文件时，在源设备未接收到接收设备的请求而欲自发地发送任意文件时，通常使用HTTP POST方法。因此，存在以下问题当源设备与接收设备之间的通信中断时，在再次开始通信之后必须从头开始进行文件的发送，浪费传输文件的资源及时间。
更一般地讲，该问题是指，在将从源设备侧自发地发送数据作为触发器(trigger)而进行推(push)型流量控制的文件传输协议中，与从接收设备侧发出请求的拉(pull)型流量控制不同，不存在当发生通信中断时进行高效的文件传输的过程。
进一步而言，即使是所述HTTP的GET方法，在其文件传输的中断、重新开始过程中，也未规定可重新开始的期间，因此其虽然适用于由非特定的多台PC下载长期公开在服务器上的文件，但在连接在网络上的任意设备之间传输文件时，不明确源设备及接收设备应将可重新开始的状态维持到何时为止。因此，在源设备及接收设备中会造成资源的浪费。
发明内容
考虑到所述问题，本发明的目的在于提供如下所述的发送设备、接收设备以及文件传输系统，即，在从发送设备自发地向接收设备传输文件的文件传输系统中，即使文件传输长时间中断，也能高效地执行文件传输的相关处理。
为了实现所述目的，本发明的文件传输系统是通过网络从发送文件的发送设备向接收所述文件的接收设备传输文件的文件传输系统。所述接收设备包括保存部件，用于保存从所述发送设备所接收的构成所述文件的文件数据；已保存大小获取部件，用于获取已保存到所述保存部件中的文件数据的大小，即已保存大小；以及接收控制部件，用于当所述发送设备询问所述已保存大小时，将由所述已保存大小获取部件所获取的所述已保存大小发送给所述发送设备。所述发送设备包括发送部件，用于将文件数据发送给所述接收设备；检测部件，用于检测所述文件传输的中断；询问部件，用于在所述检测部件检测出所述文件传输的中断之后，向所述接收设备询问所述已保存数据大小；以及发送控制部件，用于根据所述接收设备对应于所述询问部件的询问而响应的已保存数据大小，让所述发送部件发送构成所述文件的剩余文件数据。
并且，本发明的发送设备，用于进行通过网络向接收设备传输文件的文件传输，该发送设备包括发送部件，用于将构成所述文件的文件数据发送给所述接收设备；检测部件，用于检测所述文件传输的中断；询问部件，用于在所述检测部件检测出所述文件传输的中断之后，询问保存在所述接收设备中的文件数据的大小，即已保存数据大小；以及发送控制部件，用于根据所述接收设备对应于所述询问部件的询问而响应的已保存数据大小，让所述发送部件发送构成所述文件的剩余文件数据。
并且，本发明的接收设备，用于通过网络来接收从发送设备发送的文件，该接收设备包括保存部件，用于保存从所述发送设备所接收的构成所述文件的文件数据；已保存大小获取部件，用于获取已保存到所述保存部件中的文件数据的大小，即已保存大小；以及接收控制部件，用于当所述发送设备询问所述已保存大小时，将由所述已保存大小获取部件所获取的所述已保存大小发送给所述发送设备。
这样，根据本发明，发送设备在文件传输中断后可以向接收设备询问已保存大小。而且，接收设备可以将已保存大小发送给发送设备，作为对所述询问的响应。发送设备因得知已保存大小，就可以只把应发送的剩余文件数据发送给接收设备。
也就是说，当中断的文件传输重新开始进行时，发送设备无须从头开始进行文件数据的发送，仅发送对于接收设备而言所必需的剩余文件数据即可。并且，接收设备不会接收到重复的无用的文件数据。因此，在发送设备以及接收设备执行文件传输的相关处理时，即使发生长时间的中断，也不会进行无用的处理或者发生资源的浪费，可以高效地执行文件传输的相关处理。
并且，在本发明的文件传输系统中，所述接收控制部件进而也可以用于将请求中断文件传输的中断请求发送给所述发送设备。所述中断请求包括开始时间信息，其表示所述接收设备重新开始所述文件传输的开始时间；以及许可期间信息，其表示所述接收设备接受所述文件传输的终止时间。所述检测部件通过接收所述中断请求来检测所述文件传输的中断。所述发送控制部件让所述发送部件从所述开始时间起至所述许可期间之内发送所述剩余文件数据。并且，在本发明的文件传输系统中，所述发送控制部件进而也可以用于，在所述发送部件发送文件数据之前，将所述文件数据在所述接收设备中的保留期间通知给所述接收设备。所述接收控制部件进而用于，当所述文件数据保存在所述保存部件中，且，在超过所述文件数据的保留期间之前尚未从所述发送设备接收到构成所述文件的所有文件数据时，删除保存在所述保存部件中的所述文件数据。
这样，发送设备与接收设备之间可以相互交换与文件传输期间相关的信息。因此，在由对方设备中断文件传输时，发送设备以及接收设备均无须始终对文件传输的重新开始进行准备，从而不会浪费各设备的资源。也就是说，可高效地执行文件传输的相关处理。
进一步而言，本发明也可实现为将本发明的文件传输系统、发送设备以及接收设备各自的特征性构成部分作为步骤的方法；包括所述步骤的程序；保存有所述程序的CD-ROM等存储介质；集成电路等。程序也可以通过通信网络等传输介质来流通。
本发明可以提供如下所述的发送设备、接收设备以及文件传输系统，即，在从发送设备自发地向接收设备传输文件的文件传输系统中，即使文件传输长时间中断，也可以高效地执行文件传输的相关处理。
例如，在由使用HTTP的POST方法来发送文件的源设备、以及从源设备接收文件的接收设备所构成的文件传输系统中，即使在文件传输发生中断且TCP连接超时后，发送设备也可以得知已保存的数据大小。因此，发送设备可以将已保存到接收设备中的数据的后续数据发送给接收设备。
也就是说，当传输某文件时，发送设备不会发送无用的数据，接收设备也不会接收无用的数据。
结果，在将从源设备侧发送数据作为触发点而进行推型流量控制的文件传输协议中，也不会产生资源或时间等的浪费，从而可以高效地执行文件传输的相关处理。
进而，提供在中断、重新开始过程中对可重新开始的期间进行握手的方法以及部件，可以明确源设备以及接收设备应维持可重新开始的状态至何时为止。这样，可避免在文件传输中源设备以及接收设备的内存、介质等资源的浪费。通过这样的方式，也可以高效地执行文件传输的相关处理。
图1是由源设备及接收设备所构成的现有文件传输系统中重新开始传输文件的通信序列的示例图。
图2是表示本发明实施方式的文件传输系统的设备结构的图。
图3是表示本发明实施方式的源设备的功能性结构的功能方框图。
图4是表示本发明实施方式的接收设备的功能性结构的功能方框图。
图5是表示本发明实施方式的文件传输系统中的基本通信序列的图。
图6是表示从源设备发送给接收设备的各参数的内容的图。
图7是在实施方式的文件传输系统中，因源设备的原因而造成文件传输中断时的通信序列的示例图。
图8是在实施方式的文件传输系统中，因接收设备的原因而造成文件传输中断时的通信序列的示例图。
图9是在实施方式的文件传输系统中，因接收设备的原因而造成文件传输中断时的通信序列的另一示例图。
图10是表示在实施方式的文件传输系统中，重新开始文件传输时的通信序列的图。
图11是在实施方式的文件传输系统中，在开始发送文件数据之前，因源设备的原因而造成文件传输中止时的通信序列的示例图。
图12是在实施方式的文件传输系统中，在进行文件数据发送期间，因源设备的原因而造成文件传输中止时的通信序列的示例图。
图13是在实施方式的文件传输系统中，在开始发送文件数据之前，因接收设备的原因而造成文件传输中止时的通信序列的示例图。
图14是在实施方式的文件传输系统中，在进行文件数据发送期间，因接收设备的原因而造成文件传输中止时的通信序列的示例图。
图15是表示源设备将文件分割后传输给接收设备的文件传输系统的通信序列的图。
图16是表示在将文件分割进行传输的文件传输系统中，在发送分割后的一个文件数据之前，因源设备的原因而造成文件传输中断时的通信序列的图。
图17是表示在将文件分割进行传输的文件传输系统中，在接收设备接收到POST请求之后，因接收设备的原因而造成传输中断时的通信序列的图。
图18是表示在将文件分割进行传输的文件传输系统中，因接收设备的原因而造成文件传输中止时的通信序列的图。
附图标记说明101 源设备102 接收设备701 用户接口702 文件发送控制部703、802 文件控制部704、803 通信控制部705、804 文件存储部706、805 网络接口707 中断检测部708 询问部801 文件接收控制部806 已保存大小获取部具体实施方式
以下，使用附图来说明本发明的最佳实施方式。
首先，使用图2～图4来说明本发明的实施方式的文件传输系统的结构。
图2是表示本发明实施方式的文件传输系统的设备结构的图。本发明实施方式的文件传输系统是用来从源设备101向接收设备102传输文件的系统。
如图2所示，源设备101以及接收设备102连接于宽带路由器301而构成家庭网络。宽带路由器301也可以连接于互联网302。
源设备101与接收设备102各自内置有存储介质，可存储音频视频(AV，Audio Visual)内容等文件。具体而言，源设备101具有文件存储部705，接收设备102具有文件存储部804。
作为这样的设备，可以举出的例子有，具有网络连接端子的DVD/HDD混合录像机(hybrid recorder)等。在本实施方式的初始状态中，源设备101的文件存储部705中存有文件303。源设备101通过家庭网络将此文件传输到接收设备102。接收设备102将从源设备接收的文件303存储到文件存储部804中。
另外，在本实施方式中，假设接收设备102、源设备101均遵循通用即插即用论坛(Universal Plug and Play Forum)发布的UPnP-AV标准，接收设备102具有内容目录服务(CDS，Contents Directory Service)的服务器功能，源设备101具有对CDS服务器进行存取的控制点(Control Point)功能。
图3是表示本发明实施方式的源设备101的功能性结构的功能方框图。源设备101是本发明的发送设备的一个例子。另外，关于源设备101，省略对其原本具备的Control Point功能等的图示以及说明，仅对源设备101的特征性构成部分进行图示及说明。
如图3所示，源设备101具备用户接口701、文件发送控制部702、文件控制部703、通信控制部704、文件存储部705、以及网络接口706。图中的虚线所包围的区域中的构成部分，是进行文件传输相关的主要处理的构成部分。
用户接口701是用来接收用户所输入的指示等，并且利用图像等形式将信息提供给用户的接口。网络接口706是通过家庭网络而与接收设备102进行信息交换的接口。
如上所述，文件存储部705是用来存储AV内容等文件的存储装置。
文件发送控制部702是用来控制向接收设备102发送文件的控制部，其具有询问部708。询问部708是一个处理部，用于在重新开始中断的文件传输时，向接收设备102询问已保存数据大小。
另外，所述的已保存数据大小是指，在从源设备101向接收设备102的文件传输中，接收设备102所接收并保存的、构成所述文件的文件数据(以下，也简称为“数据”)的容量。也就是说，当文件大小为1000字节时，已保存数据大小为0～1000字节之间的值。
并且，所谓“文件传输的中断”，不仅是指开始发送文件数据之后文件数据的发送或者接收被中断的情况，还包括文件传输所必需的处理被中断的情况。
文件控制部703是对从文件存储部705读出文件进行控制的控制部。
通信控制部704是通过控制网络接口706而对通信进行控制的控制部，该通信是通过家庭网络进行的。由通信控制部704及网络接口706，可以实现本发明的发送设备中的发送部件所具有的发送信息的功能。并且，通信控制部704具有中断检测部707。中断检测部707是用来检测文件传输中断的处理部。
源设备101控制用户接口701来显示存储在文件存储部705中的文件的一览表。从文件存储部705中读出用户从一览表中选择的文件，并控制网络接口706将文件发送给接收设备102。
图4是表示本发明实施方式的接收设备102的功能性结构的功能方框图。接收设备102是本发明的接收设备的一个例子。另外，关于接收设备102，省略对其原本所具备的CDS服务器功能等的图示以及说明，仅对接收设备102的特征性构成部分进行图示及说明。
如图4所示，接收设备102具备文件接收控制部801、文件控制部802、通信控制部803、文件存储部804、以及网络接口805。图中虚线所包围的区域内的构成部分是进行文件传输相关的主要处理的构成部分。
网络接口805是通过家庭网络而与源设备101进行信息交换的接口。
文件存储部804是本发明的接收设备中的保存部件的一个例子，如上所述，是用来存储从源设备101接收的文件的存储装置。
文件接收控制部801是对从源设备101发送的文件的接收进行控制的控制部。
文件控制部802是对从文件存储部804读出文件进行控制的控制部，其具有已保存大小获取部806。已保存大小获取部806是从文件存储部804获取已保存数据大小的处理部。所获取的已保存数据大小，通过文件接收控制部801的控制被发送到源设备101。
通信控制部803是通过控制网络接口805而对通信进行控制的控制部，该通信是通过家庭网络进行的。
接着，参照图5至图14，对由源设备101以及接收设备102所构成的文件传输系统中的源设备101以及接收设备102的动作进行说明，其中源设备101以及接收设备102具有如上所述的结构。
首先，使用图5以及图6说明基本通信序列中各设备的动作。
图5是表示本发明实施方式的文件传输系统中的基本通信序列的图。如图5所示，在本实施方式中，通过从源设备101向接收设备102的通信来开始进行文件传输。也就是说，图5是表示从源设备101自发地进行文件传输时的通信序列图。
另外，源设备101与接收设备102之间的通信是通过宽带路由器301而转接的。但是，宽带路由器301的动作与本发明的特征无关，因此以下省略其图示以及动作的说明。
源设备101发送由UPnP-AV标准规定的CDSCreateObject请求(S501)。这里的CreateObject请求是生成表示逻辑文件的object的请求，以此在接收设备102的文件存储部804内生成新的object。此时，所生成的object在目录结构上的位置、及表示该object的文件名等元数据被确定。此元数据包含应保存文件实体的接收设备102上的统一资源标识符(URI，UniformResource Identifiers)。接收设备102向源设备发送CDSCreateObject响应，该响应中包含此URI作为文件传输的目的地址(S502)。
源设备101将POST方法的HTTP请求(以下称作“POST请求”)发送给接收设备102(S503)。此时，源设备101将图6所示的参数作为文件传输中断时接收设备102应参照的参数，附加在POST请求中并发送。具体而言，将[byte-range]、[restart-time]、以及[lifetime]这三个作为参数发送。
图6是表示从源设备101发送给接收设备102的各参数的内容的图。
如图6所示，[byte-range]是要发送的数据的字节范围。字节范围包括表示要发送的文件数据的范围即数据范围的开始位置与结束位置的信息、以及表示文件的总大小即文件大小的信息。并且，单位分别为字节。
也就是说，接收设备102不仅收到从源设备发送的数据范围的通知，也收到文件的总大小的通知。因此，可以判断出所接收的文件数据是构成某文件的一部分文件数据，还是构成某文件的全部文件数据。另外，在本实施方式中，当将一个文件发送给接收设备102时，不对其进行分割而是整个发送。对于将文件分割后进行发送的情况，将使用图15在下文中进行说明。
是重新开始发送的许可时间。重新开始发送的许可时间，是表示中断后直至重新开始文件传输动作为止的暂时停止时间的信息，单位为秒。
是文件保留期间。文件保留期间是表示接收设备102应保留object或者文件数据的时间的信息，单位为秒。当直至超过[lifetime]所示期间为止仍未接收到文件数据时，接收设备102无义务保留所创建的object。并且，在收到[lifetime]通知且接收到尚未完结的文件数据的情况下，当直至超过[lifetime]所示期间为止仍未接收到剩余文件数据时，接收设备102无义务保留尚未完结的文件数据。
这样，在无法与源设备101连接、或作为传输对象的文件消失等情况下，接收设备102也无须为了无法完成的文件传输而保持多余的资源。因此，接收设备102可高效地进行资源管理，用户手动删除不需要的object等的维护操作也不需要。
按照图5所示的通信序列，源设备101指定要发送的数据的开始位置第0字节、结束位置第999字节、以及文件大小1000字节。如上所述，这意味着将一个文件整个进行发送。进而也指定暂时停止时间1200秒(20分钟)、文件保留期间1800秒(30分钟)。
另外，表示传输中断请求的[suspend-req]并未在图5所示的通信序列中使用。对于将[suspend-req]发送给接收设备102的情况，将使用图7在下文中进行说明。
并且，从源设备101发送到接收设备102的POST请求所指定的URI，记载的是包含在从接收设备102所接收的CreateObject响应中的URI。这样，接收设备102可以将所接收的文件数据与特定的object相对应。
进而，在POST请求中附加有Expect100-continue。这样，接收设备按照RFC2616，检查是否能够以所述URI接受发来的POST请求。
检查的结果，如果可以接受，则返回“100 Continue”作为响应(S504)。另外，当无法接受来自源设备101的POST请求时、或是无法解释POST请求时，可以在传输数据之前通知源设备。因此，源设备101可以避免进行无用的数据发送。
源设备101从接收设备102接收到“100 Continue”状态后，将文件发送给接收设备102(S505)。另外，文件数据被放入POST请求的Entity Body中发送。
接收设备102将所接收的文件数据存储到文件存储部804内。接收设备102，当在文件的接收完成之后，还需要时间来进行将文件存储到文件存储部804的处理时，例如在20秒以内未完成存储时，发送由RFC2518所规定的“102 Processing”(S506)，通知源设备101正在进行存储处理。当存储完成时，接收设备102发送“201 Created”，通知源设备101存储已完成(S507)。
通过以上各设备的动作，完成从源设备101向接收设备102的文件传输。
另外，图5所示的通信序列是在文件传输中途未发生中断时的基本通信序列，但也有由于源设备101或者接收设备102的原因而发生文件传输中断的情况。因此，以下使用图7～图9，对文件传输中途发生中断时的通信序列及各设备的动作进行说明。并且，使用图10对重新开始文件传输时的通信序列及各设备的动作进行说明。
图7是在实施方式的文件传输系统中，由于源设备101的原因而造成文件传输中断时的通信序列的示例图。使用图7，对从源设备101向接收设备102发送文件数据的期间，由于源设备101的原因而造成文件传输中断时的各设备的动作进行说明。
源设备101以及接收设备102与图5所示的通信序列同样，进行CDSCreateObject请求以及响应通信。之后，源设备101将POST请求发送给接收设备102(S503)。接收设备102将“100 Continue”状态作为POST请求的响应发送到源设备101(S504)。源设备101开始向接收设备102发送文件数据(S505)。接收设备102将所接收的文件数据存储到文件存储部804中。到此为止的动作与图5所示的通信序列相同。
此处，在源设备101中有导致中断文件传输的原因产生，源设备101发送用来切断TCP连接的RST包。这样，文件传输时所利用的TCP连接被切断(S706)。
导致中断文件传输的原因，例如是因用户的操作而使传输中的文件从文件存储部705中被删除等。
源设备101进而将含有[suspend-req]以及[lifetime]的POST请求包发送给接收设备102(S707)。如图6所示，[suspend-req]是表示文件传输的中断请求的信息。也就是说，接收设备102通过接收[suspend-req]可得知文件传输已中断。并且，如上所述，[lifetime]是表示接收设备102应保留文件数据的时间的信息，此时，也意味着源设备101会在此时间内重新开始文件传输。接收设备102在经过文件保留期间之后，也可以将接收并已保存的所述文件数据删除。
另外，在所述文件传输的中断的相关处理中，RST包以及POST请求包是由文件发送控制部702所生成并发送到接收设备102中的。以下简称为“POST请求”时，其实体是指POST请求包。
并且，中断检测部707通过检测到TCP连接已断开，从而检测出文件传输已中断。
接收设备102在接收到所述POST请求时返回“200 OK”(S708)。在导致中断文件传输的原因消失之后，源设备101执行重新开始文件传输的动作，对于该动作，将使用图11在下文中进行说明。
这样，在本实施方式的文件传输系统中，在文件数据的发送开始之后且文件传输完成之前，由于源设备101的原因而造成文件传输中断。
接着，使用图8，说明在接收设备102接收到POST请求时，由于接收设备102的原因而造成文件传输中断时的各设备的动作。
图8是实施方式的文件传输系统中，由于接收设备102的原因而造成文件传输中断时的通信序列的示例图。
源设备101以及接收设备102与图5所示的通信序列同样，进行CDSCreateObject请求以及响应通信。之后，源设备101将POST请求发送给接收设备102(S503)。以上的动作与图5所示的通信序列相同。
此处，接收设备102处于无法进行文件接收处理的状态，发送“503Service Unavailable”状态作为对POST请求的响应。无法进行文件接收处理的状态，例如是文件存储部804没有空余容量的状态等。
接收设备102在进行响应时其状态包中包含表示重新开始文件传输的开始时间的“retry-after”(S804)。在经过“retry-after”所示时间之后，源设备101执行重新开始文件传输的动作，对于该动作，将使用图11在下文中进行说明。
这样一来，在本实施方式的文件传输系统中，从源设备101向接收设备102通过POST请求通知传输的文件的大小等之后，且在开始文件数据的发送之前，由于接收设备102的原因而造成文件传输中断。
以下，使用图9，说明在从源设备101向接收设备102发送文件数据期间，由于接收设备102侧的原因而造成文件传输中断时的各设备的动作。
图9是在实施方式的文件传输系统中，由于接收设备102的原因而造成文件传输中断时的通信序列的另一示例图。
源设备101以及接收设备102与图5所示的通信序列同样，进行CDSCreateObject请求以及响应通信。之后，源设备101将POST方法的HTTP请求发送给接收设备102(S503)。接收设备102将“100 Continue”状态作为对HTTP请求的响应发送给源设备101(S504)。源设备101开始向接收设备102发送文件数据(S505)。接收设备102将所接收的文件数据存储到文件存储部804中。到此为止的动作与图5所示的通信序列相同。
此处，在接收设备102中有导致中断文件传输的原因产生，接收设备102发送RST包。这样，文件传输时所利用的TCP连接被切断(S906)。导致中断文件传输的原因，例如有必须从文件存储部804中读出其他文件、无法存储所接收的文件数据等。
当TCP连接由接收设备切断时，源设备101的文件发送控制部702再次将POST请求发送给接收设备102(S907)。
接收设备102将“503 Service Unavailable”状态作为对POST请求的响应发送给源设备101(S908)。在状态包中包含所述[retry-after]。
伴随着该[retry-after]的“503 Service Unavailable”，是来自接收设备102的文件传输的中断请求。
源设备101的中断检测部707通过检测此中断请求来检测文件传输的中断。在经过“retry-after”所示时间之后，源设备101执行重新开始文件传输的动作，对于该动作，将使用图11在下文中进行说明。
这样，在本实施方式的文件传输系统中，在文件数据的发送开始之后且发送完成之前，由于接收设备102侧的原因而造成文件传输中断。
以下，对使用图7～图9所说明的文件传输的中断之后，重新开始文件传输时的各设备的动作，使用图10进行说明。
图10是表示在实施方式的文件传输系统中，重新开始文件传输时的通信序列的图。
源设备101的中断检测部707检测出文件传输已中断(S1000)。另外，中断检测部707不管文件传输的中断是由于源设备101的原因而引起、还是由于接收设备102的原因而引起，都可以根据收发包的种类以及内容等检测出文件传输已中断。
源设备101在由于自身的原因而中断文件传输的情况下，在导致该中断的原因消失之后，或者，在由于接收设备102的原因而造成文件传输中断的情况下，则在中断时从接收设备102发送的[retry-after]所示的时间经过之后，进行以下动作。
源设备101将CDSBrowse请求发送给接收设备102(S1001)，向接收设备102询问文件的保存大小。
具体而言，在源设备101的文件发送控制部702所生成的CDSBrowse请求中，包含来自询问部708的对已保存数据大小的通知请求。该CDSBrowse请求通过网络接口706被发送到接收设备102。
接收设备102在接收到所述CDSBrowse请求时，将包含已保存数据大小的CDSBrowse响应发送给源设备101(S1002)。
具体而言，已保存大小获取部806获取保存在文件存储部804中的、构成所述文件的文件数据的数据大小。进而，文件接收控制部801生成CDSBrowse响应，该响应包含由已保存大小获取部806所获取的数据大小。所生成的CDSBrowse响应通过网络接口805被发送给源设备101。
源设备101的文件发送控制部702，根据所接收的已保存数据大小来确定应传输的文件的开始位置，并从文件存储部705中读出文件数据。
例如，假设文件大小为1000字节，接收设备102所通知的已保存数据大小为400字节。此时，保存在接收设备102中的文件数据是从第0字节～第399字节为止的文件数据。因此，文件发送控制部702通过文件控制部703而从文件存储部705中读出剩余的第400字节～第999字节的文件数据。以下，当称为“剩余的文件数据”时，如上所述，是指从作为传输对象的文件数据中去除已保存到接收设备102中的文件数据后剩余的文件数据。
源设备101将包含表示数据范围与文件大小的[byte-range]等的POST请求发送给接收设备102(S1003)。接收设备102将“100 Continue”状态作为对POST请求的响应发送给源设备101(S1004)。
源设备101的文件发送控制部702，将从文件存储部705中读出的剩余的文件数据发送给通信控制部704(S1005)。接收设备102的文件控制部802，根据[byte-range]所示的数据范围，将所接收的文件数据、与中断前已保存的文件数据合并，重新构建成原文件。
这样，本发明实施方式的源设备101，在重新开始已中断的文件传输时，可以向接收设备102询问已保存数据大小。并且，本发明实施方式的接收设备102可响应此询问而将已保存数据大小通知给源设备101。
这样，源设备101无须再次从头开始进行文件传输，仅发送剩余的文件数据即可。而且，接收设备102不会重复接收文件数据。
也就是说，通过本发明实施方式的源设备101、接收设备102以及文件传输系统，在来自源设备101的自发性文件传输中，即使发生的中断超过规定的TCP连接的超时时间，也可以高效地执行文件传输的相关处理。
进一步而言，由于可在设备之间通知可重新开始传输的时间，因此具有可抑制多余的尝试重新开始传输的动作，从而可减轻设备的通信负荷的效果。
另外，在文件传输中途网络的通信路径断开的情况下，当源设备101的中断检测部707检测出通信路径的断开时，开始执行图10的通信序列所示的重新开始文件传输的动作。
并且，上文已使用图7～图9说明了文件传输中断时的通信序列以及各设备的动作，但也有由于源设备101或者接收设备102的原因而必须中止而非中断文件传输的情况。本发明实施方式的源设备101以及接收设备102在中止文件传输时，可分别通知对方设备。以下，使用图11～图14说明文件传输中止时的通信序列以及各设备的动作。
图11是在实施方式的文件传输系统中，在开始发送文件数据之前，由于源设备101的原因而造成文件传输中止时的通信序列的示例图。下面使用图11，说明在文件传输开始之前，由于源设备101的原因而造成文件传输中止时的各设备的动作。
源设备101以及接收设备102与图5所示的通信序列同样，进行CDSCreateObject请求以及响应通信(S501、S502)。此后，假设在源设备101发送POST请求之前，有以下情况发生用户对源设备101发出取消文件传输的指示、或者作为传输对象的文件被删除等。
此时，源设备101为了中止文件传输，并不发送POST请求而是将CDSDestroyObject请求发送给接收设备102(S1103)。接收设备102在接收到CDSDestroyObject时，删除对应于CDSCreateObject请求(S501)所创建的object。进而，为了通知源设备101 object已删除，而向源设备101返回CDSDestroyObject响应(S1104)。
这样，当在文件传输开始之前，由于源设备101的原因而造成文件传输中止时，接收设备102将为了保存文件而创建的object删除。也就是说，接收设备102会迅速删除已无用的object。
接着，使用图12说明在从源设备101向接收设备102发送文件数据期间，由于源设备101的原因而造成文件传输中止时的各设备的动作。
图12是在实施方式的文件传输系统中，在文件数据的发送期间，由于源设备101的原因而造成文件传输中止时的通信序列的示例图。
源设备101以及接收设备102与图5所示的通信序列同样，进行CDSCreateObject请求以及响应通信。之后，源设备101将POST请求发送给接收设备102(S503)。接收设备102将“100 Continue”状态作为对POST请求的响应发送给源设备101(S504)。源设备101开始向接收设备102发送文件数据(S505)。接收设备102将所接收的文件数据存储到文件存储部804中。到此为止的动作与图5所示的通信序列相同。
此处，假设在源设备101发送POST请求之前，发生以下情况用户对源设备101发出取消文件传输的指示、或者作为传输对象的文件被删除等。
源设备101为了中止文件传输而发送TCP的RST包(S1206)。这样，文件传输时所利用的TCP连接被切断。源设备101进而将CDSDestroyObject请求发送给接收设备102(S1207)。接收设备102对应于CDSDestroyObject请求，将已接收的文件数据删除，并将CDSDestroyObject响应发送给源设备101(S1208)。
这样，当在开始发送文件数据之后，由于源设备101的原因而造成文件传输中止时，接收设备102将已接收并保存的文件数据删除。也就是说，接收设备102会迅速删除尚未完结但已无用的文件数据。
接着，使用图13说明在接收设备102接收到POST请求时，由于接收设备102的原因而造成文件传输中止时的各设备的动作。
图13是在实施方式的文件传输系统中，在开始发送文件数据之前，由于接收设备102的原因而造成文件传输中止时的通信序列的示例图。
源设备101以及接收设备102与图5所示的通信序列同样，进行CDSCreateObject请求以及响应通信。之后，源设备101向接收设备102发送POST请求(S503)。到此为止的动作与图5相同。
此处，假设发生了以下情况，即，在接收设备102中，由于对应于来自源设备101的CDSCreateObject请求而创建的object消失等原因，而必须中止文件传输。
此时，接收设备102将“404 Not Found”状态作为对POST请求的响应发送给源设备101(S1304)。源设备101对应于“404 Not Found”而中止文件传输的相关处理。
这样，当在从源设备101通过POST请求而向接收设备102发出文件大小等通知后，且在开始发送文件数据之前，由于接收设备102的原因而造成文件传输中止时，源设备101根据来自接收设备102的通知而中止文件传输的相关处理。也就是说，源设备101不会继续进行多余的处理。
接着，使用图14说明在从源设备101向接收设备102发送文件数据期间，由于接收设备102的原因而造成文件传输中止时的各设备的动作。
图14是在实施方式的文件传输系统中，在文件数据的发送期间，由于接收设备的原因而造成文件传输中止时的通信序列的示例图。
源设备101以及接收设备102与图5同样，进行CDSCreateObject请求以及响应通信。之后，源设备101向接收设备102发送POST请求(S503)。接收设备102将“100Continue”状态作为对POST请求的响应发送给源设备101(S504)。源设备101开始向接收设备102发送文件数据(S505)。接收设备102将所接收的文件数据存储到文件存储部804中。到此为止的动作与图5所示的通信序列相同。
此处，在接收设备102中有导致中止文件传输的原因产生，接收设备102发送TCP的RST包(S1406)。这样，文件传输时所利用的TCP连接被切断。源设备101在检测出TCP连接的切断时，再次向接收设备102发送POST请求(S1407)。接收设备将“404 Not Found”状态作为对POST请求的响应发送给源设备101(S1408)。源设备101对应于“404 Not Found”而中止文件传输的相关处理。
这样一来，当在从源设备101向接收设备102开始发送文件数据之后，由于接收设备102的原因而造成文件传输中止时，源设备101根据来自接收设备102的通知而中止文件传输的相关处理。也就是说，源设备101不会继续进行多余的处理。
这样，本发明实施方式的源设备101以及接收设备102，在中止文件传输时，不管所述中止是由于哪个设备的原因所造成的，都会进行用来中止文件传输的处理，以避免发生资源的浪费以及进行无用的处理。
另外，在上述实施方式中，作为进行推型流量控制的文件传输协议，对通过HTTP的POST方法来进行文件传输的情况进行了说明。然而，也可以通过POST方法以外的方法，例如，通过PUT方法也可以达到所述效果。
并且，源设备101将图6所示的参数附加到HTTP请求包中进行发送，作为文件传输中断时接收设备102应参照的参数。
将该参数赋予请求包的具体方法有，使POST请求中包含单独定义的头，作为POST请求的消息头。
例如，将作为单独定义的头的UploadTransportInfo.dlna.org[byte-range]赋予POST请求，存放HTTP的Entity Body部中所包含的数据的范围以及总大小。并且，使其含有[lifetime]等必要的信息。接收设备102能够从源设备101所发送的POST请求的消息头中获取这些信息。
并且，在上述实施方式中，对将[byte-range]、[restart-time]、以及[lifetime]这三个参数附加到POST请求中进行发送的结构进行了说明。然而也可以仅附加[restart-time]。
另外，除了UploadTransportInfo.dlna.org以外，由于HTTP中理所当然所使用的其他头与本发明的特征无关，因此省略了相关的图示以及说明。
并且，在上述实施方式中，源设备101将文件传输给接收设备102时，是将文件整个传输。然而，源设备101也可以分割文件，并对应每一分割单位而发送到接收设备102。当接收设备102在一次POST请求中对可接收数据的大小有所限制等情况下，源设备101对应每一分割单位而发送文件数据的方法会很有效。
图15是表示源设备101将文件分割后传输给接收设备102的文件传输系统的通信序列的图。使用图15，说明源设备101将文件分割后进行传输时的各设备的动作。另外，假设源设备101为了将要发送的文件数据的范围等通知给接收设备102，而使用如上所述的单独定义的头UploadTransportInfo.dlna.org。
源设备101在传输文件之前，先向接收设备102发出CDSCreateObject请求(S1503)。接收设备102按照CDSCreateObject请求而创建object，并将CDSCreateObject响应发送给源设备101(S1504)。
源设备101决定文件的分割传输的大小。对于分割传输的大小，可以考虑到传输的中断、重新开始的频率、中断时变得无用的传输大小、以及分割所产生的系统开销(overhead)等而任意决定。此处，将1000字节的文件分割成从最初的第0字节～第499字节的文件数据、及后续的第500字节～第999字节的文件数据(S1505)。此文件分割是由源设备的文件发送控制部702来执行的。
源设备101开始进行文件传输。具体而言，源设备101发送POST请求(S1506)。在POST请求中包含单独定义的头，即UploadTransportInfo.dlna.org[byte-range]、[lifetime]。此处的[byte-range]是表示接在头后面的HTTP的Entity Body部中所包含的数据的范围、以及文件的总大小的信息。这里，指定数据范围为“0-499”，指定文件总大小为“1000”。[lifetime]中指定有内容的保留期间，此处以秒为单位指定“1800”，也就是说，指定30分钟。
接收设备102将“100 Continue”作为对所述POST请求的响应发送给源设备101(S1507)。
源设备101向接收设备102发送所通知的数据范围的文件数据(S1508)。具体而言，是将所述文件数据放入POST请求的Entity Body中进行发送。Entity Body中所包含的文件的范围，如上所述，仅为“0-499”的500个字节。
接收设备102在接收到此500个字节的文件数据后，开始将其保存到文件存储部804中。当在开始保存后，因向文件存储部804的写入速度慢等而基本上无法在20秒以内完成保存时，发送“102 Processing”(S1509)。之后，当所接收的文件数据的保存完成时(S1510)，将“201 Created”发送给源设备101(S1511)，通知源设备101传输数据已保存。
然后，源设备101与接收设备102，按照与上述相同的动作序列，即，从源设备101向接收设备102发送POST请求(S1506)开始，到接收设备102通知源设备101保存完成(S1511)为止，传输下一分割单位即第500字节～第999字节的文件数据(S1512～S1517)。
即，源设备101在UploadTransportInfo.dlna.org头的[byte-range]中放入“500-999/1000”，并通知接收设备102。接收设备102对此进行解释，之后将所接收的文件数据(S1515)拼接在已保存的第0字节～第499字节的文件数据上，并保存到文件存储部804中。
这样，即使在使用POST方法来发送文件的推型流量控制时，也可以将文件分割后进行发送。
另外，即使在这种将文件分割后进行传输的情况下，当文件传输中断时，源设备101也如图10的通信序列所示，向接收设备102询问已保存数据大小，从而仅发送应发送的剩余文件数据。例如，假设图15所示的通信序列中，在最初的500个字节的发送期间文件传输中断，而至此为止在接收设备102中已保存有200个字节。此时，源设备101通过向接收设备102进行询问而获取已保存数据大小为“200”。之后，源设备101将剩余的300个字节发送给接收设备102。
并且，当由于传输路径上的错误等而导致无法获取已保存数据大小时，会再次发送处于发送途中的文件数据。例如，在图15的通信序列中，当在后500个字节的发送期间文件传输中断，源设备101无法从接收设备102获取已保存数据大小时，将后500个字节从头开始发送。
也就是说，根据来自接收设备102的“201 Created”，已确认最初的500字节已保存到接收设备102中，因此源设备101仅对后500字节进行再次发送即可。
这样，将作为传输对象的文件分割后进行发送的方法，如上所述，不仅在接收设备102在一次POST请求中对可接收数据的大小有所限制的情况下有效，对于文件传输的高效化也有用。
并且，在已分割的文件数据发送到接收设备102之前，文件的总大小通过POST请求被通知给接收设备102。因此，接收设备102可以判断所接收的文件数据是构成某文件的一部分文件数据，还是构成某文件的全部文件数据。
例如，当在发送文件数据之前所通知的[byte-range]为“0-499/1000”时，可以判断出之后所接收的文件数据为构成某文件的一部分文件数据。而当[byte-range]为“0-999/1000”时，则可以判断出之后所接收的文件数据为构成某文件的全部文件数据。
这样，例如在接收并保存了[byte-range]被指定为“0-499/1000”的文件数据之后，未接收到剩余文件数据时，可以判断出已保存的文件数据是尚未完结的文件数据。因此，可进行如下所述的处理在规定的期间之后将其删除，或者向用户确认是否要继续保存等。
关于所接收的文件数据，如上所述，当超过源设备101所指定的[lifetime]所示的保留期间时，可进行删除。因此，接收设备102在未指定[lifetime]时，通过基于所述[byte-range]的判断，也可以在经过规定期间后进行删除。并且，当超过[lifetime]所示的保留期间，且根据[byte-range]所示的信息可判断出该文件数据是尚未完结的文件数据时，也可以删除此文件数据。
另外，用来将所述[byte-range]以及[lifetime]等通知给接收设备102的头的名称，也可以是UploadTransportInfo.dlna.org以外的头名称。进一步而言，在本实施方式中，按照数字生活网络联盟(DLNA，Digital Living NetworkAlliance)所定义的头命名方法，使用“.dlna.org”作为后缀，可避免偶然与其他任意的头名称重名。然而，并不限定于此，例如也可以使用表示其为HTTP的单独扩展头的前缀“X-”而定义为“X-UploadTransportInfo”等。
并且，在图15所示的通信序列中，是将1000字节的文件分割为各500字节的两个部分，当然，并不限定于此分割单位，可以进行任意分割。
并且，在从源设备101向接收设备102将文件分割后进行传输的文件传输系统中，也有由于源设备101或者接收设备102的原因而造成文件传输中断或者中止的情况。因此，以下使用图16以及图17，说明在发送作为分割后的1个片断的文件数据之前，文件传输中断时的通信序列以及各设备的动作。并且，使用图18说明文件传输中止时的通信序列以及各设备的动作。
图16是表示在将文件分割后进行传输的文件传输系统中，在发送分割后的一个文件数据之前，由于源设备101的原因而造成文件传输中断时的通信序列的图。
在图16的通信序列中，从发送CDSCreateObject请求(S1503)后开始，直到将作为传输对象的文件分割(S1505)为止，与使用图15所说明的情况相同，因此省略说明。
此处，假设在源设备101中，根据用户的取消指示等而中断文件的传输。此时，源设备101将包含表示将处理挂起的[suspend]的UploadTransportInfo.dlna.org头放入POST请求的消息头中，并发送给接收设备102(S1606)。
源设备101可以通过表示[suspend]的域值明确地向接收设备102发出中断的通知，该[suspend]是所述UploadTransportInfo.dlna.org头中所包含的关键字。另外，此时，不发送POST请求的Entity Body。并且，与图15所示的通信序列同样，[lifetime]也包含在所述头中，例如以秒为单位指定“1800”，也就是指定30分钟。
接收设备102发送“200 OK”(S1607)，表示已获知中断。
根据此过程，与仅因TCP切断等而中断的情况相比较，由于可进行适当的处置，例如在接收设备102中使多余的传输进程转为睡眠状态等，因此具有抑制无用处理发生的作用。
另外，传输的重新开始可由源设备101在UploadTransportInfo.dlna.org头的[lifetime]所指定的30分钟以内任意执行。另外，当源设备101无法在30分钟以内重新开始传输时，也可以通过再次发送UploadTransportInfo.dlna.orgsuspend而再次延长重新开始传输的期间。
接着，使用图17说明在将文件分割后进行传输的文件传输系统中，在接收设备102接收到POST请求后，由于接收设备102的原因而造成文件传输中断时的各设备的动作。
图17是表示在将文件分割后进行传输的文件传输系统中，在接收设备102接收到POST请求后，由于接收设备102的原因而造成文件传输中断时的通信序列的图。
在图17所示的通信序列中，从源设备101发送CDSCreateObject请求(S1503)之后开始，直到通过POST请求来通知要发送的文件数据的范围等(S1506)为止，与使用图15所说明的情况相同，因此省略说明。
此处，假设接收到所述POST请求(S1506)的接收设备102，由于正在从文件存储部804中读出数据等原因，而处于无法进行文件传输的状态。
此时，接收设备102将“503 Service Unavailable”作为对POST请求的响应发送给源设备101(S1707)，通知源设备101其处于无法进行文件传输的状态。
并且，接收设备102通过将Retry-After头放入包含“503 ServiceUnavailable”的响应消息中，来通知预计可以开始传输的时间。也就是说，Retry-After头是表示重新开始文件传输的开始时间的信息。进一步而言，通过放入单独定义的UploadTransportExpireInfo.dlna.org头，来通知可以重新开始的期间。
UploadTransportExpireInfo.dlna.org头是用来表示接受文件传输的终止时间的头。在图17所示的通信序列中，以秒为单位指定“1800”，也就是指定30分钟。此时，表示在从接收设备102发送所述响应消息(S1707)之后开始、直至30分钟后为止的期间内接受文件传输。具体而言，当经过30分钟后，对应于来自源设备101的CDSCreateObject请求(S1503)而创建的object被删除。另外，当在已接收并保存一部分文件数据之后中断文件传输时，由于文件存储部804中保存的是尚未完结的文件数据，因此所述文件数据被删除。
此处，由RFC2616所定义的Retry-After头一般并非用来保证服务的重新开始，而是用来通知即使是在比Retry-After头所示的期间更短的间隔内进行重试，服务可重新开始的可能性也较小，从而抑制对方设备的定时询问负荷。
因此，源设备101针对接收设备102，在由Retry-After头所示的20分钟以后、且由UploadTransportExpireInfo.dlna.org头所示的30分钟以内，进行重试，并确认是否可以重新开始传输，如果可以，则进行后续文件数据的发送。
这样，接收设备102在由于自身的原因而中断文件传输时，通过Retry-After头以及UploadTransportExpireInfo.dlna.org头，将源设备101应重试文件传输的开始时间以及终止时间通知给源设备101。
这样，源设备101不会进行无用的重试。从而可以防止源设备101内以及传输路径上的资源浪费。
接着，使用图18说明在将文件分割后进行传输的文件传输系统中，作为中止文件传输的一个例子，由于接收设备102的原因而造成文件传输中止时的通信序列以及各设备的动作。
图18是表示在将文件分割后进行传输的文件传输系统中，由于接收设备102的原因而造成文件传输中止时的通信序列的图。
在图18的通信序列中，从源设备101发送CDSCreateObject请求(S1503)之后开始，直至接收设备102通知源设备101其处于无法进行文件传输的状态等(S1707)为止，与使用图15及图17所说明的情况相同，因此省略说明。
假设在图18所示的通信序列中，接收设备102发出用来暂时中断文件传输的通知(S1707)，但当源设备101进行文件传输的重试(S1808)时，接收设备102并不重新开始文件传输却产生想中止文件传输的理由。
作为这样的理由，可以举出的例子有由于文件存储部804已无空余容量而导致当前没有重新开始传输的可能性，或者，一旦进行传输则会对接收设备102的动作本身造成障碍等。
在这样的情况下，接收设备102将“404 Not Found”作为响应进行发送(S1809)，表示发送目的方的URI资源，也就是用来保存所发送的文件数据的object被删除已经无法使用。另外，由于源设备101与接收设备102在时间上的差异，源设备101针对已被接收设备102删除的URI进行重试时，也有与上述序列相同的情况。
另外，当从源设备101中止文件传输时，有下述方法，即直到超时为止不对规定的URI进行重试；以及发出UPnP-AV的CDSDestroyObject，明确地从接收设备102中删除对象(object)及与其相关的URI等。
以上，使用以UPnP-AV的对象单位来管理文件传输的示例进行了说明，但并不限定于此，也可适用于仅对规定的URI进行文件发送的情况。
这样，即使是将文件分割后进行传输的文件传输系统，当文件传输中断或者中止时，源设备101或者接收设备102也能够将中断或者中止通知给对方设备。这样，收到中断或者中止通知的设备不会继续进行已无用的文件传输处理。
另外，对通过HTTP的POST方法来发送文件的情况进行了说明，但并不限定于此，对于PUT方法、进而可适用同样的握手序列的HTTP以外的文件传输协议而言也可适用。
并且，在图16～图18中，表示的是分割后的文件数据一次都未发送过，文件传输就被中断或者中止时的通信序列。然而，使用图16～图18所说明的文件传输的中断或者中止时的各设备的动作，在文件数据发送了一次或一次以上且下一次文件数据发送之前被中断或者中止时的情况也与此相同。
本发明的发送设备、接收设备、以及文件传输系统，对于在连接于网络的任意设备之间传输文件的文件传输系统有用。尤其是在文件较大且传输中断后重新开始时，如果从头开始重新传输则会产生较大浪费，此时本发明能够发挥作用。
权利要求
1.一种文件传输系统，用于通过网络从发送文件的发送设备向接收所述文件的接收设备进行文件传输，其特征在于，所述接收设备包括保存部件，用于保存从所述发送设备所接收的构成所述文件的文件数据；已保存大小获取部件，用于获取已保存到所述保存部件中的文件数据的大小，即已保存大小；以及接收控制部件，用于当所述发送设备询问所述已保存大小时，将由所述已保存大小获取部件所获取的所述已保存大小发送给所述发送设备；并且所述发送设备包括发送部件，用于将文件数据发送给所述接收设备；检测部件，用于检测所述文件传输的中断；询问部件，用于在所述检测部件检测出所述文件传输的中断之后，向所述接收设备询问所述已保存数据大小；以及发送控制部件，用于根据所述接收设备对应于所述询问部件的询问而响应的已保存数据大小，让所述发送部件发送构成所述文件的剩余文件数据。
2.根据权利要求1所述的文件传输系统，其特征在于，所述发送部件使用超文本传输协议的POST方法或者PUT方法将所述文件发送给所述接收设备。
3.根据权利要求1所述的文件传输系统，其特征在于，所述发送控制部件进而用于在所述发送部件发送文件数据之前，将所述文件数据在所述文件中的范围即数据范围通知给所述接收设备；所述接收设备进而包括文件控制部件，用于根据所述数据范围，将所述保存部件中所保存的文件数据、与收到所述数据范围的通知之后所接收的文件数据合并。
4.根据权利要求3所述的文件传输系统，其特征在于，所述发送控制部件用于将所述文件的总大小与所述数据范围一起通知给所述接收设备。
5.根据权利要求4所述的文件传输系统，其特征在于，所述发送控制部件进而用于将所述文件分割成规定大小的文件数据；所述发送部件用于将经所述发送控制部件分割的文件数据发送给所述接收设备。
6.根据权利要求1所述的文件传输系统，其特征在于，所述接收控制部件进而用于将请求中断文件传输的中断请求发送给所述发送设备；所述中断请求包括开始时间信息，其表示所述接收设备重新开始所述文件传输的开始时间；以及期间信息，其表示所述接收设备接受所述文件传输的终止时间；并且所述检测部件通过接收所述中断请求来检测所述文件传输的中断；所述发送控制部件用于让所述发送部件从所述开始时间起至所述许可期间之内发送所述剩余文件数据。
7.根据权利要求1所述的文件传输系统，其特征在于，所述发送控制部件进而用于在所述发送部件发送文件数据之前，将所述文件数据在所述接收设备中的保留期间通知给所述接收设备；所述接收控制部件进而用于，当所述文件数据保存在所述保存部件中，且，在超过所述文件数据的保留期间之前尚未从所述发送设备接收到构成所述文件的所有文件数据时，删除保存在所述保存部件中的所述文件数据。
8.根据权利要求1所述的文件传输系统，其特征在于，所述发送设备与所述接收设备之间利用传输控制协议连接来进行文件传输；所述检测部件通过检测所述发送控制部件在文件数据的发送期间切断所述TCP连接，来检测所述文件传输的中断；所述发送控制部件进而用于在所述TCP连接切断之后，将文件数据在所述接收设备中的保留期间通知给所述接收设备；所述接收控制部件进而用于，当在超过所述发送设备所通知的所述保留期间之前，尚未从所述发送设备接收到构成所述文件的所有文件数据时，删除保存在所述保存部件中的文件数据。
9.根据权利要求1所述的文件传输系统，其特征在于，所述发送设备与所述接收设备之间利用传输控制协议连接来进行文件传输；所述发送控制部件进而用于在所述接收设备切断所述TCP连接时，将用以获得文件传输许可的传输请求发送给所述接收设备；所述接收控制部件进而用于将请求中断所述文件传输的中断请求作为对所述传输请求的响应发送给所述发送设备；所述检测部件通过接收所述中断请求来检测所述文件传输的中断。
10.一种发送设备，用于进行通过网络向接收设备传输文件的文件传输，其特征在于，该发送设备包括发送部件，用于将构成所述文件的文件数据发送给所述接收设备；检测部件，用于检测所述文件传输的中断；询问部件，用于在由所述检测部件检测出所述文件传输的中断之后，询问保存在所述接收设备中的文件数据的大小，即已保存数据大小；发送控制部件，用于根据所述接收设备对应于所述询问部件的询问而响应的已保存数据大小，让所述发送部件发送构成所述文件的剩余文件数据。
11.一种接收设备，用于通过网络来接收从发送设备发送的文件，其特征在于，该接收设备包括保存部件，用于保存从所述发送设备所接收的构成所述文件的文件数据；已保存大小获取部件，用于获取已保存到所述保存部件中的文件数据的大小，即已保存大小；以及接收控制部件，用于当所述发送设备询问所述已保存大小时，将由所述已保存大小获取部件所获取的所述已保存大小发送给所述发送设备。
12.一种发送方法，用于进行通过网络向接收设备传输文件的文件传输，其特征在于，该发送方法包括发送步骤，将构成所述文件的文件数据发送给所述接收设备；检测步骤，检测所述文件传输的中断；询问步骤，在所述检测部件检测出所述文件传输的中断之后，询问保存在所述接收设备中的文件数据的大小，即已保存数据大小；以及发送控制步骤，根据所述接收设备对应于所述询问部件的询问而响应的已保存数据大小，将构成所述文件的剩余文件数据发送给所述接收设备。
13.一种接收方法，用于通过网络来接收从发送设备发送的文件，其特征在于，该接收方法包括保存步骤，将从所述发送设备所接收的构成所述文件的文件数据保存到保存部件中；已保存大小获取步骤，获取已保存到所述保存部件中的文件数据的大小，即已保存大小；以及接收控制步骤，当所述发送设备询问所述已保存大小时，将由所述已保存大小获取部件所获取的所述已保存大小发送给所述发送设备。
14.一种程序，用于进行通过网络向接收设备传输文件的文件传输，其特征在于，该程序使计算机执行以下步骤发送步骤，将构成所述文件的文件数据发送给所述接收设备；检测步骤，检测所述文件传输的中断；询问步骤，在所述检测部件检测出所述文件传输的中断之后，询问保存在所述接收设备中的文件数据的大小，即已保存数据大小；以及发送控制步骤，根据所述接收设备对应于所述询问部件的询问而响应的已保存数据大小，将构成所述文件的剩余文件数据发送给所述接收设备。
15.一种程序，用于通过网络接收从发送设备发送的文件，其特征在于，该程序使计算机执行以下步骤保存步骤，将从所述发送设备所接收的构成所述文件的文件数据保存到保存部件中；已保存大小获取步骤，获取已保存到所述保存部件中的文件数据的大小，即已保存大小；以及接收控制步骤，当所述发送设备询问所述已保存大小时，将由所述已保存大小获取部件所获取的所述已保存大小发送给所述发送设备。
全文摘要
本发明提供如下所述的发送设备、接收设备以及文件传输系统，即，在从发送设备自发地向接收设备传输文件的文件传输系统中，即使文件传输长时间中断，也能高效地执行文件传输的相关处理。在本发明的文件传输系统中，作为接收端设备的接收设备(sink device)，保存从作为发送端设备的源设备接收的构成文件的文件数据，当源设备询问已保存大小时，向源设备发送已保存大小。并且，源设备检测文件传输的中断，在检测出文件传输中断之后，向接收设备询问已保存数据大小。进而，根据接收设备对应于该询问而响应的已保存数据大小，发送构成文件的剩余文件数据。
文档编号G06F13/00GK101048989SQ20058003686
公开日2007年10月3日 申请日期2005年10月19日 优先权日2004年10月26日
发明者越野俊治, 武知秀明, 田边匠, 铃木洋佑, 加藤尚德 申请人:松下电器产业株式会社