The OBEX protocol is a client-server protocol. The protocol defines the notion of the client, which sends a request, and the server, which replies with a response. The client and server exchange the requests and responses during a connection session.
The OBEX protocol follows a client-server request-response paradigm for the conversation format. The request-response pair is referred to as an operation. The OBEX protocol defines two operations for controlling the connection, CONNECT and DISCONNECT. After the connection session is established, the client can perform various operations on the server. Two basic operations are the GET operation for downloading an object from the server and the PUT operation for uploading objects. During the connection session, these operations can be performed as many times as needed in any order.
The maximum size of the object that can be transmitted in the single PUT or GET operation is 65535 bytes. Maximum object size for the session is negotiated during the connection procedure. Both peers exchange their maximum allowed sizes and the smaller value is selected. When PUT and GET operations are requested to transmit large objects, the protocol handles transmission of the object in several packages. It helps to maintain good synchronization when requests and responses are broken into multiple OBEX packets that are limited to a size specified at connection time. Each request packet is acknowledged by the server with a response packet. The whole procedure is transparent to an application, so PUT or GET appears as one lengthy operation (for example, by using JSR-82 API an application developer can transmit large objects without bothering to split the objects into packages).
In order to cancel such lengthy operations, an ABORT command is defined. The ABORT operation may come in the middle of a request-response sequence. If the ABORT command is invoked while running an operation, the data transmission is canceled.
Request and response general formats are shown in the tables below.
|
Byte 0 |
Bytes 1, 2 |
Bytes 3 to n |
|---|---|---|
|
opcode |
packet length |
headers or request data |
|
Byte 0 |
Bytes 1, 2 |
Bytes 3 to n |
|---|---|---|
|
response code |
response length |
response data |
Note: Each peer may implement both the client and the server, and thereby create a peer-to-peer relationship between applications by using a pair of OBEX sessions, one in each direction.
The aforementioned operations are the basic ones, but not the only ones defined in the OBEX protocol. The full list is given in the table below.
|
Opcode (w/high bit set) |
Definition |
Meaning |
|---|---|---|
|
0x80 (high bit always set) |
Connect |
Choose your partner, negotiate capabilities |
|
0x81 (high bit always set) |
Disconnect |
Signal the end of the session |
|
0x02 (0x82) |
Put |
Send an object |
|
0x03 (0x83) |
Get |
Get an object |
|
0x04 (0x84) |
Reserved |
|
|
0x85 (high bit always set) |
SetPath |
Modifies the current path on the receiving side |
|
0xFF (high bit always set) |
Abort |
Abort the current operation |
|
0x06 to 0x0F |
Reserved |
Not to be used without extension to IrDA OBEX specification |
|
0x10 to 0x1F |
User definable |
Use as you wish with peer application |
|
Bits 5 and 6 are reserved and should be set to zero. Bit 7 of the opcode means Final packet of request. |
For more detailed definitions of each operation, see the IrDA OBEX specification.
IrDA OBEX Exchange Protocol (see IrDA OBEX specification) defines the application framework concept, which is built on top of the OBEX protocol. It ensures interoperability between devices, for example, sending messages to the Inbox of a device.