KR20120085342A - 멀티플렉싱된 데이터 스트림 프로토콜 - Google Patents
멀티플렉싱된 데이터 스트림 프로토콜 Download PDFInfo
- Publication number
- KR20120085342A KR20120085342A KR1020127016841A KR20127016841A KR20120085342A KR 20120085342 A KR20120085342 A KR 20120085342A KR 1020127016841 A KR1020127016841 A KR 1020127016841A KR 20127016841 A KR20127016841 A KR 20127016841A KR 20120085342 A KR20120085342 A KR 20120085342A
- Authority
- KR
- South Korea
- Prior art keywords
- interface
- data
- tcp
- packet
- headers
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
- Time-Division Multiplex Systems (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
멀티플렉싱된 데이터 스트림 프로토콜에 대해 본 명세서에 기술되어 있다. 일 실시예에서, 멀티플렉싱된 데이터 스트림 프로토콜을 제공하는 방법은 헤더를 갖는 패킷을 제공하기 위해 데이터 스트림을 패킷화하는 단계 및 IP(Internet Protocol) 주소를 사용하도록 설계되어 있지 않은 인터페이스를 통해 상기 패킷을 전송하는 단계를 포함한다. 상기 헤더는 흐름 제어 및 시퀀스를 위한 데이터를 포함하고 애플리케이션에 대한 포트와 연관되어 있으며, 상기 헤더는 다수의 애플리케이션이 상기 인터페이스를 통해 임의의 변경가능한 수의 다중 동시 세션(multiple concurrent session)을 유지할 수 있게 해준다. 헤더는 TCP(Transmission Control Protocol)-유사 헤더일 수 있고, IP-유사 헤더(IP-like header)를 포함하지 않을 수 있다. 시스템, 컴퓨터 판독가능 매체, 소프트웨어 아키텍처 및 기타 방법들에 대해서도 기술되어 있다.
Description
본 출원은 2007년 6월 22일자로 출원된, 발명의 명칭이 "Multiplexed Data Stream Protocol(멀티플렉싱된 데이터 스트림 프로토콜)"인 미국 가특허 출원 제60/945,904호의 출원일을 기초로 우선권을 주장한다. 이 가특허 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다. 본 출원은 2007년 6월 8일자로 출원된, 발명의 명칭이 "Techniques for Communicating Data Between a Host Device and An Intermittently Attached Mobile Device(호스트 장치와 간헐적으로 접속되는 장치 간의 데이터 통신 기법)"인 미국 특허 출원 제11/760,686호의 일부 계속 출원이다.
본 발명의 실시예들은 장치들 간의 데이터 통신에 관한 것이다. 보다 상세하게는, 본 발명의 실시예들은 하나 이상의 호스트 전자 장치들과, 간헐적으로 연결되는 클라이언트 장치 간의 효율적인 데이터 통신 기법에 관한 것이다.
모바일 장치(예를 들어, 이동 전화, 디지털 음악 플레이어, PDA)가 점점 보편화됨에 따라, 하나의 모바일 장치에 의해 제공되는 기능이 증가하였다. 이러한 기능의 증가는, 예를 들어, 모바일 장치 또는 호스트 장치 중 어느 하나에서 행해진 데이터의 변경을 미러링하기 위해 동기화 서비스를 제공하기 위한 동기를 일으키는 것과 연관되어 있다. 게다가, 2개의 장치 간에 하나 이상의 파일을 비롯한 데이터를 교환할 필요가 있을 수 있다. 예를 들어, 2개의 장치 간에 음악 또는 비디오 파일이 교환될 수 있다.
모바일 장치와 호스트 장치 간에 데이터를 동기화시키고 및/또는 데이터를 교환하는 다양한 기법들이 개발되었다. 현재의 기법들은 통상적으로 필요 이상으로 많은 오버헤드를 요구할 수 있는 전기능 파일 시스템(full-function file system) 기반 기법이거나 제한된 기능을 제공하는 특수-목적 기법일 수 있다. 이들 기법은 USB 등의 기존의 인터페이스를 사용한다.
각각의 장치 상의 USB 인터페이스와 같은, 장치들 간의 기존의 인터페이스는 장치가 USB(Universal Serial Bus) 인터페이스 또는 포트에 접속되고 그 다음에 임의적으로 갑자기 USB 인터페이스로부터 제거/분리될 수 있게 해주는 데 어려움이 있으며, 그 장치가 저장 장치인 경우에 특히 그렇다. 게다가, USB는, USB의 표준 통신 프로토콜에서, IP(Internet Protocol) 주소를 지원하도록 설계되어 있지 않으며, USB는 네트워크 인터페이스로 간주되지 않는다. USB는 또한 USB 인터페이스를 통해 데이터를 전송하려고 시도하거나 데이터를 수신하기 위해 대기하고 있는 독립적인 애플리케이션들을 위한 실제상 제한이 없는, 임의의 수의 다중 동시 독립 세션(multiple concurrent independent session)을 지원하도록 설계되어 있지 않으며, 적어도 어떤 시스템들의 경우, USB 인터페이스를 통해 지원되는 인터페이스 또는 세션의 수가 정적이고 시간에 따라 변경될 수 없다. USB 인터페이스가, 적어도 어떤 시스템들의 경우, 다중 세션(multiple session)으로 간주될 수 있는 다중 동시 "인터페이스"를 지원할 수 있지만, 이들의 수가 고정되어 있을 뿐이고 인터페이스가 장치에 대해 정적이다(변화될 수 없다). 반면에, USB는 보편화된 유용한 인터페이스이며, 이러한 인터페이스를 사용하여 호스트 및 클라이언트 장치 등의 2개의 시스템을 연결시키는 것이 종종 바람직하다.
멀티플렉싱된 데이터 스트림 프로토콜에 대해 본 명세서에 기술되어 있다. 일 실시예에서, 멀티플렉싱된 데이터 스트림 프로토콜을 제공하는 방법은 헤더를 갖는 패킷을 제공하기 위해 데이터 스트림을 패킷화하는 단계 및 USB 인터페이스와 같은 IP(Internet Protocol) 주소(또는 기타 네트워크 주소)를 사용하도록 설계되어 있지 않은 인터페이스를 통해 상기 패킷을 전송하는 단계를 포함한다. 본 방법은 또한 네트워크 스택 소프트웨어(network stack software)에서 헤더를 갖는 패킷을 수신하는 단계 - 상기 패킷은 상기 인터페이스를 통해 수신됨 -, 및 상기 패킷으로부터 데이터를 추출하는 단계를 포함할 수 있다. 헤더는 데이터의 흐름 제어 및 시퀀싱을 위한 데이터를 포함할 수 있고, 송신측 애플리케이션 및 수신측 애플리케이션과 같은 패킷 내의 데이터(페이로드)의 발신지 및 목적지에 대한 식별자를 포함할 수 있다. 헤더는, 헤더 내의 이러한 데이터를 사용하는 TCP-유사 프로토콜(TCP-like protocol)을 사용하여, 다수의 독립적인 애플리케이션이 상기 인터페이스를 통해 다중 동시 세션(multiple concurrent session)을 유지할 수 있게 해준다. 헤더는 TCP(Transmission Control Protocol)-유사 헤더일 수 있고, IP-유사 헤더(IP-like header)를 포함하지 않을 수 있다. 적어도 어떤 실시예들에서, USB 인터페이스와 같은 인터페이스의 표준 프로토콜은 IP 주소를 사용하지 않는다. 본 방법은 애플리케이션마다 흐름 제어를 제공할 수 있다. 흐름 제어, 시퀀싱, 멀티플렉싱, 연결 설정/종료, 확인 응답(acknowledgement), 오류 검사(예를 들어, 체크섬)(선택적임) 및 재전송(선택적임)을 위해 TCP-유사 프로토콜을 구현하는 데 TCP-유사 헤더가 사용될 수 있다. 본 방법은 인터페이스(USB 인터페이스 등)가 갑작스럽고 언제라도 일어날 수 있는(예를 들어, 예측할 수 없는) 단절에 정상적으로(gracefully) 대응할 수 있게 해준다. 예를 들어, 장치가 무선 셀룰러 전화를 갖는 핸드헬드 컴퓨터이고 그의 USB 인터페이스를 통해 호스트 장치(데스크톱 또는 랩톱 컴퓨터 또는 기타 데이터 처리 시스템일 수 있음)의 USB 인터페이스에 연결되어 있고, 장치와 호스트가 데이터를 교환하고 있으며(예를 들어, MP3 파일 또는 기타 파일을 전송하거나, 2개의 시스템을 동기화시키거나 한 시스템을 상대방 시스템에 백업하기 위해 데이터를 교환하는 경우), 또한 그 2개의 시스템이 연결되어 그들의 USB 인터페이스를 통해 데이터를 교환하는 동안 무선 셀룰러 전화 호가 수신되는 경우, 본 방법은 사용자가 전화 호에 응답할 수 있게 해주기 위해 그 연결이 갑작스럽게 단절될 수 있게 해준다. 본 방법은 서로 다른 소프트웨어 모듈들 간의 프로세스간/애플리케이션간 통신을 가능하게 해주는 하나 이상의 종래의 소켓 API(Application Programming Interface)의 사용을 포함할 수 있다. 본 방법은 또한 WiFi 또는 이더넷 연결/인터페이스 등의 종래의 네트워크 연결 또는 장치 및/또는 호스트를 통한 셀룰러 전화 연결을 통해 패킷을 처리하고 또한 비네트워크 인터페이스를 통해 전송하기 위한 패킷을 처리하는 종래의 TCP/IP 스택 소프트웨어 컴포넌트를 포함할 수 있다. 이 TCP/IP 스택 소프트웨어는, 적어도 어떤 실시예들에서, USB 인터페이스와 같은 비네트워크 인터페이스를 통해 전송하기 위한 TCP-유사 헤더를 생성하는 '인터페이스를 통한 TCP' 소프트웨어 컴포넌트(TCP over interface software component)와, 소켓 API를 통해, 통신을 할 수 있다.
일 실시예에서, 컴퓨터 판독가능 매체는 장치 상의 USB 인터페이스와 같은 제2 인터페이스를 통해 전송하기 위한 패킷을 생성하고 제2 인터페이스를 통해 수신된 패킷으로부터 데이터를 추출하는 제2 네트워크 스택 소프트웨어, 및 장치 상의 제1 인터페이스(WiFi 또는 이더넷 인터페이스 또는 무선 셀룰러 전화 인터페이스 등)를 통해 전송하기 위한 패킷을 생성하고 제1 인터페이스를 통해 수신된 패킷으로부터 데이터를 추출하는 제1 네트워크 스택 소프트웨어를 포함한다. TCP/IP 스택일 수 있는 제1 네트워크 스택 소프트웨어는 TCP-유사 패킷을 생성하는 '인터페이스를 통한 TCP' 소프트웨어 스택일 수 있는 제2 네트워크 스택 소프트웨어와 통신하도록 구성되어 있고, 이들 TCP-유사 패킷을 제2 인터페이스와 같은 비네트워크 인터페이스를 통해 전송되게 한다. 제2 네트워크 스택 소프트웨어는 제2 인터페이스를 통해 수신된 패킷으로부터 추출된 데이터를, 제2 인터페이스를 통해 다중 동시 세션을 유지할 수 있는 복수의 수신측 소프트웨어 애플리케이션으로, 제1 네트워크 스택 소프트웨어를 통해 전송하도록 구성되어 있을 수 있다. 제1 인터페이스는 인터넷에 결합되도록 설계되어 있고, 제2 인터페이스는 IP(Internet Protocol) 주소를 사용하도록 설계되어 있지 않으며, 제1 네트워크 스택 소프트웨어는 TCP/IP 스택을 포함하고, 제2 네트워크 스택 소프트웨어는 IP 헤더를 생성하지 않는 TCP-유사 스택을 포함한다. 제2 네트워크 스택 소프트웨어는 제2 인터페이스를 통해 수신된 패킷으로부터 데이터를 추출하고 이 데이터를 제1 네트워크 스택 소프트웨어를 통해 장치 상의 복수의 다중 애플리케이션 중 하나로 전송하도록 구성되어 있다. 제2 네트워크 스택 소프트웨어에 의해 생성된 헤더는 흐름 제어 및 시퀀싱을 위한 데이터 및 수신측(예를 들어, "목적지") 애플리케이션 및 송신측(예를 들어, "발신지") 애플리케이션에 대한 포트 식별자를 포함할 수 있다. 제2 네트워크 스택 소프트웨어에 의해 패킷으로부터 추출된 데이터는 이 데이터의 적어도 일부분에 TCP/IP 헤더를 부가하여 추가의 패킷을 생성하는 제1 네트워크 스택 소프트웨어에 제공될 수 있고, 그 다음에 제1 네트워크 스택 소프트웨어는 이 추가의 패킷으로부터 TCP/IP 헤더를 제거한 다음에 그 데이터를 수신측 애플리케이션에 제공한다. TCP/IP 헤더는 제1 네트워크 스택 소프트웨어에 결합되어 동작하는 루프백 인터페이스(loopback interface)에 대응하는 IP 주소를 포함할 수 있다.
본 명세서는 또한 장치, 시스템, 컴퓨터 판독가능 매체, 소프트웨어 아키텍처, 및 기타 방법에 대해서도 기술하고 있다.
다른 실시예에서, 장치들 간의(예를 들어, 호스트와 장치 간의) 통신 링크는 USB(Universal Serial Bus) 호환 유선 또는 무선 인터페이스이다. 다른 실시예에서, 장치들 간의 통신 링크는 BLUETOOTH 호환 무선 인터페이스이다. 다른 실시예에서, 통신 링크는 네트워크 인터페이스가 아닌 인터페이스이다.
일 실시예에서, 클라이언트 장치는 스마트폰이다. 다른 실시예에서, 클라이언트 장치는 미디어 플레이어 장치이다. 일 실시예에서, 호스트 장치는 데스크톱 컴퓨터 시스템이다. 다른 실시예에서, 호스트 장치는 랩톱 컴퓨터 시스템이다. 다른 실시예에서, 호스트 장치는 팜톱 또는 울트라-모바일(ultra-mobile) 컴퓨터 시스템이다.
멀티플렉싱된 데이터 스트림 프로토콜이 제공된다.
유사한 참조 번호가 유사한 구성요소를 지칭하고 있는 첨부 도면의 도면들에, 본 발명이 제한이 아닌 예로서 도시되어 있다.
도 1은 본 명세서에 기술된 기법들을 이용하여 통신을 할 수 있는 호스트 전자 장치 및 클라이언트 전자 장치의 블록도.
도 2는 호스트 장치 등의 데이터 처리 시스템의 일 실시예의 블록도.
도 3은 클라이언트 장치, 핸드헬드 컴퓨터, 또는 기타 유형의 데이터 처리 시스템 등의 데이터 처리 시스템의 일 실시예의 블록도.
도 4는 호스트 전자 장치와 클라이언트 전자 장치 간의 통신에서 사용될 수 있는 패킷 헤더의 표를 나타낸 도면.
도 5는 호스트 전자 장치와 클라이언트 전자 장치 간의 통신에서 사용될 수 있는 패킷 유형의 표를 나타낸 도면.
도 6은 클라이언트 장치로 데이터를 전송하는 기법의 일 실시예의 흐름도.
도 7은 호스트 장치와 클라이언트 장치 간에 데이터를 동기화시키는 기법의 일 실시예의 흐름도.
도 8은 호스트 및 장치라고 하는 2개의 데이터 처리 시스템을 연결시키는 소프트웨어 아키텍처의 일례를 나타낸 도면.
도 9는 본 발명의 일 실시예에 따른, 2개의 시스템 간에 데이터를 교환하는 방법의 일례를 나타낸 플로우차트로서, 여기서 데이터는 파일(예를 들어, MP3 파일, 비디오 파일, 사진, 기타) 또는 구조화된 데이터(주소록에 있는 연락처, 북마크/즐겨찾기, 일정표 데이터, 메모, 또는 할 일 항목, 기타 등등) 또는 기타 유형의 데이터(예를 들어, 위젯 등의 실행가능 소프트웨어, 기타)일 수 있음.
도 10은 본 발명의 일 실시예에 따른 초기화 방법의 플로우차트.
도 11은 일 실시예에 따른, 호스트로부터 장치로 데이터를 전송하는 방법의 일례를 나타낸 플로우차트.
도 12는 일 실시예에 따른, 장치로부터 호스트로 데이터를 전송하는 방법의 일례를 나타낸 플로우차트.
도 13은 호스트 시스템에 대한 대안의 소프트웨어 아키텍처의 일례를 나타낸 도면.
도 14a는 PTP(Picture Transfer Protocol)를 사용하는 2개의 USB 인터페이스를 통한 연결의 종래 기술의 일례를 나타낸 도면.
도 14b는 본 발명의 일 실시예에 따른 연결의 일례를 나타낸 도면.
도 15는 일 실시예에 따른, 시스템들 간에 파일을 교환하는 방법의 일례를 나타낸 플로우차트.
도 1은 본 명세서에 기술된 기법들을 이용하여 통신을 할 수 있는 호스트 전자 장치 및 클라이언트 전자 장치의 블록도.
도 2는 호스트 장치 등의 데이터 처리 시스템의 일 실시예의 블록도.
도 3은 클라이언트 장치, 핸드헬드 컴퓨터, 또는 기타 유형의 데이터 처리 시스템 등의 데이터 처리 시스템의 일 실시예의 블록도.
도 4는 호스트 전자 장치와 클라이언트 전자 장치 간의 통신에서 사용될 수 있는 패킷 헤더의 표를 나타낸 도면.
도 5는 호스트 전자 장치와 클라이언트 전자 장치 간의 통신에서 사용될 수 있는 패킷 유형의 표를 나타낸 도면.
도 6은 클라이언트 장치로 데이터를 전송하는 기법의 일 실시예의 흐름도.
도 7은 호스트 장치와 클라이언트 장치 간에 데이터를 동기화시키는 기법의 일 실시예의 흐름도.
도 8은 호스트 및 장치라고 하는 2개의 데이터 처리 시스템을 연결시키는 소프트웨어 아키텍처의 일례를 나타낸 도면.
도 9는 본 발명의 일 실시예에 따른, 2개의 시스템 간에 데이터를 교환하는 방법의 일례를 나타낸 플로우차트로서, 여기서 데이터는 파일(예를 들어, MP3 파일, 비디오 파일, 사진, 기타) 또는 구조화된 데이터(주소록에 있는 연락처, 북마크/즐겨찾기, 일정표 데이터, 메모, 또는 할 일 항목, 기타 등등) 또는 기타 유형의 데이터(예를 들어, 위젯 등의 실행가능 소프트웨어, 기타)일 수 있음.
도 10은 본 발명의 일 실시예에 따른 초기화 방법의 플로우차트.
도 11은 일 실시예에 따른, 호스트로부터 장치로 데이터를 전송하는 방법의 일례를 나타낸 플로우차트.
도 12는 일 실시예에 따른, 장치로부터 호스트로 데이터를 전송하는 방법의 일례를 나타낸 플로우차트.
도 13은 호스트 시스템에 대한 대안의 소프트웨어 아키텍처의 일례를 나타낸 도면.
도 14a는 PTP(Picture Transfer Protocol)를 사용하는 2개의 USB 인터페이스를 통한 연결의 종래 기술의 일례를 나타낸 도면.
도 14b는 본 발명의 일 실시예에 따른 연결의 일례를 나타낸 도면.
도 15는 일 실시예에 따른, 시스템들 간에 파일을 교환하는 방법의 일례를 나타낸 플로우차트.
이하의 설명에는, 많은 구체적인 상세가 기재되어 있다. 그렇지만, 본 발명의 실시예들은 이들 구체적인 상세 없이도 실시될 수 있다. 다른 경우에, 본 설명의 이해를 모호하게 하지 않기 위해 공지의 회로, 구조 및 기법에 대해서는 상세히 설명하지 않고 있다.
본 명세서에는 종단점들 간에 파일 및 기타 데이터를 전송하는 프로토콜이 기술되어 있다. 일 실시예에서, 종단점들은 호스트 전자 장치 및 클라이언트 전자 장치이다. 호스트 전자 장치는, 예를 들어, 데스크톱 컴퓨터 시스템 또는 랩톱 컴퓨터 시스템일 수 있다. 클라이언트 전자 장치는, 예를 들어, 랩톱 컴퓨터 시스템, PDA(personal digital assistant), 셀룰러-기반 장치(예를 들어, 셀룰러 전화 또는 스마트폰)일 수 있다.
일 실시예에서, 종단점들 간의 연결은 신뢰성있는 스트림 전송, 예를 들어, TCP(Transmission Control Protocol) 스트림 연결을 이용한다. 다른 스트림 연결들도 역시 지원될 수 있다. 일 실시예에서, 헤더 및 보디를 갖는 패킷을 이용하여 통신이 달성된다. 본 명세서에 표준의 최소 헤더의 일 실시예가 기술되어 있지만, 헤더가 부가의 패킷-관련 구조화된 데이터를 포함할 수 있다. 패킷 데이터가 비구조화된 데이터를 포함할 수 있거나, 비어 있을 수 있다.
도 1은 본 명세서에 기술된 기법들을 이용하여 통신을 할 수 있는 호스트 전자 장치 및 클라이언트 전자 장치의 블록도이다. 도 1의 블록도는 호스트 장치(100)와 클라이언트 장치(150) 간에 통신을 하는 데 이용될 수 있는 컴포넌트들의 개념적 도해를 제공한다. 일례에서, 호스트 장치(100)는 컴퓨터 시스템(예를 들어, 데스크톱 또는 랩톱 컴퓨터 시스템)이고, 클라이언트 장치(150)는 모바일 장치(예를 들어, PDA 또는 스마트폰)이다. 호스트 장치(100) 및 클라이언트 장치(150)는 공지된 임의의 유형의 통신 기법을 통해 통신을 할 수 있다. 예를 들어, 통신 링크(145)는 물리 케이블(예를 들어, USB(Universal Serial Bus) 호환 케이블) 또는 무선 통신 링크(예를 들어, 블루투스 호환 또는 IEEE 802.11 호환)일 수 있다. 블루투스는 Bluetooth SIG, Inc. 소유의 등록 상표이다.
애플리케이션(110)은 호스트 장치(100)에 의해 실행될 수 있는 임의의 유형의 애플리케이션일 수 있다. 예를 들어, 애플리케이션(110)은 미국 캘리포니아주 쿠퍼티노 소재의 Apple Inc.로부터 입수가능한 iTunes일 수 있다. 애플리케이션(110)은 클라이언트 장치(150)로 전달될 수 있는 및/또는 클라이언트 장치(150)와 동기화될 수 있는 기능 및/또는 데이터를 포함할 수 있다. 예를 들어, 애플리케이션(110)은 클라이언트 장치(150)에 저장되거나 클라이언트 장치(150)에 의해 재생될 수 있는 멀티미디어 컨텐츠를 저장 및/또는 재생할 수 있다. 클라이언트 장치(150)가 호스트 장치(100)와 통신을 할 때, 애플리케이션(110)은 컨텐츠가 호스트 장치(100)와 클라이언트 장치(150) 간에 전송되게 할 수 있다. 다른 유형의 애플리케이션들도 역시 지원될 수 있다.
게이트키퍼 클라이언트(115)는 애플리케이션(110)이 통신 링크(145)에 접속하는 것을 제어하기 위해 애플리케이션(110)과 상호작용한다. 게이트키퍼 클라이언트(115)는 하나 이상의 파라미터에 기초하여 통신 링크(145)에의 접속을 선택적으로 제한할 수 있다. 게이트키퍼 클라이언트(115)는 호스트 장치(100)와 클라이언트 장치(150) 간의 통신을 가능하게 해주기 전에, 예를 들어, 인증 및/또는 유효성 검사 동작을 수행할 수 있다. 게이트키퍼 클라이언트(115)는 또한 호스트 장치(100)와 클라이언트 장치(150) 간의 통신을 위한 다수의 통신 링크들 중 하나를 선택할 수 있다. 도 1의 예가 게이트키퍼 기능을 갖는 경우에 대해 기술되어 있지만, 대안의 실시예들은 게이트키퍼 기능 없이 제공될 수 있다. 게이트키퍼 클라이언트(115) 및 게이트키퍼(180)에 관한 추가의 정보가 2007년 6월 22일자로 출원된 미국 특허 출원 제11/767,447호(대리인 문서 번호 18962-113001/P5408US1)에 제공되어 있으며, 이 미국 특허 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다.
게이트키퍼 클라이언트(115)는 링크 인터페이스(140)를 통해 통신 링크(145)에 접속하기 위해 링크 드라이버(link driver)(130)와 통신을 할 수 있다. 일 실시예에서, 링크 드라이버(130)는 호스트 장치(100)와 클라이언트 장치(150) 간의 동기화 기능을 제공하기 위해 구조화된 동기 서비스(structured sync service)(120)와 상호작용한다. 일 실시예에서, 구조화된 동기 서비스(120)는 이하에서 더 상세히 기술되는 명령 및 프로토콜을 이용하여 기능할 수 있다. 링크 드라이버(130)는 링크 서비스(140)로 하여금 데이터를 나타내는 신호(예를 들어, 전기 신호, RF 신호, 적외선 신호, 광 신호)를 통신 링크(145)를 통해 전송하게 할 수 있다.
클라이언트 장치(150) 내에서, 링크 인터페이스(160)는 링크 인터페이스(140)에 대응하는 것이다. 링크 인터페이스(160)는 통신 링크(145)를 통해 신호(예를 들어, 전기 신호, RF 신호, 적외선 신호, 광 신호)를 전송 및/또는 수신할 수 있다. 클라이언트 장치(150)는 또한, 호스트 장치(100) 상의 애플리케이션(110)과 클라이언트 장치(150) 상의 미디어 동기 서비스(190) 간의 통신을 가능하게 해주기 전에, 인증, 유효성 검사 및/또는 기타 허가 기능들을 수행할 수 있는 게이트키퍼(180)를 포함하고 있다.
일 실시예에서, 미디어 동기 서비스(190)는 데이터(195)에의 액세스(예를 들어, 읽기, 쓰기, 수정, 업데이트)를 가능하게 해주기 위해 이하에서 더 상세히 기술되는 메시지 및 프로토콜을 지원할 수 있다. 데이터(195)는 클라이언트 장치(150) 상에 저장된 임의의 유형의 데이터를 나타낸다. 데이터(195)는 하나 이상의 데이터베이스, 표 및/또는 기타 저장 요소(storage element)일 수 있다. 데이터(195)는, 예를 들어, 미디어 파일(예를 들어, 오디오 및/또는 비디오 데이터 파일), 메타데이터, 연락처 정보, 이력 정보(예를 들어, 호 로그, 소프트웨어 버전 정보), 및/또는 상태 정보(예를 들어, 배터리 용량, 일련 번호, 총 메모리, 가용 메모리)일 수 있다.
클라이언트 장치(150)는 또한 클라이언트 장치(150) 상에 데이터를 유지할 수 있는 구조화된 데이터 서비스(185)를 포함할 수 있다. 구조화된 동기 서비스(120) 및 구조화된 데이터 서비스(185)를 이용하여 동기화 및/또는 유지될 수 있는 데이터의 일례로는 북마크, 연락처 정보, 일정표 정보, 기타 등등이 있을 수 있다. 구조화된 동기 서비스(120)는 동기화 소프트웨어(805)(도 8)와 동일하거나 그와 유사할 수 있으며, 구조화된 동기 서비스(185)는 동기 소프트웨어(835)(도 8)와 동일하거나 그와 유사할 수 있다.
일 실시예에서, 애플리케이션(110)이 데이터(190)에 액세스할 수 있게 해주기 위한 호스트 장치(100)와 클라이언트 장치(150) 간의 통신은 이하에서 더 상세히 기술되는 특정의 데이터 패킷 포맷을 이용하여 구조화된 동기 서비스(120) 및 미디어 동기 서비스(190)를 통해 달성될 수 있다. 일 실시예에서, 통신 링크(145)는 호스트 장치(100)와 클라이언트 장치(150) 간의 USB(Universal Serial Bus) 호환 유선 통신 링크일 수 있다. 일 실시예에서, 호스트 장치(100)와 클라이언트 장치(150) 간의 연결은 USB 호환 물리 연결 상부의 TCP 스트림 연결(TCP stream connection over the USB compliant physical connection)을 이용하여 이하에 기술되는 패킷을 전송한다.
도 2는 호스트 장치 등의 데이터 처리 시스템의 일 실시예의 블록도이다. 유의할 점은, 도 2가 컴퓨터 시스템의 다양한 컴포넌트들을 도시하고 있지만, 이러한 상세가 본 발명과 밀접한 관련은 없기 때문에 도 2가 이들 컴포넌트를 상호연결시키는 임의의 특정의 아키텍처 또는 방식을 나타내기 위한 것이 아니라는 것이다. 또한, PDA(personal digital assistant), 셀룰러 전화, 미디어 플레이어(예를 들어, iPod), 이들 장치의 측면들 또는 기능들을 겸비하는 장치(하나의 장치에 PDA 및 셀룰러 전화를 겸비한 미디어 플레이어), 네트워크 컴퓨터, 다른 장치 내에 내장된 처리 장치, 및 더 적은 컴포넌트 또는 어쩌면 더 많은 컴포넌트를 갖는 기타 데이터 처리 시스템이 또한 본 발명의 하나 이상의 실시예를 구현하는 데 사용될 수 있고 또 본 명세서에 기술된 데이터 처리 시스템들 중 하나 이상일 수 있다는 것을 잘 알 것이다. 도 2에 도시된 컴퓨터 시스템은, 예를 들어, Apple Inc.의 Macintosh 컴퓨터이거나 Microsoft Corporation의 Windows 운영 소프트웨어를 실행하는 컴퓨터일 수 있다.
컴퓨터 시스템(200)은 처리 시스템(210)을 구성하는 하나 이상의 마이크로프로세서에 결합된 버스(205)를 포함한다. 버스(205)는 또한 메모리(220) 및 비휘발성 메모리(230)(어떤 실시예들에서 자기 하드 드라이브이거나 다른 실시예들에서 플래쉬 메모리일 수 있음)에도 결합되어 있다. 버스(205)는 또한 디스플레이 제어기 및 디스플레이(240)와 하나 이상의 입/출력(I/O) 장치(250)에도 결합되어 있다.
게다가, 버스(205)는 선택적인 도크(260)와 하나 이상의 무선 송수신기(270)(블루투스 호환 송수신기 또는 WiFi 호환 송수신기 또는 적외선 송수신기일 수 있음)에도 결합되어 있을 수 있다. 무선 송수신기(270)는 도 2에 도시된 바와 같이 선택적이다.
처리 시스템(210)은 선택적으로 캐쉬(215)에 결합되어 있을 수 있다. 처리 시스템(210)은 Intel 또는 IBM의 마이크로프로세서 등의 하나 이상의 마이크로프로세서를 포함할 수 있다. 버스(205)는 공지된 방식으로 이들 다양한 컴포넌트를 서로 상호연결시킨다. 통상적으로, 입/출력 장치(250)는 입/출력 제어기를 통해 시스템에 결합되어 있다.
메모리(220)는 데이터에의 고속 액세스를 제공하지만 메모리(220) 내의 데이터를 리프레쉬 또는 유지하기 위해 계속하여 전원을 필요로 하는 동적 RAM(DRAM)으로서 구현될 수 있다. 비휘발성 메모리(230)는 시스템으로부터 전원이 제거된 후에도 데이터를 보유하는 자기 하드 드라이브 또는 기타 비휘발성 메모리일 수 있다. 도 2에서 비휘발성 메모리(230)가 데이터 처리 시스템 내의 나머지 컴포넌트들에 직접 결합되어 있는 로컬 장치인 것으로 도시되어 있지만, 다른 실시예들이, 모뎀 또는 이더넷 인터페이스 등의 네트워크 인터페이스를 통해 데이터 처리 장치에 결합되어 있는 네트워크 저장 장치와 같은, 시스템으로부터 원격지에 있는 비휘발성 메모리를 이용할 수 있다는 것을 잘 알 것이다.
잘 알려진 바와 같이, 버스(205)는 공지되어 있는 다양한 브리지, 제어기, 및/또는 어댑터를 통해 서로 연결되어 있는 하나 이상의 버스를 포함할 수 있다. 일 실시예에서, I/O 제어기(250)는 USB 호환 주변장치를 제어하는 USB 호환 어댑터 및 IEEE-1394 호환 주변장치에 대한 IEEE-1394 제어기를 포함할 수 있다.
본 명세서에 기술된 본 발명의 측면들은, 적어도 부분적으로, 소프트웨어로 실시될 수 있다. 즉, 이들 기법들은 컴퓨터 시스템 또는 기타 데이터 처리 시스템에서 그의 프로세서 또는 처리 시스템이 메모리(메모리(220) 또는 비휘발성 메모리(230) 또는 도 3에 도시된 메모리(330) 등)에 들어 있는 명령어 시퀀스를 실행하는 것에 응답하여 수행될 수 있다. 다양한 실시예들에서, 본 발명을 구현하기 위해 소프트웨어 명령어와 함께 하드와이어드 회로(hardwired circuitry)가 사용될 수 있다. 따라서, 이들 기법들은 하드웨어 회로 및 소프트웨어의 임의의 특정의 조합 또는 데이터 처리 시스템에 의해 실행되는 명령어들의 임의의 특정의 소스로 제한되지 않는다. 그에 부가하여, 본 설명 전반에 걸쳐, 설명을 간단화하기 위해 다양한 기능들 및 동작들이 소프트웨어 코드에 의해 수행되는 것으로 또는 소프트웨어 코드에 의해 야기되는 것으로 기술되어 있다. 그렇지만, 이러한 표현이 의미하는 바는 그 기능들이 처리 시스템에서 그 코드를 실행한 결과라는 것이다.
도크(260) 및/또는 무선 송수신기(270)는 도 2에 도시된 데이터 처리 시스템을, 도 3에 도시된 데이터 처리 시스템 등의 다른 데이터 처리 시스템에 또는 도 2에 도시된 시스템과 비슷한 다른 데이터 처리 시스템에 결합시키는 물리 인터페이스를 제공한다. 도크(260)는 하나의 데이터 처리 시스템과 다른 데이터 처리 시스템 간에 동기화 프로세스가 수행될 수 있게 해주기 위해 이 2개의 시스템 간의 기계적 및 물리적 연결 둘다를 제공할 수 있다. 다른 실시예들에서, 무선 송수신기(270)는 2개의 시스템 간의 기계적 연결을 제공하지 않고 동기화 프로세스를 위해 2개의 시스템 간의 무선 주파수(RF) 연결을 제공할 수 있다.
도 3은 클라이언트 장치, 핸드헬드 컴퓨터, 또는 도 2에 도시된 시스템이나 도 3에 도시된 것과 유사한 시스템 등의 기타 유형의 데이터 처리 시스템과 같은 데이터 처리 시스템의 일 실시예의 블록도이다. 데이터 처리 시스템(300)은 하나 이상의 마이크로프로세서일 수 있거나 시스템 온 칩(system on a chip) 집적 회로일 수 있는 처리 시스템(310)을 포함한다. 시스템(300)은 또한 데이터 및 처리 시스템(310)에서 실행하기 위한 프로그램을 저장하는 메모리(330)도 포함하고 있다. 시스템(300)은 또한, 예를 들어, 스피커 및 마이크를 통해 음악을 재생하거나 전화 기능을 제공하기 위한 마이크 및 스피커를 포함할 수 있는 오디오 입/출력 서브시스템(340)도 포함하고 있다.
디스플레이 제어기 및 디스플레이 장치(350)는 사용자에게 시각 사용자 인터페이스를 제공하고, 이 디지털 인터페이스는 OS X 운영 체제 소프트웨어를 실행할 때 Macintosh 컴퓨터에 보여지는 것과 유사한 그래픽 사용자 인터페이스를 포함할 수 있다. 시스템(300)은 또한 WiFi 송수신기, 적외선 송수신기, 블루투스 호환 송수신기, 및/또는 무선 셀룰러 전화 송수신기와 같은 하나 이상의 무선 송수신기도 포함하고 있다. 어떤 실시예들에서, 도시되어 있지 않은 부가의 컴포넌트들도 또한 시스템(300)의 일부일 수 있고, 어떤 실시예들에서, 도 3에 도시된 것보다 적은 수의 컴포넌트들이 또한 데이터 처리 시스템에서 사용될 수 있다.
데이터 처리 시스템(300)은 또한 사용자가 시스템(300)에 입력을 제공할 수 있게 해주기 위해 제공되어 있는 하나 이상의 입력 장치(360)도 포함하고 있다. 이들 입력 장치는 키패드, 키보드, 터치 패널 또는 멀티-터치 패널(multi-touch panel)일 수 있다. 데이터 처리 시스템(300)은 또한 도 2에 도시된 도크(260)와 같은 도크에 대한 커넥터일 수 있는 선택적인 입/출력 장치(370)도 포함하고 있다.
도시되어 있지 않은 하나 이상의 버스가 공지된 바와 같이 다양한 컴포넌트들을 상호연결시키는 데 사용될 수 있다. 데이터 처리 시스템(300)은 핸드헬드 컴퓨터 또는 PDA(personal digital assistant), PDA-유사 기능을 갖는 셀룰러 전화, 셀룰러 전화를 포함하는 핸드헬드 컴퓨터, iPod과 같은 미디어 플레이어, 또는 하나의 장치에 PDA 및 셀룰러 전화를 겸비하고 있는 미디어 플레이어와 같은 이들 장치의 특성들 또는 기능들을 겸비하고 있는 장치일 수 있다. 다른 실시예들에서, 데이터 처리 장치(300)는 네트워크 컴퓨터 또는 다른 장치 내에 내장된 처리 장치, 또는 도 3에 도시된 것보다 더 적은 수의 컴포넌트 또는 어쩌면 더 많은 수의 컴포넌트를 갖는 기타 유형의 데이터 처리 시스템일 수 있다.
본 명세서에 기술된 본 발명의 적어도 어떤 실시예들은 미디어를 제공하는 미디어 처리 시스템을 포함할 수 있는 휴대용 음악 및/또는 비디오 미디어 플레이어와 같은 디지털 미디어 플레이어, 미디어를 저장하는 저장 장치의 일부일 수 있고, 안테나 시스템 및 미디어 처리 시스템과 결합되어 있는 RF(radio frequency) 송수신기(예를 들어, 셀룰러 전화의 RF 송수신기)를 더 포함할 수 있다. 어떤 실시예들에서, 원격 저장 장치에 저장된 미디어는 RF 송수신기를 통해 미디어 플레이어로 전송될 수 있다. 이 미디어는, 예를 들어, 음악 또는 기타 오디오, 정지 화상, 또는 동화상 중 하나 이상일 수 있다.
휴대용 미디어 플레이어는 미국 캘리포니아주 쿠퍼티노 소재의 Apple Inc.의 iPod 또는 iPod Nano 미디어 플레이어 상의 클릭 휠(click wheel) 입력 장치, 터치 스크린 입력 장치, 푸시버튼 장치, 이동가능 포인팅 입력 장치 또는 기타 입력 장치와 같은 미디어 선택 장치를 포함할 수 있다. 이 미디어 선택 장치는 저장 장치 및/또는 원격 저장 장치에 저장된 미디어를 선택하는 데 사용될 수 있다.
적어도 어떤 실시예들에서, 휴대용 미디어 플레이어는 입력 장치를 통해 선택되어, 스피커 또는 이어폰(들)을 통해 또는 디스플레이 장치 상에 제공되거나 디스플레이 장치 및 스피커 또는 이어폰(들) 둘다를 통해 제공되는 미디어의 타이틀 또는 기타 표시자를 디스플레이하기 위해 미디어 처리 시스템에 결합되어 있는 디스플레이 장치를 포함할 수 있다. 휴대용 미디어 플레이어의 일례가 공개된 미국 특허 출원 제2003/0095096호 및 제2004/0224638호에 기술되어 있으며, 이들 출원 둘다는 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다.
어떤 실시예들에서, 데이터 처리 시스템(300)은 액정 디스플레이와 일체로 되어 있는 멀티-터치 입력 패널 장치일 수 있는 태블릿-유사 입력 장치를 갖는 핸드헬드 컴퓨터와 비슷한 작은 폼팩터로 구현될 수 있다. 이러한 장치의 일례가 2006년 10월 24일자로 출원된, 발명의 명칭이 "AUTOMATED RESPONSE TO AND SENSING OF USER ACTIVITY IN PORTABLE DEVICES(휴대용 장치에서의 사용자 동작의 감지 및 사용자 동작에 대한 자동화된 응답)"인 미국 특허 출원 제11/586,862호에 제공되어 있으며, 이 미국 출원은 본 출원과 동일한 양수인에게 양도되어 있다. 이 상기 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다.
이하의 설명에서, 동기화 및 비동기화 처리 동작 둘다에 대해 사용되는 다양한 소프트웨어 컴포넌트에 대해 기술한다. 적어도 어떤 실시예들에서, 이들 다양한 소프트웨어 컴포넌트가 한 유형의 데이터 처리 시스템에 대한 도 2에 도시된 메모리(220) 및/또는 메모리(230)에 저장될 수 있고, 또한 도 3에 도시된 것과 같은 시스템의 경우에, 이들 다양한 서로 다른 소프트웨어 컴포넌트가 휘발성 메모리는 물론, 플래쉬 메모리 또는 자기 하드 드라이브 등의 비휘발성 메모리를 포함할 수 있는 메모리(330)에 저장될 수 있다는 것을 잘 알 것이다.
장치들 간의 적절한 상호연결과 함께 각각의 예시적인 실시예들에서 호스트 장치와 클라이언트 장치에 대해 기술하였으며, 이제부터는 예시적인 패킷 포맷, 패킷 유형, 기능 및 데이터 흐름에 대해 기술한다. 이상의 설명에서와 같이, 이하의 설명은 통신 프로토콜의 예시적인 실시예를 제공한다. 이 프로토콜에 대한 변형들도 역시 지원될 수 있다.
도 4의 표는 패킷 헤더 포맷의 일 실시예를 나타낸 것이다. 기타 포맷들도 역시 사용될 수 있다. 특정의 크기 및 길이가 기술되어 있지만, 기타 필드 이름, 길이 및/또는 설명(description)들도 역시 지원될 수 있다.
일 실시예에서, 패킷 데이터가 리틀-엔디안(little-endian) 또는 빅-엔디안(big-endian) 포맷 중 어느 하나로 연결을 통해 전송될 수 있다. 일 실시예에서, 어느 한쪽 장치가 데이터를 어느 한쪽 포맷으로 전송할 수 있다. 수신측 장치는, 필요한 경우, 데이터 순서를 바꿀 책임이 있다. 일 실시예에서, 각각의 패킷은 일관된 엔디안 방식(endianness)을 사용해야만 한다. 일 실시예에서, 미리 정해진(예를 들어, 일정한) 서명 값(예를 들어, 0x4141504c36414643)이 모든 패킷 헤더에 대해 사용될 수 있다. 이 서명은 수신측 장치가 송신측 장치로부터 전송된 데이터의 엔디안 방식을 판정할 수 있게 해준다. 일 실시예에서, 서명 필드는 길이가 8 바이트이지만, 기타 서명 필드 크기도 역시 지원될 수 있다.
패킷 헤더는 또한 헤더를 포함하는 전체 패킷의 길이를 나타내는 필드도 포함할 수 있다. 일 실시예에서, 패킷 길이 필드가 8 바이트일 수 있지만, 예를 들어, 다른 최대 패킷 크기를 지원하기 위해 기타 패킷 길이 필드 크기가 지원될 수 있다. 패킷 헤더는 또한 패킷 일련 번호를 나타내는 필드도 포함할 수 있다. 패킷 일련 번호는 호스트 장치(100)와 클라이언트 장치(150) 간에 전송되는 패킷에 순서를 부여하는 데 이용될 수 있다. 일 실시예에서, 패킷 일련 번호 필드가 8 바이트일 수 있지만, 기타 패킷 일련 번호 필드 크기가 지원될 수 있다.
패킷 헤더는 또한 패킷 유형에 대한 필드도 포함하고 있다. 패킷 유형 필드는 패킷의 기능을 나타내는, 패킷 내의 메시지의 유형의 숫자 표시자(numerical indicator)를 포함하고 있다. 패킷 유형 및 패킷 유형 값의 한 예시적인 리스트가 도 5에 제공되어 있다. 기타 패킷 이름, 기타 패킷 기능 및/또는 기타 패킷 유형 값도 역시 지원될 수 있다. 일 실시예에서, 패킷 유형 필드가 8 바이트일 수 있지만, 기타 패킷 유형 필드 크기가 지원될 수 있다.
도 5의 표는 종단점들 간에 통신을 하는 데 이용될 수 있는 일련의 패킷의 일 실시예를 나타낸 것이다. 기타 패킷 및/또는 다른 패킷도 역시 이용될 수 있다. 특정의 패킷 유형 식별자 및 패킷 이름이 기술되어 있지만, 기타 패킷 유형 식별자, 패킷 이름 및/또는 설명도 역시 지원될 수 있다.
도 5에 열거된 패킷의 다양한 실시예들에 대해 이하에서 더 상세히 설명한다. 이들 패킷 설명은 제공될 수 있는 단지 하나의 실시예의 일례를 제공한다. 일 실시예에서, 각각의 패킷은 표준의 패킷 헤더를 포함한다. 이 헤더는 도 4에 예시된 것과 같은 포맷으로 되어 있을 수 있다.
Status 패킷은 요청 패킷(request packet)에 응답하여 상태 정보를 제공하는 데 이용될 수 있다. 상태 패킷은 또한 장애 또는 기타 오류 조건의 경우에 오류 정보를 제공하는 데도 이용될 수 있다. 일 실시예에서, 상태 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Status | 8 | 요청된 동작의 상태를 나타내는 상태 코드 |
Data 패킷은 호스트 전자 장치와 클라이언트 전자 장치 간에 데이터를 전달하는 데 이용될 수 있다. 일 실시예에서, 데이터 패킷은 임의의 크기일 수 있다. 즉, 데이터 패킷은 '헤더 + 전송될 데이터'의 길이일 수 있다. 대안의 실시예에서, 전송될 데이터가 데이터 패킷의 페이로드 용량(payload capacity)을 초과하는 경우 하나 이상의 부가의 데이터 패킷이 이용될 수 있도록 데이터 패킷이 고정된 길이일 수 있다. 일 실시예에서, Data 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Data | 가변적임 | 요청된 데이터/전송될 데이터 |
Read Directory 패킷은 타겟 장치 상의 디렉토리를 읽는 데 이용될 수 있다. 일 실시예에서, Read Directory 패킷은 이하의 표에 따른 포맷으로 되어 있다. 경로 문자열(path string)은 타겟 장치에 대한 적절한 포맷의 경로 문자열일 수 있다. 예를 들어, 경로 문자열은 UTF-8 포맷의 NULL-종료(NULL-terminated) POSIX(Portable Operating System Interface for UNIX) 경로 문자열일 수 있다. 기타 포맷들도 역시 지원될 수 있다. POSIX 표준 계열이 정식으로 IEEE 표준 1003 으로 지정되어 있으며, 국제 표준 명칭은 ISO/IEC 9945이다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
Read File 패킷은 타겟 장치 상의 하나의 파일 전체를 읽는 데 이용될 수 있다. 일 실시예에서, 그 결과가 Status 패킷 또는 Data 패킷에 넣어 제공된다. 일 실시예에서, Read File 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Offset | 8 | 파일의 시작부터 요청된 데이터까지의 오프셋 |
Length | 8 | 파일로부터 읽어낼 데이터의 길이 |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
Write File 패킷은 타겟 장치에 하나의 파일 전체를 쓰는 데 이용될 수 있다. 일 실시예에서, Write File 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
Data | 가변적임 | 파일에 써질 데이터 |
Write Part 패킷은 타겟 장치 상의 파일의 일부분에 데이터를 쓰는 데 이용될 수 있다. 패킷으로부터의 데이터가 써질 때 데이터 및/또는 파일과 연관된 상태 데이터가 유지되지 않는다는 점에서, Write Part 패킷이 무상태(stateless)일 수 있다. 일 실시예에서, Write Part 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Offset | 8 | 파일의 시작부터 쓰기의 시작까지의 오프셋 |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
Data | 가변적임 | 파일에 써질 데이터 |
Truncate (Trunc) File 패킷은 파일의 길이를 설정하는 데 이용될 수 있다. 그 길이가 대응하는 데이터보다 짧을 수 있거나(이 경우, 데이터 중 일부가 누락됨), 그 길이가 대응하는 데이터보다 클 수 있다(이 경우, 초과 부분이 미리 정해진 데이터 패턴(예를 들어, 모두 "0")으로 채워질 수 있음). 일 실시예에서, Trunc File 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Length | 8 | 파일의 길이 |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
Remove Path 패킷은 타겟 장치 상의 파일 또는 디렉토리를 삭제하는 데 이용될 수 있다. 일 실시예에서, Remove Path 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
Make Directory 패킷은 타겟 장치 상에 디렉토리를 생성하는 데 이용될 수 있다. 일 실시예에서, Make Directory 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
Get File Info 패킷은 타겟 장치 상의 파일을 설명하는 정보를 검색하는 데 이용될 수 있다. 일 실시예에서, 파일 정보는 Data 패킷에 넣어 전송되는 하나 이상의 키/값 쌍으로서 제공된다. 파일을 설명하는 정보는, 예를 들어, 파일 크기, 최근 수정 일자, 퍼미션(permission)일 수 있다. 부가의 파일 정보 및/또는 다른 파일 정보도 역시 제공될 수 있다. 일 실시예에서, Get File Info 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
Get Device Info 패킷은 타겟 장치를 설명하는 정보를 검색하는 데 이용될 수 있다. 일 실시예에서, 장치 정보는 Data 패킷에 넣어 전송되는 하나 이상의 키/값 쌍으로서 제공된다. 장치를 설명하는 정보는, 예를 들어, 장치 이름, 일련 번호, 운영 체제 버전, 배터리 레벨, 이용가능한 자유 공간일 수 있다. 부가의 장치 정보 및/또는 다른 장치 정보도 역시 제공될 수 있다. 일 실시예에서, Get Device Info 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Write File Atomic 패킷은 타겟 장치에 파일을 쓰는 데 이용될 수 있다. Write File Atomic 패킷은 파일 전체가 써지거나 파일이 전혀 써지지 않도록 해준다. Write File Atomic 패킷은, 예를 들어, 데이터베이스 파일을 쓰는 데 사용될 수 있다. 일 실시예에서, Write File Atomic 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
File Reference (Ref) Open 패킷은 타겟 장치 상의 열린 파일을 나타내는 토큰 또는 기타 식별자를 획득하는 데 이용될 수 있다. 일 실시예에서, File Ref Open 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Mode | 8 | 파일을 열 때 사용할 모드(표 16 참조) |
Path | 가변적임 | 적절한 포맷의 경로 문자열 |
일 실시예에서, 모드(Mode) 필드는 파일을 열 때 사용하는 모드의 숫자 표시자를 포함한다. 표 16에서의 모드 이름(Mode Name) 및 모드 값(Mode Value) 지정은 일 실시예에 대한 일례이다. 다른 일군의 모드가 지원될 수 있다. 또한, 다른 모드 값들이 지원될 수 있다.
모드 이름 | 모드 값 |
Read Only | 1 |
Read-Write | 2 |
Write-Truncate | 3 |
Read-Write-Truncate | 4 |
Write-Append | 5 |
Read-Write-Append | 6 |
Read Only 모드에서, 파일은 읽기만을 위해 열릴 수 있다. Read-Write 모드에서, 파일은 읽기 및 쓰기만을 위해 열릴 수 있다. Write-Truncate 모드에서, 파일은 쓰기 또는 절단을 위해 열릴 수 있다. Read-Write-Truncate 모드에서, 파일은 읽기, 쓰기 또는 절단을 위해 열릴 수 있다. Write-Append 모드에서, 파일은 쓰기 또는 첨부를 위해 열릴 수 있다. Read-Write-Append 모드에서, 파일은 읽기, 쓰기 또는 첨부를 위해 열릴 수 있다.
File Ref Open Result 패킷은 타겟 장치 상의 파일에 액세스할 때 본 명세서에 기술된 패킷들 중 하나 이상에서 사용될 수 있는 파일 참조 토큰(file reference token)을 반환하는 데 이용될 수 있다. 일 실시예에서, File Ref Open Result 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
File Ref | 8 | File Ref Open 동작으로부터 얻은 파일 참조 |
File Ref Read 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일을 읽는 데 이용될 수 있다. 일 실시예에서, File Ref Read 동작에 응답하여 파일 내의 위치가 자동적으로 전진한다. 일 실시예에서, File Ref Read 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
File Ref | 8 | File Ref Open 동작으로부터 얻은 파일 참조 |
Length | 8 | 파일로부터 읽어낼 데이터의 길이 |
File Ref Write 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일에 쓰는 데 이용될 수 있다. 일 실시예에서, File Ref Write 동작에 응답하여 파일 내의 위치가 자동적으로 전진한다. 일 실시예에서, File Ref Write 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
File Ref | 8 | File Ref Open 동작으로부터 얻은 파일 참조 |
Data | 가변적임 | 파일에 써질 데이터 |
File Ref Seek 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일 내의 위치를 구하는 데 이용될 수 있다. 일 실시예에서, File Ref Seek 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
File Ref | 8 | File Ref Open 동작으로부터 얻은 파일 참조 |
Whence | 8 | 탐색할 위치(표 21 참조) |
Offset | 8 | 파일의 시작부터 읽기 시작까지의 오프셋 |
일 실시예에서, Whence 필드 내의 값은 탐색이 어떻게 수행되어야 하는지를 나타내는 데 사용될 수 있다. 표 21은 File Ref Seek 패킷에서 사용될 수 있는 Whence 값의 일례를 제공한다.
Whence 값 | 설명 |
0 | Offset 필드에 의해 지정된 절대 위치까지 탐색함 |
1 | 파일의 현재 위치로부터 탐색함 |
2 | 파일의 끝부터 탐색함 |
File Ref Tell 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일 내의 위치를 구하는 데 이용될 수 있다. 일 실시예에서, File Ref Tell 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
File Ref | 8 | 위치가 반환될 파일 참조 |
File Ref Tell Result 패킷은 File Ref Tell 동작의 결과를 반환하는 데 이용될 수 있다. 일 실시예에서, File Ref Tell Result 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Offset | 8 | 요청된 파일 참조의 현재 위치 오프셋 |
File Ref Close 패킷은 File Ref Open 동작으로부터 얻은 파일 참조를 사용하여 파일을 닫는 데 이용될 수 있다. 일 실시예에서, File Ref Close 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
File Ref | 8 | 닫을 파일의 파일 참조 |
File Ref Set Size 패킷은 File Ref Open 동작으로부터 얻은 참조에 대응하는 파일의 크기를 설정하는 데 이용될 수 있다. 일 실시예에서, File Ref Set Size 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
File Ref | 8 | 닫을 파일의 파일 참조 |
File Size | 8 | 파일의 새로운 크기(단위: 바이트) |
File Ref Set Size 패킷은 파일의 길이를 설정하는 데 이용될 수 있다. 그 길이가 대응하는 데이터보다 짧을 수 있거나(이 경우, 데이터 중 일부가 누락됨), 그 길이가 대응하는 데이터보다 클 수 있다(이 경우, 초과 부분이 미리 정해진 데이터 패턴(예를 들어, 모두 "0")으로 채워질 수 있음).
Rename Path 패킷은 타겟 장치 상에 디렉토리 경로의 이름을 변경하는 데 이용될 수 있다. 일 실시예에서, Rename Path 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Source Path | 가변적임 | 이름 변경될 경로에 대한 적절한 포맷의 경로 문자열 |
Destination Path | 가변적임 | 새로운 경로 이름에 대한 적절한 포맷의 경로 문자열 |
경로 문자열(path string)은 타겟 장치에 대한 적절한 포맷의 경로 문자열일 수 있다. 예를 들어, 발신지 및 목적지 경로 문자열은 UTF-8 포맷의 NULL-종료 POSIX 경로일 수 있다. 기타 포맷들도 역시 지원될 수 있다. 일 실시예에서, Rename Path 패킷에서 목적지 경로 필드가 발신지 경로 필드 바로 다음에 온다.
Set FS Block Size 패킷은 타겟 장치 상의 파일 시스템에 대한 블록 크기를 설정하는 데 이용될 수 있다. 일 실시예에서, Set FS Block Size 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Block Size | 8 | 파일 시스템 동작에 대한 블록 크기 |
블록 크기는 클라이언트 장치 파일 시스템에서 이용될 수 있다. 예를 들어, 블록 크기가 64 kb인 경우, 클라이언트 장치에 파일 데이터를 쓸 때, 호스트 장치가 데이터를 보다 크거나 보다 작은 블록으로 전송하더라도 한번에 64 kb의 데이터가 써진다. 일 실시예에서, 클라이언트 장치는 데이터가 블록 크기에 따라 써지는 것을 보장하지 않지만, 성능을 위해 이용될 수 있다.
Set Socket Block Size 패킷은 타겟 장치와 호스트 장치 간의 데이터 연결에 대한 블록 크기를 설정하는 데 이용될 수 있다. 일 실시예에서, Set Socket Block Size 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
Block Size | 8 | 타겟과 호스트 간의 통신을 위한 블록 크기 |
블록 크기는 클라이언트 시스템에서 호스트 장치와 클라이언트 장치 간의 연결을 통해 데이터를 읽고 쓰는 데 이용될 수 있다. 예를 들어, 블록 크기가 64 kb인 경우, 연결로부터 데이터를 읽을 때, 클라이언트 장치는 데이터를 64 kb 블록으로서 읽으려고 시도할 수 있다. 일 실시예에서, 클라이언트 장치는 데이터가 블록 크기에 따라 처리되는 것을 보장하지 않지만, 성능을 위해 이용될 수 있다.
File Ref Lock 패킷은 제2 애플리케이션에서 사용하지 못하도록 열린 파일 참조 식별자를 잠그는 데 이용될 수 있다. 일 실시예에서, File Ref Lock 패킷은 이하의 표에 따른 포맷으로 되어 있다.
필드 이름 | 길이(단위: 바이트) | 설명 |
Header | 40 | 표준의 패킷 헤더(예를 들어, 도 2 참조) |
File Ref | 8 | 잠금될 파일의 파일 참조 |
Lock type | 8 | 파일 참조 식별자에 적용되는 잠금의 유형 |
주어진 때에 하나의 애플리케이션만이 열린 파일에 액세스할 수 있도록 파일 참조에 대한 액세스가 잠금될 수 있다. 일 실시예에서, 공유 잠금(shared lock), 배타적 잠금(exclusive lock) 및 비차단 잠금(non-blocking lock)이 지원된다. 대안의 실시예들에서, 부가의 잠금 및/또는 다른 잠금이 지원된다. 일 실시예에서, 잠금은 권고사항일 뿐이며, 애플리케이션은 파일이 잠금되어 있는지 여부를 판정하기 위해 파일을 조사할 수 있다. 일 실시예에서, 다수의 애플리케이션/프로세스가 공유 잠금을 획득할 수 있다.
상기한 메시지 및 포맷은 전체 파일 통신 프로토콜(full file communication protocol)을 지원하는 데 이용될 수 있다. 이하의 예들에서, 상기 패킷들의 일부가 프로토콜의 사용을 설명하기 위해 사용된다. 많은 기타 동작들도 역시 지원될 수 있다.
도 6은 클라이언트 장치로 데이터를 전송하는 기법의 일 실시예의 흐름도이다. 도 6의 예에서, 호스트 장치는 클라이언트 장치가 호스트 장치에 연결되어 있는지 여부를 판정할 수 있다(610). 상기한 바와 같이, 호스트 장치와 클라이언트 장치 간의 연결은 유선이거나 무선일 수 있다.
호스트 장치는 임의의 적당한 기법을 이용하여 클라이언트 장치의 존재를 검출할 수 있다. 예를 들어, 클라이언트 장치가 유선 연결을 통해 호스트 장치와 연결되어 있는 경우, 호스트 장치는 클라이언트 장치와 유선 인테페이스 간의 물리 연결을 검출하도록 구성되어 있을 수 있다. 클라이언트 장치가 무선 연결을 통해 호스트 장치와 연결되어 있는 경우, 호스트 장치는 페어링(pairing) 또는 기타 유형의 무선 연결 절차의 완료에 응답하도록 구성될 수 있다.
일 실시예에서, 클라이언트 장치가 연결되지 않은 경우(610), 호스트 장치는 클라이언트 장치가 연결되기를 기다릴 수 있다. 다른 실시예에서, 호스트 장치는 요청이 인터페이스를 통해 수신되는 경우에만 응답할 수 있다. 예를 들어, 유선 인터페이스는 클라이언트 장치와 호스트 장치 간의 통신을 개시하기 위해 사용자에 의해 눌러지는 버튼을 포함할 수 있다. 다른 예로서, 클라이언트 장치는 사용자가 호스트 장치와의 통신을 요청할 수 있게 해주는 사용자 인터페이스를 가질 수 있다.
클라이언트 장치의 연결(610)에 응답하여, 호스트 장치는 클라이언트 장치에 관한 정보를 수집할 수 있다(620). 클라이언트 장치에 관한 정보의 수집은 상기한 패킷들 중 하나 이상을 전송함으로써 달성될 수 있다. 예를 들어, 호스트 장치는 Get Device Info 패킷 및/또는 Read Directory 패킷을 전송할 수 있다. 클라이언트 장치는 요청된 정보를 호스트 장치에 제공하는 것으로 그 패킷(들)에 응답할 수 있다.
클라이언트 장치로부터 충분한 정보를 수집할 시에, 호스트 장치는 클라이언트 장치가 새로운 장치인지 여부를 판정할 수 있다(630). 즉, 호스트 장치는 클라이언트 장치가 이전에 호스트 장치에 연결된 적이 있는지 여부를 판정할 수 있다. 클라이언트 장치가 새로운 장치인 경우, 호스트 장치는 등록 절차를 수행할 수 있다(635). 등록 절차에 의해 호스트 장치는 연결을 신속히 처리하고 및/또는 백업을 위해, 예를 들어, 인증에 사용될 수 있는 클라이언트 장치에 관한 정보를 유지할 수 있다.
호스트 장치는 클라이언트 장치를 인증할 수 있다(640). 인증은 호스트 장치와 클라이언트 장치 간에, 예를 들어, 키 또는 기타 식별자를 교환하는 것에 의해 달성될 수 있다. 기타 인증 기법들도 역시 사용될 수 있다. 일 실시예에서, 호스트 장치 및 클라이언트 장치에 존재하는 대응하는 동기 서비스에 의해 인증이 수행된다.
인증 후에, 호스트 장치는 본 명세서에 기술된 패킷들을 사용하여 클라이언트 장치로 데이터를 전송할 수 있다(650). 예를 들어, 클라이언트 장치에 새로운 파일을 추가하기 위해(예를 들어, 클라이언트 장치에 새로운 미디어 파일을 로드하기 위해), 호스트 장치는 Write File 패킷을 사용하여 데이터가 클라이언트 장치 상의 파일에 써지게 할 수 있다. 하나의 세션에서 임의의 수의 데이터 전송 패킷들이 사용될 수 있다.
도 7은 호스트 장치와 클라이언트 장치 간에 데이터를 동기화시키는 기법의 일 실시예의 흐름도이다. 도 7의 예는 상기한 패킷 유형들 중 일부만을 이용한다. 그렇지만, 도 7의 예는 본 명세서에 기술된 프로토콜들 및 메시지들을 이용하여 호스트 장치와 클라이언트 장치 간에 일어날 수 있는 세션을 대표하는 것이다.
이하의 예에서, "->"는 대응하는 패킷이 호스트 장치로부터 클라이언트 장치로 전송되는 것을 나타내고, "<-"는 대응하는 패킷이 클라이언트 장치로부터 호스트 장치로 전송되는 것을 나타낸다. 패킷 유형이 먼저 열거되고, 예시적인 값을 갖는 패킷 내의 하나 이상의 필드가 열거되며, "<...>"는 부가의 필드들이 도 7의 예에 나타나 있지 않음을 나타낸다. 패킷의 데이터 섹션은, 있는 경우, "Data=..."로 나타내어져 있다. 패킷들의 리스트에 대해 먼저 설명하고, 패킷들의 리스트 이후에 세션에 대한 설명이 제공된다.
도 7의 예에서, 호스트 장치는 클라이언트 장치가 호스트 장치에 연결되어 있는지 여부를 판정할 수 있다(710). 상기한 바와 같이, 호스트 장치와 클라이언트 장치 간의 연결은 유선이거나 무선일 수 있다.
호스트 장치는 임의의 적당한 기법을 이용하여 클라이언트 장치의 존재를 검출할 수 있다. 예를 들어, 클라이언트 장치가 유선 연결을 통해 호스트 장치와 연결되어 있는 경우, 호스트 장치는 클라이언트 장치와 유선 인터페이스 간의 물리 연결을 검출하도록 구성되어 있을 수 있다. 클라이언트 장치가 무선 연결을 통해 호스트 장치와 연결되어 있는 경우, 호스트 장치는 페어링(pairing) 또는 기타 유형의 무선 연결 절차의 완료에 응답하도록 구성될 수 있다.
일 실시예에서, 클라이언트 장치가 연결되지 않은 경우(710), 호스트 장치는 클라이언트 장치가 연결되기를 기다릴 수 있다. 다른 실시예에서, 호스트 장치는 요청이 인터페이스를 통해 수신되는 경우에만 응답할 수 있다. 예를 들어, 유선 인터페이스는 클라이언트 장치와 호스트 장치 간의 통신을 개시하기 위해 사용자에 의해 눌러지는 버튼을 포함할 수 있다. 다른 예로서, 클라이언트 장치는 사용자가 호스트 장치와의 통신을 요청할 수 있게 해주는 사용자 인터페이스를 가질 수 있다.
클라이언트 장치의 연결(710)에 응답하여, 호스트 장치는 클라이언트 장치에 관한 정보를 수집할 수 있다(720). 클라이언트 장치에 관한 정보의 수집은 Get Device Info 패킷을 호스트 장치로부터 클라이언트 장치로 전송하고 Data 패킷을 클라이언트 장치로부터 호스트 장치로 전송함으로써 달성될 수 있다. 상기한 바와 같이, 클라이언트 장치에 관한 임의의 유형의 정보가 이러한 방식으로 호스트 장치에 의해 획득될 수 있다. 도 7의 예에서, 클라이언트 장치는 적어도 모델 식별자 및 파일 시스템 크기를 호스트 장치에 제공한다. 부가의 데이터 및/또는 다른 데이터도 역시 제공될 수 있다.
선택적으로, 클라이언트 장치로부터 충분한 정보를 수집하였을 때, 호스트 장치는 클라이언트 장치가 새로운 장치인지 여부를 판정할 수 있다(730). 클라이언트 장치가 새로운 장치인 경우, 호스트 장치는 선택적인 등록 절차를 수행할 수 있다(735). 호스트 장치는 클라이언트 장치를 인증할 수 있다(740). 인증은 호스트 장치와 클라이언트 장치 간에, 예를 들어, 키 또는 기타 식별자를 교환하는 것에 의해 달성될 수 있다. 기타 인증 기법들도 역시 사용될 수 있다. 일 실시예에서, 호스트 장치 및 클라이언트 장치에 존재하는 대응하는 동기 서비스에 의해 인증이 수행된다.
인증 후에, 호스트 장치는 호스트 장치와 클라이언트 장치 간에 데이터의 동기화를 시작할 수 있다. 클라이언트 장치는 클라이언트 장치 상의 경로에 대응하는 File Ref 값을 요청하고 그 경로에서 데이터를 읽을 수 있다(750). 이것은, 예를 들어, 이상에서 열거한 File Ref Open, File Ref Open Result, File Ref Read, Data 패킷들을 사용하여 달성될 수 있다. 요청된 디렉토리가 존재하지 않는 경우, 디렉토리가 생성될 수 있다(760). 요청된 데이터가 획득될 때, File Ref가 닫혀질 수 있다. 이것은 이상에서 열거한 File Ref Close 및 Status 패킷들을 사용하여 달성될 수 있다.
Make Directory 패킷은 타겟 경로가 존재하는지 여부를 판정하는 데 이용될 수 있다. 예를 들어, 이상에서 열거한 패킷들을 사용하여, 'media' 디렉토리가 존재하는지 여부를 판정하기 위해 '/media'을 타겟으로 갖는 Make Directory 패킷이 사용될 수 있다. 'media' 디렉토리가 존재하는 경우, 클라이언트 장치로부터의 그 Status 패킷은 'media' 디렉토리의 존재를 'PATH_EXISTS' 상태로 나타낼 수 있다.
업데이트될 제1 파일(예를 들어, '/media/file1.mp3')에 대해 파일 정보가 요청될 수 있다. 업데이트될 제1 파일에 관련된 정보를 요청하기 위해 Get File Info 패킷이 사용될 수 있다(770). 클라이언트 장치는 업데이트될 제1 파일에 관련된 데이터를 반환하기 위해 Data 패킷을 사용할 수 있다.
호스트 장치는 그 다음에 제1 파일을 업데이트하는 동안 사용할 File Ref 값을 요청할 수 있다. 이것은 File Ref Open Result 패킷 내의 클라이언트 장치로부터의 응답과 함께 File Ref Open 패킷을 사용하여 달성될 수 있다. 호스트 장치는 클라이언트 장치 상의 파일에 데이터를 쓰기 위해 File Ref 값을 사용할 수 있다(775). 이것은 Status 패킷에 의해 전달되는 클라이언트 장치로부터의 확인과 함께 File Ref Write 패킷을 사용하여 달성될 수 있다. 파일에의 쓰기가 완료될 때, 호스트 장치는 클라이언트 장치로부터의 Status 패킷에 의해 확인될 수 있는 File Ref를 해제(release)하기 위해 File Ref Close 패킷을 사용할 수 있다.
Make Directory 패킷은 업데이트될 제2 파일에 대한 타겟 경로가 존재하는지 여부를 판정하는 데 이용될 수 있다. 예를 들어, 이상에서 열거한 패킷들을 사용하여, 'file2.mp3' 파일이 존재하는지 여부를 판정하고 파일에 관련된 정보를 가져오기 위해 '/media/file2.mp3'을 타겟으로 갖는 Get File Info 패킷이 사용될 수 있다(780). 예를 들어, 'file2.mp3' 파일이 존재하는 경우, 클라이언트 장치로부터의 Status 패킷은 'PATH_DOES_NOT_EXIST' 상태를 반환할 수 있다.
호스트 장치는 그 다음에 제2 파일을 업데이트하는 동안 사용할 File Ref 값을 요청할 수 있다. 이것은 File Ref Open Result 패킷 내의 클라이언트 장치로부터의 응답과 함께 File Ref Open 패킷을 사용하여 달성될 수 있다. 호스트 장치는 클라이언트 장치 상의 파일에 데이터를 쓰기 위해 File Ref 값을 사용할 수 있다(785). 이것은 Status 패킷에 의해 전달되는 클라이언트 장치로부터의 확인과 함께 File Ref Write 패킷을 사용하여 달성될 수 있다. 파일에의 쓰기가 완료될 때, 호스트 장치는 클라이언트 장치로부터의 Status 패킷에 의해 확인될 수 있는 File Ref를 해제(release)하기 위해 File Ref Close 패킷을 사용할 수 있다.
임의의 수의 파일이 유사한 방식으로 업데이트될 수 있다. 동기화가 완료되지 않은 경우(790), 부가의 파일들이 상기한 바와 같이 업데이트될 수 있다. 동기화가 완료된 경우(790), 동기화 세션이 종료될 수 있다.
본 발명의 다른 측면들은 멀티플렉싱된 데이터 스트림 프로토콜(multiplexed data stream protocol)에 관한 것이다. 이러한 프로토콜의 사용에 의해, 한 장치 상의 다수의 애플리케이션(또는 동일한 애플리케이션)이 상대방 장치 상의 하나 이상의 애플리케이션과 임의의 수의 다중 동시 세션(multiple concurrent session)을 유지할 수 있고, 애플리케이션이 동적으로 세션의 생성 또는 그의 세션의 닫기를 야기하기 때문에, 동시 세션의 수가 시간에 따라 변할 수 있다. 이러한 프로토콜은 한 장치 및 다른 장치(예를 들어, 호스트) 둘다에서 사용되는 인터페이스(예를 들어, USB 인터페이스 또는 BLUETOOTH 인터페이스)의 전송과 독립적이 되도록 구현될 수 있으며, 다수의 독립적인 연결이 동일한 공통의 링크/인터페이스(예를 들어, USB 인터페이스)를 통해 유지될 수 있다. 일 실시예에서, 하나의 USB 세션이 설정되고, 그 하나의 USB 세션을 통해 임의의 변경가능한 수의 다중 동시 세션이 터널링된다. 일 실시예에서, USB와 같은 특정의 인터페이스가 프레이밍(framing)을 지원하거나, COBS (constant overhead byte stuffing) 또는 PPP/SLIP 스타일의 프레이밍과 같은 어떤 프레이밍 프로토콜이 추가되어야만 한다. 다수의 독립적인 연결이 서로 다른 목적을 위해 동시에 사용될 수 있다(예를 들어, 다른 데이터(예를 들어, 이메일 또는 설정 정보 또는 소프트웨어 위젯)도 역시 장치들 간에 교환되고 있는 동안에 미디어 파일과 같은 파일이 전송될 수 있으면서 주소록 내의 연락처와 같은 구조화된 데이터가 장치들 간에 교환 및/또는 동기화될 수 있다). 다수의 독립적인 연결을 지원할 수 있는 것이 다수의 애플리케이션이 동시에 실행될 수 있게 해주는 멀티-태스킹 운영 체제(OS)를 갖는 장치들에 특히 유용하지만, 이러한 OS가 꼭 필요한 것은 아니다.
도 14b는, 본 발명의 일 실시예를 사용하여, 임의의 수의 다중 "클라이언트" 애플리케이션(예를 들어, 구조화된 데이터를 동기화시키는 동기화 소프트웨어, 파일을 전송하는 파일 전송 소프트웨어, 백업 소프트웨어, 기타)이 USB(유선 또는 무선) 또는 BLUETOOTH와 같은 비네트워크 인터페이스를 통해 다중 동시 연결 또는 세션을 유지할 수 있는 방법을 나타낸 것이다. 도 14a는, 종래 기술에서, 장치들 간에 USB 연결을 사용할 수 있는 각각의 장치 상에 사실상 단지 하나의 클라이언트 애플리케이션이 있는 것을 나타낸 것이다. 도 14a의 상호연결된 시스템(1401)에서, 호스트 상의 클라이언트 애플리케이션(1402)은 그의 USB 인터페이스(1405) 및 연결(1407)을 통해 데이터를 전송 및 수신하기 위해 PTP(picture transfer protocol) 프로토콜(1403)을 사용하고, 장치 상의 클라이언트 애플리케이션(1411)은 장치의 USB 인터페이스(1409)를 통해 데이터를 전송 및 수신하기 위해 PTP 프로토콜(도시 생략)을 사용한다. 연결(1407) 및 USB 인터페이스(1405, 1409)는 단지 하나의 연결 또는 세션만을 지원한다. 이와 반대로, 상호연결된 시스템(1421)은 연결(1429) 및 USB 인터페이스(1427, 1431)를 통해 다중 독립 동시 연결 또는 세션을 지원한다. 호스트 상의 다수의 클라이언트 애플리케이션(1423)은 다수의 클라이언트 애플리케이션(1435)에 있는 그 각자의 상대방과 독립 동시 연결 또는 세션을 유지할 수 있다. 예를 들어, 도 8에 도시된 시스템의 경우에, 장치(801) 상의 동기화 소프트웨어(805)가 호스트 상의 동기 소프트웨어(835)와 열려있는 연결(소프트웨어(807)와 소프트웨어(831) 간의 연결과 독립적임)을 유지하고 있는 동안에, 장치(801) 상의 파일 전송 소프트웨어(807)는 호스트(803) 상의 미디어 소프트웨어(831)(예를 들어, iTunes)(또는 파일 전송 소프트웨어(833))와 열린 채로 유지되는 연결을 가질 수 있다. 다중 독립 동시 연결이 호스트 및 장치 둘다에서 TCP-유사 프로토콜을 통해 구현될 수 있으며, 이 때 TCP-유사 헤더를 갖는 TCP-유사 패킷이 USB 인터페이스(1427, 1431)와 같은 비네트워크 인터페이스를 통해 전송된다. TCP-유사 패킷은 호스트 상의 '인터페이스를 통한 TCP(TCP over interface)'(1425) 소프트웨어 및 장치 상의 '인터페이스를 통한 TCP'(1433) 소프트웨어에 의해 처리된다. '인터페이스를 통한 TCP'(1425) 소프트웨어는 도 8의 '인터페이스를 통한 TCP' 소프트웨어(821)와 동일하거나 그와 유사할 수 있으며, '인터페이스를 통한 TCP'(1431) 소프트웨어는 도 8의 '인터페이스를 통한 TCP' 소프트웨어(841)와 동일하거나 그와 유사할 수 있다. TCP-유사 패킷은 설정된 연결을 갖는 대응하는 발신지(예를 들어, 송신측) 및 목적지(예를 들어, 수신측) 애플리케이션과 연관되어 있는 각자의 발신지 및 목적지 포트를 TCP-유사 헤더에 명시하고, 이들 포트의 명시는 독립 동시 연결들이 유지될 수 있게 해준다. 본 명세서에 기술된 방법은 또한 연결이 갑작스럽게 또는 예측불가능하게 단절되는 경우(사용자가 무선 셀룰러 전화로 받은 전화 호에 응답하기 위해 장치를 그의 USB 케이블 또는 크레이들(cradle)로부터 뽑음으로써 장치를 호스트와 단절시킬 때 등) 정상적으로 복원하는 메카니즘을 제공한다. TCP-유사 프로토콜은, 세션이 단절되었을 때, 발신지 및 목적지 애플리케이션에 통지를 제공하고, 이 통지는 애플리케이션에서 통지를 처리하여 그의 상태를 원상 복구하고 데이터에 대한 임의의 원하는 정정을 구현하기 위해 사용될 수 있다. TCP-유사 프로토콜은 발신지 및 목적지 애플리케이션이 장애있는 연결 세션을 전체적으로 또는 부분적으로 무시함으로써(예를 들어, 부분적으로 수신된 파일 또는 부분적으로 수신된 일련의 구조화된 데이터를 삭제하고, 2개의 장치가 다시 연결될 때 이전에 실패한 연결 세션에서 교환하려고 시도했었던 데이터를 교환하기 위해 그 장치들의 발신지 및 목적지 애플리케이션 간에 새로운 연결을 설정하게 하는 오류 메시지 또는 상태 메시지를 설정함으로써) 신속하고 정상적으로 통신 단절로부터 복원할 수 있게 해줄 수 있다.
TCP-유사 프로토콜은 또한 TCP-유사 프로토콜 상부에서 실행되는 파일 전송 프로토콜에서도 사용될 수 있고, 이 파일 전송 프로토콜은 2개의 장치 간의 파일 전송을 제공하기 위해 사용될 수 있으며, 패킷(예를 들어, TCP-유사 패킷)으로 전송되는 파일이 수신측에서 재구성될 수 있고 데이터 전부(다수의 TCP-유사 패킷으로 수신됨)가 수신된 후에 유효성 검사될 수 있다(또는 파일의 일부분이 수신될 때 부분적으로 유효성 검사될 수 있다). 파일은 종래의 체크섬 연산(checksum operation) 또는 해쉬 연산(hash operation)을 사용하여 유효성 검사될 수 있다. 이러한 TCP-유사 프로토콜의 상부에 계층을 이루고 있을 수 있는 양방향 바이트 스트림을 처리하는 임의의 프로토콜과 같이, 많은 서로 다른 유형의 소프트웨어들이 이러한 TCP-유사 프로토콜에서 사용될 수 있다. 이들 서로 다른 유형의 소프트웨어로는 telnet(예를 들어, 대화형 텔넷 세션의 경우), rsync, 다른 장치 상의 애플리케이션을 원격 디버깅하는 gdb over IP, 기타 등등이 있을 수 있다. 게다가, 이러한 TCP-유사 프로토콜 상부에서 실행되는 소프트웨어는 원자적 트랜잭션(atomic transaction)의 사용을 비롯한 트랜잭션-유형 프로토콜을 구현할 수 있다. TCP-유사 프로토콜은 이러한 TCP-유사 프로토콜의 상부에서 실행되는 하나 이상의 소프트웨어 계층이, 다른 시스템에서 실행되는 다른 소프트웨어와 연결을 설정하여 유지할 책임을 질 필요 없이, 그의 서비스 및 기능을 제공할 수 있게 해준다.
용어 "장치" 및 "호스트"가 바꾸어 사용될 수 있다, 즉 "장치"가 장치 및 호스트 둘다에 적용된다는 것을 잘 알 것이다. 호스트가 장치이고, 장치가 호스트로 간주될 수 있다. 그렇지만, 어떤 실시예들에서, 세션이, 호스트로부터 장치로, 호스트에 의해서만 개시될 수 있고, 그 경우에 호스트가 장치와 바꾸어 사용될 수 없다. 또한, 본 명세서에 기술된 TCP-유사 프로토콜이 독립적인 연결들의 흐름 제어 및 멀티플렉싱을 지원하는 신뢰성있는 전송 메카니즘을 제공하는 통신 프로토콜의 일례이고, 다른 대안으로서 유사한 메카니즘을 제공하는 기타 프로토콜들이 본 발명의 적어도 어떤 실시예들에서 사용될 수 있다는 것을 잘 알 것이다. 또한, 본 발명의 적어도 어떤 실시예들에서, TCP 하드웨어 가속기와 같은 하드웨어가 본 명세서에 기술된 소프트웨어를 전체적으로 또는 부분적으로 대체하기 위해 사용될 수 있다는 것을 잘 알 것이다.
도 8은 (장치 상의) 인터페이스(823) 및 (호스트 상의) 인터페이스(847)를 통해 연결되어 있는 상호연결된 장치(801) 및 호스트(803)의 일례를 나타낸 것이다. 이들 인터페이스는 USB 또는 BLUETOOTH 인터페이스와 같은 비네트워크 인터페이스로 간주될 수 있다. 환언하면, LAN(local area network)과 같은 컴퓨터 네트워크에 연결하는 데 사용되는 것이 아니라 주변 장치(예를 들어, 마우스, 키보드, 저장 장치)에 사용되는 인터페이스가 호스트(803)와 장치(801)를 연결시키는 데 사용된다. 장치(801)는 컴퓨터 네트워크에 연결하도록 설계되어 있는 인터페이스(817)를 포함하고, 호스트(803)는 인터넷과 같은 네트워크에 연결하는 데도 사용되는 인터페이스(845)(WiFi, 이더넷 또는 전화 모뎀 등)를 포함한다. 인터페이스(817)는 TCP/IP 소프트웨어 스택(815)에 의해 처리되는 TCP/IP 패킷을 전송/수신하기 위해 결합되어 있고, 인터페이스(817) 및 TCP/IP 소프트웨어 스택(815)은 장치(801)에 종래의 인터넷 또는 네트워크 연결을 제공한다. 인터페이스(845)는 TCP/IP 소프트웨어 스택(843)에 의해 처리되는 TCP/IP 패킷을 전송/수신하기 위해 결합되어 있고, 인터페이스(845) 및 TCP/IP 소프트웨어 스택(843)은 호스트(803)에 종래의 인터넷 또는 네트워크 연결을 제공한다.
호스트(803)는 인터페이스(823, 847)를 통해 장치(801) 상의 클라이언트 애플리케이션(805, 807, 809)과 데이터 및/또는 파일을 교환할 수 있는 몇개의 클라이언트 애플리케이션(831, 833, 835, 837)을 포함한다. 도 8은 호스트(803) 및 장치(801) 둘다에 있는 어떤 클라이언트 애플리케이션의 일례를 나타낸 것이며, 장치 및 호스트 중 어느 하나 또는 그 둘다에 더 많은 또는 더 적은 또는 다른 클라이언트 애플리케이션이 있을 수 있다. 도 8에 도시된 예에서, 호스트(803) 상의 클라이언트 애플리케이션은 소프트웨어 모듈들 간의 상호통신(intercommunication)을 제공하는 소켓 API(839)를 통해 '인터페이스를 통한 TCP' 소프트웨어(841) 및 TCP/IP 소프트웨어 스택(843)과 통신을 한다. 소켓 API(839)는, 소켓 API에 대한 호출에 응답하여, 스트림 기반 프로토콜에 대한 세션의 각 종단점에 열린 소켓을 제공한다. 소켓 API(819)는 장치(801)에서 유사한 기능을 제공하여, 생성될 열린 소켓이 TCP/IP 소프트웨어 스택(815)과 '인터페이스를 통한 TCP' 소프트웨어(821) 간의 통신을 설정하고 유지할 수 있게 해주고 또 클라이언트 애플리케이션(805, 807, 809)이 (선택적인 게이트키퍼(811)를 통해) TCP/IP 소프트웨어 스택과 통신을 설정하고 유지할 수 있게 해준다. 통상적으로, 한쪽에 있는 각각의 클라이언트 애플리케이션은 상대방측에 있는 대응하는 클라이언트 애플리케이션과 연결을 유지하도록 구성되어 있다. 예를 들어, 동기화 소프트웨어(835)는 장치들 간에 데이터(예를 들어, 구조화된 데이터 또는 위젯, 기타)를 교환하기 위해 동기화 소프트웨어(805)와 연결을 유지하도록 구성되어 있다. 동기화 소프트웨어(835) 및 동기화 소프트웨어(805)의 일례가 2007년 1월 7일자로 출원된, 발명의 명칭이 "Synchronization Methods and Systems(동기화 방법 및 시스템)"인 미국 특허 출원 제11/650,730호에 제공되어 있으며, 이 미국 출원은 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다. 미디어 소프트웨어(831)(iTunes와 같은 미디어 플레이어일 수 있음)는 파일 전송 소프트웨어(807)(장치 상의 iTunes와 같은 미디어 플레이어일 수 있음)와 연결을 유지하도록 구성되어 있다. 어떤 실시예들에서, 이 파일 전송 소프트웨어는 또한 파일 전송 소프트웨어(833)와도 연결을 유지하도록 구성되어 있을 수 있다. 파일 공유 소프트웨어(809)는 파일 공유 소프트웨어(837)와 연결을 유지하도록 구성되어 있다. 이들 연결은 게이트키퍼(811)와 같은 하나 이상의 선택적인 게이트키퍼 및 클라이언트 애플리케이션(831, 833, 835, 837)과 '인터페이스를 통한 TCP' 소프트웨어(841) 사이에 있을 수 있는 호스트 상의 대응하는 게이트키퍼(도시 생략)를 통해 유지될 수 있다. 적어도 어떤 실시예들에서, 이 게이트키퍼는 이러한 연결이 요망되는 경우 장치와 호스트 사이에 인증된 연결을 생성하는 역할을 한다. 도 8의 게이트키퍼는 도 1에 도시된 게이트키퍼 클라이언트(115) 및 게이트키퍼(180)와 동일하거나 그와 유사할 수 있다. 어떤 애플리케이션(예를 들어, 파일 공유, telnet 또는 gdb over IP)에 대한 연결들은 장치 상의 게이트키퍼를 완전히 우회할 수 있다.
TCP/IP 소프트웨어 스택(815), '인터페이스를 통한 TCP' 소프트웨어(821) 및 '인터페이스를 통한 TCP' 소프트웨어(841)의 동작이 도 9 내지 도 12의 설명과 관련하여 이하에서 더 기술된다. 이들 소프트웨어 컴포넌트는 본 명세서에 기술되는 멀티플렉싱된 데이터 스트림 프로토콜을 제공한다.
장치(801)는 플래쉬 메모리, 하드 드라이브, 휘발성 반도체 메모리, 기타 등등을 비롯한 복수의 저장 매체들 중 임의의 저장 매체에 저장될 수 있는 데이터(813)를 포함한다. 이 데이터는 주소록, 일정표, 할 일 항목, 및 메모에 대한 구조화된 데이터를 포함할 수 있으며, 이 데이터는 본 명세서에 기술된 바와 같이 동기화 소프트웨어(805) 및 동기화 소프트웨어(835)를 통해 동기화될 수 있다. 게다가, 데이터(813)는 또한 음악에 대한 MP3 파일, 영화에 대한 MPEG 4 파일 또는 기타 오디오 비쥬얼 미디어(audio visual media)와 같은 미디어 파일도 포함할 수 있다. 데이터(813)는 또한 기타 유형의 데이터(예를 들어, 워드 프로세싱 파일, 기타) 또는 심지어 위젯과 같은 실행가능 프로그램, 설정 정보에 관한 데이터, 그리고 이메일 또는 전화 계정 정보, 기타 등등도 포함할 수 있다. 장치측에 있는 다양한 클라이언트 애플리케이션들이 데이터에 액세스하기 위해 데이터(813)가 들어 있는 저장 장치와 통신을 한다는 것을 잘 알 것이다. 예를 들어, 파일 전송 소프트웨어(807)는 파일을 전송하기 위해 데이터(813)를 읽거나 쓸 수 있다. 호스트 장치(803)가 또한 플래쉬 메모리, 하드 드라이브 또는 휘발성 메모리 장치(예를 들어, DRAM)와 같은 데이터 저장 매체, 또는 호스트 장치(803) 상의 클라이언트 애플리케이션에 의해 사용되는 데이터를 저장하는 기타 저장 매체도 포함하고 있다는 것을 잘 알 것이다.
도 8은 호스트 장치(803)의 일례를 나타낸 것인 반면, 도 13은 호스트 장치에 대한 대안의 소프트웨어 아키텍처를 나타낸 것이다. 호스트 장치(1301)는 애플리케이션(1303, 1305, 1307)을 비롯한 몇개의 클라이언트 애플리케이션을 포함하고 있으며, 각각의 애플리케이션은 소켓 API(1309)를 통해 TCP/IP 소프트웨어 스택(1313) 및 '인터페이스를 통한 TCP' 소프트웨어(1311)에 결합될 수 있다. TCP/IP 소프트웨어 스택(1313)은 또한 USB 또는 BLUETOOTH 인터페이스(1315)를 통해 패킷을 전송 및 수신하기 위해 소켓 API(1309)를 통해 '인터페이스를 통한 TCP' 소프트웨어(1311)에도 결합될 수 있다. 루프백 인터페이스(1317)는 TCP/IP 소프트웨어 스택(1313)과 '인터페이스를 통한 TCP' 소프트웨어(1311) 간의 패킷 경로를 제공하기 위해 TCP/IP 소프트웨어 스택(1313)에 결합되어 있다. '인터페이스를 통한 TCP' 소프트웨어(1311)는 도 8의 인터페이스(847)와 유사한 인터페이스(1315)에 결합되어 있다. TCP/IP 소프트웨어 스택(1313)은 도 8에 도시된 인터페이스(817)와 유사한 인터페이스(1319)에 결합되어 있다. 도 13에 도시된 호스트와 도 8에 도시된 호스트 간의 주된 차이점은 인터페이스(847)를 통해 수신 및 전송되는 TCP-유사 패킷이 TCP/IP 소프트웨어 스택(843)에 의해서가 아니라 '인터페이스를 통한 TCP' 소프트웨어(841)에 의해 처리된다는 것이고, 반면에, 도 13에 도시된 호스트 장치의 경우에는, 인터페이스(1315)를 통해 전송 및 수신되는 TCP-유사 패킷이 '인터페이스를 통한 TCP' 소프트웨어(1311) 및 TCP/IP 소프트웨어 스택(1313) 둘다에 의해 처리된다는 것이다.
도 9는 본 발명의 일 실시예에 따른, 호스트 및 장치와 같은 2개의 시스템 간에 데이터를 교환하는 방법의 일례를 나타낸 플로우차트이다. 이 방법은 한쪽에서 시작하고 2개의 장치 간의 데이터 교환이 완료된 후에 상대방측에서 종료된다. 동작(901)에서, USB 또는 BLUETOOTH 인터페이스와 같은 비네트워크 인터페이스를 통해 지원되는 독립적인 세션을 동시에 갖는 복수의 독립적인 애플리케이션 중 적어도 하나의 애플리케이션으로부터 데이터 스트림이 수신된다. 이 데이터 스트림은 소켓 인터페이스를 통해 수신될 수 있다. 예를 들어, 미디어 소프트웨어(831)에 의해 제어되는 미디어 파일은 소켓 인터페이스를 통해 '인터페이스를 통한 TCP' 소프트웨어(841)로 미디어 파일을 전송할 수 있다. 동작(903)에서, 데이터 스트림 내의 데이터에 대한 패킷이 생성되고, 이들 패킷은 TCP-유사 헤더와 같은 헤더를 패킷에 포함하고 있다. 예를 들어, '인터페이스를 통한 TCP' 소프트웨어(841)는 데이터 스트림으로부터 패킷을 생성할 수 있고, 이들 패킷 각각은 TCP-유사 헤더를 각각의 패킷에 포함하고 있다. 동작(905)에서, 이들 패킷은 인터페이스(847)와 같은 비네트워크 인터페이스를 통해 전송된다. 차례로, 이들 패킷은 인터페이스(823)와 같은 유사한 비네트워크 인터페이스를 통해 상대방 시스템에서 수신된다. 그 다음에, 동작(909)에서, 패킷 내의 데이터가, 예를 들어, '인터페이스를 통한 TCP' 소프트웨어(821)에 의해 추출된다. 데이터의 목적지는 패킷 내의 포트 식별자로부터 결정될 수 있고, 이 포트 식별자는 데이터가 수신측 장치 상의 목적지 애플리케이션으로 전송 또는 제공될 수 있게 해준다. 데이터가 MP3 파일 또는 영화 파일, 기타 등등과 같은 파일의 일부인 경우, 동작(911)에서 그 파일이 재구성되고 선택적으로 유효성 검사된다. 이 유효성 검사는 공지된 바와 같이 파일 전체에 대한 체크섬 또는 해쉬 연산의 사용을 포함할 수 있다. 연결 동안의 임의의 시점에서, 사용자 또는 시스템에서 단절이 일어나게 하는 경우(예를 들어, USB 케이블이 장치로부터 뽑아지는 경우), 양측에서 그들의 상태를 원상 복구하고 그들의 소켓을 닫아, 2개의 장치 간의 TCP-유사 연결을 종료한다. 이것은 호스트 상의 클라이언트 및 장치 상의 서비스에 세션이 끝났음을 통지한다. 또한, 장치 상의 서비스 또는 호스트 상의 클라이언트는 언제라도 세션을 닫을 수 있으며, 상대방측은 세션이 종료되었음을 통지받게 된다.
도 10은 본 발명의 일 실시예에 따른 초기화 또는 설정 방법의 일례를 제공한다. 동작(1001)에서, 호스트의 '인터페이스를 통한 TCP' 소프트웨어는 소켓 API를 통해 제공되는 포트 "X"와 같은 포트를 통해 연결하라는 호출을, 호스트상의 iTunes와 같은 애플리케이션으로부터 수신한다. 이 호출에 응답하여, 호스트의 '인터페이스를 통한 TCP' 소프트웨어는, 동작(1003)에서, SYN TCP 패킷과 같은 TCP-유사 패킷을 생성하고, 패킷이 USB 인터페이스 또는 도 8에 도시된 인터페이스(847)와 같은 비네트워크 인터페이스를 통해 전송되게 한다. 장치의 '인터페이스를 통한 TCP' 소프트웨어는 장치의 비네트워크 인터페이스(예를 들어, USB 인터페이스일 수 있는 인터페이스(823))를 통해 TCP-유사 패킷을 수신하고, 소켓을 받아(get) TCP/IP 소프트웨어 스택(815)과 연관된 루프백 주소 상의 포트와 같은 포트를 통해 그 소켓을 연결하라는 하나 이상의 호출을 발생한다. 동작(1007)에서, 장치는 synack TCP 패킷을 생성하고, '인터페이스를 통한 TCP' 소프트웨어는 장치의 비네트워크 인터페이스를 통해 호스트의 비네트워크 인터페이스로 synack TCP-유사 패킷을 전송한다. 동작(1009)에 나타낸 바와 같이, 장치 및 호스트 둘다에 있는 '인터페이스를 통한 TCP' 소프트웨어는 어느 포트/세션이 어느 소켓과 연관되어 있는지의 정보를 유지할 수 있다.
도 11은 호스트로부터 장치로 데이터를 전송하는 방법의 일례를 나타낸 것이다. 동작(1101)에서, 호스트 상의 iTunes와 같은 호스트 상의 애플리케이션은 애플리케이션의 소켓을 통해 호스트 상의 '인터페이스를 통한 TCP' 소프트웨어로 데이터를 전송한다. 예를 들어, 호스트(803)의 경우에, 미디어 소프트웨어(831)는 애플리케이션에 대해 열린 소켓을 통해 '인터페이스를 통한 TCP' 소프트웨어(841)로 데이터를 전송한다. 동작(1103)에서, 호스트 상의 '인터페이스를 통한 TCP' 소프트웨어는 데이터를 수신하고, 패킷 내에 TCP-유사 헤더 및 그 데이터 중 적어도 일부를 갖는 TCP-유사 패킷을 생성하며, 이 패킷을 USB 인터페이스 또는 도 8에 도시된 인터페이스(847)와 같은 비네트워크 인터페이스를 통해 전송한다. 동작(1105)에서, 장치 상의 '인터페이스를 통한 TCP' 소프트웨어는 패킷으로부터 데이터를 추출하고, 이 데이터(때때로 "페이로드"라고 함)를 패킷 내의 포트들에 의해 지정된 소켓 상으로 전송한다. 도 8의 예에서, '인터페이스를 통한 TCP' 소프트웨어(821)는 인터페이스(823)를 통해 수신된 데이터를 추출하고, 이 데이터를 소켓으로 전송하며, 이 소켓은 데이터가 TCP/IP 소프트웨어 스택(815)에 제공되게 한다. 동작(1107)에서, TCP/IP 소프트웨어 스택(815)과 같은 장치 상의 TCP/IP 스택은 장치 상의 '인터페이스를 통한 TCP' 소프트웨어로부터 데이터를 획득하고, IP 및 TCP 헤더를 갖는 패킷을 생성한다. 이 경우에, IP 주소는 TCP/IP 스택에 대한 루프백 주소일 수 있다. 예를 들어, TCP/IP 소프트웨어 스택(815)은 도 13에 도시된 루프백 인터페이스와 같은 루프백 인터페이스(도시 생략)를 포함할 수 있다. 패킷은 루프백 인터페이스로부터 반환되고, 동작(1107)에서, TCP/IP 스택은 TCP 및 IP 헤더를 제거하고 데이터를 소켓을 통해 애플리케이션으로 전송한다. 애플리케이션이 호스트 상의 iTunes 애플리케이션인 도 11에 도시된 예에서, 장치 상의 수신측 애플리케이션은 장치 상의 미디어 플레이어의 일부분일 수 있는 파일 전송 소프트웨어(807)일 수 있다.
도 12는 장치로부터 호스트로 데이터를 전송하는 방법의 일례를 나타낸 것이다. 동작(1201)에서, 동기화 소프트웨어(805) 또는 미디어 플레이어 소프트웨어와 같은 장치 상의 애플리케이션은 애플리케이션에 대한 소켓을 통해 TCP/IP 소프트웨어 스택(815)과 같은 장치 상의 TCP/IP 스택 소프트웨어로 데이터를 전송한다. 동작(1203)에서, TCP/IP 스택 소프트웨어는 데이터를 패킷들로 쪼개고 TCP 및 IP 헤더를 데이터와 함께 포함시켜 패킷을 생성한다. IP 헤더 내의 IP 주소는 패킷이 소프트웨어 스택(815)과 같은 TCP/IP 소프트웨어 스택으로 반환되게 하는 루프백 주소일 수 있다. 동작(1205)에서, 패킷은 루프백 주소로 보내지고 그로부터 반환되어 TCP/IP 소프트웨어 스택에 의해 수신되며, 이 TCP/IP 소프트웨어 스택은 TCP 및 IP 헤더를 제거하고 그 데이터를 데이터 스트림으로서 장치 상의 '인터페이스를 통한 TCP' 소프트웨어(821)와 같은 '인터페이스를 통한 TCP' 소프트웨어로 전송한다. 동작(1207)에서, '인터페이스를 통한 TCP' 소프트웨어는 TCP/IP 소프트웨어 스택(815)으로부터 데이터를 수신하고, 패킷화된 데이터 및 TCP-유사 헤더를 포함하는 패킷을 생성하며, 이 패킷을 USB 프로토콜을 사용하여 인터페이스(823)와 같은 USB 인터페이스를 통해 전송하기 위해 USB 드라이버를 호출한다. 동작(1209)에서, 이들 패킷은 장치의 USB 인터페이스로부터 호스트 상의 인터페이스(847)와 같은 호스트의 USB 인터페이스로 전송된다. 그 다음에, 동작(1211)에서, '인터페이스를 통한 TCP' 소프트웨어(841)와 같은 호스트 상의 '인터페이스를 통한 TCP' 소프트웨어는 패킷을 수신하고, TCP-유사 헤더를 제거하며, 그 데이터를, 예를 들어, 소켓 API를 통해 수신측 애플리케이션으로 전송한다.
도 15는 2개의 장치 간에 파일을 교환하는 방법의 일례를 제공한다. 이 경우에, 데이터는 통상적으로 연락처 정보, 기타 등등과 같은 동기화되는 구조화된 데이터가 아니다. 오히려, 데이터는 파일 전체를 구성한다. 동작(1501)에서, 데이터가 인터페이스(823) 또는 인터페이스(847)와 같은 인터페이스를 통해 TCP-유사 헤더를 갖는 패킷으로 전송된다. 동작(1503)에서, 이들 패킷은 상대방 시스템 상의 다른 인터페이스를 통해 수신되고, 파일을 재조립할 준비를 하기 위해 다수의 패킷으로부터 데이터가 추출된다. 그 다음에, 동작(1505)에서, 파일이 재구성된다. 이것은 파일에 대한 데이터 전부가 수신된 후에 일어날 수 있거나, 데이터가 수신되고 있을 때 일어날 수 있다. 파일 전송 동안에 연결이 끊어지는 경우, 장치들이 재연결될 때 파일이 전송될 수 있도록 파일이 성공적으로 전송되지 않았다는 것을 나타내기 위해 오류 메시지 및/또는 상태 메시지가 저장된다. 파일에 대한 데이터 전부가 수신된 후에 파일이 유효성 검사될 수 있거나, 데이터가 수신되고 있을 때 파일이 일부분씩 유효성 검사될 수 있다. 유효성 검사는 동작(1507)과 같은 선택적인 동작일 수 있고, 예를 들어, 종래의 체크섬 연산 또는 해쉬 연산을 사용하여 수행될 수 있다. 도 15의 방법에 사용되는 패킷은 파일 전송 프로토콜의 일부인 정보를 포함할 수 있다. 예를 들어, 패킷은 미리 정해진 패킷 포맷을 갖는 패킷 유형 및 이 패킷 유형과 연관된 패킷 기능의 표시를 포함할 수 있다. 패킷 기능은 파일 전송 프로토콜 소프트웨어의 동작을 지정할 수 있다. 단절이 있는 경우에 오류 메시지 또는 상태 메시지는, 연결이 재설정될 때 파일이 전송될 수 있도록, 연결이 중단되기 전에 일부만이 전송된 파일의 식별자를 적어도 포함할 수 있다.
이하는 도 8 내지 도 13, 도 14b 및 도 15에 도시된 하나 이상의 실시예의 구현에 대한 설명이며, 이 구현은 장치 및 호스트가 USB를 통해 통신을 할 수 있게 해준다. 이 구현은 장치 통신 프로토콜(Device Communication Protocol)이라고 할 수 있으며, 이 장치 통신 프로토콜은 (예를 들어, iTunes 미디어 동기화를 위한) 파일 전송 소프트웨어(807) 및 구조화된 데이터 동기화(동기화 소프트웨어(805) 등)와 같은 다수의 서비스가 부가의 USB 종단점을 필요로 하지 않고 장치와 동시에 통신을 할 수 있게 해주는 데 사용될 수 있다. 이 구현에서 통신 프로토콜은 벤더 고유의 인터페이스로서 구현된다. 벤더 고유의 인터페이스는 2개의 종단점, 즉 벌크 입력(Bulk Input) 종단점 및 벌크 출력(Bulk Output) 종단점을 이용한다.
이 프로토콜이 정확히 말해서 고전적인 TCP가 아닌 반면에, 흐름 제어, 연결 설정/종료 및 멀티플렉싱을 위해 TCP-유사 메카니즘을 사용한다.
이 장치 통신 프로토콜에 따른 인터페이스는 다음과 같은 인터페이스를 찾아냄으로써 식별된다.
- 장치의 벤더 ID가 Apple (0x05 AC)임
- 인터페이스 클래스가 벤더 고유임(255)
- 인터페이스 서브클래스가 254임
- 인터페이스 프로토콜이 2임
인터페이스 #1 - 벤더 고유
대안의 설정 0
종단점의 수 2
인터페이스 클래스: 255 (벤더 고유)
인터페이스 서브클래스: 254 (벤더 고유)
인터페이스 프로토콜: 2
종단점 0x85 - 벌크 입력(Bulk Input)
주소: 0x85 (IN)
속성: 0x02 (벌크 동기화 없는 데이터 종단점)
최대 패킷 크기: 512
폴링 간격: 0 (종단점이 결코 NAK하지 않음)
종단점 0x04 - 벌크 출력(Bulk Output)
주소: 0x04 (OUT)
속성: 0x02 (벌크 동기화 없는 데이터 종단점)
최대 패킷 크기: 512
폴링 간격: 0 (종단점이 결코 NAK하지 않음)
1) 메시지 헤더
모든 데이터가 메시지 형태로 전송된다. 모든 메시지가 이하의 헤더로 시작한다. 모든 헤더가 네트워크 바이트 순서로 되어 있다.
AppleUSBMobileDeviceMessageHeader
+-----+-----+-----+-----+-----+-----+-----+-----+
|Type(32 비트) | Length(32 비트) |
+-----+-----+-----+-----+-----+-----+-----+-----+
2개의 정의된 메시지 유형이 있다:
0 - 버전 메시지
6 - TCP 메시지
길이 필드는 수신된 USB 데이터그램이 올바른 크기이었는지를 검증하는 데 사용된다. 이 길이는 메시지 헤더의 크기를 포함한다. USB는 데이터를 패킷으로 전송한다. 벌크 USB 종단점의 경우, 최대 패킷 크기가 속도에 의해 결정된다. 전체 크기의 패킷(full sized packet)을 계속 전송하고 있는 한, 데이터가 모두 프레임의 일부인 것으로 간주된다. 프레임을 끝내기 위해, 최대 패킷 크기보다 작은 패킷이 전송되어야만 한다. 프레임이 정확히 2개의 전체 크기의 패킷의 경계에서 정상적으로 끝나는 경우('프레임 크기 % 최대 패킷 크기'가 0인 경우), 프레임의 끝을 나타내기 위해 0 길이의 패킷(zero length packet)이 전송될 수 있다. 헤더 내의 길이 필드가 수신된 프레임의 크기와 일치해야만 한다. 일치하지 않는 경우, 프레임이 폐기되어야만 한다. 장애를 추적하기 위해 오류가 로그되어야만 한다. 대부분의 경우에, 후속 프레임도 역시 엉망으로 되며 폐기되어야만 한다. 이러한 오류는 일어나서는 안된다. 그 손실이 TCP 메시지로 검출되고, 그 TCP 연결이 종료된다.
2) 버전 메시지
사용될 프로토콜의 버전을 협상하기 위해 시작 시에 버전 메시지가 교환된다. 장치가 나타날 때, 장치는 버전 메시지를 기다려야만 한다. 호스트는 제1 버전 메시지를 전송할 책임이 있다. 버전 메시지는 이하의 포맷을 갖는다.
+-----+-----+-----+-----+-----+-----+-----+-----+
|0 | 이 메시지의 크기 |
+-----+-----+-----+-----+-----+-----+-----+-----+
|Version(32 비트) | Features(32 비트) |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0이어야 함(32 비트)
+-----+-----+-----+-----+
Version
호스트->장치 - 요청된 버전
장치 -> 호스트 - 지원되는 버전
Features
호스트->장치
원하는 특징을 나타내는 비트필드
장치->호스트
사용될 특징을 나타내는 비트필드
호스트는 이 구현을 위해 버전을 1로 설정해야 한다. 현재 지원되는 특징이 없기 때문에 특징은 0이어야 한다. 장래에, 버전을 증가시키지 않고 체크섬 등의 특징이 추가될 수 있다. 그에 부가하여, 완전히 새로운 버전을 정의하지 않고 특징 필드를 사용하여 체크섬이 가능하게 될 수 있다. 특징 필드는 버전에 기초하여 해석된다. 버전 1에 대한 특징 필드 내의 다양한 비트들은 버전 2에서의 특징들과 다른 의미를 가질 수 있다. 호스트는 특징 필드 내의 대응하는 비트를 세트(set)시킴으로써 특징을 요청할 수 있다.
장치는 지원되는 버전으로 응답해야만 한다. 장치는 하나의 버전만을 지원할 수 있거나, 다수의 버전들을 지원할 수 있다. 장치가 호스트에 의해 요청되는 버전을 지원하는 경우, 장치는 그 버전으로 응답해야만 한다. 장치가 단지 다른 버전만을 지원하는 경우, 장치는 그가 지원하는 버전으로 응답해야만 한다. 장치가 요청된 버전으로 응답하는 경우, 장치는 지원되지 않는 특징들을 마스킹 제거(masked out)한 채로 특징 비트필드(feature bitfield)를 요청된 비트로 설정해야만 한다. 응답 버전이 요청된 버전과 일치하지 않는 경우, 특징 필드가 0으로 되어야만 한다.
장치가 호스트가 이해하지 못하는 버전을 나타내는 버전 메시지로 응답하는 경우, 호스트는 장치와 통신하기 위해 보다 새로운 소프트웨어를 필요로 할지도 모른다. 장치가 호스트가 지원하는 요청된 버전과 다른 버전으로 응답하는 경우, 호스트는 특정의 특징을 요청하기 위해 특징 필드에서 새로 협상된 버전 및 비트가 세트되어 있는 다른 버전 메시지를 전송할지도 모른다. 장치는 다수의 버전 메시지를 처리할 준비가 되어 있어야 한다.
3)
TCP
메시지
USB를 통한 데이터 통신의 경우, TCP 메시지가 사용된다. TCP 메시지는 프로토콜 값이 6이고 그 크기가 헤더를 포함하는 전체 메시지의 크기로 설정되어 있는 AppleUSBMobileDeviceHeader이다. AppleUSBMobileDeviceHeader 다음에 TCP 헤더가 온다. 가변적인 헤더 길이 및 TCP 옵션들이 현재 지원되지 않는다. 페이로드는, 있는 경우, TCP 헤더 다음에 온다.
+-----+-----+-----+-----+-----+-----+-----+-----+
|6 | 이 메시지의 크기 |
+-----+-----+-----+-----+-----+-----+-----+-----+
|src 포트 |dst 포트 |순서
+-----+-----+-----+-----+-----+-----+-----+-----+
|확인응답 |h1|플래그|윈도우 크기|
+-----+-----+-----+-----+-----+-----+-----+-----+
|체크섬 |긴급 포인터|
+-----+-----+-----+-----+
긴급 포인터(urgent pointer) 및 체크섬 필드는 현재 사용되지 않으며, 이 구현에서 0으로 설정되어야만 한다. USB가 신뢰성있어야 하기 때문에, 확인 응답이 묵시적(implicit)이다. 윈도우를 업데이트하기 위해 순서 ACK 패킷이 전송된다.
3.1) 연결의 개시
연결은 호스트가 TCP SYN 패킷을 장치로 전송하는 것에 의해 설정된다. dst(목적지) 포트는 호스트 상의 어느 서비스에 연결해야 하는지를 결정하는 데 사용된다. 이 연결을 임의의 다른 연결들과 구별하기 위해 src(발신지) 포트/dst 포트 튜플(tuple)이 고유해야만 한다.
연결이 수락되는 경우 장치는 SYN 패킷에 대해 SYN/ACK 패킷으로 응답을 한다. 자원이 충분하지 않는 경우 또는 요청된 포트를 통해 리스닝하는 서비스가 없는 경우, 장치는 연결 요청을 거부할 수 있다. 연결을 거부하기 위해, 장치는 TCP RST를 전송해야만 한다.
통상적인 TCP 연결은 3 방향 핸드쉐이크(three way handshake)를 포함한다. USB가 신뢰성있어야 하기 때문에, 이 구현에서 호스트로부터 장치로의 ACK인 세번째 패킷이 폐기(drop)될 수 있다(사용되지 않을 수 있다). 장치가 일단 SYN/ACK 패킷을 전송하면 장치는 연결이 설정된 것으로 간주한다. 호스트가 일단 SYN/ACK 패킷을 수신하면 호스트는 연결이 설정된 것으로 간주한다.
SYN 플래그에 대한 순서 번호(sequence number) 및 확인응답 번호(acknowledgement number)가 증가되는데, 그 이유는 이들 번호가 실제(고전적인) TCP에 있기 때문이다.
8의 윈도우 천이 값이 사용되지만, 이 옵션은 협상되지 않는다.
3.2) 연결의 종료
장치 또는 호스트는 연결을 끊고자 할 때, TCP RST를 전송한다. TCP RST에 응답하여, 호스트 또는 장치는 발신지 및 목적지 TCP 포트에 의해 지정된 연결과 연관된 모든 자원들을 원상 복구해야 한다.
이 구현에서는, FIN 플래그가 사용되지 않는다. 이 구현에서는, 반폐쇄(half close)가 없다.
3.3) 데이터 전송
흐름 제어를 위해 순서 번호 및 확인응답 번호가 사용된다. 호스트 또는 장치가 페이로드를 갖는 TCP 메시지를 전송할 때, 순서 번호가 전송된 페이로드의 크기만큼 증가된다. 호스트 및 장치는 마지막 확인응답된 데이터 및 마지막 광고된 윈도우를 넘어서 데이터를 전송할 수 없다. 이것이 흐름 제어가 구현되는 방법이다. 전송된 모든 데이터가 수신될 것으로 가정된다. 이 구현에서는, 재전송(retransmit)이 지원되지 않는다. 이 특징이 요망되는 경우, 대안의 실시예는 재전송을 사용할 수 있다. 데이터를 전송하는 측은 데이터가 전송되면 그 데이터의 로컬 사본을 폐기할 수 있다.
3.4) 데이터 수신
데이터가 순서대로 도착하는 것으로 가정된다. 호스트 또는 장치가 비순차적(out of order) 전송을 수신하는 경우, 순서 번호에 기초하여, 호스트는 연결을 끊고 TCP RST를 전송해야 한다.
호스트 또는 장치는, 더 많은 버퍼 공간이 이용가능한 경우, 상대방측이 더 많은 데이터를 전송할 수 있다는 것을 알려주기 위해 업데이트된 윈도우를 갖는 TCP ACK 패킷을 전송할 수 있다.
본 명세서에서 "일 실시예" 또는 "실시예"라는 말은 그 실시예와 관련하여 기술된 특정의 특징, 구조 또는 특성이 본 발명의 적어도 하나의 실시예에 포함되어 있다는 것을 의미한다. 본 명세서의 여러 곳에서 등장하는 "일 실시예에서"라는 표현이 모두 동일한 실시예를 말하는 것은 아니다.
이상의 명세서에서, 본 발명이 그의 구체적인 실시예들과 관련하여 기술되어 있다. 그렇지만, 본 발명의 광의의 사상 및 범위를 벗어나지 않고 본 발명에 다양한 수정 및 변경이 행해질 수 있다는 것이 명백할 것이다. 그에 따라, 본 명세서 및 첨부 도면은 제한적인 의미가 아니라 예시적인 것으로 간주되어야 한다.
Claims (20)
- 데이터 처리 시스템으로 하여금 방법을 수행하게 하는 실행가능 프로그램 명령어들을 포함하는 컴퓨터 판독가능 매체로서,
상기 방법은,
제1 장치를 이용하여 패킷들 - 상기 패킷들 각각은 헤더를 포함함 - 을 생성하기 위해 데이터 스트림을 패킷화하는 단계, 및
IP(Internet Protocol) 주소들을 사용하도록 설계되어 있지 않은 비네트워크 인터페이스(non-network interface)를 통해 상기 패킷들을 상기 제1 장치로부터 제2 장치로 직접 전송하는 단계를 포함하며,
상기 헤더들이 흐름 제어 및 시퀀싱을 위한 데이터를 포함하고 애플리케이션을 위한 포트와 연관되어 있으며,
상기 헤더들은 다수의 애플리케이션이 상기 제1 장치상에서 상기 비네트워크 인터페이스를 통해 임의의 수의 다중 동시 세션(multiple concurrent session)을 유지할 수 있게 해주는
컴퓨터 판독가능 매체. - 제1항에 있어서, 상기 비네트워크 인터페이스의 표준 프로토콜이 IP 주소들을 사용하지 않고,
상기 비네트워크 인터페이스가 USB(Universal Serial Bus) 호환(compliant) 유선 직렬 인터페이스 또는 BLUETOOTH 호환 무선 인터페이스 중 하나인 컴퓨터 판독가능 매체. - 제2항에 있어서, 상기 패킷들이 TCP(Transmission Control Protocol) 호환 헤더들을 포함하고 어떤 IP 호환 헤더들도 포함하지 않는 컴퓨터 판독가능 매체.
- 제3항에 있어서, 상기 흐름 제어가 애플리케이션별로 제공되고,
상기 임의의 수가 시간에 따라 동적으로 변할 수 있는 컴퓨터 판독가능 매체. - 제3항에 있어서, 상기 TCP 호환 헤더들이 IP 네트워크의 일부가 아닌 소켓과 연관되어 있는 컴퓨터 판독가능 매체.
- 제5항에 있어서, 상기 패킷화하는 단계는 상기 데이터 스트림이 TCP/IP 헤더들로 패킷화되고 래핑된(wrapped) 후에 - 여기서, 상기 IP 헤더는 루프백 주소를 지정함 -, 또한 상기 데이터 스트림을 제공하기 위해 상기 TCP/IP 헤더들이 제거된 후에 수행되는 컴퓨터 판독가능 매체.
- 제6항에 있어서, 상기 패킷화하는 단계가 TCP 스택 소프트웨어 컴포넌트에 의해 수행되고,
상기 데이터 스트림이 IP 프로토콜을 통해 인터넷에 연결하기 위한 인터페이스에 동작적으로 결합되는 TCP/IP 스택 소프트웨어 컴포넌트에 의해 TCP/IP 헤더들로 패킷화되고 래핑되는 컴퓨터 판독가능 매체. - 기계 구현 방법으로서,
제1 장치를 이용하여 패킷들 - 상기 패킷들 각각은 헤더를 포함함 - 을 생성하기 위해 데이터 스트림을 패킷화하는 단계, 및
IP(Internet Protocol) 주소들을 사용하도록 설계되어 있지 않은 비네트워크 인터페이스를 통해 상기 패킷들을 상기 제1 장치로부터 제2 장치로 직접 전송하는 단계를 포함하며,
상기 헤더들이 흐름 제어 및 시퀀싱을 위한 데이터를 포함하고 애플리케이션을 위한 포트와 연관되어 있으며,
상기 헤더들은 다수의 애플리케이션이 상기 제1 장치상에서 상기 비네트워크 인터페이스를 통해 임의의 수의 다중 동시 세션(multiple concurrent session)을 유지할 수 있게 해주는
기계 구현 방법. - 제8항에 있어서, 상기 비네트워크 인터페이스의 표준 프로토콜이 IP 주소들을 사용하지 않고,
상기 비네트워크 인터페이스가 USB(Universal Serial Bus) 호환 유선 직렬 인터페이스 또는 BLUETOOTH 호환 무선 인터페이스 중 하나인 것인 기계 구현 방법. - 제9항에 있어서, 상기 패킷들이 TCP(Transmission Control Protocol) 호환 헤더들을 포함하고 어떤 IP 호환 헤더들도 포함하지 않는 기계 구현 방법.
- 제10항에 있어서, 상기 흐름 제어가 애플리케이션별로 제공되고,
상기 임의의 수가 시간에 따라 동적으로 변할 수 있는 기계 구현 방법. - 제10항에 있어서, 상기 TCP 호환 헤더들이 IP 네트워크의 일부가 아닌 소켓과 연관되어 있는 기계 구현 방법.
- 제12항에 있어서, 상기 패킷화하는 단계는 상기 데이터 스트림이 TCP/IP 헤더들로 패킷화되고 래핑된 후에 - 여기서, 상기 IP 헤더는 루프백 주소를 지정함 -, 또한 상기 데이터 스트림을 제공하기 위해 상기 TCP/IP 헤더들이 제거된 후에 수행되는 기계 구현 방법.
- 제13항에 있어서, 상기 패킷화하는 단계가 TCP 스택 소프트웨어 컴포넌트에 의해 수행되고,
상기 데이터 스트림이 IP 프로토콜을 통해 인터넷에 연결하기 위한 인터페이스에 동작적으로 결합되는 TCP/IP 스택 소프트웨어 컴포넌트에 의해 TCP/IP 헤더들로 패킷화되고 래핑되는 기계 구현 방법. - 데이터 처리 시스템으로서,
상기 데이터 처리 시스템에서 패킷들 - 상기 패킷들 각각은 헤더를 포함함 - 을 생성하기 위해 데이터 스트림을 패킷화하는 수단, 및
IP(Internet Protocol) 주소들을 사용하도록 설계되어 있지 않은 비네트워크 인터페이스를 통해 상기 데이터 처리 시스템으로부터 다른 데이터 처리 시스템으로 상기 패킷들을 직접 전송하는 수단을 포함하며,
상기 헤더들이 흐름 제어 및 시퀀싱을 위한 데이터를 포함하고 애플리케이션을 위한 포트와 연관되어 있으며,
상기 헤더들은 다수의 애플리케이션이 상기 데이터 처리 시스템상에서 상기 비네트워크 인터페이스를 통해 임의의 수의 다중 동시 세션(multiple concurrent session)을 유지할 수 있게 해주는
데이터 처리 시스템. - 데이터 처리 시스템 상에서 실행될 실행가능 프로그램 명령어들을 포함하는 컴퓨터 판독가능 매체로서,
제1 장치상의 제1 인터페이스를 통해 전송하기 위한 패킷들을 생성하고 상기 제1 인터페이스를 통해 수신된 패킷들로부터 데이터를 추출하는 제1 네트워크 스택 소프트웨어, 및
상기 제1 장치상의 제2 인터페이스를 통해 제2 장치로 직접 전송하기 위한 패킷들을 생성하고 상기 제2 인터페이스를 통해 수신된 패킷들로부터 데이터를 추출하는, 상기 제1 네트워크 스택 소프트웨어와는 다른 제2 네트워크 스택 소프트웨어를 포함하고,
상기 제2 네트워크 스택 소프트웨어는 상기 제1 네트워크 스택 소프트웨어와 통신을 하도록 구성되어 있으며,
상기 제2 인터페이스는 상기 제2 장치상의 제3 인터페이스에 결합되도록 구성되어 있고,
상기 제2 네트워크 스택 소프트웨어는 상기 제2 인터페이스를 통해 수신된 패킷들로부터 추출된 데이터를 상기 제1 네트워크 스택 소프트웨어를 통해 전송하도록 구성되어 있으며,
상기 제2 네트워크 스택 소프트웨어는 상기 제2 인터페이스를 위해 설계된 프로토콜을 사용하여 패킷들을 전송 및 수신하도록 구성되어 있고,
상기 제2 네트워크 스택 소프트웨어는 다수의 애플리케이션이 상기 제2 인터페이스를 통해 상기 제1 장치로부터 상기 제2 장치로의 직접 다중 동시 세션을 유지할 수 있게 해주도록 구성되어 있는
컴퓨터 판독가능 매체. - 제16항에 있어서, 상기 제2 네트워크 스택 소프트웨어는 상기 제2 인터페이스를 통해 수신된 패킷들로부터 추출된 데이터를, 상기 제2 인터페이스를 통해 다중 동시 세션을 유지할 수 있도록 허용된 복수의 수신측 소프트웨어 애플리케이션으로, 상기 제1 네트워크 스택 소프트웨어를 통해 전송하도록 구성되어 있는 컴퓨터 판독가능 매체.
- 제17항에 있어서, 상기 제1 인터페이스는 인터넷에 결합되도록 설계되어 있고,
상기 제2 인터페이스는 IP(Internet Protocol) 주소들을 사용하도록 설계되어 있지 않으며,
상기 제1 네트워크 스택 소프트웨어는 TCP/IP 스택을 포함하고,
상기 제2 네트워크 스택 소프트웨어는 IP 헤더들을 생성하지 않는 TCP 호환 스택을 포함하는 컴퓨터 판독가능 매체. - 제18항에 있어서, 상기 제2 네트워크 스택 소프트웨어는 상기 제2 인터페이스를 통해 수신된 패킷들로부터 데이터를 추출하고 이 데이터를 상기 제1 네트워크 스택 소프트웨어를 통해 상기 제1 장치 상의 복수의 다중 애플리케이션 중 하나로 전송하도록 구성되어 있는 컴퓨터 판독가능 매체.
- 제19항에 있어서, 상기 제2 인터페이스가 USB(Universal Serial Bus) 호환 유선 직렬 인터페이스 또는 BLUETOOTH 호환 무선 인터페이스 중 하나이고,
상기 제2 인터페이스 및 상기 제3 인터페이스가 IP 주소들을 사용하지 않는 동일한 프로토콜을 사용하는 컴퓨터 판독가능 매체.
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/760,686 | 2007-06-08 | ||
US11/760,686 US20080307102A1 (en) | 2007-06-08 | 2007-06-08 | Techniques for communicating data between a host device and an intermittently attached mobile device |
US94590407P | 2007-06-22 | 2007-06-22 | |
US60/945,904 | 2007-06-22 | ||
US11/770,691 US20080304486A1 (en) | 2007-06-08 | 2007-06-28 | Multiplexed data stream protocol |
US11/770,691 | 2007-06-28 | ||
PCT/US2008/005946 WO2008153649A1 (en) | 2007-06-08 | 2008-05-08 | Multiplexed data stream protocol |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020107000348A Division KR101179855B1 (ko) | 2007-06-08 | 2008-05-08 | 멀티플렉싱된 데이터 스트림 프로토콜 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20120085342A true KR20120085342A (ko) | 2012-07-31 |
KR101283267B1 KR101283267B1 (ko) | 2013-08-23 |
Family
ID=39811510
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020107000348A KR101179855B1 (ko) | 2007-06-08 | 2008-05-08 | 멀티플렉싱된 데이터 스트림 프로토콜 |
KR1020127016841A KR101283267B1 (ko) | 2007-06-08 | 2008-05-08 | 멀티플렉싱된 데이터 스트림 프로토콜 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020107000348A KR101179855B1 (ko) | 2007-06-08 | 2008-05-08 | 멀티플렉싱된 데이터 스트림 프로토콜 |
Country Status (8)
Country | Link |
---|---|
US (1) | US20080304486A1 (ko) |
EP (2) | EP2156638B1 (ko) |
KR (2) | KR101179855B1 (ko) |
CN (2) | CN103297424B (ko) |
AT (2) | ATE505019T1 (ko) |
DE (2) | DE602008006071D1 (ko) |
HK (2) | HK1126592A1 (ko) |
WO (1) | WO2008153649A1 (ko) |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8341127B1 (en) * | 2006-02-02 | 2012-12-25 | Emc Corporation | Client initiated restore |
US8886902B1 (en) | 2006-02-02 | 2014-11-11 | Emc Corporation | Disk backup set access |
US8666366B2 (en) | 2007-06-22 | 2014-03-04 | Apple Inc. | Device activation and access |
EP2057793A1 (en) * | 2007-03-14 | 2009-05-13 | Hewlett-Packard Development Company, L.P. | Synthetic bridging |
CN101675626B (zh) * | 2007-03-14 | 2012-10-10 | 惠普开发有限公司 | 把数据从第一网络格式转换为非网络格式以及从非网络格式转换为第二网络格式 |
US8649393B2 (en) * | 2007-08-30 | 2014-02-11 | Broadcom Corporation | Method and system for setting alternative device classes within the MTP protocol |
US9477395B2 (en) | 2007-09-04 | 2016-10-25 | Apple Inc. | Audio file interface |
US20090064038A1 (en) * | 2007-09-04 | 2009-03-05 | Apple Inc. | Configuration of Device Settings |
US10091345B2 (en) * | 2007-09-04 | 2018-10-02 | Apple Inc. | Media out interface |
US8413172B2 (en) * | 2008-08-20 | 2013-04-02 | Sharp Laboratories Of America, Inc. | Method and system for socket API call emulation |
US9052919B2 (en) * | 2010-01-15 | 2015-06-09 | Apple Inc. | Specialized network fileserver |
US9253219B2 (en) * | 2012-03-30 | 2016-02-02 | Avaya Inc. | System and method to influence SIP routing by sequenced applications |
CN102695163B (zh) * | 2012-05-31 | 2015-04-08 | 宇龙计算机通信科技(深圳)有限公司 | 一种多数据连接并发的方法及终端 |
FR2992445B1 (fr) | 2012-06-22 | 2014-07-04 | Snecma | Procede de synchronisation de donnees d'algorithmes de calculateurs asynchrones d'aeronef |
US9923677B2 (en) * | 2014-12-26 | 2018-03-20 | Intel Corporation | Multiplexing many client streams over a single connection |
JP6521762B2 (ja) * | 2015-06-24 | 2019-05-29 | キヤノン株式会社 | Httpサーバとその制御方法、画像形成装置およびプログラム |
JP2017034482A (ja) * | 2015-07-31 | 2017-02-09 | キヤノン株式会社 | 画像形成装置、その制御方法、及びプログラム |
US10447493B2 (en) * | 2016-07-26 | 2019-10-15 | Honeywell International Inc. | MAC and physical layer techniques for enabling communications on shared physical medium with multi-drop capability |
US10939286B2 (en) * | 2018-08-06 | 2021-03-02 | Koninklijke Philips N.V. | Link status-aware medical devices and gateways |
CN111953639B (zh) * | 2019-05-17 | 2021-11-12 | 大唐移动通信设备有限公司 | 有头链路通信方法和装置 |
US11956204B1 (en) * | 2022-12-23 | 2024-04-09 | Plume Design, Inc. | IPv4-in-IPv6 relaying systems and methods to preserve IPv4 public addresses |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999039488A1 (en) * | 1998-01-29 | 1999-08-05 | British Telecommunications Public Limited Company | Communications system for mobile data transfer |
US6678535B1 (en) * | 2000-06-30 | 2004-01-13 | International Business Machines Corporation | Pervasive dock and router with communication protocol converter |
US6636789B2 (en) * | 2001-04-27 | 2003-10-21 | Spx Corporation | Method and system of remote delivery of engine analysis data |
US7103760B1 (en) * | 2001-07-16 | 2006-09-05 | Billington Corey A | Embedded electronic device connectivity system |
US7345671B2 (en) | 2001-10-22 | 2008-03-18 | Apple Inc. | Method and apparatus for use of rotational user inputs |
US7742473B2 (en) * | 2002-11-12 | 2010-06-22 | Mark Adams | Accelerator module |
US7627343B2 (en) | 2003-04-25 | 2009-12-01 | Apple Inc. | Media player system |
US7506057B2 (en) * | 2005-06-17 | 2009-03-17 | Fotonation Vision Limited | Method for establishing a paired connection between media devices |
US7792970B2 (en) * | 2005-06-17 | 2010-09-07 | Fotonation Vision Limited | Method for establishing a paired connection between media devices |
US7673066B2 (en) * | 2003-11-07 | 2010-03-02 | Sony Corporation | File transfer protocol for mobile computer |
EP1569491A3 (en) * | 2004-02-24 | 2006-11-02 | Lg Electronics Inc. | Group network system using bluetooth and generating method thereof |
JP4343760B2 (ja) * | 2004-04-28 | 2009-10-14 | 株式会社日立製作所 | ネットワークプロトコル処理装置 |
US7644211B2 (en) * | 2004-12-07 | 2010-01-05 | Cisco Technology, Inc. | Method and system for controlling transmission of USB messages over a data network between a USB device and a plurality of host computers |
US20060190238A1 (en) * | 2005-02-24 | 2006-08-24 | Autor Jeffrey S | Methods and systems for managing a device |
US7633076B2 (en) * | 2005-09-30 | 2009-12-15 | Apple Inc. | Automated response to and sensing of user activity in portable devices |
EP1798943A1 (en) * | 2005-12-13 | 2007-06-20 | Axalto SA | SIM messaging client |
US20080126653A1 (en) * | 2006-11-29 | 2008-05-29 | Icon Global, Ltd. | Portable web server with usb port |
US8666366B2 (en) * | 2007-06-22 | 2014-03-04 | Apple Inc. | Device activation and access |
US7778971B2 (en) * | 2007-01-07 | 2010-08-17 | Apple Inc. | Synchronization methods and systems |
EP2057793A1 (en) * | 2007-03-14 | 2009-05-13 | Hewlett-Packard Development Company, L.P. | Synthetic bridging |
US20080307102A1 (en) * | 2007-06-08 | 2008-12-11 | Galloway Curtis C | Techniques for communicating data between a host device and an intermittently attached mobile device |
-
2007
- 2007-06-28 US US11/770,691 patent/US20080304486A1/en not_active Abandoned
-
2008
- 2008-05-08 KR KR1020107000348A patent/KR101179855B1/ko active IP Right Grant
- 2008-05-08 CN CN201310163317.2A patent/CN103297424B/zh active Active
- 2008-05-08 KR KR1020127016841A patent/KR101283267B1/ko active IP Right Grant
- 2008-05-08 DE DE602008006071T patent/DE602008006071D1/de active Active
- 2008-05-08 WO PCT/US2008/005946 patent/WO2008153649A1/en active Application Filing
- 2008-05-08 EP EP08754293A patent/EP2156638B1/en active Active
- 2008-05-08 CN CN2008800193083A patent/CN101682635B/zh active Active
- 2008-05-08 AT AT08754293T patent/ATE505019T1/de not_active IP Right Cessation
- 2008-06-06 EP EP08157733A patent/EP2001199B1/en active Active
- 2008-06-06 DE DE602008001203T patent/DE602008001203D1/de active Active
- 2008-06-06 AT AT08157733T patent/ATE467969T1/de not_active IP Right Cessation
-
2009
- 2009-06-09 HK HK09105179.3A patent/HK1126592A1/xx not_active IP Right Cessation
-
2010
- 2010-08-06 HK HK10107568.5A patent/HK1141178A1/xx not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
ATE467969T1 (de) | 2010-05-15 |
CN101682635B (zh) | 2013-05-08 |
EP2001199B1 (en) | 2010-05-12 |
EP2156638B1 (en) | 2011-04-06 |
CN103297424A (zh) | 2013-09-11 |
KR101179855B1 (ko) | 2012-09-04 |
CN101682635A (zh) | 2010-03-24 |
KR101283267B1 (ko) | 2013-08-23 |
US20080304486A1 (en) | 2008-12-11 |
EP2001199A1 (en) | 2008-12-10 |
EP2156638A1 (en) | 2010-02-24 |
KR20100012896A (ko) | 2010-02-08 |
HK1141178A1 (en) | 2010-10-29 |
WO2008153649A1 (en) | 2008-12-18 |
HK1126592A1 (en) | 2009-09-04 |
DE602008001203D1 (de) | 2010-06-24 |
DE602008006071D1 (de) | 2011-05-19 |
CN103297424B (zh) | 2017-04-26 |
ATE505019T1 (de) | 2011-04-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101179788B1 (ko) | 트랜잭션 기반 통신을 위한 파일 프로토콜 | |
KR101179855B1 (ko) | 멀티플렉싱된 데이터 스트림 프로토콜 | |
EP2158743B1 (en) | Techniques for communicating data between a host device and an intermittently connected mobile device | |
US8886600B2 (en) | Synchronization methods and systems | |
US8375112B2 (en) | Synchronization methods and systems | |
US7921240B2 (en) | Method and system for supporting hardware acceleration for iSCSI read and write operations and iSCSI chimney | |
EP2317732A1 (en) | Data communication protocol | |
EP2122513A2 (en) | Synchronization methods and systems | |
US9325519B2 (en) | Distributed proxy for bi-directional network connectivity over point-to-point connection | |
EP1727056A2 (en) | Data communication protocol | |
US20120324056A1 (en) | Method and apparatus for hitless redundancy in data streaming | |
WO2008085869A2 (en) | Synchronization methods and systems | |
US7984166B2 (en) | Trivial file transfer protocol (TFTP) file segment and file address options | |
US20050283545A1 (en) | Method and system for supporting write operations with CRC for iSCSI and iSCSI chimney | |
WO2014176970A1 (zh) | 一种数据同步的方法及数字媒体服务器 | |
WO2024159848A9 (zh) | 基于主备机的数据包传输控制方法及装置、设备、介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A107 | Divisional application of patent | ||
A201 | Request for examination | ||
E902 | Notification of reason for refusal | ||
E701 | Decision to grant or registration of patent right | ||
GRNT | Written decision to grant | ||
FPAY | Annual fee payment |
Payment date: 20160616 Year of fee payment: 4 |
|
FPAY | Annual fee payment |
Payment date: 20170616 Year of fee payment: 5 |
|
FPAY | Annual fee payment |
Payment date: 20190617 Year of fee payment: 7 |