KR20070083649A - Transmitting device, receiving device, and file forwarding system - Google Patents

Abstract

A transmitting device, a receiving device, and a file forwarding system for effectively executing processes related to a file forwarding even if the file forwarding is interrupted for a longtime in the file forwarding system in which the transmitting device voluntarily forwards a file to the receiving device. In a file forwarding system, a sink device, which is a receiving device, stores file data, which constitutes a file, received from a source device, which is a transmitting device, and, when receiving an inquiry about the size of the stored data from the source device, notifies the source device of the size of the stored data. Having detected an interruption of the file forwarding, the source device inquires the sink device of the size of the stored data. Further, the source device transmits file data, which constitutes the remaining part of the file, in accordance with the size of the stored data notified of by the sink device in response to that inquiry.

Description

Sending, receiving and file transfer systems {TRANSMITTING DEVICE, RECEIVING DEVICE, AND FILE FORWARDING SYSTEM}

The present invention relates to a transmitting device, a receiving device, and a file transfer system for performing file transfer over a network.

In recent years, broadband environments such as xDSL and optical fiber have been established, and internet access has been rapidly spreading regardless of businesses and general households. In addition, a home network environment in which a personal computer (PC) or home appliance in a home is connected by Ethernet (registered trademark), a wireless LAN, or the like is also generalized. Under these circumstances, not only PCs, but also home appliances such as televisions, DVD recorders, air conditioners and refrigerators can be connected to each other by the Internet Protocol (IP) defined by the Internet Engineering Task Force (IETF).

One application program in the Internet or a home network is an application program for transferring files between home appliances and PCs. An example of an application program for transferring a file is an application program that provides a dubbing function such as transferring a recorded MPEG2 file between a DVD recorder or a PC to edit a TV program recorded on a DVD recorder.

While such file transfer protocols generally require file transfers without error, real-time transfers are not necessarily required. Representative protocols for file transfer in IP include Hyper Text Transfer Protocol (HTTP) defined in RFC2616, File Transfer Protocol (FTP) defined in RFC959, and the like. All of these protocols secure transmission reliability by retransmission function of Transmission Control Protocol (TCP) defined in RFC793.

In other words, TCP includes a sequence of detecting and retransmitting an error of a packet and a sequence of detecting and retransmitting a missing packet, thereby ensuring correct file transfer even if an error or packet deficiency occurs on a transmission path. On the other hand, TCP retransmission procedures have limitations, for example, in the case of a disturbance in a transmission path, a device of a sender (hereinafter referred to as a "source device"), or a device of a destination (hereinafter referred to as a "sink device"). If the interruption of the transmission takes a long time, the problem is that the TCP connection is disconnected by the timeout and the subsequent file transfer cannot be performed. In this case, the device includes a case where the file transfer must be stopped in order to perform other functions of the device, in addition to the failure. For example, the DVD recorder interrupts file transfer in order to perform timer recording.

HTTP includes a procedure for solving the above-described problems, and a sequence is defined in which a file connection can be resumed immediately after the position transmitted before the interruption by performing a TCP connection again even if the interruption of the transmission takes a long time. have. This sequence will be described with reference to FIG. 1.

1 is a diagram showing an example of a communication sequence in accordance with the resumption of file transfer in a file transfer system constituted by a conventional source device and a sink device.

The communication sequence shown in FIG. 1 is a communication sequence in a file transfer system for performing file transfer from the source device 1001 to the sink device 1002. It is also assumed that the TCP connection is disconnected during the file transfer.

First, the sink device 1002 issues an HTTP GET request to the source device 1001 (S101). The source device 1001 responds to this request with "200 OK" (S102), and transmits a file of 1000 bytes (S103). After that, a communication failure occurs and the TCP connection is disconnected (S104).

Here, it is assumed that 500 bytes of data can be stored in the sink device 1002 until the TCP connection is disconnected (S105). The sink device 1002 may wait for the communication failure to recover and may reconnect TCP at any time to resume transmission. Resumption of transmission is performed by the sink device 1002 sending an HTTP GET request to the source device 1001 with the Range header added (S106), and requesting data 500 bytes or more from the beginning of the file to be transferred. All.

The source device 1001 transmits data according to the designated range (here, 500-999 bytes) from the sink device 1002 (S107, S108), and the sink device 1002 stores the received data (S109). . In this way, it is possible to acquire only untransmitted data by resuming transmission without retransmitting the completed data. Such a procedure is used in an application program for efficiently acquiring a file by acquiring from the continuation of the acquired data when the downloading of a large file of several megabytes or more disposed on a server on the Internet fails.

The technique of providing data using the GET method of HTTP is also disclosed (for example, refer patent document 1).

Patent Document 1: Japanese Unexamined Patent Publication No. 2002-288162

However, although the above-described conventional interruption and resumption of file transfer in HTTP can be used in the HTTP GET method, there is a problem that it cannot be used in the POST method. This restriction is not a problem because the GET method of HTTP is used when downloading a file from a server on the Internet to a PC.

However, in the case of transferring a file between any devices connected to the network, the HTTP POST method is usually used when the source device wants to voluntarily send any file without the request of the sink device. Therefore, when the communication between the source device and the sink device is interrupted, there is a problem that the file must be transmitted from the beginning after the communication is resumed, and the resources and time for the file transfer are unnecessarily consumed.

More generally, the problem is that in a file transfer protocol in which a push type flow control is triggered by spontaneous transmission of data from a source side, unlike a flow type flow control that issues a request from a sink side, The problem is that there is no order for efficient file transfer in the case of an interruption.

In addition, even in the order of interruption and resumption of file transfer in the above-described HTTP GET method, a period in which resumption is possible is not specified. In the case of transferring a file between any devices connected to the network, it is not clear how long the source device and the sink device will remain in a possible state. Therefore, a waste of resources occurs in the source device and the sink device.

SUMMARY OF THE INVENTION In view of the above problems, the present invention provides a file transfer system for transmitting a file from a transmitting device to a receiving device voluntarily, even when the file transfer is interrupted for a long time, a transmission for efficiently executing the processing according to the file transfer. An object is to provide a device, a receiving device, and a file transfer system.

In order to achieve the above object, the file transfer system of the present invention is a file transfer system that performs file transfer from a transmitting device transmitting a file through a network to a receiving device receiving the file, wherein the receiving device is the transmitting device. Storage means for storing file data constituting the file, received from a storage completion size acquiring means for acquiring a storage completion size which is a size of file data that has been stored in the storage means, and the storage completion from the transmitting device; A receiving control means for transmitting the stored completed size acquired by the stored completed size obtaining means to the transmitting device when the size is inquired, wherein the transmitting device includes transmitting means for transmitting file data to the receiving device; Detection means for detecting interruption of the file transfer, and the search; On the basis of the inquiry means for inquiring the storage device of the stored data size after the interruption of the file transfer is detected by the export means, and the size of the storage data that the receiving device responds to in response to the inquiry by the inquiry means. And transmission control means for transmitting the remaining file data constituting the file to the transmission means.

Further, the transmitting device of the present invention is a transmitting device which transmits a file to a receiving device via a network, comprising: transmitting means for transmitting file data constituting the file to the receiving device, and stopping the file transfer. Detection means for detecting, inquiry means for inquiring a completed data size which is the size of file data stored in the receiving device after the interruption of the file transfer is detected by the detection means, and an inquiry by the inquiry means. And transmitting control means for transmitting the remaining file data constituting the file to the transmitting means based on the stored completed data size responded by the receiving device.

Moreover, the receiving device of the present invention is a receiving device that receives a file transmitted from a transmitting device via a network, and includes: storage means for storing file data constituting the file received from the transmitting device; Storage completion size acquiring means for acquiring a storage completion size which is a size of file data for which storage has been completed; and the storage completion size acquired by the storage completion size acquiring means when the storage completion size is inquired from the transmitting device. And reception control means for transmitting to the receiver.

Thus, according to the present invention, the transmission device can inquire the reception device of the storage completion size after the file transfer is stopped. The receiving device can also send the stored completion size to the transmitting device in response to the inquiry. By knowing the storage completion size, the transmitting device can transmit only the remaining file data to be transmitted to the receiving device.

That is, in resuming the interrupted file transfer, the transmitting device does not need to transmit the file data from the beginning, but only the remaining file data necessary for the receiving device may be transmitted. In addition, the receiving device does not receive duplicate useless file data. Therefore, in the processing according to the file transfer in the transmitting device and the receiving device, even when a long time interruption occurs, the processing according to the file transfer can be efficiently executed without wasteful processing or unnecessary consumption of resources. have.

Further, in the file transfer system of the present invention, the reception control means also sends a suspension request to the transmitting device requesting the suspension of the file transfer, and the interruption request is when the receiving device resumes the file transfer. Time information indicating (iii) and period information indicating a boil that the receiving device accepts the file transfer, and the detecting means detects the interruption of the file transfer by receiving the interruption request, and controls the transmission. The means may transmit the remaining file data to the transmitting means between the time period and the permission period, and in the file transfer system of the present invention, the transmission control means may further transmit the file data. The retention period of the file data at the receiving device before is sent to the receiving device. And notifying, the reception control means also does not receive all the file data constituting the file from the transmitting device before the file data is stored in the storage means and the retention period of the file data has elapsed. The file data stored in the storage means may be deleted.

In this manner, the transmitting device and the receiving device can exchange information on the period of time for performing file transfer with each other. As a result, when the file transfer is interrupted by the external device, each of the transmitting device and the receiving device does not need to be prepared for resumption of file transfer forever, and does not waste resources of each device. In other words, the processing according to the file transfer can be executed efficiently.

Further, the present invention can be realized as a method comprising steps of characteristic components of each of the file transfer system, the transmitting device, and the receiving device of the present invention, implemented as a program including such steps, a CD-ROM, or the like stored therein. Can be realized as a recording medium or as an integrated circuit. The program may be distributed through a transmission medium such as a communication network.

The present invention provides a file transfer system that voluntarily transfers a file from a transmitting device to a receiving device, wherein the transmission device, the receiving device, and the device for efficiently executing the processing according to the file transfer even if the file transfer is interrupted for a long time; A file transfer system can be provided.

For example, in a file transfer system constituted by a source device that transmits a file using an HTTP POST method and a sink device that receives a file from the source device, interruption of file transfer occurs and a TCP connection is timed. Even after out, the transmitting device can know the data size of the storing. Therefore, the transmitting device can transmit data following the data that has been stored in the receiving device to the receiving device.

In other words, when a file is transmitted, no unnecessary data transmission is performed by the transmitting device, and no unnecessary data is received by the receiving device.

As a result, even in the file transfer protocol for performing push-type flow control by triggering the transmission of data from the source side, the processing according to the file transfer can be efficiently executed without generating waste of resources or time.

It is also possible to provide a method and means for shaking a possible period of resumption in the sequence of suspend and resume, and to clarify how long the source device and the sink device should remain in a resumable state. This can eliminate waste of resources such as memory and media of the source device and the sink device in file transfer. This also makes it possible to efficiently execute the process associated with file transfer.

1 is a view showing an example of a communication sequence according to the resumption of file transfer in a file transfer system constituted by a conventional source device and a sink device;

2 is a diagram showing a device configuration of a file transfer system according to an embodiment of the present invention;

3 is a functional block diagram showing a functional configuration of a source device according to an embodiment of the present invention;

4 is a functional block diagram showing a functional configuration of a sink device according to an embodiment of the present invention;

5 is a diagram showing a basic communication sequence in the file transfer system according to the embodiment of the present invention;

6 is a diagram showing the contents of each parameter sent from the source device to the sink device;

7 is a diagram showing an example of a communication sequence when file transfer is interrupted due to a source device in the file transfer system according to the embodiment;

8 is a diagram showing an example of a communication sequence when file transfer is interrupted due to the situation of a sink device in the file transfer system according to the embodiment;

9 is a diagram showing another example of a communication sequence when file transfer is interrupted due to the situation of a sink device in the file transfer system according to the embodiment;

10 is a diagram showing a communication sequence when resuming file transfer in the file transfer system according to the embodiment;

11 is a diagram showing an example of a communication sequence when file transfer is stopped due to a source device before transmission of file data is started in the file transfer system according to the embodiment;

12 is a diagram showing an example of a communication sequence when file transfer is stopped due to a source device during transmission of file data in the file transfer system according to the embodiment;

13 is a diagram showing an example of a communication sequence when file transfer is stopped due to a sink device before the file data transmission starts in the file transfer system according to the embodiment;

14 is a diagram showing an example of a communication sequence when file transfer is stopped due to the situation of a sink device in the file transfer system of the embodiment;

15 is a diagram illustrating a communication sequence of a file transfer system in which a source device divides and transmits a file to a sink device;

FIG. 16 is a diagram illustrating a communication sequence in a case where a file transfer is interrupted due to a source device before transmission of one file data after division in a file transfer system for dividing and transmitting a file; FIG.

FIG. 17 is a diagram illustrating a communication sequence in a case where a transmission is interrupted due to the situation of a sink device when a sink device receives a POST request in a file transfer system that divides and transmits a file; FIG.

Fig. 18 is a diagram showing a communication sequence when file transfer is stopped due to the situation of a sink device in a file transfer system for dividing and transferring a file.

<Description of the symbols for the main parts of the drawings>

101: source device 102: sink device

701: user interface 702: file transmission control unit

703 and 802: File control unit 704 and 803: Communication control unit

705, 804: file accumulator 706, 805: network interface

707: interruption detection unit 708: inquiry unit

801: File reception control unit 806: Save completion size acquisition unit

EMBODIMENT OF THE INVENTION Hereinafter, the best form for implementing this invention is demonstrated using drawing.

First, the structure of the file transfer system of embodiment of this invention is demonstrated using FIGS.

2 is a diagram illustrating a device configuration of a file transfer system according to an embodiment of the present invention. The file transfer system according to the embodiment of the present invention is a system for transferring files from the source device 101 to the sink device 102.

As shown in FIG. 2, the source device 101 and the sink device 102 are connected to the broadband router 301 to form a home network. The broadband router 301 may be connected to the internet 302.

The source device 101 and the sink device 102 each have built-in storage media, and can store files such as Audio Visual (AV) content. Specifically, the source device 101 includes a file accumulator 705 and the sink device 102 includes a file accumulator 804.

An example of such a device is a DVD / HDD hybrid recorder having a network connection terminal. In the timing state of this embodiment, the source device 101 accumulates the file 303 in the file accumulator 705 and transmits the file to the sink device 102 via the home network. The sink device 102 accumulates the file 303 received from the source device in the file accumulator 804.

In the present embodiment, both the sink device 102 and the source device 101 comply with the UPnP-AV standard issued by the Universal Plug and Play Forum, and the sink device 102 functions as a Contents Directory Service (CDS) server. It is assumed that the source device 101 implements a Control Point function for accessing the CDS server.

