CN101682635B - 复用式数据流协议 - Google Patents

复用式数据流协议 Download PDF

Info

Publication number
CN101682635B
CN101682635B CN2008800193083A CN200880019308A CN101682635B CN 101682635 B CN101682635 B CN 101682635B CN 2008800193083 A CN2008800193083 A CN 2008800193083A CN 200880019308 A CN200880019308 A CN 200880019308A CN 101682635 B CN101682635 B CN 101682635B
Authority
CN
China
Prior art keywords
interface
network stack
grouping
data
stack software
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN2008800193083A
Other languages
English (en)
Other versions
CN101682635A (zh
Inventor
约书亚·维韦斯特·格雷斯勒
约翰·安德鲁·赖特
柯蒂斯·C·加洛韦
保罗·钦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Computer Inc
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
Priority claimed from US11/760,686 external-priority patent/US20080307102A1/en
Application filed by Apple Computer Inc filed Critical Apple Computer Inc
Priority to CN201310163317.2A priority Critical patent/CN103297424B/zh
Publication of CN101682635A publication Critical patent/CN101682635A/zh
Application granted granted Critical
Publication of CN101682635B publication Critical patent/CN101682635B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems
    • H04L12/5601Transfer mode dependent, e.g. ATM
    • H04L2012/5603Access techniques
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation 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)
  • Time-Division Multiplex Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明描述了复用式数据流协议。在一个实施例中,一种用于提供复用式数据流协议的方法包括:对数据流进行分组化以提供带有头部的分组,并且通过未被设计来使用因特网协议(IP)地址的接口发送分组。头部包含用于流控制和定序的数据并且与用于应用的端口相关联,并且头部允许多个应用通过该接口维持任意且可变数目的多个并发会话。头部可以是类似传输控制协议(TCP)的头部并且可以不包括类IP头部。还描述了系统、计算机可读介质、软件体系结构和其他方法。

Description

