KR20070083649A - 송신 기기, 수신 기기 및 파일 전송 시스템 - Google Patents

송신 기기, 수신 기기 및 파일 전송 시스템 Download PDF

Info

Publication number
KR20070083649A
KR20070083649A KR1020077008171A KR20077008171A KR20070083649A KR 20070083649 A KR20070083649 A KR 20070083649A KR 1020077008171 A KR1020077008171 A KR 1020077008171A KR 20077008171 A KR20077008171 A KR 20077008171A KR 20070083649 A KR20070083649 A KR 20070083649A
Authority
KR
South Korea
Prior art keywords
file
transmitting
size
data
file transfer
Prior art date
Application number
KR1020077008171A
Other languages
English (en)
Inventor
도시하루 고시노
히데아키 다케치
다쿠미 다나베
요우스케 스즈키
나오노리 가토
Original Assignee
마쯔시다덴기산교 가부시키가이샤
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마쯔시다덴기산교 가부시키가이샤 filed Critical 마쯔시다덴기산교 가부시키가이샤
Publication of KR20070083649A publication Critical patent/KR20070083649A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/266—Stopping or restarting the source, e.g. X-on or X-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/43—Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5603—Access techniques

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Abstract

본 발명은 송신 기기로부터 자발적으로 수신 기기에 파일을 전송하는 파일 전송 시스템에 있어서, 파일 전송이 장시간에 걸쳐 중단되는 경우라도, 파일 전송에 따른 처리를 효율적으로 실행하기 위한 송신 기기, 수신 기기 및 파일 전송 시스템을 제공한다.
본 발명의 파일 전송 시스템에 있어서, 수신 기기인 싱크 기기는 송신 기기인 소스 기기로부터 수신하는, 파일을 구성하는 파일 데이터를 저장하고, 소스 기기로부터 저장 완료 사이즈가 문의되면, 저장 완료 사이즈를 소스 기기에 송신한다. 또한, 소스 기기는 파일 전송의 중단을 검출하고, 파일 전송을 중단이 검출한 후에 싱크 기기에 저장 완료 데이터 사이즈를 문의한다. 또한, 그 문의에 따라 싱크 기기가 응답한 저장 완료 데이터 사이즈에 의거하여 파일을 구성하는 나머지의 파일 데이터를 송신한다.

Description

