Jump to content

OBject EXchange

From Wikipedia, the free encyclopedia
(Redirected fromOBEX)
This article is about the communications protocol. For the portion of the brain, seeObex.

OBEX(abbreviation ofOBject EXchange,also termedIrOBEX) is acommunication protocolthat facilitates the exchange of binary objects between devices. It is maintained by theInfrared Data Associationbut has also been adopted by theBluetooth Special Interest Groupand theSyncMLwing of theOpen Mobile Alliance(OMA). One of OBEX's earliest popular applications was in thePalm III.ThisPDAand its many successors use OBEX to exchange business cards, data, even applications.

Although OBEX was initially designed for infrared, it has now been adopted byBluetooth,and is also used overRS-232,USB,WAPand in devices such asLivescribesmartpens.

Comparison to HTTP[edit]

OBEX is similar in design and function toHTTPin providing the client with a reliable transport for connecting to a server and may then request or provide objects. But OBEX differs in many important respects:

  • HTTP is normally layered above aTCP/IPlink. OBEX can also be, but is commonly implemented on anIrLAP/IrLMP/Tiny TPstack on anIrDAdevice. InBluetooth,OBEX is implemented on aBaseband/ACL/L2CAP(and, for legacy uses,RFCOMM) stack. Other such "bindings" of OBEX are possible, such as overUSB.
  • HTTP uses human-readable text, but OBEX uses binary-formattedtype–length–valuetriplets named "Headers" to exchange information about a request or an object. These are much easier to parse by resource-limited devices.
  • HTTP transactions are inherently stateless; generally an HTTP client opens a connection, makes a single request, receives its response, and either closes the connection ormakes other unrelated requests.In OBEX, a single transport connection may bear many related operations. In fact, recent additions to the OBEX specification allow an abruptly closed transaction to be resumed with all state information intact.

Objects[edit]

OBEX works by exchangingobjects,which are used for a variety of purposes: establishing the parameters of a connection, sending and requesting data, changing the current path or the attributes of a file.

Objects arefieldsandheaders.As an example, the following may be the object used for requesting the phonebook from a mobile:

Object Fields Command GET, Final 0x83
Length total length of object 0x00 0x29
Headers Connection ID 1 0xCB0x00 0x00 0x00 0x01
Name "telecom/pb.vcf" 0x010x00 0x1e0x00 0x74 0x00 0x65 0x00 0x6c 0x00 0x65 0x00 0x63 0x00 0x6f 0x00 0x6d 0x00 0x2f 0x00 0x70 0x00 0x62 0x00 0x2e 0x00 0x76 0x00 0x63 0x00 0x66 0x00 0x00

This object contains two fields (command and length) and two headers. The first field (command) specifies that it is a request for data (GET). The second field is the total size of the object, including the two fields.

This object also contains two headers, specifically a "Connection ID" and a "Name". The first byte of each header is the header's name and its content type. In this case:

  • 0xCB means that this header is a "Connection ID", a number obtained previously; the two highest-order bits of 0xCB are 11, and this pair specifies that this as a 4-byte quantity;
  • the first byte of the second header is 0x01; this byte identifies this header as a "Name" one; the first two bits of 0x01 are 00, meaning that the content of this header is a null-terminated unicode string (inUCS-2form), prefixed by the number of bytes it is made of (0x00 0x1e).

A possible response, containing the requested data, could be:

Response Fields Response code OK, Final 0xA0
Length total length of object 0x00 0x35
Headers End-of-Body "BEGIN:VCARD..." 0x490x00 0x2F0x42 0x45 0x47 0x49 0x4e 0x3a 0x56 0x43 0x41 0x52 0x44

In this example, the phonebook is assumed short enough to be contained in a single response object. The only header has 0x49 as its identifier, meaning that it is an "End of Body", the last chunk of information (also the only one, in this case). The first two bits of 0x49 are 01, meaning that the content of this header is length-prefixed data: the two next bytes 0x00 0x2F tells the length of this data (in decimal, 47), the succeeding ones are the data, in this case a phonebook comprising only an emptyvCardof 47 bytes.

This example shows a single GET command and its response, the only headers involved being connection id, name and end-of-body. Before issuing it, a CONNECT command should have been sent for establishing some parameters of the connection, including the connection id. Other commands are: put, setpath, action, abort, disconnect. Some other notable headers include: type, time, description, target.

Session[edit]

After the client (e.g., computer) connects to the server (e.g., mobile), a typical session consists in the client sending a number of objects and getting their responses from the server. As an example:

  • CONNECT: one of the fields specifies the largest size of packets the client can receive; a TARGET header specifies the kind of service the client is expecting (file-browsing, sync-ml, phonebook access); the server answer with its maximal packet length, the connection id, and other data
  • GET: the client requests a file, specifying the connection id, the file name and/or its type; the server answer with the file content, or just a part of it; in the latter case, the client has to send other GET objects to obtain the rest of the file
  • SETPATH: the client tells the server to switch to a different file folder, specifying the connection id and the folder name in two headers
  • GET: the client requests a listing of the folder content by sending an object with the connection id and an appropriate TYPE header (e.g., "x-obex/folder-listing" for file transfer, "x-bt/vcard-listing" for phonebook access)
  • PUT: the client sends a file to the server; if it is too large to fit into a single packet, the server will request the next part with a CONTINUE response
  • DISCONNECT: the client informs the server that it is closing the session

The exchange may differ significantly depending on the service. For example,SyncMLdoes not use SETPATH, while anOBEX pushis made of just CONNECT (without a TARGET header), PUT and an optional DISCONNECT.

Protocols[edit]

The following protocols runs over OBEX, or have bindings to do so:

OBEX Push
Transfers a file from the originator of the request to the recipient; a CONNECTION object containing no target is sent, then PUT is used to transfer the file
OBEX File Transfer Protocol
Stores and retrieves files, similar toFTP.The target header of the CONNECTION object is {0xF9, 0xEC, 0x7B, 0xC4, 0x95, 0x3C, 0x11, 0xD2, 0x98, 0x4E, 0x52, 0x54, 0x00, 0xDC, 0x9E, 0x09}; the response contains the connection id to use in subsequent GET, PUT, SETPATH and ACTION object.
Phonebook Access
Similar to file transfer, but uses a target {0x79, 0x61, 0x35, 0xF0, 0xF0, 0xC5, 0x11, 0xD8, 0x09, 0x66, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66}; phonebook entries can be listed (with various possible orderings and filters) and retrieved from certain directories under telecom/ using GET and SETPATH
IrMC
IrMCwas designed for the exchange of phonebook entries, calendar entries, digital business cards, andto-do lists.In its connectionless form, a single PUT is used to transfer data; otherwise, various files and folders within telecom/ can be retrieved or pushed; a target header {'I', 'R', 'M', 'C', '-', 'S', 'Y', 'N', 'C'} may be used in GET requests to differentiate the kind of indexing used
SyncML
SyncMLcan synchronize phonebooks, calendars, notes, and other data. In its OBEX binding, the target of the CONNECT object is {'S', 'Y', 'N', 'C', 'M', 'L', '-', 'S', 'Y', 'N', 'C'}; a session then consists in a sequence of PUT-GET pairs where namelessXMLorWBXMLfiles are sent and received, in turn.

Implementations[edit]

javax.obex[edit]

Optional package javax.obex inJava APIs for Bluetoothprovides an implementation of OBEX inJava.[1]

OpenObex[edit]

OpenObex is an open-source implementation of OBEX inC.It provides functions for connecting overIrDA,Bluetooth,USBandTCP/IP,building objects and handling received data. An example schema of a client application is: 

voidcallback_function(...){
/* process received data */
}

intmain(){
OBEX_Init(...,callback_function);
OBEX_TransportConnect(...);

object=OBEX_ObjectNew(...);
OBEX_ObjectAddHeader(object,...);
OBEX_ObjectAddHeader(object,...);
OBEX_Request(...,object);
while(...)
OBEX_HandleInput(...)

object=OBEX_ObjectNew(...);
OBEX_ObjectAddHeader(object,...);
OBEX_Request(...,object);
while(...)
OBEX_HandleInput(...)

/*... */

OBEX_TransportDisconnect(handle);
OBEX_Cleanup(handle);
}

Objects are sent byOBEX_Request.After callingOBEX_HandleInput,received data is processed in the callback function (which was specified when callingOBEX_Init). The callback function can determine whether the response has been completely received, and therefore whether the main program can exit from thewhileloop it is executing.

PyOBEX and nOBEX[edit]

PyOBEX provides partial support for OBEX inPython.[2]nOBEX is a fork of PyOBEX with more complete OBEX support, and support for the BluetoothHands Free Profileto facilitate OBEX testing on automotive infotainment systems.[3]

Profiles[edit]

OBEX is the foundation for many higher-layer "profiles":

Profiles
Classification Profile
IrDA Point and Shoot profile
Infrared Financial Messaging (IrFM)profile
Bluetooth SIG Generic Object Exchange Profile
Object Push Profile(phone to phone transfers)
File Transfer Profile(phone to PC transfers)
Synchronization Profile
Basic Imaging Profile
Basic Printing Profile
OMA SyncMLbinding

Supported devices[edit]

See also[edit]

References[edit]

  1. ^javax.obex API
  2. ^PyOBEX
  3. ^nOBEX

External links[edit]

Retrieved from "https://en.wikipedia.org/w/index.php?title=OBject_EXchange&oldid=1220048679"