3 is a functional block diagram showing the functional configuration of the source apparatus 101 of the embodiment of the present invention. The source device 101 is an example of the transmission device of the present invention. In addition, illustration and description of the control point function etc. which are originally provided with respect to the source apparatus 101 are abbreviate | omitted, and only the characteristic structure part of the source apparatus 101 is illustrated and demonstrated.

As shown in FIG. 3, the source device 101 includes a user interface 701, a file transmission control unit 702, a file control unit 703, a communication control unit 704, a file storage unit 705, and a network interface 706. It is provided. The component part in the area | region enclosed by the dotted line in a figure is a component part which performs the main process according to a file transfer.

The user interface 701 is an interface that receives an input such as an instruction from a user and provides information to the user as an image. The network interface 706 is an interface for exchanging information with the sink device 102 via the home network.

The file accumulator 705 is a memory device that accumulates files such as AV contents as described above.

The file transmission control unit 702 is a control unit that controls transmission of a file to the sink device 102, and has a query unit 708. The inquiry unit 708 is a processing unit that inquires the sink device 102 of the stored data size when resuming the interrupted file transfer.

In addition, in the file transfer from the source device 101 to the sink device 102, the stored data size described above means that the file data constituting the file received and stored by the sink device 102 (hereinafter, simply “ Data ”). That is, when the file size is 1000 bytes, the stored data size becomes a value between 0 bytes and 1000 bytes.

The term "interruption of file transfer" includes not only the case where the transmission or reception of the file data is stopped after the transmission of the file data is started, but also the case where the processing required for the file transfer is interrupted.

The file control unit 703 is a control unit that controls reading of a file from the file accumulation unit 705.

The communication control unit 704 is a control unit for controlling communication via the home network by controlling the network interface 706. By the communication control unit 704 and the network interface 706, a function for transmitting information that the transmission means in the transmission device of the present invention has is realized. The communication control unit 704 also has an interruption detection unit 707. The interruption detector 707 is a processor that detects the interruption of the file transfer.

The source device 101 controls the user interface 701 to display a list of files stored in 705. The file selected by the user from the list is read from the file accumulator 705, and the network interface 706 is controlled and sent to the sink device 102.

4 is a functional block diagram showing a functional configuration of the sink device 102 according to the embodiment of the present invention. The sink device 102 is an example of the receiving device of the present invention. In addition, illustration and description of the CDS server function and the like originally provided for the sink device 102 will be omitted, and only the characteristic components of the sink device 102 will be shown and described.

As shown in FIG. 4, the sink device 102 includes a file reception control unit 801, a file control unit 802, a communication control unit 803, a file storage unit 804, and a network interface 805. The component part in the area enclosed by the dotted line in a figure is a component part which performs the main process according to a file transfer.

The network interface 805 is an interface for exchanging information with the source device 101 via a home network.

The file accumulating unit 804 is an example of storage means in the receiving device of the present invention, and is a storage device that accumulates a file received from the source device 101 as described above.

The file reception control unit 801 is a control unit for controlling reception of a file transmitted from the source device 101.

The file control unit 802 is a control unit that controls reading of a file from the file accumulating unit 804 and has a storage completed size obtaining unit 806. The storage completed size acquisition unit 806 is a processing unit that acquires the storage completion data size from the file storage unit 804. The acquired stored data size is transmitted to the source device 101 under the control of the file reception control unit 801.

The communication control unit 803 is a control unit that controls communication via the home network by controlling the network interface 805.

Next, operations of the source device 101 and the sink device 102 in the file transfer system constituted by the source device 101 and the sink device 102 configured as described above will be described with reference to FIGS. do.

First, the operation of each device in the basic communication sequence will be described with reference to FIGS. 5 and 6.

It is a figure which shows the basic communication sequence in the file transfer system of embodiment of this invention. As shown in FIG. 5, in the present embodiment, file transfer is started by communication from the source device 101 to the sink device 102. That is, FIG. 5 is a communication sequence diagram in spontaneous file transfer from the source device 101.

In addition, communication between the source device 101 and the sink device 102 is relayed by the broadband router 301. However, since the operation of the broadband router 301 is not concerned with the features of the present invention, the description of the illustration and operation will be omitted below.

The source device 101 sends a CDS: CreateObject request defined in the UPnP-AV standard (S501). Here, the CreateObject request is a request for creating an object representing a logical file, whereby an object is newly created in the file storage unit 804 of the sink device 102. At that time, metadata such as a position on the directory structure of the object to be generated and a file name indicating the object is determined. This metadata includes Uniform Resource Identifiers (URIs) on the sink device 102 where file entities should be stored. The sink device 102 transmits a CDS: CreateObject response including this URI as the destination address of the file to the source device (S502).

The source device 101 sends an HTTP request (hereinafter referred to as a "POST request") of the POST method to the sink device 102 (S503). At this time, the source device 101 adds the parameter shown in FIG. 6 to the POST request as a parameter to be referred to by the sink device 102 when the file transfer is stopped. Specifically, three of [byte-range], [restart-time] and [lifetime] are sent as parameters.

6 is a diagram showing the contents of each parameter sent from the source device 101 to the sink device 102.

As shown in Fig. 6, [byte-range] is a byte range of data to be transmitted. The byte range is information indicating the start and end positions of the data range, which is the range of the file data to be transmitted, and information indicating the file size, which is the total size of the file. In addition, each unit is a byte.

That is, the sink device 102 is not only informed of the range of data transmitted from the source device but also the total size of the file. Therefore, it is possible to determine whether the received file data is a part of file data constituting a certain file or all file data constituting a certain file. In the present embodiment, when one file is transmitted to the sink device 102, the files are transmitted collectively without being divided. The case where the file is divided and transmitted will be described later with reference to FIG. 15.

[restart-time] is a transmission resume permission time. The transmission resumption allowance time is information indicating the pause time until the file transfer operation is resumed after the interruption, and the unit is seconds.

[lifetime] is the file retention period. The file holding period is information indicating the time when the sink device 102 should hold the object or file data, and the unit is seconds. The sink device 102 is not obliged to hold the created object if it does not receive the file data until the period shown in [lifetime] elapses. In addition, when [lifetime] is notified and the file data that is not completed is received, the file data that is not completed until the time period shown in [lifetime] is not received, and the remaining file data is not received. There is no.

As a result, even when the source device 101 becomes inaccessible or loses the file to be transferred, the sink device 102 does not need to maintain unnecessary resources for file transfer that cannot be completed. Therefore, the resource can be managed efficiently in the sink device 102, and maintenance such as deletion of unnecessary objects by the user's hand is also unnecessary.

In the communication sequence of FIG. 5, the source device 101 designates the head position: 0 byte, the end position: 999 byte, and the file size: 1000 bytes of the data to be transmitted. This means that one file is collectively transmitted as described above. In addition, a pause time: 1200 seconds (20 minutes) and a file holding period: 1800 seconds (30 minutes) are also specified.

In addition, [suspend-req] indicating a request to suspend transmission is not used in the communication sequence of FIG. The case of sending [suspend-req] to the sink device 102 will be described later with reference to FIG.

In addition, the URI included in the CreateObject response received from the sink device 102 is described as the URI specified in the POST request transmitted from the source device 101 to the sink device 102. As a result, the sink device 102 can associate the specific object with the received file data.

POST requests also have Expect: 100-continue. As a result, the sink device checks whether or not the transmitted POST request can be accepted by the URI according to RFC2616.

If the result of the check is acceptable, the response returns "100 Continue" (S504). If the POST request from the source device 101 cannot be accepted or the POST request cannot be interpreted, the data is returned. The source device 101 can be notified before the transmission of the source device 101. Thus, the source device 101 can avoid unnecessary data transmission.

The source device 101 transmits a file to the sink device 102 by receiving the “100 Continue” status from the sink device 102 (S505). The file data is also stored and transmitted in the entity body of the POST request. .

The sink device 102 accumulates the received file data in the file accumulator 804. When the sink device 102 requires time for file accumulation processing to the file accumulation unit 804 after completion of the reception of the file, for example, when accumulation is not completed within 20 seconds, the “102 Processing” defined in RFC2518 is applied. &Quot; S506, and notifies the source device 101 that the accumulation process is in progress. The sink device 102 transmits " 201 Created &quot; upon completion of the accumulation, and the source device 101 indicates that the accumulation is completed. Notify (S507).

The file transfer from the source device 101 to the sink device 102 is completed by the operation of each device described above.

In addition, although the communication sequence shown in FIG. 5 is a basic communication sequence in which interruption does not occur in the middle of a file transfer, file transfer may be interrupted by the circumstances of the source apparatus 101 or the sink apparatus 102. FIG. Therefore, below, the communication sequence and operation | movement of each apparatus in the case of interruption | interruption in the middle of a file transfer are demonstrated using FIGS. In addition, a communication sequence and operation of each device when resuming file transfer will be described with reference to FIG.

FIG. 7 is a diagram illustrating an example of a communication sequence when file transfer is interrupted due to the circumstances of the source apparatus 101 in the file transfer system according to the embodiment. The operation of each device when file transfer is interrupted due to the circumstances of the source device 101 during transmission of file data from the source device 101 to the sink device 102 will be described with reference to FIG. 7.

The source device 101 and the sink device 102 perform CDS: CreateObject request and response communication similarly to the communication sequence of FIG. 5. Thereafter, the source device 101 sends a POST request to the sink device 102 (S503). The sink device 102 transmits a “100 Continue” status to the source device 101 as a response to the POST request (S504). The source device 101 starts transmitting the file data to the sink device 102 (S505). The sink device 102 stores the received file data in the file storage unit 804. The operation up to this point is the same as the communication sequence shown in FIG.

Here, the source device 101 causes a factor to interrupt the file transfer, and sends an RST packet to disconnect the TCP connection. As a result, the TCP connection used for file transfer is disconnected (S706).

The factor for interrupting file transfer is, for example, that a file being transferred is deleted from the file accumulator 705 by a user's operation.

The source device 101 also transmits a POST request packet including [suspend-req] and [lifetime] to the sink device 102 (S707). [suspend-req] is information indicating a request to suspend file transfer, as shown in FIG. That is, the sink device 102 may know that the file transfer is stopped by receiving [suspend-req]. In addition, [lifetime] is information indicating the time at which the sink device 102 should hold the file data as described above, and in this case, it means that the source device 101 resumes file transfer within that time. After the file retention period has elapsed, the sink device 102 may delete the file data received and stored.

Further, in the processing according to the interruption of the file transfer described above, the RST packet and the POST request packet are generated by the file transmission control unit 702 and transmitted to the sink device 102. Hereinafter, in the case of simply &quot; POST request &quot;, the entity refers to a POST request packet.

In addition, the interruption detecting unit 707 detects that the TCP connection is disconnected and detects that the file transfer is interrupted.

When receiving the POST request, the sink device 102 responds with “200 OK” (S708). After the source device 101 eliminates the factor of interrupting the file transmission, the file device 101 resumes file transmission described later with reference to FIG. Execute the action.

In this way, in the file transfer system of the present embodiment, the file transfer is interrupted due to the circumstances of the source apparatus 101 after the start of file data transmission and before the file transfer is completed.

Next, when the sink device 102 receives the POST request, the operation of each device when the file transfer is interrupted due to the situation of the sink device 102 will be described with reference to FIG. 8.

8 is a diagram illustrating an example of a communication sequence when file transfer is interrupted due to the situation of the sink device 102 in the file transfer system according to the embodiment.

The source device 101 and the sink device 102 perform CDS: CreateObject request and response communication similarly to the communication sequence of FIG. Thereafter, the source device 101 sends a POST request to the sink device 102 (S503). The operation so far is the same as the communication sequence shown in FIG. 5.

Here, the sink device 102 is in a state in which the file receiving process cannot be performed, and transmits a “503 Service Unavailable” status as a response to the POST request. A state in which the file receiving process cannot be performed is, for example, a file. The storage unit 804 has no empty capacity or the like.

The sink device 102 responds with the status packet including "retry-after" indicating when to resume file transfer (S804). After the source device 101 has passed the time shown in "retry-after", The file transfer resume operation described later is executed using FIG.

In this way, in the file transfer system of the present embodiment, after the size of the file transmitted by the POST request and the like are notified from the source device 101 to the sink device 102, and before the transmission of the file data is started. File transfer is interrupted due to the situation of the sink device 102.

Next, the operation of each device when the file transfer is interrupted due to a factor on the sink device 102 side while transmitting the file data from the source device 101 to the sink device 102 will be described with reference to FIG. 9. .

9 is a diagram illustrating another example of a communication sequence when file transfer is interrupted due to the situation of the sink device 102 in the file transfer system according to the embodiment.

The source device 101 and the sink device 102 perform CDS: CreateObject request and response communication similarly to the communication sequence of FIG. 5. After that, the source device 101 sends an HTTP request of the POST method to the sink device 102 (S503). The sink device 102 transmits a “100 Continue” status to the source device 101 as a response to the HTTP request (S504). The source device 101 starts transmitting the file data to the sink device 102 (S505). The sink device 102 stores the received file data in the file storage unit 804. The operation up to this point is the same as the communication sequence shown in FIG.

Here, the sink device 102 causes a factor of stopping file transfer, and sends an RST packet. As a result, the TCP connection used for file transfer is disconnected (S906). The factor that interrupts file transfer is that, for example, it is necessary to read another file from the file accumulator 804 and thus cannot accumulate the received file data.

When the TCP connection is disconnected by the sink device, the file transmission control unit 702 of the source device 101 transmits a POST request to the sink device 102 again (S907).

The sink device 102 transmits the "503 Service Unavailable" status to the source device 101 as a response to the POST request (S908). The above-mentioned [retry-after] is included in the status packet.

The "503 Service Unavailable" accompanying this [retry-after] is a request for stopping file transfer from the sink device 102.

The interruption detection unit 707 of the source device 101 detects the interruption of the file transfer by detecting the interruption request. After elapse of the time shown in " retry-after &quot;, the source device 101 executes the file transfer resume operation described later with reference to FIG.

In this way, in the file transfer system of the present embodiment, the file transfer is stopped by the factor on the sink device 102 side after the start of the transmission of the file data and before the transmission is completed.

Next, the operation of each device at the time of resuming the file transfer after the file transfer described with reference to FIGS. 7 to 9 will be described with reference to FIG. 10.

10 is a diagram showing a communication sequence when resuming file transfer in the file transfer system according to the embodiment.

The stop detection unit 707 of the source device 101 detects that the file transfer is stopped (S1000). Further, the interruption detection unit 707 determines whether the file transmission is based on the type and contents of the packet to be transmitted and received, regardless of whether the interruption of the file transmission is due to the situation of the source device 101 or the situation of the sink device 102. The interruption can be detected.

