OBEX (Abkürzung für OBject EXchange , auch IrOBEX genannt ) ist ein Kommunikationsprotokoll , das den Austausch binärer Objekte zwischen Geräten ermöglicht. Es wird von der Infrared Data Association gepflegt und wird auch von der Bluetooth Special Interest Group sowie dem SyncML- Zweig der Open Mobile Alliance (OMA) verwendet . Eine der ersten weit verbreiteten Anwendungen von OBEX war der Palm III . Dieser PDA und seine zahlreichen Nachfolger nutzen OBEX zum Austausch von Visitenkarten, Daten und sogar Anwendungen.

Obwohl OBEX ursprünglich für Infrarot konzipiert wurde, wird es mittlerweile auch über Bluetooth genutzt und kommt auch über RS-232 , USB , WAP und in Geräten wie Livescribe Smartpens zum Einsatz.

Vergleich mit HTTP

OBEX ist in Aufbau und Funktion ähnlich wie HTTP , da es dem Client einen zuverlässigen Transport für die Verbindung zu einem Server bietet, über den er Objekte anfordern oder bereitstellen kann. OBEX unterscheidet sich jedoch in vielen wichtigen Punkten:

  • HTTP ist üblicherweise über einer TCP/IP -Verbindung angesiedelt. OBEX kann ebenfalls darüber liegen, wird aber üblicherweise auf einem IrLAP / IrLMP / TinyTP- Stack auf einem IrDA -Gerät implementiert. Bei Bluetooth ist OBEX auf einem Baseband / ACL / L2CAP -Stack (und für ältere Anwendungen auf einem RFCOMM- Stack) implementiert . Weitere Anbindungen von OBEX sind möglich, beispielsweise über USB .
  • HTTP verwendet für Menschen lesbaren Text, OBEX hingegen nutzt binär formatierte Typ-Längen-Wert- Tripletts, sogenannte „Header“, um Informationen über eine Anfrage oder ein Objekt auszutauschen. Diese lassen sich von ressourcenbeschränkten Geräten wesentlich einfacher verarbeiten.
  • HTTP-Transaktionen sind von Natur aus zustandslos; üblicherweise öffnet ein HTTP-Client eine Verbindung, sendet eine einzelne Anfrage, empfängt die Antwort und schließt entweder die Verbindung oder sendet weitere, unabhängige Anfragen . In OBEX kann eine einzelne Transportverbindung mehrere zusammenhängende Operationen umfassen. Tatsächlich ermöglichen neuere Erweiterungen der OBEX-Spezifikation die Fortsetzung einer abrupt beendeten Transaktion, wobei alle Zustandsinformationen erhalten bleiben.

Objekte

OBEX funktioniert durch den Austausch von Objekten , die für verschiedene Zwecke verwendet werden: zum Festlegen der Parameter einer Verbindung, zum Senden und Anfordern von Daten, zum Ändern des aktuellen Pfads oder der Attribute einer Datei.

Objekte bestehen aus Feldern und Spaltenüberschriften . Beispielsweise könnte folgendes Objekt verwendet werden, um das Telefonbuch von einem Mobiltelefon abzurufen:

Objekt Felder BefehlGETFinale 0x83
LängeGesamtlänge des Objekts 0x00 0x29
Überschriften Verbindungs-ID10xCB 0x00 0x00 0x00 0x01
Name"telecom/pb.vcf"0x01 0x00 0x1e 0x00 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

Dieses Objekt enthält zwei Felder (Befehl und Länge) und zwei Header. Das erste Feld (Befehl) gibt an, dass es sich um eine Datenanforderung handelt GET. Das zweite Feld gibt die Gesamtgröße des Objekts einschließlich der beiden Felder an.

Dieses Objekt enthält außerdem zwei Header, genauer gesagt eine „Verbindungs-ID“ und einen „Namen“. Das erste Byte jedes Headers enthält den Namen des Headers und seinen Inhaltstyp. In diesem Fall:

  • 0xCBbedeutet, dass dieser Header eine "Verbindungs-ID" ist, eine zuvor ermittelte Nummer; die beiden höchstwertigen Bits von 0xCBsind 11, und dieses Paar gibt an, dass es sich um eine 4-Byte-Größe handelt;
  • Das erste Byte des zweiten Headers ist 0x01; dieses Byte identifiziert diesen Header als einen "Name"-Header; die ersten beiden Bits von 0x01sind 00, was bedeutet, dass der Inhalt dieses Headers eine nullterminierte Unicode- Zeichenkette (im UCS-2- Format) ist, der die Anzahl der Bytes vorangestellt ist, aus denen sie besteht ( 0x00 0x1e).