复用式数据流协议
本申请要求2007年6月22日提交的题为“Multiplexed Data StreamProtocol”的临时美国专利申请No.60/945,904的申请日的权益。特此通过引用将该临时申请并入在此。本申请还是2007年6月8日提交的题为“Techniques for Communicating Data Between a Host Device and AnIntermittently Attached Mobile Device”的美国专利申请No.11/760,686的部分继续案。
技术领域
本发明的实施例涉及在设备之间传输数据。更具体而言,本发明的实施例涉及用于在一个或多个主机电子设备和一断续连接的客户端设备之间高效传输数据的技术。
背景技术
随着移动设备(例如,移动电话、数字音乐播放器、数字个人助理)的普及度增大,单个移动设备提供的功能已经增加了。与这种功能的增加相关联的是这样一种动机,即,提供同步服务,以便例如反映出在移动设备或者主机设备上对数据做出的改变。另外,可能需要在两个设备之间交换包括一个或多个文件在内的数据。例如,在两个设备之间可交换音乐或视频文件。
已经开发出各种技术来在移动设备和主机设备之间同步数据和/或交换数据。当前的技术通常或者是可能需要一些不必要开销的基于全功能文件系统的技术,或者可能是提供有限功能的专用技术。这些技术使用现有的接口,例如USB。
设备之间的现有接口,例如每个设备上的USB接口,难以允许设备附接到USB(通用串行总线)接口或端口并随后任意且突然地从USB接口移除/断开,尤其在设备是存储设备的情况下更是如此。另外,USB未被设计来在USB的标准通信协议中支持因特网协议(IP)地址;USB并不被认为是网络接口。USB也未被设计来为试图通过USB接口发送数据或等待接收数据的独立应用支持任意数目(实际上是无限数目)的多个并发独立会话,并且对于至少某些系统,在USB接口上支持的接口或会话的数目是静态的并且不能随时间而改变。对于至少某些系统,USB接口可以支持多个并发“接口”,这多个并发“接口”可被认为是多个会话,但其数目是固定的,并且对于一个设备,接口是静态的(并且不能改变)。另一方面,USB是常见且有用的接口,从而经常会希望使用这种接口来连接两个系统,例如主机和客户端设备。
发明内容
这里描述了复用式数据流协议。在一个实施例中,一种用于提供复用式数据流协议的方法包括:对数据流进行分组化以提供带有头部的分组,并且通过接口将这些分组发送到另一设备,该接口未被设计来使用因特网协议(IP)地址(或其他网络地址),例如是USB接口。该方法还可包括在网络栈软件处接收带有头部的分组并从分组中提取数据,其中分组是通过该接口接收的。头部可包含用于数据的定序和流控制的数据,并且可包含分组中的数据(有效载荷)的源和目的地(例如分别是发送方应用和接收方应用)的标识符。通过使用一种在头部中使用此数据的类TCP(TCP-like)协议,头部允许了多个独立应用通过该接口维持多个并发会话。头部可以是类似传输控制协议(TCP)的头部,并且可以不包括类IP头部。该接口(例如USB接口)的标准协议在至少某些实施例中不使用IP地址。该方法可逐应用地提供流控制。类TCP头部可用于实现一种类TCP协议,用于流控制、定序、复用、连接建立/终止、确认以及可选的差错校验(例如,校验和)和可选的重发。此方法允许了接口(例如USB接口)对突然的且时间任意的(例如,意外的)连接断开得体地做出响应。例如,如果设备是带有无线蜂窝电话的手持式计算机并通过其USB接口连接到主机设备(其可以是桌面型或膝上型计算机或其他数据处理系统)的USB接口,并且如果设备和主机正在交换数据(例如,传送MP3文件或其他文件或者交换数据以同步两个系统或在一个系统上备份另一个系统)并且如果在两个系统相连接并且通过其USB接口交换数据的同时接收到无线蜂窝电话,则该方法允许突然断开连接,以便允许用户应答该电话呼叫。该方法可包括使用一个或多个传统的套接字API(应用程序接口),这种套接字API允许了不同软件模块之间的进程间/应用间通信。该方法还可包括传统的TCP/IP栈软件组件,该TCP/IP栈软件组件通过设备和/或主机上的传统网络连接(例如WiFi或以太网连接/接口或蜂窝电话连接)来处理分组并且还处理分组以便通过非网络接口发送。该TCP/IP栈软件在至少某些实施例中可以通过套接字API与接口TCP软件组件通信,接口TCP软件组件创建类TCP头部,用于通过非网络接口(例如USB接口)发送。
在一个实施例中,一种计算机可读介质包括:第二网络栈软件,用于创建分组以便通过设备上的第二接口(例如USB接口)发送并且从通过第二接口接收的分组中提取数据;以及第一网络栈软件,用于创建分组以便通过设备上的第一接口(例如WiFi或以太网接口或无线蜂窝电话接口)发送并且从通过第一接口接收的分组中提取数据。第一网络栈软件可以是TCP/IP栈,其被配置为与第二网络栈软件通信,第二网络栈软件可以是接口TCP软件栈,该接口TCP软件栈创建类TCP分组并且使得这些类TCP分组通过非网络接口(例如第二接口)被发送。第二网络栈软件可被配置为通过第一网络栈软件来把从通过第二接口接收的分组中提取的数据发送到多个接收方软件应用,这多个接收方软件应用被允许通过第二接口维持多个并发会话。第一接口被设计为耦合到因特网,而第二接口未被设计来使用因特网协议(IP)地址,并且第一网络栈软件包括TCP/IP栈,而第二网络栈软件包括不创建IP头部的类TCP栈。第二网络栈软件被配置为从通过第二接口接收的分组中提取数据并且通过第一网络栈软件将该数据发送到设备上的多个应用之一。由第二网络栈软件创建的头部可包括用于流控制和定序的数据以及接收方(例如“目的地”)应用和发送方(例如“源”)应用的端口标识符。由第二网络栈软件从分组中提取的数据可以被提供给第一网络栈软件,第一网络栈软件向该数据的至少一部分添加TCP/IP头部以创建另外的分组,然后第一网络栈软件从这些另外的分组中去除TCIP/IP头部,并随后将数据提供给接收方应用。TCP/IP头部可包括与环回接口(loopback interface)相对应的IP地址,该环回接口与第一网络栈软件操作性地耦合。
本说明书还描述了设备、系统、计算机可读介质、软件体系结构和其他方法。
在另一实施例中,设备之间(例如主机和设备之间)的通信链路是遵从通用串行总线(USB)的有线或无线接口。在另一实施例中,设备之间的通信链路是遵从BLUETOOTH的无线接口。在另一实施例中,通信链路是不为网络接口的接口。
在一个实施例中,客户端设备是智能电话。在另一实施例中,客户端设备是媒体回放设备。在一个实施例中,主机设备是桌面型计算机系统。在另一实施例中,主机设备是膝上型计算机系统。在另一实施例中,主机设备是掌上型或超便携型计算机系统。
附图说明
在附图中以示例方式而非限制方式示出了本发明,在附图中相似的标号指代类似的要素。
图1是可利用这里描述的技术通信的主机电子设备和客户端电子设备的框图。
图2是诸如主机设备之类的数据处理系统的一个实施例的框图。
图3是诸如客户端设备、手持式计算机或其他类型的数据处理系统之类的数据处理系统的一个实施例的框图。
图4是可用于主机电子设备和客户端电子设备之间的通信中的分组头部的表格。
图5是可用于主机电子设备和客户端电子设备之间的通信中的分组类型的表格。
图6是用于将数据传送到客户端设备的技术的一个实施例的流程图。
图7是用于在主机设备和客户端设备之间同步数据的技术的一个实施例的流程图。
图8示出了用于连接被称为主机和设备的两个数据处理系统的软件体系结构的示例。
图9是示出根据本发明一个实施例用于在两个系统之间交换数据的方法的示例的流程图;该数据可以是文件(例如,MP3文件、视频文件、图片等等)或者结构化数据(例如地址簿中的联络信息,或者书签/收藏夹,或者日历数据,或者注释,或者待做事项,等等)或者其他类型的数据(例如,诸如窗口小部件之类的可执行软件,等等)。
图10示出了根据本发明一个实施例的初始化方法的流程图。
图11是示出根据本发明一个实施例用于将数据从主机传送到设备的方法的示例的流程图。
图12是示出根据本发明一个实施例用于将数据从设备传送到主机的方法的示例的流程图。
图13示出了主机系统的替代软件体系结构的示例。
图14A示出了通过两个USB接口使用图片传送协议(PTP)进行的连接的现有技术示例。
图14B示出了根据本发明一个实施例的连接的示例。
图15是示出根据一个实施例用于在系统之间交换文件的方法的示例的流程图。
具体实施方式
在以下描述中,阐述了许多具体细节。然而,没有这些具体细节也可实现本发明的实施例。在其他情况下,没有详细示出公知的电路、结构和技术,以避免使这里的描述难以理解。
这里描述的是用于在端点之间传送文件和其他数据的协议。在一个实施例中,端点是主机电子设备和客户端电子设备。主机电子设备例如可以是桌面型计算机系统或膝上型计算机系统。客户端电子设备例如可以是膝上型计算机系统、个人数字助理、具备蜂窝电话能力的设备(例如,蜂窝电话或智能电话)。
在一个实施例中,端点之间的连接利用了可靠的流传输,例如传输控制协议(TCP)流连接。也可支持其他流连接。在一个实施例中,通信是利用具有头部和主体的分组来实现的。这里在一个实施例中描述了标准的最低限度头部,但头部也可包含另外的特定于分组的结构化数据。分组数据可包括非结构化数据,或者可以是空的。
图1是可利用这里描述的技术通信的主机电子设备和客户端电子设备的框图。图1的框图提供了可用于在主机设备100和客户端设备150之间通信的组件的概念性图示。在一个示例中,主机设备100是计算机系统(例如,桌面型或膝上型计算机系统),客户端设备150是移动设备(例如,PDA或智能电话)。主机设备100和客户端设备150可以经由现有技术已知的任何类型的通信技术来通信。例如,通信链路145可以是物理线缆(例如,遵从通用串行总线的线缆),或者无线通信链路(例如,遵从或遵从IEEE 802.11)。
Figure G2008800193083D00062
是Bluetooth SIG公司拥有的注册商标。
应用110可以是可被主机设备100执行的任何类型的应用。例如,应用110可以是可从加利福尼亚州库珀蒂诺的Apple公司获得的iTunes。应用110可包括可被传输到客户端设备150和/或与客户端设备150同步的功能和/或数据。例如,应用110可存储和/或播放可被存储在客户端设备150上或者由客户端设备150播放的多媒体内容。当客户端设备150与主机设备100通信时,应用110可以使得内容被在主机设备100和客户端设备150之间传送。也可支持其他类型的应用。
关守(gatekeeper)客户端115与应用110交互,以控制应用110对通信链路145的访问。关守客户端115可以基于一个或多个参数来选择性地限制对通信链路145的访问。关守客户端115例如可在允许主机设备100和客户端设备150之间的通信之前执行认证和/或核实操作。关守客户端115还可选择多个通信链路之一来用于主机设备100和客户端设备150之间的通信。虽然图1的示例是在有关守功能的情况下描述的,但是在没有关守功能的情况下可提供替代实施例。关于关守客户端115和关守180的更多信息在2007年6月22日提交的美国专利申请No.11/767,447(代理人案卷号18962-113001/P5408US1)中提供,该申请通过引用被并入在此。
关守客户端115可与链路驱动器130通信以经由链路接口140访问通信链路145。在一个实施例中,链路驱动器130与结构化同步服务120交互,以在主机设备100和客户端设备150之间提供同步功能。在一个实施例中,结构化同步服务120可以利用下文中更详细描述的命令和协议来工作。链路驱动器130可以使得链路接口140使表示数据的信号(例如,电信号、射频信号、红外信号、光信号)通过通信链路145传输。
在客户端设备150内,链路接口160是链路接口140的对应物。链路接口160可以经由通信链路145发送和/或接收信号(例如,电信号、射频信号、红外信号、光信号)。客户端设备150还包括关守180,关守180可在允许主机设备100上的应用110和客户端设备150上的媒体同步服务190之间的通信之前执行认证、核实和/或其他授权功能。
在一个实施例中,媒体同步服务190可支持下文中更详细描述的消息和协议,以允许对数据195的访问(例如,读取、写入、修改、更新)。数据195表示存储在客户端设备150上的任何类型的数据。数据195可以是一个或多个数据库、表格和/或其他存储单元。数据195例如可以是媒体文件(例如,音频和/或视频数据文件)、元数据、联络信息、历史信息(例如,呼叫记录、软件版本信息)和/或状态信息(例如,电池容量、序列号、总存储器、可用存储器)。
客户端设备150还可包括结构化数据服务185,结构化数据服务185可维护客户端设备150上的数据。可利用结构化同步服务120和结构化数据服务185来同步和/或维护的数据的示例可包括书签、联络信息、日历信息等等。结构化同步服务120可以与同步软件805(在图8中)相同或相似,结构化同步服务185可以与同步软件835(在图8中)相同或相似。
在一个实施例中,主机设备100和客户端设备150之间为了允许应用110访问数据190而进行的通信可利用下文中更详细描述的特定数据分组格式通过结构化同步服务120和媒体同步服务190来实现。在一个实施例中,通信链路145可以是主机设备100和客户端设备150之间遵从通用串行总线(USB)的有线通信链路。在一个实施例中,主机设备100和客户端设备150之间的连接利用了遵从USB的物理连接上的TCP流连接来传输下文中描述的分组。
图2是诸如主机设备之类的数据处理系统的一个实施例的框图。注意,虽然图2示出了计算机系统的各种组件,但其并不意图表示互连这些组件的任何特定体系结构或方式,因为这种细节与本发明并没有密切关系。还应当明白,个人数字助理(PDA)、蜂窝电话、媒体播放器(例如,iPod)、组合这些设备的多个方面或功能的设备(组合在一个设备中的媒体播放器与PDA和蜂窝电话)、网络计算机、嵌入在另外的设备内的处理设备、以及其他具有更少组件或者可能更多组件的数据处理系统也可用于实现本发明的一个或多个实施例,并且可以是这里描述的数据处理系统中的一个或多个。图2所示的计算机系统例如可以是来自Apple公司的Macintosh计算机或者来自Microsoft公司的运行Windows操作软件的计算机。
计算机系统200包括总线205,总线205耦合到形成处理系统210的一个或多个微处理器。总线205还耦合到存储器220和非易失性存储器230,非易失性存储器230在某些实施例中可以是磁性硬盘驱动器,或者在其他实施例中可以是闪存。总线205还耦合到显示控制器和显示器240以及一个或多个输入/输出(I/O)设备250。
另外,总线205可耦合到可选的扩展坞260并且耦合到一个或多个无线收发机270,无线收发机270可以是遵从的收发机或者遵从WiFi的收发机或者红外收发机。无线收发机270如图2所示是可选的。
处理系统210还可以可选地耦合到缓存215。处理系统210可包括一个或多个微处理器,例如来自Intel或IBM的微处理器。总线205以现有技术中已知的方式将这各种组件互连在一起。通常,输入/输出设备250通过输入/输出控制器耦合到系统。
存储器220可以实现为动态RAM(DRAM),动态RAM提供对数据的快速访问,但为了刷新或维护存储器220中的数据其不断地需要电力。非易失性存储器230可以是磁性硬盘驱动器或者其他的即使在系统断电之后仍保存数据的非易失性存储器。虽然图2示出了非易失性存储器230是直接耦合到数据处理系统中的其余组件的本地设备,但应当明白,其他实施例可以利用远离系统的非易失性存储器,例如网络存储设备,其通过网络接口(例如调制解调器或以太网接口)耦合到数据处理系统。
正如现有技术中公知的,总线205可包括通过各种桥接器、控制器和/或适配器相互连接的一条或多条总线,这是现有技术中已知的。在一个实施例中,I/O控制器250可包括用于控制遵从USB的外围设备的遵从USB的适配器,以及用于遵从IEEE-1394的外围设备的IEEE-1394控制器。
这里描述的本发明的一些方面至少部分可用软件实现。即,这些技术可以在计算机系统或其他数据处理系统中响应于其处理器或处理系统执行存储器(例如,存储器220、非易失性存储器230或图3所示的存储器330)中包含的指令序列而实现。在各种实施例中,硬件电路可与软件指令结合使用以实现本发明。从而,这些技术并不限于硬件电路和软件的任何特定组合或者数据处理系统所执行的指令的任何特定来源。此外,在这里的描述的各处,各种功能和操作被描述为由软件代码执行或者由软件代码引起,以便简化描述。然而,这种表述的含义是这些功能是由于处理系统执行代码而得到的。
扩展坞260和/或无线收发机270提供了物理接口,用于将图2所示的数据处理系统耦合到另外的数据处理系统,例如图3所示的数据处理系统,或者耦合到与图2所示的系统类似的另外的数据处理系统。扩展坞260可提供一个数据处理系统和另一数据处理系统之间的机械和电气连接,以允许在两个系统之间执行同步处理。在其他实施例中,无线收发机270可提供两个系统之间的射频(RF)连接,以便在无需在两个系统之间提供机械连接的情况下进行同步处理。
图3是诸如客户端设备、手持式计算机或其他类型的数据处理系统(例如图2所示的系统或者与图3所示类似的系统)之类的数据处理系统的一个实施例的框图。数据处理系统300包括处理系统310,处理系统310可以是一个或多个微处理器,或者可以是片上系统集成电路。系统300还包括用于存储数据和供处理系统310执行的程序的存储器330。系统300还包括音频输入/输出子系统340,音频输入/输出子系统340可包括麦克风和扬声器,用于例如通过扬声器和麦克风回放音乐或提供电话功能。
显示控制器和显示设备350为用户提供可视用户接口;该数字接口可包括与运行OS X操作系统软件时在Macintosh计算机上所示类似的图形用户接口。系统300还包括一个或多个无线收发机,例如WiFi收发机、红外收发机、遵从
Figure G2008800193083D00101
的收发机和/或无线蜂窝电话收发机。未示出的其他组件在某些实施例中也可作为系统300的一部分,并且在某些实施例中,在数据处理系统中可使用比图3所示要少的组件。
数据处理系统300还包括一个或多个输入设备360,设置这些输入设备360是为了允许用户向系统300提供输入。这些输入设备可以是小键盘或者键盘或者触摸面板或者多点触控面板(multi-touch panel)。数据处理系统300还包括可选的输入/输出设备370,输入/输出设备370可以是扩展坞(例如图2所示的扩展坞260)的连接器。
一条或多条总线(未示出)可用于互连各种组件,这是现有技术中已知的。数据处理系统300可以是手持式计算机或个人数字助理(PDA),或者具有类似PDA的功能的蜂窝电话,或者包括蜂窝电话的手持式计算机,或者媒体播放器(例如iPod),或者组合这些设备的多个方面或功能的设备,例如组合在一个设备中的媒体播放器与PDA和蜂窝电话。在其他实施例中,数据处理系统300可以是网络计算机或者嵌入在另外的设备内的处理设备,或者具有比图3所示更少的组件或者可能更多的组件的其他类型的数据处理系统。
这里描述的本发明的至少某些实施例可以是诸如便携式音乐和/或视频媒体播放器之类的数字媒体播放器的一部分,该数字媒体播放器可包括用于呈送媒体的媒体处理系统、用于存储媒体的存储设备,并且还可包括与天线系统和媒体处理系统相耦合的射频(RF)收发机(例如,用于蜂窝电话的RF收发机)。在某些实施例中,存储在远程存储设备上的媒体可通过RF收发机被传输到媒体播放器。媒体例如可以是音乐或其他音频、静止图片或运动图片中的一种或多种。
便携式媒体播放器可包括媒体选择设备,例如来自加利福尼亚州库珀蒂诺的Apple公司的
Figure G2008800193083D00111
或iPod
Figure G2008800193083D00112
媒体播放器上的点拨轮(clickwheel)输入设备、触摸屏输入设备、按钮设备、可移动点选输入设备或其他输入设备。媒体选择设备可用于对存储在存储设备和/或远程存储设备上的媒体进行选择。
在至少某些实施例中,便携式媒体播放器可包括显示设备,该显示设备耦合到媒体处理系统,用于显示通过输入设备选择并且通过扬声器或(一个或多个)耳机或在显示设备上或者既在显示设备上又在扬声器或(一个或多个)耳机上呈送的媒体的标题或其他指示符。便携式媒体播放器的示例在已公布的美国专利申请No.2003/0095096和2004/00224638中有所记载,这两者都通过引用并入在此。
在某些实施例中,数据处理系统300可以以类似于具有平板状输入设备的手持式计算机的小外形参数来实现,该输入设备可以是与液晶显示器相集成的多点触控输入面板设备。这种设备的示例在2006年10月24日提交的题为“AUTOMATED RESPONSE TO AND SENSING OF USERACTIVITY IN PORTABLE DEVICES”的美国专利申请No.11/586,862中提供,该申请被转让给了与本申请相同的受让人。特此通过引用将上述申请并入在此。
在以下描述中,描述了用于同步和非同步处理操作的各种软件组件。应当理解,在至少某些实施例中,对于一种类型的数据处理系统,这各种软件组件可被存储在图2所示的存储器220和/或存储器230中,并且在例如图3所示的系统的情况下,这各种不同的软件组件可被存储在存储器330中,存储器330可包括易失性存储器以及非易失性存储器,例如闪存或磁性硬盘驱动器。
在伴随着设备之间的适当互连,利用其各自的示例性实施例描述了主机设备和客户端设备之后,现在描述示例性的分组格式、分组类型、功能和数据流。与以上描述一样,以下描述提供了通信协议的示例性实施例。也可支持对这种协议的变化。
图4中的表格示出了分组头部格式的一个实施例。也可使用其他格式。虽然描述了特定的大小和长度,但是也可支持其他字段名称、长度和/或描述。
在一个实施例中,分组数据可以以小端(little-endian)或大端(big-endian)格式通过连接发送。在一个实施例中,任一设备可以以任一格式发送数据。接收方设备在必要时可负责交换数据顺序。在一个实施例中,每个分组必须使用一致的字节顺序(endianness)。在一个实施例中,预定的(例如,固定的)签名值(例如,0x4141504c36414643)可用于所有分组头部。签名可允许接收方设备确定从发送方设备发送来的数据的字节顺序。在一个实施例中,签名字段的长度是8字节;然而,也可支持其他签名字段大小。
分组头部还可包括表明包括头部在内的整个分组的长度的字段。在一个实施例中,分组长度字段可以是8个字节;然而,也可支持其他分组长度字段大小,例如支持不同的最大分组大小。分组头部还可包括表明分组序列号的字段。分组序列号可用于对在主机设备100和客户端设备150之间传输的分组排序。在一个实施例中,分组序列号字段可以是8个字节;然而,也可支持其他分组序列号字段大小。
分组头部还包括用于分组类型的字段。分组类型字段包括分组中的消息的类型的数值指示符,这表明了分组的功能。分组类型和分组类型值的一个示例性列表在图5中提供。也可支持其他分组标签、其他分组功能和/或其他分组类型值。在一个实施例中,分组类型字段可以是8个字节;然而,也可支持其他分组类型字段大小。
图5中的表格示出可用于在端点之间通信的一组分组的一个实施例。也可使用其他和/或不同的分组。虽然描述了特定的分组类型标识符和分组名称,但也可支持其他分组类型标识符、分组名称和/或描述。
图5中列出的分组的各种实施例在下文中更详细描述。这些分组描述只是提供了可以提供的一个实施例的示例。在一个实施例中,每个分组包括标准分组头部。该头部可以具有如图4所示的格式。
“状态”(Status)分组可用于响应于请求分组而提供状态信息。状态分组还可用于在故障或其他差错状况的情况下提供差错信息。在一个实施例中,状态分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  状态   8   表示所请求操作的状态的状态代码。
表3:“状态”分组
“数据”(Data)分组可用于在主机电子设备和客户端电子设备之间携带数据。在一个实施例中,数据分组可以具有任何大小。即,数据分组可以是头部加上要传输的数据的长度。在替代实施例中,数据分组可以是固定长度的,从而如果要传输的数据超过了数据分组的有效载荷容量,则可利用一个或多个另外的数据分组。在一个实施例中,数据分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  数据   可变   所请求的数据/要传输的数据。
表4:“数据”分组
“读取目录”(Read Directory)分组可用于读取目标设备上的目录。在一个实施例中,“读取目录”分组具有根据以下表格的格式。路径串可以是具有针对目标设备的适当格式的路径串。例如,对于UTF-8格式的UNIX(POSIX)路径串,路径串可以是以NULL终止的便携式操作系统接口。也可支持其他格式。POSIX标准家族被正式称为IEEE Std.1003,并且国际标准名称是ISO/IEC 9945。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  路径   可变  适当格式的路径串。
表5:“读取目录”分组
“读取文件”(Read File)分组可用于读取目标设备上的完整文件。在一个实施例中,结果在“状态”分组或“数据”分组中提供。在一个实施例中,“读取文件”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  偏移量   8   从文件开始到所请求数据的偏移量。
  长度   8   要从文件中读取的数据的长度。
  路径   可变   适当格式的路径串。
