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 | Befehl | GETFinale | 0x83 |
|---|---|---|---|---|
| Länge | Gesamtlänge des Objekts | 0x00 0x29 | ||
| Überschriften | Verbindungs-ID | 1 | 0xCB 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 von0xCBsind11, 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 von0x01sind00, 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; einTARGETHeader 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 weitereGETObjekte 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 entsprechendenTYPEHeader 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 nachfolgendenGET,PUT,SETPATHundACTIONObjekten 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 untertelecom/VerwendungGETvon „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 werdenGET, 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 vonPUT-PaarenGET, 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“:
| Einstufung | Profil |
|---|---|
| IrDA | Point-and-Shoot-Profil |
| Profil für Infrarot-Finanznachrichten (IrFM) | |
| Bluetooth SIG | Generisches Objektaustauschprofil |
| Objekt-Push-Profil (Telefon-zu-Telefon-Übertragungen) | |
| Dateiübertragungsprofil (Übertragung vom Telefon zum PC) | |
| Synchronisierungsprofil | |
| Grundlegendes Bildgebungsprofil | |
| Grundlegendes Druckprofil | |
| OMA | SyncML- Bindung |
Unterstützte Geräte
- Android- Geräte ab Version 2.1 „Eclair“ .
- Alle Palm-Geräte seit Palm III , außer webOS-Geräte: Palm Pre, Palm Pre Plus, Palm Pixi und Palm Pixi Plus.
- Die meisten Nicht-Android- Handys von Sharp , Motorola , Samsung , Sony Ericsson , HTC und Nokia mit Infrarot- oder Bluetooth- Anschluss werden unterstützt. Android-Geräte werden zwar auch unterstützt, aber das bedeutet eigentlich, dass diese ebenfalls unterstützt werden.
- LG enV Touch (VX11000)
- Viele weitere PDAs seit 2003, bis zu ihrem Niedergang aufgrund der Ablösung durch Smartphones.
- Viele andere Telefone mit Infrarot- oder Bluetooth- Anschluss
- Windows Phone 7.8- und 8-Geräte (beschränkt auf die Übertragung von Bildern, Musik und Videos über eine „Bluetooth Share“-App).
Siehe auch
Referenzen
Externe Links
- OBEX-Spezifikation auf IrDA.org
- Bluetooth-Profile, archiviert am 31.12.2013 in der Wayback Machine , einschließlich Spezifikationen für OBEX und OBEX-basierte Protokolle (GOEP, FTP, OBEX push, SYNC)
- OpenOBEX ist eine Open-Source-Implementierung des OBEX-Protokolls.