Obex is all called object Exchange, the Chinese object exchange, so it is called a barter protocol. It has a core position in this software, and file transfer and IRMC synchronization will use it.
The OBEX protocol is built on top of the IrDA architecture.
The OBEX protocol enables easy and efficient exchange of information between different devices and different platforms by simply using the "put" and "get" commands. supports a wide range of devices, such as PC,PDA, telephones, cameras, automatic answering machines, calculators, data collectors, watches, and more.
The OBEX protocol defines a flexible concept of--objects. is also the object. These objects can include files, diagnostic information, E-commerce cards, bank deposits, and so on. Objects has no advanced technical implications here, it depends on your application.
The OBEX protocol is small to be used for "command and control" functions, such as the operation of televisions, VCRs, etc. The avenue can do complex operations, such as transaction processing and synchronization of databases.
Obex can have the following characteristics:
1, the friendly application--can realize the rapid development.
2. Austerity-available on small devices with limited resources.
3. Cross platform
4, flexible data support.
5, convenient as the other Internet Transport protocol upper layer protocol.
6, scalability-Provides extended support for future requirements without impacting the existence of implementations. For example, scalable security, data compression, and so on.
7, can test can be debugged.
For more specific information on Obex, please refer to the Irobex agreement.
Second, Obex object model
About headers
The object model answers how objects are described in the OBEX protocol. This model must include the transmitted object and the description of the object. To do this, OBEX defines the concept of headers.
A header reflects an aspect of an object, such as the name, length, description text, or object itself. For example, a file object Demo.txt will contain its name, a type labeled "Text", and the length and the file itself.
Composition of the headers
Headers is simply made up of
Hi is made up of a byte that indicates what the header contains and how it is formatted. HV contains one or more bytes, and its structure is determined by hi.
All headers are optional, depending on the type of device and the kind of transaction. You can use all headers, or some, or none. IDs can cause headers to be resolvable and to be independent of the transport order, or they can cause unsupported headers to be ignored.
Hi can also be divided into two parts, high 2-bit and low 6-bit. The high 2-bit determines how HI is encoded (see table II), and the low 6 bits determine the meaning of hi (see table III). All two tables are excerpts from the Irobex and part of the translation.
Table II
Hi the 8th and 7th places
Significance
(0x00)
A Unicode literal that ends with null (0x00). A 2-byte unsigned integer length prefix.
For more detailed explanations of commonly used headers, please refer to Irobex for more information
1, Name
Name is a header that describes the name of an object, consisting of a Unicode string ending with null (0x00). For example: DEMO.TXT
2, Length
Length describes the size of the object, consisting of 4 bytes. If length is known beforehand, this header should be used. This allows the recipient to quickly know how much space needs to be allocated to make the process more rapid. But this is also not necessary, in some cases the length can not be confirmed, but the device can through the End-body header know when the end.
3, Time
Time describes when the object was last modified. Use the ISO8601 format.
local time format: YYYYMMDDTHHMMSS
UTC time Format: yyyymmddthhmmssz
The T in the format can easily distinguish between date and time. UTC time uses z as a mark. It is recommended to use UTC time.
4, Body, end-of-body
The body header is described by Hi, a 2Byte-length description, and the entire object itself. The composition of the end-of-body is the same as the body, but it identifies the last part of the object. If the object is already small, use end-of-body directly.
Iii. requests (Request) and Responses (Response)
Obex use request and response as the most basic operation. Each request requested must have a response, or you can assume that it failed.
The request consists of one or more packet (packages), each of which is structured in the following table
Request Packet Structure
Byte 0
Byte 1,2
Byte 3 to N
Operation code (OpCode)
Packet Length (packet lengths)
Headers or request information
Because each request may have multiple packet,opcode, the highest bit is called the final bit. If it is set to 1, then this is the last packet of the request. For example, when you send a large file with a put operation, there are several packet as a request. Then only the last packet Finalbit is set to 1.
Response is also composed of one or more packet, each of which is structured as follows table
Response Packet Structure
Byte 0
Byte 1,2
Byte 3 to N
Response Code (return value)
Response Length (response lengths)
ResponseData Response to Data
The same responsecode's highest position is also called Finalbit. ResponseData may contain objects and headers, or other information.
The following table lists the common opcode and responsecode, please refer to the Irobex 1.2 documentation for more details.
OpCode
Opcode (W/high bit set)
Defined
Significance
0x80 *
Connect
Connection
0X81 *
Disconnect
Disconnect
0x02 (0x82)
Put
Send an Object
0X03 (0x83)
Get
Get an Object
0x04 (0x84)
Reserved
Retained by
0X85 *
SetPath
Set path
0xFF *
Abort
Cancel the current operation
0x06 to 0x0f
Reserved
As extended retention
0x10 to 0x1f
User definable
User-defined
* Always set Finalbit
Responsecode
Responsecode
Defined
0x10 (0x90)
Continue (continued)
0x20 (0xa0)
Ok,success
0x40 (0XC0)
Bad Request (service side does not understand request)
0x41 (0xC1)
Unauthorized (Unauthorized)
0x43 (0XC3)
Fobidden (Forbidden--Server understands request, but refuses)
0x44 (0XC4)
Not Found (not found)
Iv. description.
1, connect (connection)
This action initializes the session and then sets the parameters. The request format is
Byte 0
Byte 1,2
Byte 3
Byte 4
Byte 5,6
Byte 7 to N
0x80
Package length
OBEX version
Sign
Maximum Obex package length
Optional header
Note: The OBEX version is now 1.0.
The response format is:
Byte 0
Byte 1,2
Byte 3
Byte 4
Byte 5,6
Byte 7 to N
Responsecode
Package length
OBEX version
Sign
Maximum Obex package length
Optional header
For more information on Connect please refer to Irobex
2. Disconnect (disconnect current session)
This operation disconnects the OBEX session. For example, disconnect the current folderlisting service, and then connect to the IRMC Sync Service using connect to achieve the functions of synchronous communication thin.
The Disconnect format is:
Byte 0
Bytes 1,2
Bytes 3 to N
0x81
Package length
Optional header
A successful fracture will return 0xa0, and the rejection will return 0XD3
3. Put operation
The put operation sends an object to the server from the client. Typically contains at least name and length two headers. There may also be a date/time Header for the file.
The format of the put operation is as follows:
Byte 0
Bytes 1,2
Bytes 3 to N
0x02 (when Finalbit is set to 0x82)
Packetlength Packet Length
A group header
The response format is as follows:
Byte 0
Bytes 1,2
Bytes 3 to N
Responsecode (required to continue for 0x90; success for 0xa0)
Package length
Optional header
More detailed usage of the put operation will be explained in the File Transfer section.
4, get operation
The get operation returns an object from the service side.
The format of the get operation is as follows:
Byte 0
Bytes 1,2
Bytes 3 to N
0x03
Package length
A group header
The response format is as follows:
Byte 0
Bytes 1,2
Bytes 3 to N
Response Code
Package length
Optional header
More detailed usage of the get operation will be explained in the File Transfer section.
5, abort operation
The abort operation interrupts a multiple-package operation (for example, sending a large file). The abort operation can contain description headers that describe the cause of the interruption.
The format of the abort operation is as follows:
Byte 0
Bytes 1,2
Bytes 3 to N
0xFF
Package length
Optional header
The abort corresponds to a successful operation (0XA0) indicating that the operation has been received and that the server has been synchronized with the client. If another value is returned, the client should disconnect.
6, SetPath
The SetPath action is used to toggle the other's path. You typically use a name header to specify the offset path name. If empty, returns the default directory, usually the root directory
Note: Flags can be set Bit0 and Bit1. Bit0 represents a return to the previous level directory; Bit1 indicates that a directory is created if the directory does not exist, otherwise an error is returned.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