表6:“读取文件”分组
“写入文件”(Write File)分组可用于向目标设备写入完整文件。在一个实施例中,“写入文件”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  路径   可变  适当格式的路径串。
  数据   可变  要写入到文件的数据。
表7:“写入文件”分组
“写入部分”(Write Part)分组可用于向目标设备上的文件的一部分写入数据。“写入部分”分组可以是无状态的,因为当来自分组的数据被写入时,与该数据和/或文件相关联的状态数据未被维持。在一个实施例中,“写入部分”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  偏移量   8   从文件开始到写入开始的偏移量。
  路径   可变   适当格式的路径串。
  数据   可变   要写入到文件的数据。
表8:“写入部分”分组
“截断(截)文件”(Truncate(Trunc)File)分组可用于设定文件的长度。长度可以短于相应的数据,在此情况下一些数据被丢弃,或者长度可以长于相应的数据,在此情况下超出部分可用预定的数据样式(例如全“0”)来填充。在一个实施例中,“截文件”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  长度   8   文件长度。
  路径   可变   适当格式的路径串。
表9:“截文件”分组
“去除路径”(Remove Path)分组可用于删除目标设备上的文件或目录。在一个实施例中,“去除路径”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  路径   可变  适当格式的路径串。
表10:“去除路径”分组
“制作目录”(Make Directory)分组可用于在目标设备上创建目录。在一个实施例中,“去除路径”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  路径   可变  适当格式的路径串。
表11:“制作目录”分组
“获得文件信息”(Get File Info)分组可用于检索描述目标设备上文件的信息。在一个实施例中,文件信息是以在“数据”分组中传输的一个或多个键/值对的形式来提供的。描述文件的信息例如可以是文件大小、最后修改日期、许可权限。也可提供另外和/或不同的文件信息。在一个实施例中,“获得文件信息”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  路径   可变  适当格式的路径串。
表12:“获得文件信息”分组
“获得设备信息”(Get Device Info)分组可用于检索描述目标设备的信息。在一个实施例中,设备信息是以在“数据”分组中传输的一个或多个键/值对的形式来提供的。描述设备的信息例如可以是设备名称、序列号、操作系统版本、电池水平、可用空闲空间。也可提供另外和/或不同的文件信息。在一个实施例中,“获得设备信息”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
表13:“获得设备信息”分组
“原子式文件写入”(Write File Atomic)分组可用于在目标设备上写入文件。“原子式文件写入”分组保证要么整个文件被写入,要么该文件全都不被写入。“原子式文件写入”分组例如可用于写入数据库文件。在一个实施例中,“原子式文件写入”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  路径   可变  适当格式的路径串。
表14:“原子式文件写入”分组
“文件索引(Ref)打开”(File Reference(Ref)Open)分组可用于获得表示目标设备上的打开文件的令牌或其他标识符。在一个实施例中,“原子式文件写入”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  模式   8   打开文件时使用的模式(参见表16)
  路径   可变   适当格式的路径串。
表15:“文件Ref打开”分组
在一个实施例中,“模式”字段包括打开文件时使用的模式的数值指示符。表16中的“模式名称”和“模式值”称呼是用于一个实施例的示例。可以支持一组不同的模式。另外,可以支持不同的模式值。
  模式名称   模式值
  只读   1
  读-写   2
  写-截断   3
  读-写-截断   4
  写-附加   5
  读-写-附加  6
表16:模式
在“只读”模式中,文件可被打开来仅供读取。在“读-写”模式中,文件可被打开来仅供读取和写入。在“写-截断”模式中,文件可被打开来供写入或截断。在“读-写-截断”模式中,文件可被打开来供读取、写入或截断。在“写-附加”模式中,文件可被打开来供写入或附加。在“读-写-附加”模式中,文件可被打开来供读取、写入或附加。
“文件Ref打开结果”(File Ref Open Result)分组可用于返回文件索引令牌,该文件索引令牌可在访问目标设备上的文件时用于这里描述的分组之中的一个或多个中。在一个实施例中,“文件Ref打开结果”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  文件Ref   8  由于“文件Ref打开”操作而得到的文件索引
表17:“文件Ref打开结果”分组
“文件Ref读取”(File RefRead)分组可用于利用由于“文件Ref打开”操作而得到的文件索引来读取文件。在一个实施例中,文件内的位置响应于“文件Ref读取”操作而被自动推进。在一个实施例中,“文件Ref读取”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  文件Ref   8  由于“文件Ref打开”操作而得到的文件索引
  长度   8  要从文件读取的数据的长度
表18:“文件Ref读取”分组
“文件Ref写入”(File Ref Write)分组可用于利用由于“文件Ref打开”操作而得到的文件索引来写入文件。在一个实施例中,文件内的位置响应于“文件Ref写入”操作而被自动推进。在一个实施例中,“文件Ref写入”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  文件Ref   8  由于“文件Ref打开”操作而得到的文件索引
  数据   可变  要写入到文件的数据
表19:“文件Ref写入”分组
“文件Ref搜寻”(File Ref Seek)分组可用于利用由于“文件Ref打开”操作而得到的文件索引来确定文件内的位置。在一个实施例中,“文件Ref搜寻”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  文件Ref   8  由于“文件Ref打开”操作而得到的文件索引
  何处   8  要搜寻的位置。(参见表21)
  偏移量   8  从文件开始到开始读取的偏移量
表20:“文件Ref搜寻”分组
在一个实施例中,“何处”字段中的值可用于表明要如何执行搜寻。表21提供了可用于“文件Ref搜寻”分组中的“何处”值的示例。
  “何处”值   描述
  0   搜寻到由“偏移量”字段指定的绝对位置。
  1   从文件的当前位置起搜寻。
  2   从文件末尾起搜寻。
表21:用于“文件Ref搜寻”分组中的“何处”值
“文件Ref告知”(File Ref Tell)分组可用于利用由于“文件Ref打开”操作而得到的文件索引来确定文件内的位置。在一个实施例中,“文件Ref告知”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
 文件Ref   8   其位置将被返回的文件索引。
表22:“文件Ref告知”分组
“文件Ref告知结果”(File Ref Tell Result)分组可用于返回“文件Ref告知”操作的结果。在一个实施例中,“文件Ref告知结果”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  偏移量   8   所请求的文件索引的当前位置偏移量。
表23:“文件Ref告知结果”分组
“文件Ref关闭”(File Ref Close)分组可用于利用由于“文件Ref打开”操作而得到的文件索引来关闭文件。在一个实施例中,“文件Ref关闭”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  文件Ref   8  要关闭的文件的文件Ref。
表24:“文件Ref关闭”分组
“文件Ref设定大小”(File Ref Set Size)分组可用于设定与由于“文件Ref打开”操作而得到的索引相对应的文件的大小。在一个实施例中,“文件Ref设定大小”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  文件Ref   8   要关闭的文件的文件Ref。
  文件大小   8   文件的以字节为单位的新大小。
表25:“文件Ref设定大小”分组
“文件Ref设定大小分组”可用于设定文件的长度。该长度可短于相应的数据,在此情况下一些数据被丢弃,或者该长度可以长于相应的数据,在此情况下超出部分可用预定的数据样式(例如全“0”)来填充。
“重命名路径”(Rename Path)分组可用于对目标设备上的目录路径重命名。在一个实施例中,“重命名路径”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  源路径   可变   要重命名的路径的适当格式的路径串。
  目的地路径   可变   新路径名称的适当格式的路径串。
表26:“重命名路径”分组
路径串可以是具有针对目标设备的适当格式的路径串。例如,源和目的地路径串可以是UTF-8格式的以NULL终止的POSIX路径串。也可支持其他格式。在一个实施例中,目的地路径字段在“重命名路径”分组中紧跟着源路径字段。
“设定FS块大小”(Set FS Block Size)分组可用于为目标设备上的文件系统设定块大小。在一个实施例中,“设定FS块大小”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度  描述
  头部   40  标准分组头部(例如参见图2)
  块大小   8  文件系统操作的块大小
表27:“设定文件系统块大小”分组
块大小可被客户端设备文件系统所使用。例如,在64kb块大小的情况下,当向客户端设备写入文件数据时,即使主机设备按更大或更小的块发送数据,一次也将写入64kb的数据。在一个实施例中,客户端设备不保证数据是根据块大小写入的,但为了获得性能可以利用块大小。
“设定套接字块大小”(Set Socket Block Size)分组可用于为目标设备和主机设备之间的数据连接设定块大小。在一个实施例中,“设定套接字块大小”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  块大小   8   目标和主机之间的通信的块大小
表28:“设定套接字块大小”分组
块大小可被客户端系统用于经由主机设备和客户端设备之间的连接读取和写入数据。例如,在64kb块大小的情况下,当从连接读取数据时,客户端设备可以尝试以64kb块的形式读取数据。在一个实施例中,客户端设备不保证数据是根据块大小来处理的,但为了获得性能可以利用块大小。
“文件Ref锁定”(File Ref Lock)分组可用于将打开文件索引标识符锁定以免被第二应用所使用。在一个实施例中,“文件Ref锁定”分组具有根据以下表格的格式。
  字段名称   以字节为单位的长度   描述
  头部   40   标准分组头部(例如参见图2)
  文件Ref   8   要锁定的文件的文件Ref。
  锁定类型   8   要应用到文件索引标识符的锁定的类型
表29:“文件Ref锁定”分组
可以阻止对文件索引的访问,以使得在给定的时刻,只有一个应用具有对打开的文件的访问权限。在一个实施例中,支持共享锁定、独家锁定和非阻止锁定。在替代实施例中,支持另外和/或不同的锁定。在一个实施例中,锁定只是咨询性的,应用必须查询文件以判定该文件是否被锁定。在一个实施例中,多个应用/进程可获得共享锁定。
以上描述的消息和格式可用于支持完全文件通信协议。在以下示例中,分组的子集可用于说明协议的使用。也可支持许多其他操作。
图6是用于将数据传送到客户端设备的技术的一个实施例的流程图。在图6的示例中,主机设备可以判定客户端设备是否已连接到主机设备(610)。如上所述,主机设备和客户端设备之间的连接可以是有线的或无线的。
主机设备可以利用任何适当的技术来检测客户端设备的存在性。例如,如果客户端设备经由有线连接与主机设备相连接,则主机设备可被配置为检测客户端设备与有线接口的物理连接。如果客户端设备经由无线连接与主机设备相连接,则主机设备可被配置为对配对或其他类型的无线连接过程的完成做出响应。
在一个实施例中,如果没有连接客户端设备(610),则主机设备可以等待连接客户端设备。在另一实施例中,主机设备可以仅在经由接口接收到请求的情况下做出响应。例如,有线接口可包括供用户按压以发起客户端设备和主机设备之间的通信的按钮。又例如,客户端设备可以具有允许用户请求与主机设备通信的用户接口。
响应于客户端设备的连接(610),主机设备可以收集关于客户端设备的信息(620)。对关于客户端设备的信息的收集可以通过发送上述分组中的一个或多个来实现。例如,主机设备可以发送“获得设备信息”分组和/或“读取目录”分组。客户端设备可以通过将所请求的信息提供给主机设备来对(这一个或多个)分组做出响应。
在从客户端设备收集到足够的信息后,主机设备可以判定客户端设备是否是新设备(630)。即,主机设备可以判定客户端设备以前是否曾连接到主机设备。如果客户端设备是新设备,则主机设备可以执行注册过程(635)。注册过程可以允许主机设备保存关于客户端设备的信息,该信息可用于例如认证、加速连接和/或备份目的。
主机设备可以认证客户端设备(640)。认证可通过例如在主机设备和客户端设备之间交换密钥或其他标识符来实现。也可使用其他认证技术。在一个实施例中,认证是利用存在于主机设备和客户端设备上的对应同步服务来执行的。
在认证之后,主机设备可利用这里描述的分组来将数据传送到客户端设备(650)。例如,为了向客户端设备添加新文件(例如,在客户端设备上加载新的媒体文件),主机设备可以使用“写入文件”分组来使得数据被写入到客户端设备上的文件中。在单个会话中可以使用任意数目的数据传送分组。
图7是用于在主机设备和客户端设备之间同步数据的技术的一个实施例的流程图。图7的示例仅利用了以上论述的分组类型的子集。然而,图7的示例代表了利用这里阐述的协议和消息可在主机设备和客户端设备之间发生的会话。
在以下示例中,“->”表明相应分组是从主机设备发送到客户端设备的,“<-”表明相应分组是从客户端设备发送到主机设备的。分组类型首先被列出,然后分组中的一个或多个字段被列出并带有示例值,其中“<...>”表明在图7的示例中没有示出另外的字段。分组的数据部分(如果有的话)由“Data=...”来指示。首先给出分组的列表,然后在分组列表之后提供对会话的说明。
->Get Device Info
<-Data<Model=ABC123,Filesystem Size=1234,<...>>
       执行可选的注册和/或认证
->File Ref Open<Path=′/DeviceData.xml′,Mode=Read>
<-File Ref Open Result<FileRef=408>
->File Ref Read<FileRef=408,Length=8192>
<-Data<Data=<...>>
->File Ref Close<FileRef=408>
<-Status<Status=SUCCESS>
->Make Directory<Path=′/media′>
<-Status<Status=PATH_EXISTS>
->Get File Info<Path=′/media/file1.mp3′>
<-Data<Data=<...>>
->File Ref Open<Path=′/media/file1.mp3′,
mode=WriteTrucate>
<-File Ref Open Result<FileRef=831>
->File Ref Write<FileRef=831,Data=<...>>
<-Status<Status=SUCCESS>
->File Ref Write<FileRef=831,Data=<...>>
<-Status<Status=SUCCESS>
->File Ref Close<FileRef831>
<-Status<Status=SUCCESS>
->Get File Info<Path=′/media/file2.mp3′>
<-Status<Status=PATH_DOES_NOT_EXIST>
->File Ref Open<Path=′/media/file2.mp3′,
mode=WriteTrucate>
<-File Ref Open Result<FileRef=831>
->File Ref Write<FileRef=831,Data=<...>>
<-Status<Status=SUCCESS>
->File Ref Write<FileRef=831,Data=<...>>
<-Status<Status=SUCCESS>
->File Ref Close<FileRef831>
<-Status<Status=SUCCESS>
在图7的示例中,主机设备可以判定客户端设备是否已经连接到主机设备(710)。如上所述,主机设备和客户端设备之间的连接可以是有线的或者无线的。
主机设备可以利用任何适当的技术来检测客户端设备的存在性。例如,如果客户端设备经由有线连接与主机设备相连接,则主机设备可被配置为检测客户端设备与有线接口的物理连接。如果客户端设备经由无线连接与主机设备相连接,则主机设备可被配置为对配对或其他类型的无线连接过程的完成做出响应。
在一个实施例中,如果没有连接客户端设备(710),则主机设备可以等待连接客户端设备。在另一实施例中,主机设备可以仅在经由接口接收到请求的情况下做出响应。例如,有线接口可包括供用户按压以发起客户端设备和主机设备之间的通信的按钮。又例如,客户端设备可以具有允许用户请求与主机设备通信的用户接口。
响应于客户端设备的连接(710),主机设备可以收集关于客户端设备的信息(720)。对关于客户端设备的信息的收集可以通过从主机设备向客户端设备发送“获得设备信息”分组以及从客户端设备向主机设备发送“数据”分组来实现。如上所述,主机设备可通过这种方式获取关于客户端设备的任何类型的信息。在图7的示例中,客户端设备至少向主机设备提供型号标识符和文件系统大小。也可提供另外和/或不同的数据。
可选地,在从客户端设备收集到足够的信息后,主机设备可以判定客户端设备是否是新设备(730)。如果客户端设备是新设备,则主机设备可以执行可选的注册过程(735)。主机设备可以认证客户端设备(740)。认证可通过例如在主机设备和客户端设备之间交换密钥或其他标识符来实现。也可使用其他认证技术。在一个实施例中,认证是利用存在于主机设备和客户端设备上的对应同步服务来执行的。
在认证之后,主机设备可以开始主机设备和客户端设备之间的数据同步。客户端设备可以请求与客户端设备上的路径相对应的文件Ref值并且读取该路径中的数据(750)。这可通过利用例如以上列出的“文件Ref打开”、“文件Ref打开结果”、“文件Ref读取”、“数据”分组来实现。如果所请求的目录不存在,则可以创建该目录(750)。当已获取所请求的数据时,可以关闭文件Ref。这可通过使用以上列出的“文件Ref关闭”和“状态”分组来实现。
“制作目录”分组可用于判定是否存在目标路径。例如,利用以上列出的分组,具有目标“/media”的“制作目录”分组可用于判定是否存在“media”目录。如果存在“media”目录,则来自客户端设备的该“状态”分组可以利用“PATH_EXISTS”状态来表明“media”目录的存在。
可以为要更新的第一文件(例如,′/media/file1.mp3′)请求文件信息。“获得文件信息”分组可用于请求与要更新的第一文件有关的信息(770)。客户端设备可以使用“数据”分组来返回与要更新的第一文件有关的数据。
主机设备随后可请求在更新第一文件时使用的文件Ref值。这可利用“文件Ref打开”分组来实现,来自客户端设备的响应则在“文件Ref打开结果”分组中。主机设备可以使用文件Ref值来将数据写入到客户端设备上的文件(775)。这可利用“文件Ref写入”分组来实现,来自客户端设备的确认则由“状态”分组携带。当对文件的写入完成时,主机设备可以使用“文件Ref关闭”分组来释放文件Ref,这可由来自客户端设备的“状态”分组加以确认。
“制作目录”分组可用于判定是否存在用于要更新的第二文件的目标路径。例如,利用以上列出的分组,具有目标“′/media/file2.mp3′”的“获得文件信息”分组可用于判定是否存在“file2.mp3”文件并且获得与该文件有关的信息(780)。如果例如不存在“file2.mp3”文件,则来自客户端设备的“状态”分组可返回“PATH_DOES_NOT_EXIST”状态。
主机设备随后可请求在更新第二文件时使用的文件Ref值。这可利用“文件Ref打开”分组来实现,来自客户端设备的响应则在“文件Ref打开结果”分组中。主机设备可以使用文件Ref值来将数据写入到客户端设备上的文件(785)。这可利用“文件Ref写入”分组来实现,来自客户端设备的确认则由“状态”分组携带。当对文件的写入完成时,主机设备可以使用“文件Ref关闭”分组来释放文件Ref,这可由来自客户端设备的“状态”分组加以确认。
以类似的方式可以更新任意数目的文件。如果同步未完成(790),则可以如上所述地更新另外的文件。如果同步完成(790),则可以终止同步会话。
本公开的另一方面涉及复用式数据流协议。这种协议的使用使得设备上的多个应用(或者同一应用)能够与另一设备上的一个或多个应用维持任意数目的多个并发会话,并且随着应用动态地引起会话的创建或者其会话的关闭,并发会话的数目可随时间而变化。这种协议可以按独立于一个设备和另一设备(例如,主机)两者上使用的接口(例如,USB接口或BLUETOOTH接口)的传输的方式来实现,并且在同一个共同的链路/接口(例如,USB接口)上可以维持多个独立连接。在一个实施例中,建立单个USB会话,并且在该单个USB会话上隧传(tunnel)了任意且可改变数目的多个并发会话。在一个实施例中,特定接口例如USB应当支持成帧,或者某种成帧协议应当被添加,例如COBS(恒定开销字节填充)或PPP/SLIP风格的成帧。多个独立连接可被同时用于不同目的(例如,诸如媒体文件之类的文件可被传送,同时诸如地址簿中的联络人之类的结构化数据可在设备之间被交换和/或同步,同时其他数据(例如,电子邮件或设置信息或软件窗口小部件)也在设备之间被交换)。支持多个独立连接的能力对于具有多任务操作系统(OS)的设备尤其有用,这种操作系统允许多个应用同时运行,但这种OS并非必要的。
图14B示出了利用本发明一个实施例任意数目的多个“客户端”应用(例如,用于同步结构化数据的同步软件、用于传送文件的文件传送软件、备份软件等等)如何能够在诸如USB(有线或无线)或BLUETOOTH之类的非网络接口上维持多个并发连接或会话。图14A示出了在现有技术中实际上在每个设备上仅有一个客户端应用(或者静态的、固定数目的客户端应用)能够使用设备之间的USB连接。在图14A的互连的系统1401中,主机上的客户端应用1402使用PTP(图片传送协议)1403通过其USB接口1405和连接1407来发送和接收数据,并且设备上的客户端应用1411使用PTP协议(未示出)通过设备的USB接口1409来发送和接收数据。连接1407以及USB接口1405和1409仅支持单个连接或会话。与之不同,互连的系统1421通过连接1429以及USB接口1427和1431支持多个独立且并发的连接或会话。主机设备上的多个客户端应用1423可以与多个客户端应用1435中其各自的对应物维持独立且并发的连接或会话。例如,在图8所示的系统的情况下,设备801上的文件传送软件807可以与主机803上的媒体软件831(例如,iTunes)(或者与文件传送软件833)具有打开且维持的连接,同时设备801上的同步软件805可以与主机上的同步软件835维持打开的连接(其独立于软件807和831之间的连接)。多个独立且并发的连接可以通过在主机和设备两者上使用类TCP协议来实现,其中具有类TCP头部的类TCP分组通过非网络接口(例如USB接口1427和1431)传输。类TCP分组被主机上的接口TCP(TCP over interface)1425软件和设备上的接口TCP 1431软件所处理。接口TCP 1425软件可以与图8中的接口TCP软件821相同或相似,接口TCP 1431软件可以与图8中的接口TCP软件841相同或相似。类TCP分组在类TCP头部中指定与建立了连接的相应源(例如,发送方)和目的地(例如,接收方)应用相关联的相应的源和目的地端口,并且对这些端口的指定允许了维持独立且并发的连接。这里描述的方法还提供了一种机制,用于在连接被突然或意外断开的情况下(例如,当用户将设备从其USB线缆或支座上拔掉以便应答由无线蜂窝电话接收到的电话呼叫,从而使设备与主机断开连接时)得体地恢复。类TCP协议在会话被切断时向源和目的地应用提供通知,并且该通知可被应用用来处理通知并清扫其状态并且实现对数据的任何期望校正。类TCP协议可以允许源和目的地应用通过全部或部分忽略发生故障的连接会话(例如,通过删除部分接收的文件或部分接收的结构化数据集并且设定差错消息或状态消息,该差错消息或状态消息将使得两个设备在重新连接时在这些源和目的地应用之间建立新的连接以便交换在先前发生故障的连接会话中尝试交换的数据),来从断开的通信中迅速且得体地恢复。
类TCP协议还可结合在类TCP协议上方运行的文件传送协议使用,并且文件传送协议可用于在两个设备之间提供文件传送,并且利用分组(例如,类TCP分组)传送的文件可以在接收方被重建,并且可在(利用多个类TCP分组接收的)所有数据都已被接收到之后被核实(或者它可以在部分文件被接收到之后被部分地核实)。可以利用传统的校验和操作或散列操作来核实文件。许多不同类型的软件可结合这个类TCP协议使用,例如任何结合双向字节流工作的协议可被层叠在这个类TCP协议上方。这些不同类型的软件可以包括telnet(例如,用于交互式telnet会话)、rsync、用于远程调试另一设备上的应用的gdb over IP,等等。另外,在这个类TCP协议上方运行的软件可实现事务型协议,包括对原子事务的使用。这个类TCP协议允许了在这个类TCP协议上方运行的一层或多层软件提供其服务和功能,而不要求它们负责与在另一系统上运行的另一软件建立和维持连接。
应当理解,术语“设备”和“主机”是可互换使用的;换言之,“设备”既适用于设备也适用于主机。主机是设备,并且设备可以被认为是主机。然而,在某些实施例中,会话可仅由主机发起并且是从主机到设备的,在这种情况下主机不可与设备互换。还应当理解,这里描述的类TCP协议是提供一种支持独立连接的复用和流控制的可靠传输机制的通信协议的示例,提供类似机制的其他协议也可作为替代用于本发明的至少某些实施例中。还应当明白,在本发明的至少某些实施例中,诸如TCP硬件加速器之类的硬件可用于完全或部分替换这里描述的软件。
图8示出了通过(设备上的)接口823和(主机上的)接口847连接的互连的设备801和主机803的示例。这些接口可以被认为是非网络接口,例如USB或BLUETOOTH接口。换言之,用于外围设备(例如,鼠标、键盘、存储设备)但不用于连接到计算机网络(例如LAN(局域网)或因特网)的接口被用于连接主机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包括若干个客户端应用831、833、835和837,这些客户端应用可以通过接口823和847与设备801上的客户端应用805、807和809交换数据和/或文件。图8示出了主机803和设备801上的某些客户端应用的示例,但在设备和主机之一或两者之上可以有更多或更少或不同的客户端应用。在图8所示的示例中,主机803上的客户端应用通过一提供软件模块之间的互通信的套接字API 839与接口TCP软件841和TCP/IP软件栈843通信。套接字API 839响应于对套接字API的调用而为基于流的协议的会话的每个端点提供一个打开的套接字。套接字API 819在设备801上提供类似的功能,从而允许创建打开的套接字,以建立并维持TCP/IP软件栈815和接口TCP软件821之间的通信,并且允许客户端应用805、807和809与TCP/IP软件栈建立并维持通信(通过可选的关守811)。通常,一方的每个客户端应用被配置为与另一方的相应对应物维持连接。例如,同步软件835被配置为与同步软件805维持连接,以便在设备之间交换数据(例如,结构化数据或窗口小部件等等)。同步软件835和同步软件805的示例在2007年1月7日提交的题为“Synchronization Methods andSystems”的美国专利申请No.11/650,730中提供,该申请通过引用被并入在此。媒体软件831(其可以是媒体播放器,例如iTunes)被配置为与文件传送软件807(其可以是设备上的媒体播放器,例如iTunes)维持连接。文件传送软件在某些实施例中还可以被配置为与文件传送软件833维持连接。文件共享软件809被配置为与文件共享软件837维持连接。这些连接可通过一个或多个可选的关守来维持,所述关守例如是关守811以及主机上的可能存在于客户端应用831、833、835、837与接口TCP软件841之间的相应关守(未示出)。在至少某些实施例中,关守帮助在需要经认证的连接的情况下在设备和主机之间创建这种连接。图8中的关守可以与图1所示的关守客户端115和关守180相同或相似。用于某些应用(例如,文件共享或telenet或gdb over IP)的连接可以完全绕开设备上的关守。
在下文中结合对图9-12的描述来进一步描述TCP/IP软件栈815、接口TCP软件821以及接口TCP软件841的操作。这些软件组件支持这里描述的复用式数据流协议。
设备801包括数据813,该数据813可被存储在包括闪存、硬盘驱动器、易失性半导体存储器等等在内的多个存储介质中的任何一个之中。该数据可包括用于地址簿、日历、待做事项和注释的结构化数据,该数据可以如这里所述通过同步软件805和同步软件835来加以同步。另外,数据813还可包括媒体文件,例如用于音乐的MP3文件或者用于电影或其他视听媒体的MPEG 4文件。数据813还可包括其他类型的数据(例如,字处理文件等等)或者甚至包括可执行程序,例如窗口小部件、与设置信息和电子邮件或电话账户信息有关的数据,等等。应当明白,设备方的各种客户端应用与包含数据813的存储设备通信以便访问数据。例如,文件传送软件807可以读取或写入数据813以便传送文件。应当理解,主机设备803也包括数据存储介质,例如闪存或硬盘驱动器或易失性存储器设备(例如,DRAM),或者其他存储介质,用于存储供主机803上的客户端应用使用的数据。
图8示出了主机设备803的一个示例,而图13示出了主机设备的替代软件体系结构。主机设备1301包括若干个客户端应用,其中包括应用1303、1305和1307,其每一个通过套接字API 1309耦合到TCP/IP软件栈1313和接口TCP软件1311。TCP/IP软件栈1313也可通过套接字API1309耦合到接口TCP软件1311,以便通过USB或BLUETOOTH接口1315来发送和接收分组。环回接口1317耦合到TCP/IP软件栈1313,以便在TCP/IP软件栈1313和接口TCP软件1311之间为分组提供路径。接口TCP软件1311耦合到接口1315,接口1315类似于图8的接口847。TCP/IP软件栈1313耦合到接口1319,接口1319类似于图8所示的接口817。图13所示的主机和图8所示的主机之间的主要差异在于通过接口847接收和发送的类TCP分组是由接口TCP软件841而不是由TCP/IP软件栈843处理的;另一方面,在图13所示的主机设备的情况下,通过接口1315发送和接收的类TCP分组是由接口TCP软件1311和TCP/IP软件栈1313两者处理的。
图9是示出根据本发明一个实施例用于在两个系统(例如主机和设备)之间交换数据的方法的示例的流程图。该方法开始于一方,并且在两个设备之间完成数据交换之后,结束于另一方。在操作901中,从同时具有通过非网络接口(例如USB或BLUETOOTH接口)支持的独立会话的多个独立应用中的至少一个接收数据流。该数据流可通过套接字接口来接收。例如,由媒体软件831控制的媒体文件可通过套接字接口向接口TCP软件841发送媒体文件。在操作903中,为数据流中的数据创建分组,并且这些分组包括头部,例如分组中的类TCP头部。例如,接口TCP软件841可以根据数据流创建分组,并且这些分组中的每一个包括每个分组中的类TCP头部。这些分组在操作905中通过非网络接口(例如接口847)被发送。进而,这些分组在其他系统处通过类似的非网络接口(例如接口823)被接收。然后,在操作909中,分组中的数据被例如接口TCP软件821所提取。可以根据分组内的端口标识符来确定数据的目的地,这使得数据可以被发送或提供到接收设备上的目的地应用。如果数据是诸如MP3文件或电影文件等等之类的文件的一部分,则该文件在操作911中被重建并且可选地被核实。核实可以包括对整个文件使用校验和或者散列操作,这是现有技术中已知的。如果在连接期间的任何时刻,用户或系统导致发生断开连接(例如,从设备中拔掉USB线缆),则两方清扫其状态并且关闭其套接字,从而终止两个设备之间的类TCP连接。这样就告知了主机上的客户端和设备上的服务:会话结束了。另外,设备上的服务或主机上的客户端可以在任何时间关闭会话,并且另一方将被告知会话已被关闭。
图10提供了根据本发明一个实施例的初始化或设置方法的示例。在操作1001中,主机的接口TCP软件从诸如主机上的iTunes之类的应用的接收调用,以在诸如通过套接字API提供的端口“X”之类的端口上进行连接。响应于该调用,主机的接口TCP软件在操作1003中创建类TCP分组,例如SYN TCP分组,并且使得该分组通过非网络接口(例如USB接口或者图8所示的接口847)被发送。设备的接口TCP软件通过设备的非网络接口(例如,接口823,其可以是USB接口)接收该类TCP分组并且生成一个或多个调用,以获得套接字并且在诸如与TCP/IP软件栈815相关联的环回地址上的端口之类的端口上连接该套接字。设备在操作1007中使得synack TCP分组被创建,并且接口TCP软件使得通过设备的非网络接口将该synack类TCP分组发送到主机的非网络接口。如操作1009中所示,设备和主机两者上的接口TCP软件都可维持关于哪个端口/会话与哪个套接字相关联的信息。
图11示出了用于将数据从主机传送到设备的方法的一个示例。在操作1101中,主机上的应用(例如主机上的iTunes)在该应用的套接字上向主机上的接口TCP软件发送数据。例如,在主机803的情况下,媒体软件831通过为该应用打开的套接字向接口TCP软件841发送数据。在操作1103中,主机上的接口TCP软件接收该数据并且创建类TCP分组,在该分组内具有类TCP头部和该数据中的至少一些,并且主机上的接口TCP软件通过非网络接口(例如USB接口或图8所示的接口847)来发送该分组。在操作1105中,设备上的接口TCP软件从分组中提取数据并且将该数据(有时称为“有效载荷”)发送到由分组中的端口指定的套接字上。在图8的示例中,接口TCP软件821提取通过接口823接收的数据并且将该数据发送到套接字上,这将使得数据被提供到TCP/IP软件栈815。在操作1107中,设备上的TCP/IP栈,例如TCP/IP软件栈815,获得来自设备上的接口TCP软件的数据,并且创建带有IP和TCP头部的分组。此情况下的IP地址可以是TCP/IP栈的环回地址。例如,TCP/IP软件栈815可包括环回接口(未示出),例如图13所示的环回接口。分组将从该环回接口返回,并且TCP/IP栈在操作1107中去除TCP和IP头部并且将数据在套接字上发送到应用。在图11所示的应用是主机上的iTunes应用的示例中,设备上的接收方应用可以是文件传送软件807,该文件传送软件可以是设备上的媒体播放器的一部分。
图12示出了用于将数据从设备传送到主机的方法的示例。在操作1201中,设备上的应用,例如同步软件805或者媒体播放器软件,通过用于该应用的套接字将数据发送到TCP/IP栈软件或设备,例如TCP/IP软件栈815。在操作1203中,TCP/IP软件栈将数据分解为分组,并且将TCP和IP头部与数据包括在一起以便创建分组。IP头部中的IP地址可以是环回地址,以使得分组被返回到TCP/IP软件栈,例如软件栈815。在操作1205中,分组被引导到环回地址并从环回地址返回,并且被TCP/IP软件栈所接收,TCP/IP软件栈去除TCP和IP头部并且将数据以数据流的形式传送到接口TCP软件,例如设备上的接口TCP软件821。在操作1207中,接口TCP软件接收来自TCP/IP软件栈815的数据,并且创建包含分组化数据和类TCP头部的分组,并且调用USB驱动器以利用USB接口(例如接口823)上的USB协议来发送分组。在操作1209中,这些分组被从设备的USB接口发送到主机的USB接口,例如主机上的接口847。然后,在操作1211中,主机上的接口TCP软件,例如接口TCP软件841,接收分组并且去除类TCP头部,并且通过例如套接字API将数据传送到接收方应用。
图15提供了用于在两个设备之间交换文件的方法的示例。在此情况下,数据通常不是诸如联络信息等等之类的被同步的结构化数据。更确切地说,数据构成整个文件。在操作1501中,数据以分组的形式与类TCP头部一起通过诸如接口823或接口847之类的接口被传送。在操作1503中,这些分组通过另一系统上的另一接口被接收,并且数据被从多个分组中提取出来以准备重新组装文件。然后,在操作1505中,重建文件。这可以在文件的所有数据已被接收到之后发生或者可以在数据被接收的同时发生。如果在文件传送期间连接丢失,则存储差错消息和/或状态消息以表明文件未被成功传送,以便其可在设备被重新连接时被传送。文件可以在文件的所有数据已被接收到之后被加以核实或者可在其被接收的同时被部分核实。核实可以是可选的操作,例如操作1507,并且可以通过使用传统的校验和操作或散列操作来执行。图15的方法中使用的分组可以包括作为文件传送协议的一部分的信息。例如,分组可以包括对具有预定分组格式的分组类型和与该分组类型相关联的分组功能的指示。分组功能可以指定文件传送协议软件的操作。在发生连接断开的情况下的差错消息或状态消息可以至少包括在连接被中断之前仅部分传送的文件的标识符,以便在重新建立连接时可传送该文件。
以下是对图8-13、图14B和图15所示的一个或多个实施例的实现方式的描述;此实现方式允许设备和主机经由USB通信。该实现方式可被称为设备通信协议,该协议可用来允许诸如文件传送软件807(例如,用于iTunes媒体同步)和结构化数据同步(例如,同步软件805)之类的多个服务同时与设备通信,而无需另外的USB端点。此实现方式中的通信协议是作为厂商特定接口实现的。厂商特定接口利用两个端点,即大块输入(Bulk Input)端点和大块输出(Bulk Output)端点。
虽然该协议并不完全是典型的TCP,但它确实使用了类似TCP的机制来进行流控制、连接建立/终止和复用。
根据此设备通信协议的接口是通过找到这样一个接口来识别的:
-设备的厂商ID为Apple(0x05AC)
-接口类为厂商特定(255)
-接口子类为254
-接口协议为2
接口#1-厂商特定
替代设定    0
端点数目    2
接口类:255(厂商特定)
接口子类:254(厂商特定)
接口协议:2
端点0x85-大块输入
地址:0x85(输入)
属性:0x02(大块无同步数据端点)
最大分组大小:512
查询间隔:0(端点永不NAK)
端点0x04-大块输出
地址:0x04(输出)
属性:0x02(大块无同步数据端点)
最大分组大小:512
查询间隔:0(端点永不NAK)
1)消息头部
所有数据都是以消息的形式发送的。每个消息开始于以下头部。所有头部都是按网络字节顺序的。
AppleUSBMobileDeviceMessageHeader
+-------+-------+-------+-------+-------+-------+-------+-------+
|类型(32比特)               |长度(32比特)       |
+-------+-------+-------+-------+-------+-------+-------+-------+
存在两个定义的消息类型:
0-版本消息
6-TCP消息
长度字段用于验证接收到的USB数据报是正确大小的。长度包括消息头部的大小。USB以分组的形式发送数据。对于大块USB端点,最大分组大小由速度决定。只要你保持发送标准大小的分组,数据就被认为是帧的一部分。为了结束帧,应当发送小于最大分组大小的分组。如果帧将正常地正好结束于两个标准大小分组的边界上(帧大小%最大分组大小为0),则可以发送零长度分组来表示帧的结束。头部中的长度字段应当匹配所接收的帧的大小。如果它不匹配,则帧应当被丢弃。应当记录差错来追踪故障。在大多数情况下,后续的帧也会出问题,因而也必须被丢弃。这些差错不应当发生。将利用TCP消息来检测丢失,并且将放弃该TCP连接。
2)版本消息
版本消息是在开始时交换的,用于协商要使用的协议的版本。当设备出现时,它应当等待版本消息。主机负责发送第一条版本消息。版本消息具有以下格式:
+-------+-------+-------+-------+-------+-------+-------+-------+
|0                    |此消息的大小                 |
+-------+-------+-------+-------+-------+-------+-------+-------+
|版本(32比特)               |特征(32比特)               |
+-------+-------+-------+-------+-------+-------+-------+-------+
|应当为零(32比特)                |
+-------+-------+-------+-------+
版本
主机->设备-请求的版本
设备->主机-支持的版本
特征
主机->设备
表明期望特征的比特字段。
设备->主机
表明将使用的特征的比特字段。
对于此实现方式,主机应当将“版本”设定为1。特征应当为零,因为目前没有支持的特征。将来,可以添加诸如校验和之类的特征,而不会冲击版本。此外,可以利用特征字段来实现校验和,而无需定义全新的版本。特征字段是基于版本来解释的。版本1的“特征”字段中的各种比特可具有与版本2中的“特征”不同的含义。主机可以通过设定“特征”字段中的相应比特来请求特征。
设备应当以所支持的版本来做出响应。设备可以仅支持一个版本,或者它可支持多个版本。如果设备支持主机所请求的版本,则设备应当以该版本来做出响应。如果设备仅支持一不同的版本,则设备应当以它支持的版本来做出响应。如果设备以所请求的版本做出响应,则设备应当将特征比特字段设定为所请求的比特,其中掩蔽掉任何不支持的特征。如果响应版本不与所请求的版本匹配,则“特征”字段应当为零。
如果设备以指示出主机不理解的版本的版本消息来做出响应,则主机可能需要更新的软件来与设备通信。如果设备以与主机支持的所请求版本不同的版本来做出响应,则主机可以发送另一版本消息,其带有新协商的版本,并且在“特征”字段中设定了比特以请求特定的特征。设备应当准备好处理多个版本消息。
3)TCP消息
对于经由USB的数据通信,使用TCP消息。TCP消息是AppleUSBMobileDeviceHeader,其中协议值为6并且大小被设定为包括头部在内的整个消息的大小。AppleUSBMobileDeviceHeader后面是TCP头部。目前不支持可变头部长度和TCP选项。
有效载荷(如果有的话)跟在TCP头部后面。
+-------+-------+-------+-------+-------+-------+-------+-------+
|6                    |此消息的大小                 |
+-------+-------+-------+-------+-------+-------+-------+-------+
|src端口      |dst端口     |序列                     |
+-------+-------+-------+-------+-------+-------+-------+-------+
|确认                         |hl|标志      |窗口大小        |
+-------+-------+-------+-------+-------+-------+-------+-------+
|校验和         |紧急指针       |
+-------+-------+-------+-------+
紧急指针和校验和字段目前未被使用并且在此实现方式中应当被设定为零。由于USB被认为是可靠的,因此确认是隐含的。单纯的ACK分组被发送来更新窗口。
3.1)发起连接
通过主机向设备发送TCP SYN分组来建立连接。dst(目的地)端口被用于确定在主机上连接哪个服务。src(源)端口/dst端口元组应当是唯一的,以将此连接与任何其他连接区分开来。
如果接受连接,则设备利用SYN/ACK分组对SYN分组做出响应。如果没有足够的资源,或者没有服务在所请求的端口上侦听,则设备可以拒绝连接请求。为了拒绝连接,设备应当发送TCP RST。
正常的TCP连接涉及三次握手。由于USB被认为是可靠的,因此第三分组,即从主机到设备的ACK,在此实现方式中可被丢弃(不使用)。设备一旦发送了SYN/ACK分组就认为连接已建立。主机一旦接收到SYN/ACK分组就认为连接已建立。
对于SYN标志递增序列和确认号,就像在真实(典型)TCP中那样。
窗口偏移值8被使用,但此选项未被协商。
3.2)终止连接
当设备或主机希望关闭连接时,它发送TCP RST。响应于TCP RST,主机或设备应当清扫与通过源和目的地TCP端口指定的连接相关联的任何资源。
FIN标志在此实现方式中未被使用。在此实现方式中没有半关闭。
3.3)发送数据
序列和确认号被用于流控制。当主机或设备发送带有有效载荷的TCP消息时,序列号按所发送的有效载荷的大小而递增。主机和设备不被允许发送超出最后确认的数据加上最后通告的窗口的数据。流控制就是这样实现的。假定所发送的任何数据都将被接收到。在此实现方式中不支持重发。替代实施例可以使用重发,如果需要这种特征的话。发送数据一方一旦发送了数据就可丢弃数据的本地拷贝。
3.4)接收数据
数据被假定是按顺序到达的。如果主机或设备接收到乱序的发送(基于序列号),则主机应当关闭连接并且发送TCP RST。
当主机或设备有更多缓冲器空间可用时,它可以发送带有更新的窗口的TCP ACK分组,以表明另一方可发送更多数据。
本说明书中提及“一个实施例”或“实施例”指的是联系该实施例描述的特定的特征、结构或特性被包括在本发明的至少一个实施例中。在本说明书中各处出现的短语“在一个实施例中”并不一定都指同一实施例。
在以上说明书中,已经参考其具体实施例描述了本发明。然而,很明显,在不脱离本发明的更宽精神和范围的情况下,可以对其进行各种修改和变化。因此,说明书和附图应当被看作说明性的而非限制性的。

Claims (20)

1.一种机器实现的方法,包括:
利用第一网络栈软件创建分组以便通过设备上的第一接口发送,并且利用所述第一网络栈软件从通过所述第一接口接收的分组中提取数据;
利用第二网络栈软件创建分组以便通过所述设备上的第二接口发送,并且利用所述第二网络栈软件从通过所述第二接口接收的分组中提取数据,所述第二网络栈软件被配置为与所述第一网络栈软件通信,其中所述第二接口被配置为耦合到另一系统上的第三接口;
利用所述第二网络栈软件通过所述第一网络栈软件来发送从通过所述第二接口接收的分组中提取的数据;
利用所述第二网络栈软件来利用设计用于所述第二接口的协议来发送和接收分组;以及
利用所述第一网络栈软件和所述第二网络栈软件,允许所述设备上的多个应用通过所述第二接口维持多个并发会话。
2.如权利要求1所述的方法,其中,
利用所述第二网络栈软件通过所述第一网络栈软件来发送从通过所述第二接口接收的分组中提取的数据的步骤把该数据发送到多个接收方软件应用,这多个接收方软件应用被允许通过所述第二接口维持多个并发会话。
3.如权利要求1所述的方法,其中,所述第一接口被设计为耦合到因特网并且所述第二接口未被设计来使用因特网协议IP地址,并且所述第一网络栈软件包括TCP/IP栈并且所述第二网络栈软件包括不创建IP头部的遵从TCP的栈。
4.如权利要求3所述的方法,还包括:
利用所述第二网络栈软件从通过所述第二接口接收的分组中提取数据,并且利用所述第二网络栈软件通过所述第一网络栈软件将该数据发送到所述设备上的所述多个应用之一。
5.如权利要求4所述的方法,其中,所述第二接口是遵从通用串行总线USB的有线串行接口或遵从BLUETOOTH的无线接口中的一种,并且所述第二接口和所述第三接口使用相同的不使用IP地址的协议。
6.如权利要求5所述的方法,其中,由所述第二网络栈软件创建的头部包括用于流控制和定序的数据以及接收方应用的端口标识符。
7.如权利要求6所述的方法,其中,由所述第二网络栈软件从分组中提取的数据被提供给所述第一网络栈软件,所述第一网络栈软件向该数据添加TCP/IP头部以创建另外的分组,然后从所述另外的分组中去除所述TCP/IP头部,然后将该数据提供给所述接收方应用。
8.如权利要求7所述的方法,其中,所述TCP/IP头部包括与环回接口相对应的IP地址,该环回接口与所述第一网络栈软件操作性地耦合。
9.一种机器实现的方法,包括:
利用第一网络栈软件创建分组以便通过设备上的第一接口发送,并且利用第一网络栈软件从通过所述第一接口接收的分组中提取数据;
利用第二网络栈软件创建分组以便通过所述设备上的第二接口发送,并且利用所述第二网络栈软件从通过所述第二接口接收的分组中提取数据,所述第二网络栈软件被配置为与所述第一网络栈软件通信,其中所述第二接口被配置为耦合到另一系统上的第三接口;
利用所述第二网络栈软件创建包含从所述第一网络栈软件接收的数据的分组;
利用所述第二网络栈软件通过所述第二接口来发送包含从所述第一网络栈软件接收的数据的分组;
利用所述第二网络栈软件来利用设计用于所述第二接口的协议来发送和接收分组;以及
利用所述第一网络栈软件和所述第二网络栈软件,允许所述设备上的多个应用通过所述第二接口维持多个并发会话。
10.如权利要求9所述的方法,其中,所述第一接口被设计为耦合到因特网并且所述第二接口未被设计来使用因特网协议IP地址,并且所述第一网络栈软件包括TCP/IP栈并且所述第二网络栈软件包括不创建IP头部的遵从TCP的栈。
11.如权利要求10所述的方法,其中,所述第二接口是遵从通用串行总线USB的有线串行接口或遵从BLUETOOTH的无线接口中的一种,并且所述第二接口和所述第三接口使用相同的不使用IP地址的协议。
12.如权利要求11所述的方法,其中,由所述第二网络栈软件创建的头部包括用于流控制和定序的数据以及接收方应用的端口标识符。
13.如权利要求12所述的方法,其中,从所述第一网络栈软件接收的数据在被递送到所述第二网络栈软件之前曾被用TCP/IP头部来分组化并被去分组化,并且所述TCP/IP头部包括与环回接口相对应的IP地址,该环回接口与所述第一网络栈软件操作性地耦合。
14.一种用于在设备之间传输数据的装置,包括:
用于利用第一网络栈软件创建分组以便通过设备上的第一接口发送并且利用所述第一网络栈软件从通过所述第一接口接收的分组中提取数据的装置;
用于利用第二网络栈软件创建分组以便通过所述设备上的第二接口发送并且利用所述第二网络栈软件从通过所述第二接口接收的分组中提取数据的装置,所述第二网络栈软件被配置为与所述第一网络栈软件通信,其中所述第二接口被配置为耦合到另一系统上的第三接口;
用于利用所述第二网络栈软件通过所述第一网络栈软件来发送从通过所述第二接口接收的分组中提取的数据的装置;
用于利用所述第二网络栈软件来利用设计用于所述第二接口的协议来发送和接收分组的装置;以及
用于利用所述第一网络栈软件和所述第二网络栈软件允许所述设备上的多个应用通过所述第二接口维持多个并发会话的装置。
15.如权利要求14所述的装置,其中,
用于利用所述第二网络栈软件通过所述第一网络栈软件来发送从通过所述第二接口接收的分组中提取的数据的装置是把该数据发送到多个接收方软件应用的装置,这多个接收方软件应用被允许通过所述第二接口维持多个并发会话。
16.如权利要求14所述的装置,其中,所述第一接口被设计为耦合到因特网并且所述第二接口未被设计来使用因特网协议IP地址,并且所述第一网络栈软件包括TCP/IP栈并且所述第二网络栈软件包括不创建IP头部的遵从TCP的栈。
17.如权利要求16所述的装置,还包括:
用于利用所述第二网络栈软件从通过所述第二接口接收的分组中提取数据的装置和用于利用所述第二网络栈软件通过所述第一网络栈软件将该数据发送到所述设备上的所述多个应用之一的装置。
18.一种用于在设备之间传输数据的装置,包括:
用于利用第一网络栈软件创建分组以便通过设备上的第一接口发送并且利用第一网络栈软件从通过所述第一接口接收的分组中提取数据的装置;
用于利用第二网络栈软件创建分组以便通过所述设备上的第二接口发送并且利用所述第二网络栈软件从通过所述第二接口接收的分组中提取数据的装置,所述第二网络栈软件被配置为与所述第一网络栈软件通信,其中所述第二接口被配置为耦合到另一系统上的第三接口;
用于利用所述第二网络栈软件创建包含从所述第一网络栈软件接收的数据的分组的装置;
用于利用所述第二网络栈软件通过所述第二接口来发送包含从所述第一网络栈软件接收的数据的分组的装置;
用于利用所述第二网络栈软件来利用设计用于所述第二接口的协议来发送和接收分组的装置;以及
用于利用所述第一网络栈软件和所述第二网络栈软件允许所述设备上的多个应用通过所述第二接口维持多个并发会话的装置。
19.如权利要求18所述的装置,其中,所述第一接口被设计为耦合到因特网并且所述第二接口未被设计来使用因特网协议IP地址,并且所述第一网络栈软件包括TCP/IP栈并且所述第二网络栈软件包括不创建IP头部的遵从TCP的栈。
20.如权利要求19所述的装置,其中,所述第二接口是遵从通用串行总线USB的有线串行接口或遵从BLUETOOTH的无线接口中的一种,并且所述第二接口和所述第三接口使用相同的不使用IP地址的协议。
CN2008800193083A 2007-06-08 2008-05-08 复用式数据流协议 Active CN101682635B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201310163317.2A CN103297424B (zh) 2007-06-08 2008-05-08 数据处理方法和系统

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 Child Applications (1)