송신 기기, 수신 기기 및 파일 전송 시스템 {TRANSMITTING DEVICE, RECEIVING DEVICE, AND FILE FORWARDING SYSTEM}
본 발명은 네트워크를 통하여 파일 전송을 행하기 위한 송신 기기, 수신 기기 및 파일 전송 시스템에 관한 것이다.
최근, xDSL이나 광섬유 등의 브로드밴드 환경이 갖추어짐으로써 기업, 일반 가정을 불문하고 인터넷 접속이 급속히 보급되어 오고 있다. 또한, 가정 내의 퍼스널 컴퓨터(PC)나 가전 기기를 Ethernet(등록 상표)이나 무선 LAN 등으로 접속하는 홈 네트워크 환경도 일반화하고 있다. 이와 같은 상황 속에서 PC 뿐만 아니라 텔레비전이나 DVD 레코더, 에어콘, 냉장고와 같은 가전도 Internet Engineering Task Force(IETF)에 의해 정의되는 Internet Protocol(IP)에 의해 서로 접속할 수 있도록 되고 있다.
인터넷이나 홈 네트워크에서의 어플리케이션 프로그램의 하나로서 가전 기기, PC 사이에 파일을 전송하는 어플리케이션 프로그램이 있다. 파일을 전송하는 어플리케이션 프로그램의 예로서 DVD 레코더에 녹화한 TV 프로그램을 편집하기 위해서 PC에 전송하거나 DVD 레코더 사이에서 녹화한 MPEG2 파일을 전송하는 등의 더빙 기능을 제공하는 어플리케이션 프로그램이 있다.
이러한 파일 전송을 행하는 프로토콜에서는 일반적으로 파일의 전송이 잘못없이 행해지는 것이 요구되는 한편, 리얼타임의 전송은 반드시 요구되지 않는다. IP에 있어서 파일 전송을 행하는 대표적인 프로토콜로서는, RFC2616에서 정의되는 Hyper Text Transfer Protocol(HTTP)이나, RFC959에서 정의되는 File Transfer Protocol(FTP) 등이 존재한다. 이들의 프로토콜은 모두 RFC793에서 정의되는 Transmission Control Protocol(TCP)의 재송 기능에 의해서 전송의 신뢰성을 확보하고 있다.
즉, TCP는 패킷의 에러를 검출하여 재송하는 순서와, 결핍된 패킷을 검출하여 재송하는 순서를 포함하고 있고, 그 때문에 전송로 상에서 에러나 패킷 결핍이 일어나도 올바른 파일의 전송을 보장할 수 있다. 한편으로 TCP의 재송 순서에는 한계도 있고, 예를 들어 전송로의 장애나 송신원의 기기(이하, 「소스 기기」라고 함)나, 수신처의 기기(이하, 「싱크 기기」라고 함)의 사정에 의해 전송의 중단이 장시간에 걸친 경우, TCP 접속이 타임 아웃에 의해 절단되고, 그 이후의 파일 전송을 행할 수 없게 된다는 과제가 존재하였다. 여기서의 기기의 사정에는 장애 외에, 기기의 다른 기능을 실행하기 위해서 파일 전송을 중단해야 하는 경우를 포함한다. 예를 들어, DVD 레코더가 타이머 녹화를 실행하기 위해서 파일 전송을 중단하는 경우 등을 들 수 있다.
HTTP에는 전술한 과제를 해결하기 위한 순서가 포함되어 있고, 전송의 중단이 임의의 장시간에 걸친 경우라도 재차 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 참조).
특허 문헌 1 : 일본 공개특허공보 2002-288162호
그러나, 상기 종래의 HTTP의 파일 전송의 중단, 재개 순서는 HTTP의 GET 메소드에서는 사용할 수 있지만, POST 메소드에서는 사용할 수 없다는 과제가 존재한다. 인터넷 상의 서버로부터 PC에 파일을 다운로드하는 경우는 HTTP의 GET 메소드가 사용되기 때문에 이러한 제약은 문제는 되지 않는다.
그러나, 네트워크에 접속되는 임의의 기기 사이에 파일을 전송하는 경우에 있어서, 소스 기기가 임의의 파일을 싱크 기기의 요구없이 자발적으로 송신하고자 하는 경우에는 통상 HTTP POST 메소드가 이용된다. 그 때문에, 소스 기기와 싱크 기기 사이의 통신이 중단된 경우에는, 통신의 재개 후에 파일의 송신을 최초부터 행해야 하고, 파일 전송을 위한 리소스나 시간을 쓸데없이 소비한다는 과제가 있다.
이 과제는 보다 일반적으로 말하면, 소스측으로부터 자발적으로 데이터를 송신하는 것을 트리거로 하여 푸시형의 플로우 제어를 행하는 파일 전송 프로토콜에 있어서는, 싱크측으로부터 리퀘스트를 발행하는 풀형의 플로우 제어와 달리, 통신의 중단이 있는 경우에 효율적인 파일 전송을 행하는 순서가 존재하지 않았다는 과 제이다.
또한, 전술의 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)는 각각 축적 미디어를 내장하고, Audio Visual(AV) 컨텐츠 등의 파일을 축적할 수 있다. 구체적으로는, 소스 기기(101)는 파일 축적부(705)를 구비하고 싱크 기기(102)는 파일 축적부(804)를 구비한다.
이러한 기기의 예로서 네트워크 접속 단자를 구비한 DVD/HDD 하이브리드 레코더 등을 들 수 있다. 본 실시의 형태의 시기 상태에서는 소스 기기(101)가 파일 축적부(705)에 파일(303)을 축적하고 있고, 본 파일을 홈 네트워크를 통하여 싱크 기기(102)에 전송한다. 싱크 기기(102)는 소스 기기로부터 수신한 파일(303)을 파일 축적부(804)에 축적한다.
또한, 본 실시의 형태에서는 싱크 기기(102), 소스 기기(101) 모두 유니버설 플러그 앤 플레이 포럼이 발행하는 UPnP-AV 규격에 준거하고 있고, 싱크 기기(102)는 Contents Directory Service(CDS) 서버 기능을 실장하고 있으며, 소스 기기(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)를 제어함으로써 홈 네트워크를 통한 통신을 제어하는 제어부이다.
다음에, 이상과 같이 구성된 소스 기기(101) 및 싱크 기기(102)에 의해 구성되는 파일 전송 시스템에서의 소스 기기(101) 및 싱크 기기(102)의 동작을 도 5로부터 도 14를 참조하여 설명한다.
우선, 기본의 통신 시퀀스에서의 각 기기의 동작을 도 5 및 도 6을 이용하여 설명한다.
도 5는 본 발명의 실시의 형태의 파일 전송 시스템에서의 기본의 통신 시퀀스를 나타내는 도면이다. 도 5에 나타내는 바와 같이, 본 실시의 형태에서는 소스 기기(101)로부터 싱크 기기(102)로의 통신에 의해 파일 전송이 개시된다. 즉, 도 5는 소스 기기(101)로부터의 자발적인 파일 전송에서의 통신 시퀀스도이다.
또한, 소스 기기(101)와 싱크 기기(102) 사이의 통신은 브로드밴드 라우터(301)에 의해 중계된다. 그러나, 브로드밴드 라우터(301)의 동작은 본 발명의 특징에 관여하지 않기 때문에, 이하, 그 도시 및 동작의 설명은 생략한다.
소스 기기(101)는 UPnP-AV 규격으로 규정된 CDS : CreateObject 리퀘스트를 송부한다(S501). 여기서 CreateObject 리퀘스트는 논리적인 파일을 나타내는 object를 생성하는 리퀘스트이며, 이것에 의해서 싱크 기기(102)의 파일 축적부(804) 내에 신규로 object가 생성된다. 그 때, 생성되는 object의 디렉토리 구조 상의 위치나, 그 object를 나타내는 파일명 등의 메타 데이터가 결정된다. 이 메타 데이터에는 파일 실체를 저장해야 할 싱크 기기(102) 상의 Uniform Resource Identifiers(URI)가 포함되어 있다. 싱크 기기(102)는 파일의 전송처 어드레스로서 이 URI를 포함한 CDS : CreateObject 리스펀스를 소스 기기에 송신한다(S502).
소스 기기(101)는 POST 메소드의 HTTP 리퀘스트(이하, 「POST 리퀘스트」라고 함)를 싱크 기기(102)에 송부한다(S503). 이 때, 소스 기기(101)는 파일 전송이 중단된 경우에 싱크 기기(102)가 참조해야 할 파라미터로서, 도 6에 나타내는 파라미터를 POST 리퀘스트에 부가하여 송부한다. 구체적으로는, 파라미터로서 [byte-range], [restart-time] 및 [lifetime]의 세 개를 송부한다.
도 6은 소스 기기(101)로부터 싱크 기기(102)에 송부되는 각 파라미터의 내용을 나타내는 도면이다.
도 6에 나타내는 바와 같이, [byte-range]는 송신하는 데이터의 바이트 레인지이다. 바이트 레인지란 송신하는 파일 데이터의 범위인 데이터 범위의 선두 위치와 종단 위치를 나타내는 정보 및 파일의 총 사이즈인 파일 사이즈를 나타내는 정보이다. 또한, 단위는 각각 바이트이다.
즉, 싱크 기기(102)는 소스 기기로부터 송신되는 데이터의 범위뿐만 아니라 파일의 총 사이즈도 통지된다. 그 때문에, 수신한 파일 데이터가 어떤 파일을 구성하는 일부의 파일 데이터인지, 또는, 어떤 파일을 구성하는 모든 파일 데이터인 지를 판단할 수 있다. 또한, 본 실시의 형태에 있어서는 1개의 파일을 싱크 기기(102)에 송신하는 경우, 분할하지 않고 일괄하여 송신한다. 파일을 분할하여 송신하는 경우에 대해서는 도 15를 이용하여 후술한다.
[restart-time]은 송신 재개 허가 시간이다. 송신 재개 허가 시간이란, 중단 후에 파일 전송 동작을 재개할 때까지의 일시 정지 시간을 나타내는 정보로서, 단위는 초이다.
[lifetime]은 파일 유지 기간이다. 파일 유지 기간이란 싱크 기기(102)가 object 또는 파일 데이터를 유지해 두어야 할 시간을 나타내는 정보로서, 단위는 초이다. 싱크 기기(102)는 [lifetime]에 나타나는 기간이 경과하기까지, 파일 데이터를 수신하지 않는 경우, 작성한 object를 유지해 둘 의무가 없다. 또한, [lifetime]이 통지되고 완결되어 있지 않은 파일 데이터를 수신한 경우, [lifetime]에 나타나는 기간이 경과하기까지, 나머지의 파일 데이터를 수신하지 않는 경우, 완결되어 있지 않은 파일 데이터를 유지해 둘 의무가 없다.
이것에 의해, 소스 기기(101)가 접속 불능이 되거나 전송 대상의 파일을 소실한 경우라도, 싱크 기기(102), 완료할 수 없는 파일 전송을 위한 쓸데없는 리소스를 유지해 둘 필요가 없다. 그 때문에, 싱크 기기(102)에 있어서 리소스를 효율적으로 관리할 수 있고, 사용자의 손에 의한 불필요한 object의 삭제 등의 유지보수도 불필요하다.
도 5의 통신 시퀀스에서는 소스 기기(101)는 송신하는 데이터의 선두 위치 : 0바이트째, 종단 위치 : 999바이트째 및 파일 사이즈 : 1000바이트를 지정하고 있 다. 이것은, 전술한 바와 같이 1개의 파일을 일괄하여 송신하는 것을 의미한다. 또한, 일시 정지 시간 : 1200초(20분), 파일 유지 기간 : 1800초(30분)도 지정하고 있다.
또한, 전송 중단 요구를 나타내는 [suspend-req]는, 도 5의 통신 시퀀스에 있어서는 사용되고 있지 않다. [suspend-req]를 싱크 기기(102)에 송부하는 경우에 대해서는, 도 7을 이용하여 후술한다.
또한, 소스 기기(101)로부터 싱크 기기(102)에 송신되는 POST 리퀘스트에서 지정하는 URI로서 싱크 기기(102)로부터 수신한 CreateObject 리스펀스에 포함되어 있던 URI가 기술된다. 이것에 의해, 싱크 기기(102)는 특정한 object와 수신한 파일 데이터를 대응시킬 수 있다.
또한, POST 리퀘스트에는 Expect : 100-continue가 부가된다. 이것에 의해, 싱크 기기는 RFC2616에 따라, 송신된 POST 리퀘스트를 상기 URI에서 받아들일 수 있을지의 체크를 행한다.
체크의 결과, 받아들임이 가능하면 응답으로서 “100 Continue"를 돌려준다(S504). 또한, 소스 기기(101)로부터의 POST 리퀘스트를 받아들일 수 없는 경우나, POST 리퀘스트를 해석할 수 없는 경우에는 데이터의 전송 전에 소스 기기에 통지할 수 있다. 따라서 소스 기기(101)는 쓸데없는 데이터 송신을 회피할 수 있다.
소스 기기(101)는 “100 Continue" 스테이터스를 싱크 기기(102)로부터 수신함으로써, 파일을 싱크 기기(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의 통신 시퀀스와 마찬가지로, CDS : CreateObject 리퀘스트 및 리스펀스 통신을 행한다. 이 후, 소스 기기(101)는 POST 리퀘스트를 싱크 기기(102)에 송부한다(S503). 싱크 기기(102)는 POST 리퀘스트의 응답으로서 “100 Continue" 스테이터스를 소스 기기(101)에 송신한다(S504). 소스 기기(101)는 파일 데이터의 싱크 기기(102)에의 송신을 개시한다(S505). 싱크 기기(102)는 수신한 파일 데이터를 파일 축적부(804)에 축적한다. 여기까지의 동작은, 도 5에 나타내는 통신 시퀀스와 동일하다.
여기서 소스 기기(101)에 있어서, 파일 전송을 중단하는 요인이 발생하고, TCP 접속을 절단하기 위한 RST 패킷을 송부한다. 이것에 의해, 파일 전송에 이용하고 있는 TCP 접속은 절단된다(S706).
파일 전송을 중단하는 요인이란, 예를 들어, 사용자의 조작에 의해 전송 중인 파일이 파일 축적부(705)로부터 삭제된 것 등이다.
소스 기기(101)는 또한, [suspend-req] 및 [lifetime]을 포함한 POST 리퀘스트 패킷을 싱크 기기(102)에 송신한다(S707). [suspend-req]는 도 6에 나타내는 바와 같이, 파일 전송의 중단 요구를 나타내는 정보이다. 즉, 싱크 기기(102)는 [suspend-req]를 수신함으로써 파일 전송이 중단되는 것을 알 수 있다. 또한, [lifetime]은 전술한 바와 같이 싱크 기기(102)가 파일 데이터를 유지해 두어야 할 시간을 나타내는 정보이며, 이 경우는 소스 기기(101)가 그 시간 내에 파일 전송을 재개하는 것도 의미한다. 싱크 기기(102)는 파일 유지 기간이 경과한 후에는, 수신하여 저장이 완료된 해당 파일 데이터를 삭제해도 좋다.
또한, 전술의 파일 전송의 중단에 따른 처리에 있어서, RST 패킷 및 POST 리 퀘스트 패킷은 파일 송신 제어부(702)에 의해 생성되고 싱크 기기(102)에 송신된다. 이하, 단순히 「POST 리퀘스트」라고 하는 경우, 실체로서는 POST 리퀘스트 패킷을 가리킨다.
또한, 중단 검출부(707)는 TCP 접속이 절단된 것을 검출하는 것으로, 파일 전송이 중단된 것을 검출한다.
싱크 기기(102)는 상기 POST 리퀘스트를 수취하면 “200 OK"를 답장한다(S708). 소스 기기(101)는 파일 전송을 중단하는 요인이 없어진 후에, 도 11을 이용하여 후술하는 파일 전송의 재개 동작을 실행한다.
이렇게 하여 본 실시의 형태의 파일 전송 시스템에 있어서, 파일 데이터의 송신의 개시 후 또한 파일 전송이 완료되기 전에 소스 기기(101)의 사정에 의해 파일 전송이 중단된다.
다음에, 싱크 기기(102)가 POST 리퀘스트를 수신했을 때에, 싱크 기기(102)의 사정에 의해 파일 전송이 중단되는 경우의 각 기기의 동작을 도 8을 이용하여 설명한다.
도 8은, 실시의 형태의 파일 전송 시스템에 있어서, 싱크 기기(102)의 사정에 의해 파일 전송이 중단될 때의 통신 시퀀스의 일례를 나타내는 도면이다.
소스 기기(101) 및 싱크 기기(102)는 도 5의 통신 시퀀스와 마찬가지로, CDS : CreateObject 리퀘스트 및 리스펀스 통신을 행하다. 이 후, 소스 기기(101)는 POST 리퀘스트를 싱크 기기(102)에 송부한다(S503). 여기까지의 동작은, 도 5에 나타내는 통신 시퀀스와 동일하다.
여기서, 싱크 기기(102)는 파일의 수신 처리를 행할 수 없는 상태이며, POST 리퀘스트에 대한 응답으로서 “503 Service Unavailable" 스테이터스를 송신한다. 파일의 수신 처리를 행할 수 없는 상태란, 예를 들어 파일 축적부(804)의 빈 용량이 없는 상태 등이다.
싱크 기기(102)는 스테이터스 패킷에 파일 전송을 재개하는 시기를 나타내는“retry-after"를 포함하여 응답한다(S804). 소스 기기(101)는 “retry-after"에 나타나는 시간을 경과한 후에, 도 11을 이용하여 후술하는 파일 전송의 재개 동작을 실행한다.
이렇게 하여 본 실시의 형태의 파일 전송 시스템에 있어서, 소스 기기(101)로부터 싱크 기기(102)에, POST 리퀘스트에 의해 전송되는 파일의 사이즈 등이 통지된 후, 또한 파일 데이터의 송신이 개시되기 전에 싱크 기기(102)의 사정에 의해 파일 전송이 중단된다.
다음에, 소스 기기(101)로부터 싱크 기기(102)로의 파일 데이터의 송신 중에, 싱크 기기(102)측의 요인에 의해 파일 전송을 중단할 때의 각 기기의 동작을 도 9를 이용하여 설명한다.
도 9는, 실시의 형태의 파일 전송 시스템에 있어서, 싱크 기기(102)의 사정에 의해 파일 전송이 중단될 때의 통신 시퀀스의 다른 일례를 나타내는 도면이다.
소스 기기(101) 및 싱크 기기(102)는, 도 5의 통신 시퀀스와 마찬가지로, CDS : CreateObject 리퀘스트 및 리스펀스 통신을 행한다. 이 후, 소스 기기(101)는 POST 메소드의 HTTP 리퀘스트를 싱크 기기(102)에 송부한다(S503). 싱크 기기 (102)는 HTTP 리퀘스트의 응답으로서 “100 Continue" 스테이터스를 소스 기기(101)에 송신한다(S504). 소스 기기(101)는 파일 데이터의 싱크 기기(102)에의 송신을 개시한다(S505). 싱크 기기(102)는 수신한 파일 데이터를 파일 축적부(804)에 축적한다. 여기까지의 동작은, 도 5에 나타내는 통신 시퀀스와 동일하다.
여기서 싱크 기기(102)에 있어서, 파일 전송을 중단하는 요인이 발생하고, RST 패킷을 송부한다. 이것에 의해, 파일 전송에 이용하고 있는 TCP 접속은 절단된다(S906). 파일 전송을 중단하는 요인이란, 예를 들어 파일 축적부(804)로부터 다른 파일을 독출할 필요가 생겨 수신하는 파일 데이터를 축적할 수 없는 등이다.
TCP 접속이 싱크 기기에 의해 절단되면, 소스 기기(101)의 파일 송신 제어부(702)는 다시 POST 리퀘스트를 싱크 기기(102)에 송신한다(S907).
싱크 기기(102)는 POST 리퀘스트에의 응답으로서 “503 Service Unavailable" 스테이터스를 소스 기기(101)에 송신한다(S908). 스테이터스 패킷에는 전술의 [retry-after]가 포함된다.
이 [retry-after]를 수반하는 “503 Service Unavailable"는 싱크 기기(102)로부터의 파일 전송의 중단 요구이다.
소스 기기(101)의 중단 검출부(707)는 이 중단 요구를 검출함으로써 파일 전송의 중단을 검출한다. 소스 기기(101)는 “retry-after"에 나타나는 시간을 경과한 후에, 도 11을 이용하여 후술하는 파일 전송의 재개 동작을 실행한다.
이와 같이 하고, 본 실시의 형태의 파일 전송 시스템에 있어서, 파일 데이터의 송신의 개시 후 또한 송신이 완료하기 전에, 싱크 기기(102)측의 요인에 의해 파일 전송이 중단된다.
다음에, 도 7~도 9를 이용하여 설명한 파일 전송의 중단 후에, 파일 전송을 재개할 때의 각 기기의 동작을 도 10을 이용하여 설명한다.
도 10은 실시의 형태의 파일 전송 시스템에 있어서, 파일 전송을 재개할 때의 통신 시퀀스를 나타내는 도면이다.
소스 기기(101)의 중단 검출부(707)는 파일 전송이 중단된 것을 검출한다(S1000). 또한, 중단 검출부(707)는 파일 전송의 중단이 소스 기기(101)의 사정에 의한 것인지, 싱크 기기(102)의 사정에 의한 것인지를 불문하고, 송수신하는 패킷의 종류 및 내용 등으로부터 파일 전송이 중단된 것을 검출할 수 있다.
소스 기기(101)는 자신의 사정에 의해 파일 전송을 중단한 경우에는, 그 중단의 요인이 없어진 후에, 또한 싱크 기기(102)의 사정에 의해 파일 전송이 중단된 경우에는, 중단 시에 싱크 기기(102)로부터 송신된 [retry-after]에 나타나는 시간이 경과한 후에 이하의 동작을 행한다.
소스 기기(101)는 CDS : Browse 리퀘스트를 싱크 기기(102)에 송신하고(S1001), 싱크 기기(102)에 대해서 파일의 저장 사이즈를 문의한다.
구체적으로는, 소스 기기(101)의 파일 송신 제어부(702)에 의해 생성되는 CDS : Browse 리퀘스트에, 문의부(708)에 의해서 저장 완료 데이터 사이즈의 통지 요구가 포함된다. 그 CDS : Browse 리퀘스트는 네트워크 인터페이스(706)를 통하여 싱크 기기(102)에 송신된다.
싱크 기기(102)는 상기 CDS : Browse 리퀘스트를 수취하면 저장 완료 데이터 사이즈를 포함한 CDS : Browse 리스펀스를 소스 기기(101)에 송신한다(S1002).
구체적으로는, 저장 완료 사이즈 취득부(806)가 파일 축적부(804)에 저장되어 있는, 해당 파일을 구성하는 파일 데이터의 데이터 사이즈를 취득한다. 또한, 파일 수신 제어부(801)가 저장 완료 사이즈 취득부(806)에 의해 취득된 데이터 사이즈를 포함한 CDS : Browse 리스펀스를 생성한다. 생성된 CDS : Browse 리스펀스는 네트워크 인퍼테이스(805)를 통하여 소스 기기(101)에 송신된다.
소스 기기(101)의 파일 송신 제어부(702)는 수신한 저장 완료 데이터 사이즈에 따라 전송해야 할 파일의 선두 위치를 결정하고, 파일 축적부(705)로부터 파일 데이터를 독출한다.
예를 들어, 파일 사이즈가 1000바이트이고, 싱크 기기(102)로부터 통지된 저장 완료 데이터 사이즈가 400바이트인 경우를 상정한다. 이 경우, 싱크 기기(102)에 저장되어 있는 파일 데이터는 0바이트째부터 399바이트째까지의 파일 데이터이다. 따라서, 파일 송신 제어부(702)는 나머지의 400바이트째부터 999바이트째까지의 파일 데이터를 파일 제어부(703)를 통하여 파일 축적부(705)로부터 독출한다. 이하, 「나머지의 파일 데이터」라고 하는 경우, 전술한 바와 같이 전송 대상의 파일 데이터로부터 싱크 기기(102)에 저장이 완료된 파일 데이터를 제외한, 나머지의 파일 데이터를 가리킨다.
소스 기기(101)는 데이터 범위와 파일 사이즈를 가리키는 [byte-range] 등을 포함한 POST 리퀘스트를 싱크 기기(102)에 송신한다(S1003). 싱크 기기(102)는 POST 리퀘스트에의 응답으로서 “100 Continue" 스테이터스를 소스 기기(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의 통신 시퀀스와 마찬가지로 CDS : CreateObject 리퀘스트 및 리스펀스 통신을 행한다(S501, S502). 이 후, 소스 기기(101)가 POST 리퀘스트를 송신하기 전에 소스 기기(101)에 있어서, 사용자에 의해 파일 전송의 캔슬 지시가 이루어지거나, 또는, 전송 대상의 파일이 삭제되는 등의 사상이 발생했다고 상정한다.
이 경우, 소스 기기(101)는 파일 전송을 중지하기 위해서 POST 리퀘스트로 바꾸어 CDS : DestroyObject 리퀘스트를 싱크 기기(102)에 송신한다(S1103). 싱크 기기(102)는 CDS : DestroyObject를 수신하면 CDS : CreateObject 리퀘스트(S501)에 따라 작성한 object를 삭제한다. 또한, object를 삭제한 취지를 통지하기 위해서, 소스 기기(101)에 CDS : DestroyObject 리스펀스를 응답한다(S1104).
이와 같이, 파일 전송이 개시되기 전에 소스 기기(101)의 사정에 의해 파일 전송이 중지된 경우, 싱크 기기(102)에서는 파일을 저장하기 위해서 작성된 object가 삭제된다. 즉, 싱크 기기(102)에 있어서 쓸데없는 object는 신속하게 삭제된다.
다음에, 소스 기기(101)로부터 싱크 기기(102)로의 파일 데이터의 송신 중에 소스 기기(101)의 사정에 의해 파일 전송이 중지될 때의 각 기기의 동작을 도 12를 이용하여 설명한다.
도 12는 실시의 형태의 파일 전송 시스템에 있어서, 파일 데이터의 송신 중에 소스 기기(101)의 사정에 의해 파일 전송이 중지될 때의 통신 시퀀스의 일례를 나타내는 도면이다.
소스 기기(101) 및 싱크 기기(102)는, 도 5의 통신 시퀀스와 마찬가지로 CDS : CreateObject 리퀘스트 및 리스펀스 통신을 행하다. 이 후, 소스 기기(101)는 POST 리퀘스트를 싱크 기기(102)에 송부한다(S503). 싱크 기기(102)는 POST 리퀘스트의 응답으로서 “100 Continue" 스테이터스를 소스 기기(101)에 송신한다(S504). 소스 기기(101)는 파일 데이터의 싱크 기기(102)로의 송신을 개시한다(S505). 싱크 기기(102)는 수신한 파일 데이터를 파일 축적부(804)에 축적한다. 여기까지의 동작은, 도 5에 나타내는 통신 시퀀스와 동일하다.
여기서, 소스 기기(101)가 POST 리퀘스트를 송신하기 전에, 소스 기기(101)에 있어서 사용자에 의해 파일 전송의 캔슬 지시가 이루어지거나, 또는, 전송 대상의 파일이 삭제되는 등의 사상이 발생했다고 상정한다.
소스 기기(101)는 파일 전송을 중지하기 위해서, TCP의 RST 패킷을 송신한다(S1206). 이것에 의해, 파일 전송에 이용하고 있는 TCP 접속이 절단된다. 소스 기기(101)는 또한, CDS : DestroyObject 리퀘스트를 싱크 기기(102)에 송신한다(S1207). 싱크 기기(102)는 CDS : DestroyObject 리퀘스트에 따라 수신 완료 파일 데이터를 삭제하고, CDS : DestroyObject 리스펀스를 소스 기기(101)에 송신한다(S1208).
이와 같이, 파일 데이터의 송신이 개시된 후에, 소스 기기(101)의 사정에 의해, 파일 전송이 중지된 경우, 싱크 기기(102)에서는 수신하여 저장 완료된 파일 데이터는 삭제된다. 즉, 싱크 기기(102)에 있어서 쓸데없는, 완결되어 있지 않은 파일 데이터는 신속하게 삭제된다.
다음에, 싱크 기기(102)가 POST 리퀘스트를 수신했을 때에, 싱크 기기(102)의 사정에 의해 파일 전송이 중지될 때의 각 기기의 동작을 도 13을 이용하여 설명한다.
도 13은 실시의 형태의 파일 전송 시스템에 있어서, 파일 데이터의 송신이 개시되기 전에 싱크 기기(102)의 사정에 의해 파일 전송이 중지될 때의 통신 시퀀스의 일례를 나타내는 도면이다.
소스 기기(101) 및 싱크 기기(102)는 도 5의 통신 시퀀스와 마찬가지로, CDS : CreateObject 리퀘스트 및 리스펀스 통신을 행한다. 이 후, 소스 기기(101)는 POST 리퀘스트를 싱크 기기(102)에 송신한다(S503). 여기까지의 동작은, 도 5와 동일하다.
여기서, 싱크 기기(102)에 있어서, 소스 기기(101)로부터의 CDS : CreateObject 리퀘스트에 따라 작성된 object가 소실되었다는 등의 이유에 의해 파일 전송을 중지할 필요가 생긴 경우를 상정한다.
이 경우, 싱크 기기(102)는 POST 리퀘스트로의 응답으로서 “404 Not Found" 스테이터스를 소스 기기(101)에 송신한다(S1304). 소스 기기(101)는 “404 Not Found" 에 따라 파일 전송에 따른 처리를 중지한다.
이와 같이, 소스 기기(101)로부터 싱크 기기(102)에 POST 리퀘스트에 의해 파일 사이즈 등이 통지된 후, 또한 파일 데이터의 송신이 개시되기 전에 싱크 기기(102)의 사정에 의해 파일 전송이 중지된 경우, 소스 기기(101)는 싱크 기기(102)로부터의 통지에 의해 파일 전송에 따른 처리를 중지한다. 즉, 소스 기기(101)는 불필요한 처리를 계속하지 않는다.
다음에, 싱크 기기(102)의 사정에 의해 소스 기기(101)로부터 싱크 기기(102)로의 파일 데이터의 송신 중에 파일 전송이 중지될 때의 각 기기의 동작을 도 14를 이용하여 설명한다.
도 14는, 실시의 형태의 파일 전송 시스템에 있어서, 파일 데이터의 송신 중에 싱크 기기의 사정에 의해 파일 전송이 중지될 때의 통신 시퀀스의 일례를 나타 내는 도면이다.
소스 기기(101) 및 싱크 기기(102)는, 도 5와 동일하게 CDS : CreateObject 리퀘스트 및 리스펀스 통신을 행한다. 이 후, 소스 기기(101)는 POST 리퀘스트를 싱크 기기(102)에 송부한다(S503). 싱크 기기(102)는 POST 리퀘스트로의 응답으로서 “100 Continue" 스테이터스를 소스 기기(101)에 송신한다(S504). 소스 기기(101)는 파일 데이터의 싱크 기기(102)로의 송신을 개시한다(S505). 싱크 기기(102)는 수신한 파일 데이터를 파일 축적부(804)에 축적한다. 여기까지의 동작은, 도 5에 나타내는 통신 시퀀스와 동일하다.
여기서, 싱크 기기(102)에 있어서 파일 전송을 중지하는 요인이 발생하고 TCP의 RST 패킷을 송신한다(S1406). 이것에 의해, 파일 전송에 이용하고 있는 TCP 접속이 절단된다. 소스 기기(101)는 TCP 접속의 절단을 검출하면, 다시 POST 리퀘스트를 싱크 기기(102)에 송신한다(S1407). 싱크 기기는 POST 리퀘스트로의 응답으로서 “404 Not Found" 스테이터스를 소스 기기(101)로 송신한다(S1408). 소스 기기(101)는 “404 Not Found"에 따라 파일 전송에 따른 처리를 중지한다.
이와 같이, 소스 기기(101)로부터 싱크 기기(102)로의 파일 데이터의 송신이 개시된 후에, 싱크 기기(102)의 사정에 의해 파일 전송이 중지된 경우, 소스 기기(101)는 싱크 기기(102)로부터의 통지에 의해 파일 전송에 따른 처리를 중지한다. 즉, 소스 기기(101)는 불필요한 처리를 계속하지 않는다.
이와 같이, 본 발명의 실시의 형태의 소스 기기(101) 및 싱크 기기(102)는 파일 전송을 중지하는 경우, 그 중지가 어느 기기의 사정에 의하는 것이라도 쓸데 없는 리소스의 소비 및 쓸데없는 처리가 발생하지 않도록 파일 전송의 중지를 위한 처리가 행해진다.
또한, 전술의 실시의 형태에 있어서 푸시형의 플로우 제어를 행하는 파일 전송 프로토콜로서 HTTP의 POST 메소드에 의해 파일 전송을 행하는 경우를 설명하였다. 그러나, POST 메소드 이외라도 좋고, 예를 들어 PUT 메소드라도 상기 효과가 없어지는 것은 아니다.
또한, 소스 기기(101)는 파일 전송이 중단된 경우에 싱크 기기(102)가 참조하는 파라미터로서 도 6에 나타내는 파라미터를 HTTP 리퀘스트 패킷에 부가하여 송부한다고 하였다.
이 파라미터를 부여하는 구체적인 방법으로서 독자적으로 정의한 헤더를 POST 리퀘스트의 메시지 헤더로서 포함시키는 방법이 있다.
예를 들어, POST 리퀘스트에 독자적으로 정의한 헤더인 UploadTransportInfo.dlna.org:[byte-range]를 부여하고, HTTP의 Entity Body부에 포함되는 데이터의 범위 및 총 사이즈를 저장한다. 또한, [lifetime] 등의 필요한 정보를 포함시킨다. 싱크 기기(102)는 소스 기기(101)로부터 송신된 POST 리퀘스트의 메시지 헤더로부터 이러한 정보를 취득할 수 있다.
또한, 전술의 실시의 형태에 있어서는 POST 리퀘스트에 [byte-range], [restart-time], 및 [lifetime]의 3개의 파라미터를 부가하여 송부하는 구성을 설명하였다. 그러나 [restart-time]만을 부가해도 좋다.
또한, UploadTransportInfo. dlna. org 이외의 HTTP에서 당연히 사용되는 그 밖의 헤더에 대해서는 본 발명의 특징에 관계하지 않기 때문에 도시 및 설명을 생략한다.
또한, 전술의 실시의 형태에 있어서, 소스 기기(101)는 파일을 싱크 기기(102)에 전송하는 경우, 일괄하여 전송한다고 하였다. 그러나, 소스 기기(101)는 파일을 분할하고, 분할 단위마다 싱크 기기(102)에 송부할 수도 있다. 싱크 기기(102)가 1회의 POST 리퀘스트로 수신 가능한 데이터 사이즈에 제한이 있는 경우 등, 소스 기기(101)가 분할 단위마다 파일 데이터를 송신하는 방법은 유효하다.
도 15는 소스 기기(101)가 싱크 기기(102)에 파일을 분할하여 전송하는 파일 전송 시스템의 통신 시퀀스를 나타내는 도면이다. 도 15를 이용하여, 소스 기기(101)가 파일을 분할하여 전송할 때의 각 기기의 동작을 설명한다. 또한, 소스 기기(101)는 송신하는 파일 데이터의 범위 등을 싱크 기기(102)에 통지하기 위해서, 전술의, 독자적으로 정의한 헤더 UploadTransportInfo. dlna. org를 사용한다고 상정한다.
소스 기기(101)는 파일의 전송에 앞서, 싱크 기기(102)에 대해 CDS : CreateObject 리퀘스트를 송신한다(S1503). 싱크 기기(102)는 CDS : CreateObject 리퀘스트에 따라 object를 작성하고, CDS : CreateObject 리스펀스를 소스 기기(101)에 송신한다(S1504).
소스 기기(101)는 파일을 분할 전송하는 사이즈를 결정한다. 분할 전송의 사이즈는 전송의 중단, 재개의 빈도, 중단 시에 쓸모없게 되는 전송 사이즈, 분할에 의한 오버헤드 등을 감안하여 임의로 결정할 수 있다. 여기에서는 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)는 상기 POST 리퀘스트로의 응답으로서 “100 Continue"를 소스 기기(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)와 싱크 기기(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바이트째부터 499Byte째의 파일 데이터에 어펜드하여 파일 축적부(804)에 저장한다.
이와 같이 하여, POST 메소드를 이용하여 파일을 송신하는 푸시형의 플로우 제어에서도 파일을 분할하여 송신을 행하는 것이 가능해진다.
또한, 이와 같이 파일이 분할되어 전송되는 경우에 있어서도, 파일 전송이 중단된 경우, 소스 기기(101)는, 도 10의 통신 시퀀스에 나타내는 바와 같이, 싱크 기기(102)에 저장 완료 데이터 사이즈를 문의함으로써 송신해야 할 나머지의 파일 데이터만을 송신한다. 예를 들어, 도 15의 통신 시퀀스에 있어서, 최초의 500바이트의 송신 중에 파일 전송이 중단되고, 그때까지 싱크 기기(102)에 200바이트가 저장되어 있던 경우를 상정한다. 이 경우, 소스 기기(101)는 싱크 기기(102)에 문의함으로서 저장 완료 데이터 사이즈가 “200"인 것을 취득한다. 그 후, 소스 기기 (101)는 나머지의 300바이트를 싱크 기기(102)에 송신한다.
또, 전송로 상의 에러 등에 의해, 저장 완료 데이터 사이즈를 취득할 수 없는 경우, 송신 도중이던 파일 데이터를 재송신한다. 예를 들어, 도 15의 통신 시퀀스에 있어서, 후의 500바이트의 송신 중에 파일 전송이 중단되고, 소스 기기(101)가 싱크 기기(102)로부터 저장 완료 데이터 사이즈를 취득할 수 없는 경우, 후의 500바이트를 최초부터 송신한다.
즉, 최초의 500바이트는 싱크 기기(102)로부터의 “201 Created"에 의해 싱크 기기(102)에 저장이 완료된 상태인 것이 확인되어 있기 때문에, 소스 기기(101)는 후의 500바이트만을 재송신하면 좋다.
이와 같이, 전송 대상의 파일을 분할하여 송신하는 방법은, 전술한 바와 같이, 싱크 기기(102)가 1회의 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)에 통지하기 위한 헤더의 이름은 UploadTansportInfo. dlna. org 이외의 헤더명이라도 상관없다. 또한 본 실시의 형태에서는 Digital Living Network Alliance(DLNA)로 정의하는 헤더 명명 수법에 따라 “.dlna. org"를 접미어로서 이용하고, 다른 임의의 헤더명과의 우연의 일치를 회피하고 있다. 그러나, 이것에 한정하지 않고, 예를 들어 HTTP의 독자 확장 헤더인 것을 나타내는 접두어 “X-"를 이용하여 “X-UploadTransportInfo" 등이라 정의해도 상관없다.
또한, 도 15에 나타내는 통신 시퀀스에 있어서는 1000바이트의 파일을 500바이트씩 2분할했지만, 당연하게 그 분할 단위로 한정되는 것은 아니고, 임의의 분할이 가능하다.
또한, 소스 기기(101)로부터 싱크 기기(102)로 파일을 분할하여 전송하는 파일 전송 시스템에 있어서도, 소스 기기(101) 또는 싱크 기기(102)의 사정에 의해 파일 전송이 중단 또는 중지되는 경우가 있다. 따라서, 이하에, 분할된 1개의 단편인 파일 데이터의 송신 전에 파일 전송이 중단되는 경우의 통신 시퀀스 및 각 기기의 동작을 도 16 및 도 17을 이용하여 설명한다. 또한, 파일 전송이 중지되는 경우의 통신 시퀀스 및 각 기기의 동작을 도 18을 이용하여 설명한다.
도 16은 파일을 분할하여 전송하는 파일 전송 시스템에 있어서, 분할 후의 하나의 파일 데이터의 송신 전에 소스 기기(101)의 사정에 의해 파일 전송이 중단되는 경우의 통신 시퀀스를 나타내는 도면이다.
도 16의 통신 시퀀스에 있어서 CDS : CreateObject 리퀘스트를 송신(S1503)하고 나서, 전송 대상의 파일을 분할(S1505)하기 까지는, 도 15를 이용하여 설명한 대로이며 설명을 생략한다.
여기서, 소스 기기(101)에 있어서, 사용자의 캔슬 지시 등에 의해 파일의 전송을 중단하는 경우를 상정한다. 이 경우, 소스 기기(101)는 POST 리퀘스트의 메시지 헤더에 처리의 보류를 나타내는 [suspend]를 포함한 UploadTransportInfo. dlna. org 헤더를 저장하고 싱크 기기(102)에 송신한다(S1606).
소스 기기(101)는 이 UploadTransportInfo. dlna. org : 헤더에 포함되는 키 워드인 [suspend]를 나타내는 필드값에 의해서 싱크 기기(102)에 명시적으로 중단을 통지할 수 있다. 또한, 이 경우, POST 리퀘스트의 Entity Body는 송신되지 않는다. 또한, 도 15의 통신 시퀀스와 동일하게, [lifetime]도 상기 헤더에 포함되고 예를 들어, 초단위로 “1800", 즉 30분이 지정된다.
싱크 기기(102)는 “200 OK"를 송신하고(S1607), 중단을 양해한 것을 나타낸다.
본 순서에 의하면 단순히 TCP 절단 등에 의해 중단한 경우와 비교하면, 싱크 기기(102)에서 불필요한 전송 프로세스를 슬립시키는 등, 적절한 대처를 행할 수 있기 때문에, 쓸데없는 처리의 발생을 억제하는 효과가 있다.
또한, 전송의 재개는 UploadTransportInfo. dlna. org : 헤더의 [lifetime]에서 지정한 30분 이내에 소스 기기(101)가 임의로 행할 수 있다. 또한, 30분 이내에 소스 기기(101)가 전송의 재개를 행할 수 없는 경우, 다시 UploadTransportInfo. dlna. org : suspend를 송신함으로써 전송 재개 기간의 재연장을 행하는 것도 가능하다.
다음에, 파일을 분할하여 전송하는 파일 전송 시스템에 있어서, 싱크 기기(102)가 POST 리퀘스트를 수신했을 때에 싱크 기기(102)의 사정에 의해 파일 전송이 중단되는 경우의 각 기기의 동작을 도 17을 이용하여 설명한다.
도 17은, 파일을 분할하여 전송하는 파일 전송 시스템에 있어서, 싱크 기기(102)가 POST 리퀘스트를 수신했을 때에 싱크 기기(102)의 사정에 의해 파일 전송이 중단되는 경우의 통신 시퀀스를 나타내는 도면이다.
도 17의 통신 시퀀스에 있어서, 소스 기기(101)가 CDS : CreateObject 리퀘스트를 송신(S1503)하고 나서, 송신하는 파일 데이터의 범위 등을 POST 리퀘스트에 의해 통지하기(S1506)까지는, 도 15를 이용하여 설명한 대로이며 설명을 생략한다.
여기서, 상기 POST 리퀘스트(S1506)를 수신한 싱크 기기(102)가 파일 축적부(804)로부터 데이터를 독출 중이라는 등의 이유에 의해 파일 전송을 행할 수 있는 상태가 아닌 경우를 상정한다.
이 경우, 싱크 기기(102)는 POST 리퀘스트로의 응답으로서 “503 Service Unavailable"을 소스 기기(101)로 송신하고(S1707), 파일 전송을 행할 수 있는 상태가 아닌 것을 소스 기기(101)에 통지한다.
또한, 싱크 기기(102)는 “503 Service Unavailable"를 포함한 리스펀스 메시지에 Retry-After : 헤더를 저장함으로써 전송을 개시할 수 있는 예상의 시간을 통지한다. 즉, Retry-After : 헤더는, 파일 전송을 재개하는 시기를 나타내는 정보이다. 또한, 독자적으로 정의한 헤더인 UploadTransportExpireInfo. dlna. org: 헤더를 저장함으로써 재개가 가능한 기간을 통지한다.
UploadTransportExpireInfo. dlna. org : 헤더는, 파일 전송을 받아들이는 종기를 나타내기 위한 헤더이다. 도 17의 통신 시퀀스에서는 초 단위로 “1800", 즉 30분이 지정되어 있다. 이 경우, 싱크 기기(102)가 상기 리스펀스 메시지를 송신(S1707)하고 나서 30분 후까지는 파일 전송을 받아들이는 것을 나타낸다. 구체적으로는, 30분이 경과하면 소스 기기(101)로부터의 CDS : CreateObject 리퀘스트(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) 내 및 전송로 상에서의 리소스의 쓸데없는 사용을 막을 수 있다.
다음에, 파일을 분할하여 전송하는 파일 전송 시스템에 있어서, 파일 전송이 중지되는 경우의 일례로서 싱크 기기(102)의 사정에 의해 파일 전송이 중지되는 경우의 통신 시퀀스 및 각 기기의 동작을 도 18을 이용하여 설명한다.
도 18은, 파일을 분할하여 전송하는 파일 전송 시스템에 있어서, 싱크 기기(102)의 사정에 의해 파일 전송이 중지되는 경우의 통신 시퀀스를 나타내는 도면이다.
도 18의 통신 시퀀스에 있어서, 소스 기기(101)가 CDS : CreateObject 리퀘스트를 송신(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의 CDS : DestroyObject를 발행하여 싱크 기기(102)로부터 명시적으로 오브젝트와 그에 따른 URI를 삭제하는 방법 등이 있다.
이상 UPnP-AV의 오브젝트 단위로 파일 전송을 관리하는 예로 설명했지만, 이것에 한정하지 않고, 단순히 소정의 URI에 대해서 파일 송신을 행하는 경우에도 적용 가능하다.
이와 같이, 파일을 분할하여 전송하는 파일 전송 시스템이라도, 파일 전송이 중단 또는 중지된 경우에는, 소스 기기(101) 또는 싱크 기기(102)의 중단 또는 중지를 상대 기기에 통지할 수 있다. 이것에 의해, 중단 또는 중지가 통지된 기기는 쓸데없이 되는 파일 전송을 위한 처리를 계속하지 않는다.
또한, HTTP의 POST 메소드에 의해 파일을 송신하는 경우를 설명했지만, 이것에 한정하지 않고, PUT 메소드, 나아가서는 동일한 핸드 쉐이크 시퀀스가 적용 가능한 HTTP 이외의 파일 전송 프로토콜에도 적용이 가능하다.
또한, 도 16~도 18에서는 분할 후의 파일 데이터가 1회도 송신되지 않고 파일 전송이 중단 또는 중지되는 경우의 통신 시퀀스를 나타내고 있다. 그러나, 도 16~도 18을 이용하여 설명한 파일 전송의 중단 또는 중지 시의 각 기기의 동작은, 1회 이상 파일 데이터가 송신된 후, 또한 다음의 파일 데이터가 송신하기 전에 중단 또는 중지되는 경우에서도 동일하다.
본 발명의 송신 기기, 수신 기기 및 파일 전송 시스템은 네트워크에 접속되 는 임의의 기기 사이에서 파일을 전송하는 파일 전송 시스템에 있어서 유용하다. 특히 파일의 사이즈가 크고, 전송을 중단하여 재개할 때에 전송을 처음부터 다시 하면 낭비가 많은 경우에 효과를 발휘한다.

Claims (15)

  1. 네트워크를 통하여, 파일을 송신하는 송신 기기로부터 상기 파일을 수신하는 수신 기기로의 파일 전송을 행하는 파일 전송 시스템으로서,
    상기 수신 기기는,
    상기 송신 기기로부터 수신하는, 상기 파일을 구성하는 파일 데이터를 저장하는 저장 수단과,
    상기 저장 수단에 저장이 완료된 파일 데이터의 사이즈인 저장 완료 사이즈를 취득하는 저장 완료 사이즈 취득 수단과,
    상기 송신 기기로부터 상기 저장 완료 사이즈가 문의되면, 상기 저장 완료 사이즈 취득 수단에 의해 취득된 상기 저장 완료 사이즈를 상기 송신 기기에 송신하는 수신 제어 수단을 구비하고,
    상기 송신 기기는,
    파일 데이터를 상기 수신 기기에 송신하는 송신 수단과,
    상기 파일 전송의 중단을 검출하는 검출 수단과,
    상기 검출 수단에 의해 상기 파일 전송의 중단이 검출된 후에, 상기 수신 기기에 상기 저장 완료 데이터 사이즈를 문의하는 문의 수단과,
    상기 문의 수단에 의한 문의에 따라 상기 수신 기기가 응답한 저장 완료 데이터 사이즈에 의거하여, 상기 파일을 구성하는 나머지의 파일 데이터를 상기 송신 수단에 송신시키는 송신 제어 수단을 구비하는 파일 전송 시스템.
  2. 청구항 1에 있어서, 상기 송신 수단은 Hyper Text Transfer Protocol(HTTP)의 POST 메소드 또는 PUT 메소드를 사용하여 상기 파일을 상기 수신 기기에 송신하는 파일 전송 시스템.
  3. 청구항 1에 있어서, 상기 송신 제어 수단은 또한, 상기 송신 수단이 파일 데이터를 송신하기 전에 상기 파일 데이터의 상기 파일에서의 범위인 데이터 범위를 상기 수신 기기에 통지하고,
    상기 수신 기기는 또한 상기 데이터 범위에 의거하여 상기 저장 수단에 저장되어 있는 파일 데이터와, 상기 데이터 범위가 통지된 후에 수신한 파일 데이터를 결합하는 파일 제어 수단을 구비하는 파일 전송 시스템.
  4. 청구항 3에 있어서, 상기 송신 제어 수단은 상기 데이터 범위와 함께 상기 파일의 총 사이즈를 상기 수신 기기에 통지하는 파일 전송 시스템.
  5. 청구항 4에 있어서, 상기 송신 제어 수단은 또한, 상기 파일을 소정의 사이즈의 파일 데이터로 분할하고,
    상기 송신 수단은 상기 송신 제어 수단에 의해 분할된 파일 데이터를 상기 수신 기기에 송신하는 파일 전송 시스템.
  6. 청구항 1에 있어서, 상기 수신 제어 수단은 또한, 파일 전송의 중단을 요구하는 중단 요구를 상기 송신 기기에 송신하고,
    상기 중단 요구는 상기 수신 기기가 상기 파일 전송을 재개하는 시기(始期)를 나타내는 시기 정보와, 상기 수신 기기가 상기 파일 전송을 받아들이는 종기를 나타내는 기간 정보를 포함하고,
    상기 검출 수단은 상기 중단 요구를 수신함으로써 상기 파일 전송의 중단을 검출하고,
    상기 송신 제어 수단은 상기 시기부터 상기 허가 기간의 사이에 상기 나머지의 파일 데이터를 상기 송신 수단에 송신시키는 파일 전송 시스템.
  7. 청구항 1에 있어서, 상기 송신 제어 수단은 또한, 상기 송신 수단이 파일 데이터를 송신하기 전에 상기 파일 데이터의 상기 수신 기기에서의 유지 기간을 상기 수신 기기에 통지하고,
    상기 수신 제어 수단은, 또한 상기 파일 데이터가 상기 저장 수단에 저장되고 또한 상기 파일 데이터의 유지 기간이 경과하기 전에 상기 파일을 구성하는 모든 파일 데이터를 상기 송신 기기로부터 수신하지 않는 경우, 상기 저장 수단에 저장되어 있는 상기 파일 데이터를 삭제하는 파일 전송 시스템.
  8. 청구항 1에 있어서, 상기 송신 기기와 상기 수신 기기와는 Transmission Control Protocol(TCP) 접속에 의해 파일 전송을 행하고,
    상기 검출 수단은 상기 송신 제어 수단이 파일 데이터의 송신 중에 상기 TCP 접속을 절단한 것을 검출함으로써 상기 파일 전송의 중단을 검출하고,
    상기 송신 제어 수단은, 또한 상기 TCP 접속의 절단 후에 파일 데이터의 상기 수신 기기에서의 유지 기간을 상기 수신 기기에 통지하고,
    상기 수신 제어 수단은, 또한 상기 송신 기기로부터 통지된 상기 유지 기간이 경과하기 전에, 상기 파일을 구성하는 모든 파일 데이터를 상기 송신 기기로부터 수신하지 않은 경우, 상기 저장 수단에 저장되어 있는 파일 데이터를 삭제하는 파일 전송 시스템.
  9. 청구항 1에 있어서, 상기 송신 기기와 상기 수신 기기는 Transmission Control Protocol(TCP) 접속에 의해 파일 전송을 행하고,
    상기 송신 제어 수단은, 또한 상기 TCP 접속이 상기 수신 기기에 의해 절단되면, 파일 전송의 허가를 얻기 위한 전송 요구를 상기 수신 기기에 송신하고,
    상기 수신 제어 수단은, 또한 상기 전송 요구에의 응답으로서 상기 파일 전송의 중단을 요구하는 중단 요구를 상기 송신 기기에 송신하며,
    상기 검출 수단은 상기 중단 요구를 수신함으로써 상기 파일 전송의 중단을 검출하는 파일 전송 시스템.
  10. 네트워크를 통하여, 수신 기기로 파일을 전송하는 파일 전송을 행하는 송신 기기로서,
    상기 파일을 구성하는 파일 데이터를 상기 수신 기기에 송신하는 송신 수단과,
    상기 파일 전송의 중단을 검출하는 검출 수단과,
    상기 검출 수단에 의해 상기 파일 전송의 중단이 검출된 후에 상기 수신 기기에 저장되어 있는 파일 데이터의 사이즈인 저장 완료 데이터 사이즈를 문의하는 문의 수단과,
    상기 문의 수단에 의한 문의에 따라 상기 수신 기기가 응답한 저장 완료 데이터 사이즈에 의거하여 상기 파일을 구성하는 나머지의 파일 데이터를 상기 송신 수단에 송신시키는 송신 제어 수단을 구비하는 송신 기기.
  11. 네트워크를 통하여, 송신 기기로부터 송신되는 파일을 수신하는 수신 기기로서,
    상기 송신 기기로부터 수신하는, 상기 파일을 구성하는 파일 데이터를 저장하는 저장 수단과,
    상기 저장 수단에 저장이 완료된 파일 데이터의 사이즈인 저장 완료 사이즈를 취득하는 저장 완료 사이즈 취득 수단과,
    상기 송신 기기로부터 상기 저장 완료 사이즈가 문의되면, 상기 저장 완료 사이즈 취득 수단에 의해 취득된 상기 저장 완료 사이즈를 상기 송신 기기에 송신하는 수신 제어 수단을 구비하는 수신 기기.
  12. 네트워크를 통하여, 수신 기기에 파일을 전송하는 파일 전송을 행하기 위한 송신 방법으로서,
    상기 파일을 구성하는 파일 데이터를 상기 수신 기기에 송신하는 송신 단계와,
    상기 파일 전송의 중단을 검출하는 검출 단계와,
    상기 검출 수단에 의해 상기 파일 전송의 중단이 검출된 후에, 상기 수신 기기에 저장되어 있는 파일 데이터의 사이즈인 저장 완료 데이터 사이즈를 문의하는 문의 단계와,
    상기 문의 수단에 의한 문의에 따라 상기 수신 기기가 응답한 저장 완료 데이터 사이즈에 의거하여 상기 파일을 구성하는 나머지의 파일 데이터를 상기 수신 기기에 송신하는 송신 제어 단계를 포함한 송신 방법.
  13. 네트워크를 통하여, 송신 기기로부터 송신되는 파일을 수신하기 위한 수신 방법으로서,
    상기 송신 기기로부터 수신하는, 상기 파일을 구성하는 파일 데이터를 저장 수단에 저장하는 저장 단계와,
    상기 저장 수단에 저장이 완료된 파일 데이터의 사이즈인 저장 완료 사이즈를 취득하는 저장 완료 사이즈 취득 단계와,
    상기 송신 기기로부터 상기 저장 완료 사이즈가 문의되면, 상기 저장 완료 사이즈 취득 수단에 의해 취득된 상기 저장 완료 사이즈를 상기 송신 기기에 송신 하는 수신 제어 단계를 포함하는 수신 방법.
  14. 네트워크를 통하여, 수신 기기에 파일을 전송하는 파일 전송을 행하기 위한 프로그램으로서,
    상기 파일을 구성하는 파일 데이터를 상기 수신 기기에 송신하는 송신 단계와,
    상기 파일 전송의 중단을 검출하는 검출 단계와,
    상기 검출 수단에 의해 상기 파일 전송의 중단이 검출된 후에 상기 수신 기기에 저장되어 있는 파일 데이터의 사이즈인 저장 완료 데이터 사이즈를 문의하는 문의 단계와,
    상기 문의 수단에 의한 문의에 따라 상기 수신 기기가 응답한 저장 완료 데이터 사이즈에 의거하여 상기 파일을 구성하는 나머지의 파일 데이터를 상기 수신 기기에 송신하는 송신 제어 단계를 컴퓨터에 실행시키기 위한 프로그램.
  15. 네트워크를 통하여, 송신 기기로부터 송신되는 파일을 수신하기 위한 프로그램으로서,
    상기 송신 기기로부터 수신하는, 상기 파일을 구성하는 파일 데이터를 저장 수단에 저장하는 저장 단계와,
    상기 저장 수단에 저장이 완료된 파일 데이터의 사이즈인 저장 완료 사이즈를 취득하는 저장 완료 사이즈 취득 단계와,
    상기 송신 기기로부터 상기 저장 완료 사이즈가 문의되면, 상기 저장 완료 사이즈 취득 수단에 의해 취득된 상기 저장 완료 사이즈를 상기 송신 기기에 송신하는 수신 제어 단계를 컴퓨터에 실행시키기 위한 프로그램.
KR1020077008171A 2004-10-26 2005-10-19 송신 기기, 수신 기기 및 파일 전송 시스템 KR20070083649A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPJP-P-2004-00310316 2004-10-26
JP2004310316 2004-10-26

Publications (1)

Publication Number Publication Date
KR20070083649A true KR20070083649A (ko) 2007-08-24

Family

ID=36227688

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020077008171A KR20070083649A (ko) 2004-10-26 2005-10-19 송신 기기, 수신 기기 및 파일 전송 시스템

Country Status (6)

Country Link
US (1) US20080091830A1 (ko)
EP (1) EP1806877A1 (ko)
JP (1) JPWO2006046446A1 (ko)
KR (1) KR20070083649A (ko)
CN (1) CN101048989A (ko)
WO (1) WO2006046446A1 (ko)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4754982B2 (ja) 2006-02-13 2011-08-24 パナソニック株式会社 ファイル転送システム
US20070260747A1 (en) * 2006-03-10 2007-11-08 Jan Samzelius Protecting Electronic File Transfer from Unauthorized Access or Copying
JP4530420B2 (ja) * 2006-05-15 2010-08-25 日本電信電話株式会社 ファイル転送システム、ファイル転送プログラムおよびファイル転送方法
EP1959642B1 (en) 2007-01-30 2015-05-13 Sony Corporation Content transmission system, content sending apparatus and method, content reception apparatus and method, program, and recording media
JP5233175B2 (ja) * 2007-06-08 2013-07-10 ソニー株式会社 コンテンツ配信システム、配信サーバ、端末及びコンテンツ配信方法
CN101389017B (zh) * 2007-09-14 2011-11-30 中兴通讯股份有限公司 一种移动流媒体直播业务中保存媒体文件的方法
US8910240B1 (en) * 2007-11-12 2014-12-09 Google Inc. Mapping content using uniform resource identifiers
CN101656991B (zh) 2008-08-18 2013-03-20 华为技术有限公司 消息发送过程中切换终端的方法及设备
JP5231942B2 (ja) * 2008-10-29 2013-07-10 キヤノン株式会社 画像処理装置およびその制御方法、並びにシステム、プログラム
JP5513068B2 (ja) * 2009-10-19 2014-06-04 キヤノン株式会社 情報処理装置、及びその制御方法
US9104517B2 (en) 2010-01-27 2015-08-11 Code Systems Corporation System for downloading and executing a virtual application
US9229748B2 (en) 2010-01-29 2016-01-05 Code Systems Corporation Method and system for improving startup performance and interoperability of a virtual application
CN101827404B (zh) * 2010-04-09 2012-05-23 无锡泛联物联网科技股份有限公司 无线传感网中多移动sink接入控制方法
US8763009B2 (en) 2010-04-17 2014-06-24 Code Systems Corporation Method of hosting a first application in a second application
CN102316129B (zh) * 2010-07-01 2013-08-21 江苏大学 一种嵌入式设备与远程数据库进行数据交换的方法
US8782106B2 (en) * 2010-07-02 2014-07-15 Code Systems Corporation Method and system for managing execution of virtual applications
CN102456052B (zh) * 2010-11-02 2013-04-10 江苏大学 一种嵌入式设备与数据库数据同步方法
CN102801754A (zh) * 2011-05-24 2012-11-28 英业达集团(天津)电子技术有限公司 一种断点续传的方法及系统
JP5319753B2 (ja) * 2011-10-31 2013-10-16 株式会社東芝 コンテンツ送信装置及びコンテンツ受信装置
JP5947540B2 (ja) * 2011-11-07 2016-07-06 株式会社スクウェア・エニックス・ホールディングス 管理装置、管理装置の制御方法
KR101332170B1 (ko) * 2011-11-09 2013-11-25 에스케이텔레콤 주식회사 Ｈｔｔｐ를 이용한 파일 전송 시스템, 그의 메시지 서버, 단말 및 방법
KR20140098411A (ko) * 2013-01-31 2014-08-08 네이버 주식회사 모바일 단말에서 대용량 첨부 메일을 발송하는 방법 및 시스템
CN104580285A (zh) * 2013-10-15 2015-04-29 镇江雅迅软件有限责任公司 一种基于http协议断点续传文件的实现方法
CN103677810B (zh) * 2013-11-21 2018-06-01 金蝶软件（中国）有限公司 业务移动应用系统及其应用方法
US9934475B2 (en) * 2015-05-13 2018-04-03 Bank Of America Corporation Managing enterprise data movement using a heuristic data movement detection engine
JP2017163451A (ja) * 2016-03-11 2017-09-14 株式会社リコー 通信システム及び通信方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3605242B2 (ja) * 1996-11-12 2004-12-22 富士通株式会社 データ送信装置、データ受信装置、およびデータファイル記憶媒体
US5832232A (en) * 1996-12-16 1998-11-03 Intel Corporation Method and apparatus for providing user-based flow control in a network system
JPH11242640A (ja) * 1998-02-25 1999-09-07 Kdd Corp ファイル転送方法
US6460087B1 (en) * 1998-02-25 2002-10-01 Kdd Corporation Method of transferring file
JP3673473B2 (ja) * 1998-10-05 2005-07-20 松下電器産業株式会社 データ転送方法およびデータ転送システム
JP2001007975A (ja) * 1999-06-18 2001-01-12 Ricoh Co Ltd 画像通信装置およびその制御方法
JP3645537B2 (ja) * 2002-06-03 2005-05-11 蝶理情報システム株式会社 通信制御システム
JP2004236005A (ja) * 2003-01-30 2004-08-19 Murata Mach Ltd 画像通信装置
KR100605880B1 (ko) * 2004-02-25 2006-08-01 삼성전자주식회사 클라이언트와 서버 간의 메시지 파일 송신 방법

Also Published As

Publication number Publication date
JPWO2006046446A1 (ja) 2008-05-22
EP1806877A1 (en) 2007-07-11
CN101048989A (zh) 2007-10-03
US20080091830A1 (en) 2008-04-17
WO2006046446A1 (ja) 2006-05-04

Similar Documents

Publication Publication Date Title
KR20070083649A (ko) 송신 기기, 수신 기기 및 파일 전송 시스템
JPWO2006046445A1 (ja) ファイル転送システム、送信機器及び受信装置
EP1840750B1 (en) Av server
US7698392B2 (en) Method and system for establishing a user-friendly data transfer service application executing within a heterogeneous distributed service application execution environment
US20080209036A1 (en) Information processing control apparatus, method of delivering information through network, and program for it
KR101037941B1 (ko) 홈 네트워크 장치를 이용한 홈 간 컨텐츠 공유 장치 및방법
US8266298B2 (en) Storage medium, uniqueness assurance realizing method, session management method and uniqueness assurance information setting management device
WO2014112207A1 (ja) 監視システムおよび監視カメラ
US20090265443A1 (en) Network apparatus, content distribution method and computer program product
EP2168311B1 (en) Upnp control point and method of handling upnp control request
US7818438B2 (en) Control apparatus and control method
JP5448489B2 (ja) 情報処理装置及びその制御方法、情報処理システム、及び、プログラム
JP4886712B2 (ja) アクセス制御システム、アクセス制御方法、アクセス制御装置およびアクセス制御プログラム
JP2002312225A (ja) データ管理装置及びデータ管理方法
JP2007312227A (ja) 情報処理システム及びその制御方法、並びに該制御方法を実行するプログラム
JP2006025291A (ja) 省電力制御方法
US8095651B2 (en) Delayable events in home network
JP6101312B2 (ja) 通信装置及びその制御方法及びプログラム
JP5775562B2 (ja) 情報処理装置及びその制御方法、及び、プログラム
JP2010056924A (ja) コンテンツ受信装置およびコンテンツ受信方法
KR100674754B1 (ko) 홈 네트워크에서 데이터 스트림의 트래픽 제어 방법
JP2006185384A (ja) コンテンツサーバ、コンテンツ受信装置、プログラム及び記録媒体
JP2013132001A (ja) コンテンツ送信装置、コンテンツ送信方法、コンテンツ送信装置の制御プログラム、コンテンツ受信装置、コンテンツ受信方法、コンテンツ受信装置の制御プログラム
JP2010232875A (ja) 再生装置
JP2008226039A (ja) インターネットストレージネームサービス（ｉＳＮＳ）方法及びサーバ及びプログラム

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid