Patent Application
20080307109
Embodiments of the invention relate to communicating data between devices. More particularly, embodiments of the invention relate to techniques for efficiently communicating data between one or more host electronic devices and an intermittently connected client device.
With the increasing popularity of mobile devices (e.g., mobile phones, digital music players, digital personal assistants), the functionality provided by a single mobile device has increased. This increase in functionality has an associated motivation to provide synchronization services in order to, for example, mirror changes to data made on either the mobile device or the host device. Further, there may be a need to exchange data, including one or more files, between the two devices. For example, music or video files may be exchanged between the two devices.
Various techniques have been developed to synchronize data and/or exchange data between a mobile device and a host device. Current techniques are typically either full-function file system based techniques that may require more overhead than necessary or may be specific-purpose techniques that provide limited functionality. These techniques use existing interfaces such as USB.
Existing interfaces between devices, such as a USB interface on each device, have difficulty allowing a device to be attached to a USB (Universal Serial Bus) interface or port and then arbitrarily and abruptly removed/disconnected from the USB interface, particularly if the device is a storage device. Further, USB is not designed to support, in USB's standard communication protocol, Internet Protocol (IP) addresses; USB is not considered a network interface. USB is also not designed to support an arbitrary, virtually unlimited, number of multiple concurrent independent sessions for independent applications seeking to send, or waiting to receive, data through a USB interface and, for at least certain systems, the number of interfaces or sessions supported over a USB interface is static and cannot be changed over time. A USB interface may, for at least certain systems, support multiple concurrent “interfaces,” which may be considered multiple sessions, but there is only a fixed number of these and the interfaces are static (and cannot change) for a device. On the other hand, USB is a common and useful interface, and it is often desirable to use such an interface to connect two systems such as a host and a client device.
This description relates to file protocols (e.g. file transfer protocols) for transaction based communication. In one embodiment, a method to use a file transfer protocol includes receiving packets containing headers, the packets being received at a first network stack software through a non-network interface, such as a USB interface, and extracting data from the packets and reconstructing a file from data in the packets. The extracting may be performed by a first network stack software, and the headers contain data for flow control and sequencing and data identifying ports for sending and receiving file transfer applications; the data in the headers allow multiple independent applications, including file transfer applications and others, to maintain multiple concurrent sessions through the interface, which may be a USB compliant (wired or wireless) or BLUETOOTH compliant interface. The method may further include validating the file after all data for the file has been received; the validating may be performed through the use of checksums and/or hash functions relative to the whole file. The packets containing portions of the file may include an indication of a packet type having a predetermined packet format and a packet functionality associated with the packet type.
The interface may be a USB wired or wireless interface (or a BLUETOOTH wireless interface) which has a standard protocol that does not use Internet Protocol (IP) addresses. The packets, transmitted through the non-network interface, may include Transmission Control Protocol (TCP) like headers and contain no IP compliant headers, and the TCP-like headers may specify port identifiers which are associated with opened sockets, which have been opened through the use of a socket API for interprocess communication between software modules. The method may also include creating further packets to contain the data extracted from the packets, and the further packets contain TCP/IP headers in which the IP header specifies a loopback address, and the data is extracted from the further packets and provided to the file transfer application. The creating of the further packets and the extracting of the data from the further packets may be performed by a TCP/IP stack software which is operatively coupled to a network interface from connecting to the Internet through an IP protocol.
Another embodiment includes a computer readable medium containing executable program instructions configured to be executed on a data processing system. The medium includes a first network stack software to create packets for transmission through a first interface (such as a WiFi or Ethernet or cellular telephone interface) on a device and to extract data from packets received through the first interface, and a second network stack software to create packets for transmission through a second interface (which may be a non-network interface such as a USB or BLUETOOTH interface) on the device and to extract data from packets received through the second interface, and a file transfer protocol software (such as a media player configured to transfer media files from one device to another device) operatively coupled to communicate with the first network stack software to receive the data extracted from the packets received through the second interface and to reconstruct a file from the data extracted from the packets. The second network stack software is configured to communicate with the first network stack software and the second interface is configured to be coupled to a third interface (e.g., another non-network interface such as a USB or BLUETOOTH interface) on another system (e.g., a host device). The second network stack software is configured to send data, extracted from packets received through the second interface, through the first network stack software and to the receiving file transfer protocol application. The second network stack software is configured to transmit and receive packets using a protocol designed for the second interface. The file transfer protocol software may validate the file after all the data for the file has been received (or it may validate the file in parts as it is received); the validation may be performed by using, for example, conventional checksum operations or hash operations. The packets may include information which is part of the file transfer protocol. For example, the packets may include an indication of a packet type having a predetermined packet format and a packet functionally associated with the packet type. The packet functionality may specify an operation of the file transfer protocol software. The packets created by the second network stack software may include Transmission Control Protocol (TCP)-like headers and no IP headers, and the TCP-like headers may be associated with (through port identifiers in the headers) an open socket for the file transfer protocol software. The first network stack software and the second network stack software are configured to allow multiple applications, including the file transfer protocol software, on the device to maintain multiple concurrent sessions through the second interface and wherein the file is an audio or audiovisual media file. The first network stack software may include a TCP/P stack and the second network stack software may include a TCP-like stack which creates the TCP-like headers. The file transfer protocol software (or other software) may generate an error message or a status message in response to a failure to transfer a complete file (e.g., the USB connection is interrupted in the middle of a file transfer) and this message is later used to cause the file (and other data or files) to be transferred, in whole or in part (if the prior part which was transmitted was also successfully saved at the recipient's side) when connection is re-established. The error message or status message includes at least an identifier of the file which was only partially transferred before the connection was interrupted.
This specification also describes devices, systems, computer readable media, software architectures, and other methods.
In another embodiment, the communications link between devices (e.g. between a host and a device) is a Universal Serial Bus (USB) compliant wired or wireless interface. In another embodiment, the communications link between devices is a BLUETOOTH compliant wireless interface. In another embodiment, the communications link is an interface which is not a network interface.
In one embodiment, the client device is a smartphone. In another embodiment, the client device is a media playback device. In one embodiment, the host device is a desktop computer system. In another embodiment, the host device is a laptop computer system. In another embodiments the host device is a palmtop or ultra-mobile computer system.
The invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.
In the following description, numerous specific details are set forth. However, embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.
Described herein is a protocol for transferring files and other data between endpoints. In one embodiment, the endpoints are a host electronic device and a client electronic device. The host electronic device may be, for example, a desktop computer system or a laptop computer system. The client electronic device may be for example, a laptop computer system, a personal digital assistant, a cellular-enabled device (e.g., a cellular telephone or smartphone).
In one embodiment, the connection between the end points utilizes a reliable stream transport, for example, a Transmission Control Protocol (TCP) stream connection. Other stream connections may also be supported. In one embodiment, communication is accomplished utilizing packets that have a header and a body. Described herein in one embodiment of a standard minimum header, but a header may contain additional packet-specific structured data. The packet data may include unstructured data, or may be empty.
Application 110 may be any type of application that may be executed by host device 100. For example, application 110 may be iTunes available from Apple Inc. of Cupertino, Calif. Application 110 may include functionality and/or data that may be communicated to and/or synchronized with client device 150, For example, application 110 may store and/or play multimedia content that may be stored on or played by client device 150. When client device 150 communicates with host device 100, application 110 may cause content to be transferred between host device 100 and client device 150. Other types of applications may also be supported.
Gatekeeper client 115 interacts with application 110 to control access to communications link 145 by application 110. Gatekeeper client 115 may selectively limit access to communications link. 145 based on one or more parameters. Gatekeeper client 115 may, for example, perform authentication and/or validation operations prior to allowing communications between host device 100 and client device 150. Gatekeeper client 115 may also select one of multiple communications link for communication between host device 100 and client device 150. While the example of
Gatekeeper client 115 may communicate with link driver 130 to access communications link 145 via link interface 140. In one embodiment, link driver 130 interacts with structured sync services 120 to provide synchronization functionality between host device 100 and client device 150. In one embodiment, structured sync services 120 may function utilizing the commands and protocols described in greater detail below. Link driver 130 may cause link interface 140 to cause signals (e.g., electrical, radio frequency, infrared, optical) representing data to be transmitted over communications link 145.
Within client device 150, link interface 160 is the counterpart to link interface 140. Link interface 160 may send and/or receive signals (e.g., electrical, radio frequency, infrared, optical) via communications link 145. Client device 150 also includes gatekeeper 180 that may perform authentication, validation and/or other authorization functions before allowing communication between application 110 on host device 100 and media sync services 190 on client device 150.
In one embodiment, media sync services 190 may support the messages and protocols described in greater detail below to allow access (e.g., read, write, modify, update) of data 195. Data 195 represents any type of data stored on client device 150. Data 195 may be one or more databases, tables and/or other storage elements. Data 195 may be, for example, media files (e.g., audio and/or video data files), metadata, contact information, historical information (e.g., call logs, software version information) and/or status information (e.g., battery capacity, serial number, total memory, available memory).
Client device 150 may also include structured data services 185, which may maintain data on client device 150. Examples of data that may be synchronized and/or maintained utilizing structured sync services 120 and structured data services 185 may include bookmarks, contact information, calendar information, etc. The structured sync services 120 may be the same as or similar to synchronization software 805 (in
In one embodiment, communication between host device 100 and client device 150 to allow application 110 to access data 190 may be accomplished trough structured sync services 120 and media sync services 190 utilizing specific data packet formats described in greater detail below. In one embodiment, communications link 145 may be a Universal Serial Bus (USB) compliant wired communications link between host device 100 and client device 150. In one embodiment, the connection between host device 100 and client device 150 utilizes a TCP stream connection over the USB compliant physical connection to transmit the packets described below.
Computer system 200 includes bus 205 which is coupled to one or more microprocessors which form processing system 210. Bus 205 is also coupled to memory 220 and to a non-volatile memory 230, which may be a magnetic hard drive in certain embodiments, or flash memory in other embodiments. Bus 205 is also coupled to display controller and display 240 and one or more input/output (I/O) devices 250.
Further, bus 205 may be coupled to optional dock 260 and to one or more wireless transceivers 270, which may be a Bluetooth® compliant transceiver or a WiFi compliant transceiver or an infrared transceiver. Wireless transceivers 270 are optional as shown in
Processing system 210 may optionally be coupled to cache 215. Processing system 210 may include one or more microprocessors, such as a microprocessor from Intel or IBM. Bus 205 interconnects these various components together in a manner which is known in the art. Typically, the input/output devices 250 are coupled to the system through input/output controllers.
Memory 220 may be implemented as dynamic RAM (DRAM) which provides fast access to data but requires power continually in order to refresh or maintain the data in memory 220. Non-volatile memory 230 may be a magnetic hard drive or other nonvolatile memory which retains data even after power is removed from the system. While
Bus 205, as is well known in the art, may include one or more buses connected to each other through various bridges, controllers, and/or adapters as is known in the an. In one embodiment, I/O controller 250 may include a USB compliant adapter for controlling USB compliant peripherals and an IEEE-1394 controller for IEEE-1394 compliant peripherals.
Aspects of the inventions described herein may be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor or processing system executing sequences of instructions contained in a memory, such as memory 220 or non-volatile memory 230 or the memory 330 shown in
Dock 260 and/or wireless transceivers 270 provide a physical interface for coupling the data processing system shown in
Display controller and display device 350 provide a visual user interface for the user; this digital interface may include a graphical user interface which is similar to that shown on a Macintosh computer when running OS X operating system software. System 300 also includes one or more wireless transceivers, such as a WiFi transceiver, an infrared transceiver, a Bluetooth® compliant transceiver, and/or a wireless cellular telephony transceiver. Additional components, not shown, may also be part of system 300 in certain embodiments, and in certain embodiments fewer components than shown in
Data processing system 300 also includes one or more input devices 360 which are provided to allow a user to provide input to system 300. These input devices may be a keypad or a keyboard or a touch panel or a multi-touch panel. Data processing system 300 also includes optional input/output device 370 which may be a connector for a dock, such as dock 260 shown in
One or more buses, not shown, may be used to interconnect the various components as is known in the art. Data processing system 300 may be a handheld computer or a personal digital assistant (PDA), or a cellular telephone with PDA-like functionality, or a handheld computer which includes a cellular telephone, or a media player, such as an iPod, or devices which combine aspects or functions of these devices, such as a media player combined with a PDA and a cellular telephone in one device. In other embodiments, data processing system 300 may be a network computer or an embedded processing device within another device, or other types of data processing systems which have fewer components or perhaps more components than that shown in
At least certain embodiments of the inventions described herein may be part of a digital media player, such as a portable music and/or video media player, which may include a media processing system to present the media, a storage device to store the media and may further include a radio frequency (RF) transceiver (e.g., an RF transceiver for a cellular telephone) coupled with an antenna system and the media processing system. In certain embodiments, media stored on a remote storage device may be transmitted to the media player through the RF transceiver. The media may be, for example, one or more of music or other audio, still pictures, or motion pictures.
The portable media player may include a media selection device, such as a click wheel input device on an iPod® or ipod Nano® media player from Apple Inc. of Cupertino, Calif., a touch screen input device, pushbutton device, movable pointing input device or other input device. The media selection device may be used to select the media stored on the storage device and/or the remote storage device.
The portable media player may, in at least certain embodiments, include a display device which is coupled to the media processing system to display titles or other indicators of media being selected through the input device and being presented, either through a speaker or earphone(s), or on the display device, or on both display device and a speaker or earphone(s). Examples of a portable media player are described in published U.S. patent application numbers 200310095096 and 2004/0224638, both of which are incorporated herein by reference.
In certain embodiments, data processing system 300 may be implemented in a small form factor which resembles a handheld computer having a tablet-like input device which may be a multi-touch input panel device which is integrated with a liquid crystal display. Examples of such devices are provided in U.S. patent application Ser. No. 11/586,862, filed Oct. 24, 2006, and entitled “AUTOMATED RESPONSE TO AND SENSING OF USER ACTIVITY IN PORTABLE DEVICES,” which is assigned to the same assignee as the instant application. This foregoing application is hereby incorporated herein by reference.
In the following description, various software components which are used for both synchronization and non-synchronization processing operations are described. It will be understood that in at least certain embodiments, these various software components may be stored in memory 220 and/or memory 230 shown in
Having described a host device and a client device with example embodiments of each along with appropriate interconnections between devices, example packet formats, packet types, functionality and data flows are now described. As with the description above, the description that follows provides an example embodiment of a communications protocol Variations on this protocol may also be supported.
The table in
In one embodiment, packet data may be sent over the connection in either little-endian or big-endian format. In one embodiment, either device may send data in either format. The receiving device is responsible for swapping the data ordering, if necessary. In one embodiment, each packet must use a consistent endianness. In one embodiment, a predetermined (e.g., fixed) signature value (e.g., 0x4141504e36414643) may be used for all packet headers. The signature may allow the receiving device to determine the endianness of the data transmitted from the transmitting device. In one embodiment, the signature field is 8 bytes in length; however, other signature field sizes may also be supported.
The packet header may also include a field that indicates the length of the entire packet including the header. In one embodiment, the packet length field may be 8 bytes; however, other packet length field sizes may be supported, for example, to support different maximum packet sizes. The packet header may also include a field that indicates a packet serial number. The packet serial number may be utilized to order packets transmitted between host device 100 and client device 150. In one embodiment, the packet serial number field may be 8 bytes; however, other packet serial number field sizes may be supported.
The packet header also includes a field for packet type. The packet type field includes a numerical indicator of the type of message in the packet, which indicates the function of the packet. One example listing of packet types and packet type values is provided in
The table in
Various embodiments of the packets listed in
The Status packet may be utilized to provide status information in response to a request packet. The status packet may also be utilized to provide error information in the event of a failure or other error condition. In one embodiment, the status packet is formatted according to the following table.
The Data packet may be utilized to carry data between the host electronic device and the client electronic device. In one embodiment, the data packet may be of any size. That is, the data packet may be the length of the header plus the data to be transmitted. In an alternate embodiment, the data packet may be a fixed length such that if the data to be transmitted exceeds the payload capacity of the data packet, one or more additional data packets may be utilized. In one embodiment, the data packet is formatted according to the following table.
The Read Directory packet may be utilized to read a directory on the target device. In one embodiment, the Read Directory packet is formatted according to the following table. The path string may be a path string in the appropriate format for the target device. For example, the path string may be a NULL-terminated Portable Operating System Interface for UNIX (POSIX) path string in UTF-8 format. Other formats may also be supported. The family of POSIX standards is formally designated as IEEE Std. 1003 and the international standard name is ISO/IEC 9945.
The Read File packet may be utilized to read a complete file on the target device. In one embodiment, the result is provided in a Status packet or a Data packet. In one embodiment, the Read File packet is formatted according to the following table.
The Write File packet may be utilized to write a complete file to the target device. In one embodiment, the Write File packet is formatted according to the following table.
The Write Part packet may be utilized to write data to a portion of a file on the target device. The Write Pan packet may be stateless in that when the data from the packet is written, state data associated with the data and/or the file is not maintained. In one embodiment, the Write Part packet is formatted according to the following table.
The Truncate (Trunc) File packet may be utilized to set the length of a file. The length may be shorter than the corresponding data in which case some of the data is dropped, or the length may be greater than the corresponding data in which case the excess may be filled with a predetermined data pattern (e.g., all “0”). In one embodiment, the Trunc File packet is formatted according to the following table.
The Remove Path packet may be utilized to delete a file or directory on the target device. In one embodiment, the Remove Path packet is formatted according to the following table.
The Make Directory packet may be utilized to create a directory on the target device. In one embodiment, the Remove Path packet is formatted according to the following table.
The Get File Info packet may be utilized to retrieve information describing a file on the target device. In one embodiment, the file information is provided as one or more key/value pairs transmitted in a Data packet. The information describing the file may be, for example, file size, last modification date, permissions. Additional and/or different file information may also be provided. In one embodiment, the Get File Info packet is formatted according to the following table.
The Get Device Info packet may be utilized to retrieve information describing the target device. In one embodiment, the device information is provided as one or more key/value pairs transmitted in a Data packet. The information describing the device may be, for example, device name, serial number, operating system version, battery level, free space available. Additional and/or different device information may also be provided. In one embodiment, the Get Device Info packet is formatted according to the following table.
The Write File Atomic packet may be utilized to write a file on the target device. The Write File Atomic packet guarantees that the whole file is written or that none of the file is written. The Write File Atomic packet may be used, for example, to write a database file. In one embodiment, the Write File Atomic packet is formatted according to the following table.
The File Reference (Ref) Open packet may be utilized to obtain a token or other identifier to represent an open file on the target device. In one embodiment, the Write File Atomic packet is formatted according to the following table.
In one embodiment, the Mode field includes a numeric indicator of a mode to use when opening the file. The Mode Name and Mode Value designations in Table 16 are examples for one embodiment. A different group of modes may be supported. Also, different mode values may be supported.
In Read Only mode, the file may be opened for reading only. In Read-Write mode, the file may be opened for reading and writing only. In Write-Truncate mode, the file may be opened for writing or truncation. In Read-Write-Truncate mode, the file may be opened for reading, writing or truncation. In Write-Append mode, the file may be opened for writing or appending In Read-Write-Append mode, the file may be opened for reading, writing or appending.
The File Ref Open Result packet may be utilized to return a file reference token that may be used in one or more of the packets described herein when accessing a file on the target device. In one embodiment, the File Ref Open Result packet is formatted according to the following table.
The File Ref Read packet may be utilized to read a file using the file reference resulting from the File Ref Open operation. In one embodiment, the position within the file is automatically advanced in response to a File Ref Read operation. In one embodiment, the File Ref Read packet is formatted according to the following table.
The File Ref Write packet may be utilized to write to a file using the file reference resulting form the File Ref Open operation. In one embodiment, the position within the file is automatically advanced in response to a File Ref Write operation. In one embodiment, the File Ref Write packet is formatted according to the following table.
The File Ref Seek packet may be utilized to determine a location within a file using the file reference resulting from the File Ref Open operation. In one embodiment, the File Ref Seek packet is formatted according to the following table.
In one embodiment, values in the Whence field may be used to indicate how the seek is to be performed. Table 21 provides an example of Whence values that may be used in a File Ref Seek packet.
The File Ref Tell packet may be utilized to determine a location within a file using the file reference resulting from the File Ref Open operation. In one embodiment, the File Ref Tell packet is formatted according to the following table.
The File Ref Tell Result packet may be utilized to return the result of a File Ref Tell operation. In one embodiment, the File Ref Tell Result packet is formatted according to the following table.
The File Ref Close packet may be utilized to close a file using the file reference resulting from the File Ref Open operation. In one embodiment, the File Ref Close packet is formatted according to the following table.
The File Ref Set Size packet may be utilized to set the size of a file corresponding to the reference resulting from the File Ref Open operation. In one embodiment, the File Ref Set Size packet is formatted according to the following table.
The File Ref Set Size packet may be utilized to set the length of a file. The length may be shorter than the corresponding data in which case some of the data is dropped, or the length may be greater than the corresponding data in which case the excess may be filled with a predetermined data pattern (e.g., all “0”).
The Remove Path packet may be utilized to rename a directory path on the target device. In one embodiment, the Rename Path packet is formatted according to the following table.
The path string may be a path string in the appropriate format for the target device. For example, the source and destination path strings may be a NULL-terminated POSIX path strings in UTF-8 format. Other formats may also be supported. In one embodiment, the destination path field immediately follows the source path field in the Rename Path packet.
The Set FS Block Size packet may be utilized to set a block size for the file system on the target device. In one embodiment, the Set FS Block Size packet is formatted according to the following table.
The block size may be utilized on by the client device file system. For example, with a block size of 64 kb, when writing file data to the client device, 64 kb of data would be written at a time even if the host device sends data in larger or smaller blocks. In one embodiment, the client device does not guarantee that data is written according to block size, but may be utilized for performance.
The Set Socket Block Size packet may be utilized to set a block size for the data connection between the target device and the host device. In one embodiment, the Set Socket Block Size packet is formatted according to the following table.
The block size may be utilized by the client system to read and write data via the connection between the host device and the client device. For example, with a block size of 64 kb, when reading data from the connection, the client device may attempt to read data as 64 kb blocks. In one embodiment, the client device does not guarantee that data is processed according to block size, but may be utilized for performance.
The File Ref Lock packet may be utilized to lock an open file reference identifier against use by a second application. In one embodiment, the File Ref Lock packet is formatted according to the following table.
The access to a file reference may be blocked so that only one application may have access to the opened file at a given time. In one embodiment, a shared lock, an exclusive lock and a non-blocking lock are supported. In alternate embodiments, additional and/or different locks are supported. In one embodiment, the lock is advisory only and an application must query the file to determine whether the file is locked or not. In one embodiment, multiple applications/processes may obtain a shared lock.
The messages and formats described above may be utilized to support a full file communication protocol. In the examples that follow a subset of the packets are used to illustrate uses of the protocol. Many other operations may also be supported.
The host device may detect the presence of the client device utilizing any suitable technique. For example, if the client device is connected with the host device via a wired connection, the host device may be configured to detect the physical connection of the client device to the wired interface. If the client device is connected with the host device via a wireless connection, the host device may be configured to respond to the completion of a pairing or other type of wireless connection procedure.
In one embodiment, if no client device is connected, 610, the host device may wait for a client device to be connected. In another embodiment, the host device may respond only if a request is received via the interface. For example, the wired interface may include a button to be pressed by a user to initiate communication between the client device and the host device. As another example, the client device may have a user interface that allows the user to request communications with the host device.
In response to connection of the client device, 610, the host device may gather information about the client device 620. Gathering of information about the client device may be accomplished by sending one or more of the packets discussed above. For example, the host device may send a Get Device Info packet and/or a Read Directory packet. The client device may respond to the packet(s) by providing the requested information to the host device.
Upon gathering sufficient information from the client device, the host device may determine whether the client device is a new device, 630. That is, the host device may determine whether the client device has ever been connected to the host device before. If the client device is a new device, the host device may perform a registration procedure, 635. The registration procedure can allow the host device to retain information about the client device that may be used, for example, for authentication, to expedite connections and/or for backup purposes.
The host device may authenticate the client device, 640. Authentication may be accomplished by, for example, exchange of keys or other identifiers between the host device and the client device. Other authentication techniques may also be used. In one embodiment, authentication is performed with corresponding sync services resident on the host device and the client device.
After authentication the host device may transfer data to the client device, 650, using the packets described herein. For example, to add a new file to the client device (e.g., load a new media file on the client device), the host device may use a Write File packet to cause the data to be written to a file on the client device. Any number of data transfer packets may be used in a single session.
In the example that follows, “→” indicates that the corresponding packet is transmitted from the host device to the client device and “←” indicates that the corresponding packet is transmitted from the client device to the host device. The packet type is listed first and one or more fields in the packet are listed with example values with “< . . . >” indicating that additional fields are not shown in the example of
In the example of
The host device may detect the presence of the client device utilizing any suitable technique. For example, if the client device is connected with the host device via a wired connection, the host device may be configured to detect the physical connection of the client device to the wired interface. If the client device is connected with the host device via a wireless connection, the host device may be configured to respond to the completion of a pairing or other type of wireless connection procedure.
In one embodiment, if no client device is connected, 710, the host device may wait for a client device to be connected. In another embodiment, the host device may respond only if a request is received via the interface. For example, the wired interface may include a button to be pressed by a user to initiate communication between the client device and the host device. As another example, the client device may have a user interface that allows the user to request communications with the host device.
In response to connection of the client device, 710, the host device may gather information about the client device 720. Gathering of information about the client device may be accomplished by transmitting the Get Device Info packet from the host device to the client device and transmitting the Data packet from the client device to the host device. As discussed above, any type of information about the client device may be acquired by the host device in this manner. In the example of
Optionally, upon gathering sufficient information from the client device, the host device may determine whether the client device is a new device, 730. If the client device is a new device, the host device may perform an optional registration procedure, 735. The host device may authenticate the client device, 740. Authentication may be accomplished by, for example, exchange of keys or other identifiers between the host device and the client device. Other authentication techniques may also be used. In one embodiment, authentication is performed with corresponding sync services resident on the host device and the client device.
After authentication, the host device may begin synchronization of data between the host device and the client device. The client device may request a File Ref value corresponding to a path on the client device and read data in the path, 750. This may be accomplished by using, for example, the File Ref Open, File Ref Open Result, File Ref Read, Data packets listed above. If the requested directory does not exist, the directory may be created, 750. When the requested data has been acquired, the File Ref may be closed. This may he accomplished by using the File Ref Close and Status packets listed above.
A Make Directory packet may be utilized to determine whether a target path exists. For example, using the packets listed above, a Make Directory packet with the target of ‘/media’ may be used to determine whether the ‘media’ directory exists. If the ‘media’ directory does exist, that Status packet from the client device may indicate the presence of the ‘media’ directory with a ‘PATH_EXISTS’ status.
File information may be requested for a first file to be updated (e.g., ‘/media/file1.mp3’). The Get File Info packet may be used to request information related to the first file to be updated, 770. The client device may use a Data packet to return data related to the first file to be updated.
The host device may then request a File Ref value to use while updating the first file. This may be accomplished using the File Ref Open packet with a response from the client device in a File Ref Open Result packet. The Host device may use the File Ref value to write data to the file on the client device, 775. This may be accomplished using the File Ref Write packet with confirmations from the client device carried by Status packets. When writing to the file is complete, the host device may use a File Ref Close packet to release the File Ref, which can be confirmed by a Status packet from the client device.
A Make Directory packet may be utilized to determine whether a target path for a second file to be updated exists. For example, using the packets listed above, a Get File Info packet with the target of ‘/media/file2.mp3' may be used to determine whether the ‘file2.mp3’ file exists and get information related to the file, 780. If, for example, the ‘file2.mp3’ file does not exist, the Status packet from the client device may return a ‘PATH_DOES_NOT_EXIST’ status.
The host device may then request a File Ref value to use while updating the second file. This may be accomplished using the File Ref Open packet with a response from the client device in a File Ref Open Result packet. The Host device may use the File Ref value to write data to the file on the client device, 785. This may be accomplished using the File Ref Write packet with confirmations from the client device carried by Status packets. When writing to die file is complete, the host device may use a File Ref Close packet to release the File Ref, which can be confirmed by a Status packet from the client device.
Any number of files may be updated in a similar manner. If the synchronization is not complete, 790, additional files may be updated as described above. If the synchronization is complete, 790, the synchronization session may be terminated.
Another aspect of this disclosure relates to multiplexed data stream protocols. The use of such a protocol allows for multiple applications (or the same application) on a device being able to maintain an arbitrary number of multiple concurrent sessions with one or more applications on the other device and the number of concurrent sessions can change over time as applications dynamically cause the creation of sessions or the closure of their sessions. Such a protocol may be implemented in a manner so that it is independent of the transport of the interfaces (e.g. USB interfaces or BLUETOOTH interfaces) used on both a device and another device (e.g., a host) and multiple independent connections can be maintained over the same, common link/interface (e.g., the USB interface). In one embodiment, a single USB session is established and an arbitrary and changeable number of multiple concurrent sessions are tunneled over that single USB session. In one embodiment, the particular interface, such as USB, should either support framing or some framing protocol should be added, such as COBS (constant overhead byte stuffing) or a PPP/SLIP style of framing. The multiple independent connections can be used concurrently for different purposes (e.g., files, such as media files, can be transferred while structured data, such as contacts in an Address Book, can be exchanged and/or synchronized between the devices while other data (e.g., emails or set-up information or software widgets) is also being exchanged between devices). The ability to support multiple independent connections is particularly useful for devices which have a multi-tasking operating system (OS), which allows multiple applications to run concurrently, although such an OS is not necessary.
The TCP-like protocol may also be used with a file transfer protocol, running on top of the TCP-like protocol, and the file transfer protocol may be used to provide file transfers between the two devices, and a file transferred in packets (e.g., the TCP-like packets) can be reconstructed on the receiving side and can be validated after all the data (received in multiple TCP-like packets) has been received (or it may be validating in part as portions of the file are received). The file may be validated using conventional checksum operations or hash operations. Many different types of software may be used with this TCP-like protocol, such as any protocol that works with a bi-directional stream of bytes may be layered on top of this TCP-like protocol. These different types of software may include telnet (e.g. for interactive telnet sessions), rsync, gdb over IP for remotely debugging applications on another device, etc. Further, the software running on top of this TCP-like protocol may implement a transaction-type protocol, including the use of atomic transactions. This TCP-like protocol allows the one or more layers of software running on top of this TCP-like protocol to provide their services and functionality without requiring that they be responsible for establishing and maintaining a connection with another software running on another system.
It will be understood that the terms “device” and “host” are used interchangeably; in other words, “device” applies to both a device and a host. A host is a device and a device may be considered a host. However, in certain embodiments, a session may only be initiated by a host, from the host to a device, and in that case the host is not interchangeable with the device. It will also he understood that the TCP-like protocol described herein is an example of a communications protocol which provides a reliable transport mechanism which supports flow control and multiplexing of independent connections and that other protocols, which provide a similar mechanism, may alternatively be used in a least certain embodiments of the invention. It will also be appreciated that hardware, such as TCP hardware accelerators, may be used to wholly or partially replace the software described herein in at least certain embodiments of the invention.
The host 803 includes several client applications 831, 833, 835 and 837 which may exchange data and/or files, through the interfaces 823 and 847, with client applications 805, 807, and 809 on device 801.
The operation of TCP/IP software stack 815, and TCP over interface software 821, and TCP over interface software 841 are described further below in conjunction with the description of
The device 801 includes data 813 which may be stored in any one of a plurality of storage media, including flash memory, hard drives, volatile semiconductor memory, etc. This data may include the structured data for address books, calendar, to do items, and notes, which data may be synchronized through the synchronization software 805 and the synchronization software 835 as described herein. Further, the data 813 may also include media files, such as MP3 files for music or MPEG 4 files for movies or other audio visual media. The data 813 may also include other types of data (e.g., word processing files, etc.) or even executable programs, such as widgets, data relating to set up information and email or phone account information, etc. It will be appreciated that the various client applications on the device side communicate with the storage device containing the data 813 in order to access the data. For example, the file transfer software 807 may read or write the data 813 in order to transfer files. It will be understood that the host device 803 also includes a data storage medium, such as a flash memory or a hard drive or a volatile memory device (e.g. DRAM), or other storage media for storing the data used by the client applications on the host device 803.
The following is a description of an implementation of the one or more embodiments shown in
While the protocol is not precisely classic TCP, it does use TCP like mechanisms for flow control, connection establishment/termination and multiplexing.
An interface according to this Device Communication Protocol is identified by finding an interface where:
All data is sent in the form of messages. Every message starts with the following header. All headers are in network byte order.
There are two defined message types:
The length field is used to verify the received USB datagram was the right size. The length includes the size of the message header. USB sends data in packets. For bulk USB Endpoints, the maximum packet size is determined by the speed. As long as you keep sending full sized packets, the data is all considered to be part of a frame. In order to end a frame, a packet smaller than the maximum packet size should be sent. If a frame would normally end exactly on the boundary of two full sized packets (frame size % max packet size is 0), a zero length packet may be sent to denote the end of a frame. The length field in the header should match the size of the frame received. If it does not match, the frame should be discarded. An error should be logged to track the failure. In most cases, the subsequent frame will also be screwed up and have to be dropped. These errors should not occur. The loss will be detected with TCP messages and that TCP connection will be dropped.
Version messages are exchanged at the start to negotiate the version of the protocol to be used. When a device appears, it should wait for a version message. The host is responsible for sending the first version message. A version message has the following format:
The host should set the Version to 1 for this implementation. The features should be zero since there are currently no supported features. In the future, features such as checksumming may be added without bumping the version. In addition, checksumming may be enabled using the feature field without defining a whole new version. The feature field is interpreted based on the version. Various bits in the Features field for version 1 may have a different meaning from Features in version 2. The host may request features by setting the corresponding bit in the Features field.
The device should respond with the version supported. The device may support only one version or it may support multiple versions. If the device supports the version requested by the host, the device should respond with that version. If the device only supports a different version, the device should respond with the version it supports. If the device responds with the requested version, the device should set the feature bitfield to the requested bits with any unsupported features masked out. If the response version does not match the requested version, the Features field should be zero.
If the device responds with a versions message that indicates a version that the host does not understand, the host may require newer software to communicate with the device. If the device responds with a different version from the requested version that the host does support, the host may send another version message with the newly negotiated version and bits set in the Features field to request specific features. The device should be prepared to handle multiple version messages.
For data communication over USB, TCP messages are used. TCP messages are the AppleUSBMobileDeviceHeader where the protocol value is 6 and the size is set to the size of the entire message including the header. The AppleUSBMobileDeviceHeader is followed by a TCP header. Variable header lengths and TCP options are not currently supported.
The payload, if any follows the TCP header.
The urgent pointer and checksum fields are currently unused and should be set to zero in this implementation. Since USB is supposed to be reliable, acknowledgments are implicit. A pure ACK packet is sent to update the window.
A connection is established by the host sending a TCP SYN packet to the device. The dst (destination) port is used to determine which service to connect to on the host. The src (source) port/dst port tuple should be unique to distinguish this connection from any other connections.
The device responds to the SYN packet with a SYN/ACK packet if the connection is accepted. The device may reject the connection request if there are insufficient resources or there is no service listening on the requested port. To reject the connection, the device should send a TCP RST.
A normal TCP connection involves a three way handshake. Since USB is supposed to be reliable, the third packet, the ACK from the Host to the Device may be dropped (not used) in this implementation. The device considers the connection established once it sends the SYN/ACK packet. The Host considers the connection established once it receives the SYN/ACK packet.
The sequence and acknowledgement numbers are incremented for SYN flags as they are in real (classic) TCP.
A window shift value of 8 is used though this option is not negotiated.
When the device or host wants to close a connection, it sends a TCP RST. In response to a TCP RST, a host or device should clean up any resources associated with the connection specified by the source and destination TCP ports.
The FIN flag is not used in this implementation. There is no half close in this implementation.
The sequence and acknowledgement numbers are used for flow control. When the host or device sends a TCP message with a payload, the sequence number increments by the size of the payload sent. The host and device are not allowed to send data beyond the last acknowledged data plus the last advertised window. This is how flow control is implemented. It is assumed that any data sent will be received. There is no support for retransmits in this implementation. Alternative embodiments may use retransmission if this feature is desired. The side sending data may discard the local copy of the data once it has been sent.
Data is assumed to arrive in order. If the host or device receives an out of order transmission, based on the sequence number, the host should close the connection and send a TCP RST.
When the host or device has more buffer space available, it may send a TCP ACK packet with an updated window to indicate that the other side may send more data.
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
This application claims the benefit of the filing date of provisional U.S. patent application Ser. No. 60/945,904, filed Jun. 22, 2007 and entitled “Multiplexed Data Stream Protocol.” This provisional application is hereby incorporated herein by reference. This application is also a continuation-in-part of U.S. patent application Ser. No. 11/760,686, filed Jun. 8, 2007, and entitled “Techniques for Communicating Data Between a Host Device and An Intermittently Attached Mobile Device.”
| Number | Date | Country | |
|---|---|---|---|
| 60945904 | Jun 2007 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11760686 | Jun 2007 | US |
| Child | 11770697 | US |