Application Number Title Priority Date Filing Date
CN201310163317.2A Division CN103297424B (zh) 2007-06-08 2008-05-08 数据处理方法和系统

Publications (2)

Publication Number Publication Date
CN101682635A CN101682635A (zh) 2010-03-24
CN101682635B true CN101682635B (zh) 2013-05-08

Family

ID=39811510

Family Applications (2)

Application Number Title Priority Date Filing Date
CN2008800193083A Active CN101682635B (zh) 2007-06-08 2008-05-08 复用式数据流协议
CN201310163317.2A Active CN103297424B (zh) 2007-06-08 2008-05-08 数据处理方法和系统

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201310163317.2A Active CN103297424B (zh) 2007-06-08 2008-05-08 数据处理方法和系统

Country Status (8)

Country Link
US (1) US20080304486A1 (zh)
EP (2) EP2156638B1 (zh)
KR (2) KR101283267B1 (zh)
CN (2) CN101682635B (zh)
AT (2) ATE505019T1 (zh)
DE (2) DE602008006071D1 (zh)
HK (2) HK1126592A1 (zh)
WO (1) WO2008153649A1 (zh)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8886902B1 (en) 2006-02-02 2014-11-11 Emc Corporation Disk backup set access
US8341127B1 (en) * 2006-02-02 2012-12-25 Emc Corporation Client initiated restore
US8666366B2 (en) 2007-06-22 2014-03-04 Apple Inc. Device activation and access
EP2145432A2 (en) * 2007-03-14 2010-01-20 Hewlett-Packard Development Company, L.P. Connecting collaboration nodes
GB2453771B (en) * 2007-07-31 2009-08-05 Hewlett Packard Development Co Synthetic bridging
US8649393B2 (en) * 2007-08-30 2014-02-11 Broadcom Corporation Method and system for setting alternative device classes within the MTP protocol
US10091345B2 (en) * 2007-09-04 2018-10-02 Apple Inc. Media out interface
US20090064038A1 (en) * 2007-09-04 2009-03-05 Apple Inc. Configuration of Device Settings
US9477395B2 (en) 2007-09-04 2016-10-25 Apple Inc. Audio file interface
US8413172B2 (en) * 2008-08-20 2013-04-02 Sharp Laboratories Of America, Inc. Method and system for socket API call emulation
US8307134B2 (en) * 2010-01-15 2012-11-06 Apple Inc. Multiple communication interfaces on a portable storage device
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

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1289497A (zh) * 1998-01-29 2001-03-28 英国电讯有限公司 传送移动数据的通信系统
EP1569491A2 (en) * 2004-02-24 2005-08-31 Lg Electronics Inc. Group network system using bluetooth and generating method thereof

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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
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
GB2453771B (en) * 2007-07-31 2009-08-05 Hewlett Packard Development Co Synthetic bridging

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1289497A (zh) * 1998-01-29 2001-03-28 英国电讯有限公司 传送移动数据的通信系统
EP1569491A2 (en) * 2004-02-24 2005-08-31 Lg Electronics Inc. Group network system using bluetooth and generating method thereof