Eine mögliche Antwort, die die angeforderten Daten enthält, könnte lauten:

Antwort Felder Antwortcode OKFinale 0xA0
Länge Gesamtlänge des Objekts 0x00 0x35
Überschriften Ende des Körpers "BEGIN:VCARD..."0x49 0x00 0x2F 0x42 0x45 0x47 0x49 0x4e 0x3a 0x56 0x43 0x41 0x52 0x44

In diesem Beispiel wird davon ausgegangen, dass das Telefonbuch kurz genug ist, um in einem einzelnen Antwortobjekt enthalten zu sein. Der einzige Header hat 0x49als Kennung „Ende des Antworttextes“, was bedeutet, dass es sich um den letzten Informationsblock (in diesem Fall auch den einzigen) handelt. Die ersten beiden Bits von „ Ende des Antworttextes“ 0x49sind 01„Ende des Antworttextes“, was bedeutet, dass der Inhalt dieses Headers längenpräfixierte Daten enthält: Die beiden folgenden Bytes 0x00 0x2Fgeben die Länge dieser Daten an (dezimal 47), die darauffolgenden Bytes enthalten die Daten selbst, in diesem Fall ein Telefonbuch, das lediglich aus einer leeren vCard von 47 Bytes besteht.

Dieses Beispiel zeigt einen einzelnen GETBefehl und seine Antwort. Die einzigen relevanten Header sind Verbindungs-ID, Name und End-of-Body. Vor der Ausführung dieses Befehls CONNECTmuss ein Befehl gesendet worden sein, um einige Verbindungsparameter, einschließlich der Verbindungs-ID, festzulegen. Weitere Befehle sind beispielsweise PUT` <Befehl1>`, SETPATH` ACTION<Befehl2>`, ABORT`<Befehl3>` und ` DISCONNECT<Befehl4>`. Zu den weiteren wichtigen Headern gehören Typ , Zeit , Beschreibung und Ziel .

Sitzung

Nachdem sich der Client (z. B. ein Computer) mit dem Server (z. B. einem Mobilgerät) verbunden hat, besteht eine typische Sitzung darin, dass der Client eine Reihe von Objekten sendet und deren Antworten vom Server empfängt. Zum Beispiel:

  • CONNECTEines der Felder gibt die maximale Paketgröße an, die der Client empfangen kann; ein TARGETHeader spezifiziert die Art des vom Client erwarteten Dienstes (Dateibrowsing, Synchronisierung , Telefonbuchzugriff); die Serverantwort enthält die maximale Paketlänge, die Verbindungs-ID und weitere Daten.
  • GETDer Client fordert eine Datei an und gibt dabei die Verbindungs-ID, den Dateinamen und/oder den Dateityp an. Der Server antwortet mit dem Dateiinhalt oder nur einem Teil davon. Im letzteren Fall muss der Client weitere GETObjekte senden, um den Rest der Datei zu erhalten.
  • SETPATHDer Client teilt dem Server mit, dass er zu einem anderen Dateiordner wechseln soll, indem er die Verbindungs-ID und den Ordnernamen in zwei Headern angibt.
  • GETDer Client fordert eine Auflistung des Ordnerinhalts an, indem er ein Objekt mit der Verbindungs-ID und einem entsprechenden TYPEHeader sendet (z. B. x-obex/folder-listingfür Dateiübertragung, x-bt/vcard-listingfür den Zugriff auf das Telefonbuch).
  • PUTDer Client sendet eine Datei an den Server; falls diese zu groß für ein einzelnes Paket ist, fordert der Server mit einer CONTINUE-Antwort den nächsten Teil an.
  • DISCONNECTDer Client teilt dem Server mit, dass er die Sitzung beendet.

Der Austausch kann je nach Dienst erheblich variieren. SyncML verwendet beispielsweise kein SETPATH, während ein OBEX-Push lediglich aus CONNECT(ohne TARGET-Header) PUTund einem optionalen besteht DISCONNECT.

Protokolle

Die folgenden Protokolle laufen über OBEX oder verfügen über entsprechende Bindungen:

OBEX Push
Überträgt eine Datei vom Absender der Anfrage an den Empfänger; es wird ein CONNECTION-Objekt ohne Ziel gesendet, anschließend wird PUT verwendet, um die Datei zu übertragen.
OBEX-Dateiübertragungsprotokoll
Speichert und ruft Dateien ab, ähnlich wie FTP . Der Zielheader des CONNECTION-Objekts ist {0xF9, 0xEC, 0x7B, 0xC4, 0x95, 0x3C, 0x11, 0xD2, 0x98, 0x4E, 0x52, 0x54, 0x00, 0xDC, 0x9E, 0x09}; die Antwort enthält die Verbindungs-ID, die in nachfolgenden GET, PUT, SETPATHund ACTIONObjekten verwendet wird.
Zugriff auf das Telefonbuch
Ähnlich wie bei der Dateiübertragung, jedoch mit einem Zielverzeichnis {0x79, 0x61, 0x35, 0xF0, 0xF0, 0xC5, 0x11, 0xD8, 0x09, 0x66, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66}; Telefonbucheinträge können (mit verschiedenen Sortier- und Filteroptionen) aufgelistet und aus bestimmten Verzeichnissen unter telecom/Verwendung GETvon „und“ abgerufen werden.SETPATH
IrMC
IrMC wurde für den Austausch von Telefonbucheinträgen, Kalendereinträgen, digitalen Visitenkarten und Aufgabenlisten entwickelt . In der verbindungslosen Variante PUTwird eine einzige Schnittstelle zur Datenübertragung verwendet; andernfalls können verschiedene Dateien und Ordner innerhalb des Verzeichnisses telecom/ abgerufen oder übertragen werden. Ein Zielheader {'I', 'R', 'M', 'C', '-', 'S', 'Y', 'N', 'C'}kann in Anfragen verwendet werden GET, um die Art der verwendeten Indizierung zu unterscheiden.
SyncML
SyncML kann Telefonbücher, Kalender, Notizen und andere Daten synchronisieren. In seiner OBEX-Bindung ist das Ziel des CONNECTObjekts {'S', 'Y', 'N', 'C', 'M', 'L', '-', 'S', 'Y', 'N', 'C'}; eine Sitzung besteht dann aus einer Sequenz von PUT-Paaren GET, in denen namenlose XML- oder WBXML- Dateien nacheinander gesendet und empfangen werden.

Implementierungen

javax.obex

Das optionale Paket javax.obex in den Java-APIs für Bluetooth stellt eine Implementierung von OBEX in Java bereit . [ 1 ]

OpenObex

OpenObex ist eine Open-Source-Implementierung von OBEX in C. Es bietet Funktionen für Verbindungen über IrDA , Bluetooth , USB und TCP/IP , zum Erstellen von Objekten und zur Verarbeitung empfangener Daten. Ein Beispielschema einer Client-Anwendung ist:

void callback_function (...) { /* Empfangene Daten verarbeiten */ }int main () { 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 ); }

Objekte werden gesendet OBEX_Request. Nach dem Aufruf von OBEX_HandleInputwerden die empfangenen Daten in der Callback-Funktion verarbeitet (die beim Aufruf von angegeben wurde OBEX_Init). Die Callback-Funktion kann feststellen, ob die Antwort vollständig empfangen wurde und ob das Hauptprogramm daher die aktuelle whileSchleife verlassen kann.

PyOBEX und nOBEX

PyOBEX bietet teilweise Unterstützung für OBEX in Python . [ 2 ] nOBEX ist ein Fork von PyOBEX mit umfassenderer OBEX-Unterstützung und Unterstützung für das Bluetooth Hands Free Profile , um OBEX-Tests auf Infotainmentsystemen in Fahrzeugen zu erleichtern. [ 3 ]

Profile

OBEX ist die Grundlage für viele höherwertige „Profile“:

Profile
Einstufung Profil
IrDAPoint-and-Shoot-Profil
Profil für Infrarot-Finanznachrichten (IrFM)
Bluetooth SIGGenerisches Objektaustauschprofil
Objekt-Push-Profil (Telefon-zu-Telefon-Übertragungen)
Dateiübertragungsprofil (Übertragung vom Telefon zum PC)
Synchronisierungsprofil
Grundlegendes Bildgebungsprofil
Grundlegendes Druckprofil
OMASyncML- Bindung

Unterstützte Geräte

Siehe auch

Referenzen