When the source device 101 stops the file transfer due to its own circumstances, the source device 101 stops the transfer of the file, and when the file transfer is stopped due to the situation of the sink device 102, the source device 101 stops the file transfer. The following operation is performed after the time shown in [retry-after] transmitted from 102 has elapsed.

The source device 101 sends a CDS: Browse request to the sink device 102 (S1001), and asks the sink device 102 of the file storage size.

Specifically, the CDS: Browse request generated by the file transmission control unit 702 of the source device 101 includes a notification request of the stored data size by the inquiry unit 708. The CDS: Browse request is sent to the sink device 102 via the network interface 706.

When the sink device 102 receives the CDS: Browse request, the sink device 102 transmits a CDS: Browse response including the stored data size to the source device 101 (S1002).

Specifically, the stored-complete size acquisition unit 806 acquires the data size of the file data constituting the file stored in the file storage unit 804. In addition, the file reception control unit 801 generates a CDS: Browse response including the data size acquired by the storage completion size acquisition unit 806. The generated CDS: Browse response is transmitted to the source device 101 via the network interface 805.

The file transmission control unit 702 of the source device 101 determines the head position of the file to be transmitted in accordance with the received stored data size, and reads out the file data from the file accumulator 705.

For example, suppose that the file size is 1000 bytes and the storage completed data size notified from the sink device 102 is 400 bytes. In this case, the file data stored in the sink device 102 is the file data from the 0th byte to the 399th byte. Therefore, the file transmission control unit 702 reads out the remaining file data of the 400th to 999th byte from the file storage unit 705 via the file control unit 703. Hereinafter, in the case of the "rest of file data", the remaining file data except for the file data that has been stored in the sink device 102 from the file data to be transferred is indicated as described above.

The source device 101 transmits a POST request to the sink device 102 including [byte-range] indicating a data range and a file size (S1003). The sink device 102 transmits the "100 Continue" status to the source device 101 in response to the POST request (S1004).

The file transmission control unit 702 of the source device 101 transmits the remaining file data read out from the file accumulation unit 705 to the communication control unit 704 (S1005). Based on the data range shown in [byte-range], the file controller 802 of the sink device 102 combines the received file data with the file data that has been stored before stopping and reconstructs the original file.

In this manner, the source device 101 according to the embodiment of the present invention can query the sink device 102 for the stored data size when resuming the interrupted file transfer. In addition, the sink device 102 according to the embodiment of the present invention can notify the source device 101 of the stored data size according to the inquiry.

Thereby, the source apparatus 101 does not need to perform file transfer again from the beginning, but only transmits the remaining file data. In addition, the sink device 102 does not receive duplicate file data.

That is, by the source device 101, the sink device 102, and the file transfer system of the embodiment of the present invention, in spontaneous file transfer from the source device 101, it is longer than the timeout time of the prescribed TCP connection. Even if an interruption occurs, the processing associated with file transfer can be efficiently executed.

Moreover, since the time which can resume transmission can be notified between devices, unnecessary transfer resumption trial operation can be suppressed and the communication load of a device can be reduced.

When the communication path of the network is cut off during the file transfer, when the interruption detection unit 707 of the source device 101 detects the disconnection of the communication path, the file transfer resume operation shown in the communication sequence of FIG. 10 is started.

In addition, although the communication sequence and operation of each device when the file transfer is interrupted using Figs. 7 to 9 have been described, the file transfer is not interrupted but stopped due to the circumstances of the source device 101 or the sink device 102. You may need to do this. Each of the source device 101 and the sink device 102 of the embodiment of the present invention can notify each other of the devices when the file transfer is stopped. Hereinafter, the communication sequence according to the suspension of file transfer and the operation of each device will be described with reference to FIGS. 11 to 14.

11 is a diagram showing an example of a communication sequence when file transfer is stopped due to the source device 101 before the file data transmission starts in the file transfer system according to the embodiment. An operation of each device when the execution of the file transfer is stopped due to the circumstances of the source device 101 before the file transfer is started using FIG. 11 will be described.

The source device 101 and the sink device 102 perform CDS: CreateObject request and response communication similarly to the communication sequence of FIG. 5 (S501 and S502). Subsequently, before the source device 101 transmits the POST request, the source device 101 indicates that a cancellation instruction for file transfer is issued by the user, or a file such as a transfer target is deleted. Imagine.

In this case, the source device 101 transmits the CDS: DestroyObject request to the sink device 102 in place of the POST request in order to stop the file transfer (S1103). Upon receiving the CDS: DestroyObject, the sink device 102 deletes the object created according to the CDS: CreateObject request (S501). In addition, in order to notify that the object has been deleted, the source device 101 responds with a CDS: DestroyObject response (S1104).

In this manner, when the file transfer is stopped due to the circumstances of the source device 101 before the file transfer starts, the sink device 102 deletes the object created to store the file. In other words, an obsolete object in the sink device 102 is quickly deleted.

Next, the operation of each device when the file transfer is stopped due to the circumstances of the source device 101 during the transmission of the file data from the source device 101 to the sink device 102 will be described with reference to FIG. 12.

12 is a diagram showing an example of a communication sequence when file transfer is stopped due to circumstances of the source device 101 during the file data transmission in the file transfer system according to the embodiment.

The source device 101 and the sink device 102 perform CDS: CreateObject request and response communication similarly to the communication sequence of FIG. Thereafter, the source device 101 sends a POST request to the sink device 102 (S503). The sink device 102 transmits a “100 Continue” status to the source device 101 as a response to the POST request (S504). The source device 101 starts transmitting the file data to the sink device 102 (S505). The sink device 102 stores the received file data in the file storage unit 804. The operation up to this point is the same as the communication sequence shown in FIG.

In this case, before the source device 101 transmits the POST request, it is assumed that the source device 101 has a command such as a cancellation of file transfer or a deletion of a file to be transmitted by the user. do.

In order to stop the file transfer, the source device 101 transmits an RST packet of TCP (S1206). This disconnects the TCP connection used for file transfer. The source device 101 also transmits a CDS: DestroyObject request to the sink device 102 (S1207). The sink device 102 deletes the received file data according to the CDS: DestroyObject request and transmits a CDS: DestroyObject response to the source device 101 (S1208).

In this way, after the transmission of the file data starts, when the file transfer is stopped due to the circumstances of the source device 101, the file data received and stored in the sink device 102 is deleted. In other words, useless and incomplete file data in the sink device 102 is quickly deleted.

Next, when the sink device 102 receives the POST request, the operation of each device when the file transfer is stopped due to the situation of the sink device 102 will be described with reference to FIG. 13.

13 is a diagram showing an example of a communication sequence when file transfer is stopped due to the situation of the sink device 102 before the file data transmission is started in the file transfer system according to the embodiment.

The source device 101 and the sink device 102 perform CDS: CreateObject request and response communication similarly to the communication sequence of FIG. Thereafter, the source device 101 transmits a POST request to the sink device 102 (S503). The operation so far is the same as in FIG. 5.

It is assumed here that the sink device 102 needs to suspend file transfer for the reason that the object created according to the CDS: CreateObject request from the source device 101 is lost.

In this case, the sink device 102 transmits a "404 Not Found" status to the source device 101 as a response to the POST request (S1304). The source device 101 transmits a file according to "404 Not Found". Stop processing accordingly.

In this manner, after the file size or the like is notified from the source device 101 to the sink device 102 by the POST request, and before transmission of the file data is started, the file transfer is stopped due to the circumstances of the sink device 102. In this case, the source device 101 stops the process according to the file transfer by the notification from the sink device 102. In other words, the source device 101 does not continue unnecessary processing.

Next, the operation of each device when file transfer is stopped during transmission of file data from the source device 101 to the sink device 102 due to the situation of the sink device 102 will be described with reference to FIG.

14 is a diagram showing an example of a communication sequence when file transfer is stopped due to the situation of the sink device in the file transfer system according to the embodiment.

The source device 101 and the sink device 102 perform CDS: CreateObject request and response communication similarly to FIG. 5. Thereafter, the source device 101 sends a POST request to the sink device 102 (S503). The sink device 102 transmits a “100 Continue” status to the source device 101 as a response to the POST request (S504). The source device 101 starts transmitting the file data to the sink device 102 ( S505) The sink device 102 stores the received file data in the file storage unit 804. The operation up to this point is the same as the communication sequence shown in FIG.

Here, the factor of stopping file transfer occurs in the sink device 102 and transmits an RST packet of TCP (S1406). This disconnects the TCP connection used for file transfer. When the source device 101 detects the disconnection of the TCP connection, the source device 101 transmits a POST request to the sink device 102 again (S1407). The sink device transmits a "404 Not Found" status to the source device 101 as a response to the POST request (S1408). The source device 101 stops processing according to file transfer in accordance with "404 Not Found".

In this manner, after the transmission of the file data from the source device 101 to the sink device 102 is started, when the file transfer is stopped due to the situation of the sink device 102, the source device 101 is connected to the sink device 102. The notification from the file system stops processing associated with file transfer. In other words, the source device 101 does not continue unnecessary processing.

As described above, when the source device 101 and the sink device 102 of the embodiment of the present invention stop the file transfer, the wasteful resource consumption and the wasteful processing, even if the suspension depends on the circumstances of any device. Processing for stopping the file transfer is performed so that does not occur.

In addition, in the above-described embodiment, a case has been described in which a file transfer is performed by an HTTP POST method as a file transfer protocol for push type flow control. However, other than the POST method may be used, for example, the PUT method does not lose the above effect.

In addition, when the file transfer is interrupted, the source device 101 adds and sends the parameter shown in FIG. 6 to the HTTP request packet as a parameter referred to by the sink device 102.

As a specific method of providing this parameter, there is a method of including a uniquely defined header as a message header of a POST request.

For example, a uniquely defined header, UploadTransportInfo.dlna.org:[byte-range], is given to a POST request, and the range and total size of data included in the entity body of HTTP are stored. In addition, necessary information such as [lifetime] is included. The sink device 102 can obtain this information from the message header of the POST request sent from the source device 101.

In addition, in the above embodiment, a configuration in which three parameters, [byte-range], [restart-time], and [lifetime], are added to the POST request and described is described. However, only [restart-time] may be added.

Also, UploadTransportInfo. dlna. Other headers that are naturally used in HTTP other than org are not related to the features of the present invention and are not shown or described.

In addition, in the above-mentioned embodiment, when the source device 101 transmits a file to the sink device 102, it is said that it transfers collectively. However, the source device 101 may divide the file and send it to the sink device 102 for each division unit. The method in which the source device 101 transmits file data for each division unit is effective, such as when the sink device 102 has a limit on the data size that can be received in one POST request.

FIG. 15 is a diagram illustrating a communication sequence of a file transfer system in which a source device 101 divides and transmits a file to the sink device 102. An operation of each device when the source device 101 divides and transmits a file will be described with reference to FIG. 15. In addition, in order to notify the sink device 102 of the range of file data to be transmitted, etc., the source device 101 independently defines the header UploadTransportInfo. dlna. Assume that you use org.

The source device 101 transmits a CDS: CreateObject request to the sink device 102 before transmitting the file (S1503). The sink device 102 creates an object according to the CDS: CreateObject request and transmits a CDS: CreateObject response to the source device 101 (S1504).

The source device 101 determines the size of the divided transmission of the file. The size of the divided transmission can be arbitrarily determined in consideration of the interruption of the transmission, the frequency of resumption, the transmission size that becomes useless at the time of interruption, the overhead due to the division, and the like. Here, the file of 1000 bytes is divided into file data of the first 0 byte to 499 byte and file data of the next 500 byte to 999 byte (S1505). This file division is performed by the file transmission control unit 702 of the source device.

The source device 101 starts file transfer. Specifically, the source device 101 transmits a POST request (S1506). The POST request has its own custom header, UploadTransportInfo. dlna. org: contains [byte-range], [lifetime]. [Byte-range] is information indicating the range of data and the total size of the file included in the HTTP Entity Body part following the header. The data range "0-499" and the total size of the file "1000" Is specified. In [lifetime], the retention period of the content is specified. Here, "1800" or 30 minutes is specified in seconds.

The sink device 102 transmits "100 Continue" to the source device 101 in response to the POST request (S1507).

The source device 101 transmits the file data of the data range notified to the sink device 102 (S1508). Specifically, the file data is stored and transmitted in the entity body of the POST request. As described above, the file included in the entity body is only 500 bytes of "0-499".

When the sink device 102 receives the file data of 500 bytes, the sink device 102 starts storing the file in the file storage unit 804. After the start of storage, when the recording cannot be completed within 20 seconds, for example, the recording speed to the file storing unit 804 is delayed, " 102 Processing " is transmitted (S1509). When the saving is completed (S1510), "201 Created" is transmitted to the source device 101 (S1511), and the transmission data is notified.

Next, the source device 101 and the sink device 102 transmit the POST request from the source device 101 to the sink device 102 (S1506) from the sink device 102 to the source device 101. By the same operation procedure as the notification of completion of storage (S1511), file data from the 500th byte to the 999th byte, which are the next division units, are transferred (S1512 to S1517).

That is, the source device 101 uploads UploadTransportInfo. dlna. "500-999 / 1000" is stored in the [byte-range] of the org header and notified to the sink device 102. The sink device 102 interprets this, and thereafter already receives the received file data (S1515). The file data is stored in the file accumulator 804 by appending to the stored file data of the 0 th byte to the 499 byte.

In this manner, even in push type flow control in which a file is transmitted using the POST method, the file can be divided and transmitted.

Also, even in the case where the file is divided and transmitted in this manner, when the file transfer is interrupted, the source device 101 inquires the sink device 102 of the stored data size as shown in the communication sequence of FIG. 10. In this way, only the remaining file data to be transmitted is transmitted. For example, in the communication sequence of FIG. 15, it is assumed that the file transfer is interrupted during the first 500 bytes of transmission, and 200 bytes are stored in the sink device 102 until then. In this case, the source device 101 inquires of the sink device 102 to acquire that the stored data size is "200". Then, the source device 101 sends the remaining 300 bytes to the sink device 102. Send.

If the stored data size cannot be obtained due to an error on the transmission path or the like, the file data that was being transmitted is retransmitted. For example, in the communication sequence of FIG. 15, if the file transfer is interrupted during the transmission of the subsequent 500 bytes, and the source device 101 cannot acquire the stored completed data size from the sink device 102, the subsequent 500 bytes Send from the beginning.

That is, since the first 500 bytes are confirmed to be stored in the sink device 102 by "201 Created" from the sink device 102, the source device 101 may retransmit only the next 500 bytes. .

As described above, the method of dividing and transmitting a file to be transmitted is effective not only when the size of data that the sink device 102 can receive in one POST request but also when the file transfer is efficient. Do.

Further, before the divided file data is transmitted to the sink device 102, the total size of the file is notified to the sink device 102 in the POST request. Therefore, the sink device 102 can determine whether the received file data is a part of file data constituting a certain file or all file data constituting a certain file.

For example, if the [byte-range] notified prior to transmission of the file data is "0-499 / 1000", it can be determined that the file data received thereafter is part of the file data constituting a certain file. , If [byte-range] is “0-999 / 1000”, it can be judged that the received file data is all file data constituting a file.

By this means, for example, if [byte-range] has received and stored the file data specified by "0-499 / 1000", and the remaining file data is not received, the file data that has been saved is completed. It can be determined that the file data is not present, and therefore, such as deleting after a predetermined period of time or confirming whether or not to continue the storage can be performed.

As described above, the received file data can be deleted by exceeding the holding period indicated by [lifetime] specified by the source device 101. Therefore, when [lifetime] is not specified, the sink device 102 may be deleted after a predetermined period has elapsed by the judgment based on the above-described [byte-range]. The file data may be deleted if it is determined that the file data has not been completed since the retention period shown in [lifetime] and from the information shown in [byte-range].

In addition, the name of the header for notifying the sink device 102 of these [byte-range], [lifetime] and the like is UploadTansportInfo. dlna. It may be a header name other than org. In the present embodiment, in accordance with the header naming scheme defined by Digital Living Network Alliance (DLNA), “.dlna. org "is used as a suffix to avoid accidental matching with any other header name. However, the prefix" X- "is used to indicate that it is, for example, HTTP's own extended header. Or X-UploadTransportInfo ".

In addition, in the communication sequence shown in FIG. 15, although the 1000-byte file was divided into two by 500 bytes, it is not necessarily limited to the dividing unit, and arbitrary division is possible.

Also, even in a file transfer system that divides and transfers a file from the source device 101 to the sink device 102, file transfer is sometimes stopped or stopped due to the circumstances of the source device 101 or the sink device 102. have. Therefore, the communication sequence and operation of each device when the file transfer is interrupted before transmission of the file data, which is one divided fragment, will be described below with reference to FIGS. 16 and 17. In addition, the communication sequence when the file transfer is stopped and the operation of each device will be described with reference to FIG.

Fig. 16 is a diagram showing a communication sequence in the case where a file transfer is interrupted due to the circumstances of the source device 101 before the transmission of one file data after division in the file transfer system for dividing and transmitting the file.

In the communication sequence shown in FIG. 16, the process of transmitting the CDS: CreateObject request (S1503) and then dividing the file to be transferred (S1505) is as described with reference to FIG. 15 and description thereof is omitted.

It is assumed here that the source device 101 stops the file transfer due to a user cancel instruction or the like. In this case, the source device 101 uploads the UploadTransportInfo. Message containing [suspend] indicating the suspension of processing in the message header of the POST request. dlna. The org header is stored and transmitted to the sink device 102 (S1606).

The source device 101 sends this UploadTransportInfo. dlna. org: The sink device 102 can be explicitly notified of the suspension by the field value indicating [suspend] which is a keyword included in the header. In this case, the entity body of the POST request is not transmitted. In addition, similar to the communication sequence of FIG. 15, [lifetime] is also included in the header and, for example, "1800", that is, 30 minutes is designated in seconds.

The sink device 102 transmits "200 OK" (S1607), indicating that the interruption is understood.

According to this procedure, compared with the case of simply interrupting by TCP disconnection or the like, the sink device 102 can take an appropriate action such as slipping an unnecessary transfer process, so that there is an effect of suppressing the use of unnecessary processing.

In addition, resumption of transmission is performed by UploadTransportInfo. dlna. org: The source device 101 can arbitrarily perform within 30 minutes specified by [lifetime] of the header. If the source device 101 cannot resume transmission within 30 minutes, the UploadTransportInfo. dlna. It is also possible to extend the transmission resumption period by sending org: suspend.

Next, in the file transfer system that divides and transmits a file, the operation of each device when the file transfer is interrupted due to the situation of the sink device 102 when the sink device 102 receives the POST request is shown in FIG. It will be described using.

FIG. 17 is a diagram illustrating a communication sequence when a file transfer is interrupted due to the situation of the sink device 102 when the sink device 102 receives a POST request in a file transfer system that divides and transmits a file. .

In the communication sequence of FIG. 17, until the source device 101 transmits a CDS: CreateObject request (S1503) and then notifies the range of file data to be transmitted, etc., by the POST request (S1506), using FIG. As described, description is omitted.

It is assumed here that the sink device 102 that has received the POST request S1506 is not in a state where file transfer can be performed for the reason that data is being read from the file accumulator 804.

In this case, the sink device 102 transmits "503 Service Unavailable" to the source device 101 as a response to the POST request (S1707), and notifies the source device 101 that it is not in a state capable of file transfer. do.

In addition, the sink device 102 notifies the expected time to start the transmission by storing the Retry-After: header in a response message containing “503 Service Unavailable.” That is, the Retry-After: header transmits a file. Information indicating when to resume the data, and notifying of the period in which resumption is possible by storing the header, UploadTransportExpireInfo.dlna.org :, which is an independently defined header.

UploadTransportExpireInfo. dlna. The org: header is a header that indicates the end that accepts file transfers. In the communication sequence of Fig. 17, “1800”, that is, 30 minutes is designated in seconds. In this case, it indicates that the sink device 102 accepts the file transfer until 30 minutes after transmitting the response message (S1707). Specifically, after 30 minutes, the object created in response to the CDS: CreateObject request S1503 from the source device 101 is deleted, and the file transfer is interrupted after already receiving and storing some file data. In this case, the file data which has not been completed is stored in the file accumulator 804, and the file data is deleted.

Here, the Retry-After: header defined in RFC2616 does not generally guarantee the resumption of service, and it is unlikely that the retry-After: header can resume service even if the retry is performed at intervals shorter than the period indicated in the Retry-After: header. In order to suppress the polling load of the counterpart device by notifying.

Therefore, the source device 101 transmits to the sink device 102 after 20 minutes indicated by the Retry-After: header. dlna. The org: retry is performed within 30 minutes indicated by the header to confirm whether transmission can be resumed, and transmission of file data is continued if possible.

As described above, when the sink device 102 stops the file transfer due to its own circumstances, the Retry-After: header and UploadTransportExpireInfo. dlna. The org: header informs the source device 101 of when and when the source device 101 should retry file transfer.

As a result, the source device 101 does not perform an unnecessary retry. As a result, unnecessary use of resources in the source device 101 and on the transmission path can be prevented.

Next, in the file transfer system that divides and transfers a file, a communication sequence when the file transfer is stopped due to the situation of the sink device 102 as an example of the case where the file transfer is stopped, and the operation of each device are shown in FIG. 18. It will be described using.

FIG. 18 is a diagram illustrating a communication sequence when file transfer is stopped due to the situation of the sink device 102 in the file transfer system that divides and transmits a file.

In the communication sequence of FIG. 18, after the source device 101 transmits a CDS: CreateObject request (S1503), the source device 101 is not in a state where the sink device 102 can perform file transfer. Until notification (S1707), it is as described using FIG. 15 and FIG. 17, and description is abbreviate | omitted.

In the communication sequence of FIG. 18, the sink device 102 is once notified (S1707) for stopping file transfer. However, when the source device 101 performs a retry of file transfer (S1808), It is assumed that there was a reason for the sink device 102 to stop the file transfer without resuming it.

For this reason, for example, since the free space of the file accumulating unit 804 is lost, there is no expectation that the current transfer can be resumed, or the transfer itself causes a problem in the operation of the sink device 102. And the like.

In this case, the sink device 102 transmits in response to "404 Not Found" (S1809), indicating that the URI resource of the transmission destination, i.e., the object for storing the transmitted file data is deleted and is not available at the minimum. In addition, even if the source device 101 retries a URI that has already been deleted from the sink device 102 due to the difference between the timers of the source device 101 and the sink device 102, the same order may occur. have.

In addition, when the file transfer is stopped from the source device 101, the method does not retry to a predetermined URI until time-out, or it is explicit from the sink device 102 by issuing a CDS: DestroyObject of UPnP-AV. For example, you can delete an object and its URI.

As described above as an example of managing file transfer on an object basis of UPnP-AV, the present invention is not limited to this, and can be applied to a case where a file transmission is simply performed for a predetermined URI.

In this manner, even in a file transfer system that divides and transmits a file, when the file transfer is interrupted or stopped, the external device can be notified of the interruption or suspension of the source device 101 or the sink device 102. As a result, the device notified of the interruption or interruption does not continue processing for unnecessary file transfer.

In addition, although the case of transmitting a file by the HTTP POST method has been described, the present invention is not limited to this, but can be applied to a file transfer protocol other than HTTP to which the PUT method, and thus the same handshake sequence, can be applied.

16 to 18 show a communication sequence when the file data after division is not transmitted once but the file transfer is interrupted or stopped. However, the operation of each device at the time of interruption or interruption of the file transfer described with reference to Figs. same.

The transmitting device, the receiving device, and the file transfer system of the present invention are useful in a file transfer system for transferring files between any device connected to a network. Especially when the file size is large and the transfer is restarted from the beginning when the transfer is interrupted and resumed, it is effective when there is much waste.

Claims (15)

A file transfer system for performing file transfer from a transmitting device transmitting a file to a receiving device receiving the file, via a network, The receiving device, Storage means for storing file data constituting the file, received from the transmitting device; Storage completion size acquisition means for acquiring a storage completion size which is a size of file data which has been stored in said storage means; And receiving control means for transmitting the stored completed size acquired by the stored completed size obtaining means to the transmitting device when the stored completed size is inquired from the transmitting device. The transmitting device, Transmitting means for transmitting file data to the receiving device; Detection means for detecting interruption of the file transfer; Inquiring means for inquiring the storage device of the completed data size after the interruption of the file transfer is detected by the detecting means; And transmission control means for transmitting the remaining file data constituting the file to the transmission means based on the size of the stored data that the receiving device responds to in response to the inquiry by the inquiry means. The file transfer system according to claim 1, wherein said transmitting means transmits said file to said receiving device using a POST method or a PUT method of Hyper Text Transfer Protocol (HTTP). The transmission apparatus according to claim 1, wherein the transmission control means further notifies the receiving device of a data range which is a range in the file of the file data before the transmission means transmits file data, And the receiving device further comprises file control means for combining the file data stored in the storage means based on the data range with the file data received after the data range is notified. 4. The file transfer system according to claim 3, wherein said transmission control means notifies said receiving device of the total size of said file together with said data range. The method according to claim 4, wherein the transmission control means further divides the file into file data of a predetermined size, And the transmitting means transmits the file data divided by the transmission control means to the receiving device. The reception device according to claim 1, wherein the reception control means further transmits a suspension request to the transmitting device requesting the suspension of file transfer, The interruption request includes timing information indicating when the receiving device resumes the file transfer, and period information indicating a termination when the receiving device accepts the file transfer, The detecting means detects the interruption of the file transfer by receiving the interruption request, And said transmission control means transmits said remaining file data to said transmission means between said time period and said permission period. The transmission device according to claim 1, wherein the transmission control means further notifies the receiving device of the holding period of the file data in the receiving device before the transmitting means transmits the file data, The reception control means further includes, when the file data is stored in the storage means and not receiving all file data constituting the file from the transmitting device before the retention period of the file data has elapsed. A file transfer system for deleting the stored file data. The method according to claim 1, wherein the transmitting device and the receiving device performs a file transfer by a Transmission Control Protocol (TCP) connection, The detecting means detects the interruption of the file transfer by detecting that the transmission control means disconnects the TCP connection during transmission of the file data, The transmission control means further notifies the receiving device of the holding period of the file data in the receiving device after the disconnection of the TCP connection, The reception control means further deletes the file data stored in the storage means when all the file data constituting the file is not received from the transmission device before the sustain period notified from the transmission device elapses. File transfer system. The method according to claim 1, wherein the transmitting device and the receiving device performs a file transfer by a Transmission Control Protocol (TCP) connection, The transmission control means further transmits a transmission request for obtaining a permission of file transfer to the receiving device when the TCP connection is disconnected by the receiving device, The reception control means further transmits a stop request to the transmitting device requesting the suspension of the file transfer in response to the transfer request, And the detecting means detects the interruption of the file transfer by receiving the interruption request. A transmitting device for performing file transfer for transferring files to a receiving device via a network, Transmitting means for transmitting file data constituting the file to the receiving device; Detection means for detecting interruption of the file transfer; Inquiring means for inquiring a storage completed data size which is a size of file data stored in the receiving device after the interruption of the file transfer is detected by the detecting means; And transmission control means for transmitting the remaining file data constituting the file to the transmission means based on the size of the completed data that the reception device responds to in response to the inquiry by the inquiry means. A receiving device that receives a file transmitted from a transmitting device through a network, Storage means for storing file data constituting the file, received from the transmitting device; Storage completion size acquisition means for acquiring a storage completion size which is a size of file data which has been stored in said storage means; And a reception control means for transmitting the stored completed size acquired by the stored completed size obtaining means to the transmitting device when the stored completed size is inquired from the transmitting device. As a transmission method for performing file transfer which transmits a file to a receiving device via a network, A transmitting step of transmitting file data constituting the file to the receiving device; A detecting step of detecting interruption of the file transfer; An inquiry step of inquiring of a storage completed data size which is a size of file data stored in the receiving device after the interruption of the file transfer is detected by the detecting means; And a transmission control step of transmitting, to the receiving device, the remaining file data constituting the file based on the size of the stored completed data answered by the receiving device in response to the inquiry by the inquiry means. As a receiving method for receiving a file transmitted from a transmitting device via a network, A storing step of storing, in a storage means, file data constituting the file, received from the transmitting device; A storage completion size acquisition step of acquiring a storage completion size which is a size of file data which has been stored in the storage means; And a receiving control step of transmitting the stored completed size acquired by the stored completed size obtaining means to the transmitting device when the stored completed size is inquired from the transmitting device. A program for performing file transfer to transfer a file to a receiving device via a network, A transmitting step of transmitting file data constituting the file to the receiving device; A detecting step of detecting interruption of the file transfer; An inquiry step of inquiring of a completed data size which is a size of file data stored in the receiving device after the interruption of the file transfer is detected by the detecting means; A program for causing a computer to execute a transmission control step of transmitting, to the receiving device, the remaining file data constituting the file based on the size of the completed data that the receiving device responds to in response to the inquiry by the inquiry means. A program for receiving a file transmitted from a transmitting device via a network, A storing step of storing, in a storage means, file data constituting the file, received from the transmitting device; A storage completion size acquisition step of acquiring a storage completion size which is a size of file data which has been stored in the storage means; A program for causing a computer to execute a reception control step of transmitting the stored completed size acquired by the stored completed size obtaining means to the transmitting device when the stored completed size is inquired from the transmitting device.

Images