Also Published As

Publication number Publication date
CN103297424A (zh) 2013-09-11
ATE505019T1 (de) 2011-04-15
EP2001199A1 (en) 2008-12-10
KR20120085342A (ko) 2012-07-31
EP2001199B1 (en) 2010-05-12
DE602008006071D1 (de) 2011-05-19
KR20100012896A (ko) 2010-02-08
EP2156638A1 (en) 2010-02-24
CN103297424B (zh) 2017-04-26
DE602008001203D1 (de) 2010-06-24
ATE467969T1 (de) 2010-05-15
KR101179855B1 (ko) 2012-09-04
EP2156638B1 (en) 2011-04-06
CN101682635A (zh) 2010-03-24
HK1141178A1 (en) 2010-10-29
WO2008153649A1 (en) 2008-12-18
US20080304486A1 (en) 2008-12-11
KR101283267B1 (ko) 2013-08-23
HK1126592A1 (en) 2009-09-04

Similar Documents

Publication Publication Date Title
CN101682635B (zh) 复用式数据流协议
CN101682634B (zh) 用于基于事务的通信的文件协议
CN102394872B (zh) 数据通信协议
US7778971B2 (en) Synchronization methods and systems
US8886600B2 (en) Synchronization methods and systems
US8375112B2 (en) Synchronization methods and systems
US7739410B2 (en) Synchronization methods and systems
EP2672398A1 (en) Synchronization methods and systems
EP2115627B1 (en) Synchronization methods and systems
US20080163743A1 (en) Synchronization methods and systems
US20140016633A1 (en) Techniques for communicating data between a host device and an intermittently attached mobile device

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant