|
[Studienarbeiten: Kommunikation zwischen PDAs] | |
Die unterliegende IrLAP-Schicht bietet nur eine einzige
Verbindung zwischen zwei Geräten. Um die Möglichkeit von konkurierenden und
unabhängigen (logischen) Verbindungen, beispielsweise zwischen verschiedenen parallel
laufenden Anwendungen, zu schaffen, müssen diese also über die einzelne IrLAP-Verbindung
simuliert werden.
IrLMP wurde für diese Aufgabe entwickelt. Dies impliziert die Möglichkeit der Erkennung
von möglichen Diensten auf anderen Geräten, sowie das multiplexen und demultiplexen der
Daten auf eine einzelne Verbindung. Für die Erkennung wurde der LM-IAS (Link Management Information Access
Service) entworfen, mit der Möglichkeit, auf eine Datenbasis eines fremden Gerätes
zuzugreifen und gewünschte Informationen abzurufen. Das Multiplexen und Demultiplexen
läuft über den sogenannten Link Management
Multiplexer (LM-MUX).
Ein Problem der IrLAP-Schicht ist die fehlende Flußkontrolle. Sollte beispielsweise eine
Anwendung die ihr zugeschickten Daten nicht abrufen, stauen sich im Puffer die Daten für
etwaige andere Applikationen - was zu Verklemmungen führen kann. IrDA hat aus diesem
Grund eine Flußkontrolle für IrLMP bereits definiert: IrTinyTP,
das im nächsten Kapitel behandelt wird.
Die Hauptaufgabe der LM-MUX ist der verbindungsorientierte Daentransfer zwischen
mehreren LM-MUX-Clients. Diese werden über ihre LSAPs (Link
Service Acces Point) miteinander verbunden. LSAP-Connections zwischen verschienden
Geräten müssen über IrLAP abgefertigt werden. Innerhalb einer Station werden die LSAPs
durch ihren LSAP-SEL (LSAP-Selector) Wert unterschieden. Der LSAP-SEL kann verglichen werden mit der Portnummer
unter TCP/IP und ist momentan eine ganze Zahl zwischen 1 und 128.
Ein LSAP ist immer genau bestimmt durch die Device-Adresse und den LSAP-SEL (die zusammen auch als LSAP Adresse oder
LSAP-ID bezeichnet werden). Grundsätzlich sind also gleiche Werte des LSAP-SEL auf verschiedenen Geräten möglich.
Auch die Kommunikation zwischen LSAPs auf einem einzelnen Gerät ist über LM-MUX
möglich; hierbei wird das IrLAP nicht benötigt.
Zur Verdeutlichung dieser Begriffe dient die folgende Grafik: 
Zu sehen sind drei Stationen A, B und C. A beherrscht
Point-To-Multipoint und ist mit B und C über die IrLAP Schicht verbunden. Es existieren
also nur zwei IrLAP-Verbindungen. Über diese Verbindungen greifen nun die LM-MUX
Schichten auf ihre Partnerschichten der anderen Geräte zu. Der LSAP mit dem LSAP-SEL D
z.B. greift sowohl auf den LSAP mit dem LSAP-SEL A auf der Station A, als auch auf
den LSAP mit der LSAP-SEL B auf der Station A zu. Dabei dürfen die LSAP-SEL C und
A (oder C und B) gleich sein - unterschieden wird durch die Adresse
der Station. Dagegen müssen die LSAP-SEL A und B (oder C und D)
verschiedene Werte aufweisen, um die LSAPs auf einer einzigen Station unterscheiden zu
können. Auf Station C ist auch eine Verbindung von zwei LSAPs auf der selben Station zu
sehen - der Weg über die IrLAP-Schicht ist nicht notwendig.
Dieses Dienstelement ist für die Entdeckung anderer IrDA-Geräte zuständig. Bei einem
Adressenkonflikt wird es versuchen, diesen zu lösen. Es ist vorgesehen, daß ein
erkanntes Gerät über die Entdeckung informiert wird (und dadurch eine passive Entdeckung
leistet)
| LM_DiscoverDevices.request(nrSlots) | Sucht nach anderen Geräten |
| LM_DiscoverDevices.confirm(status, List of (deviceAddress, DeviceInfo, method)) | Ergebnis der Suche; liefert evtl. mehrere Geräte |
| LM_DiscoverDevices.indication(deviceAddress, DeviceInfo, method) | Anzeige, daß Gerät von einem anderen Gerät entdeckt wurde |
| nrSlots | Parameter für IrLAP (siehe IrLAP) |
| status | gibt an ob wirklich gesucht wurde, oder ob Daten aus dem Cache genutzt wurden |
| deviceAddress | die 32-bit IrLAP Geräte Adresse |
| DeviceInfo | Erweiterte Informationen über das suchende/gefundene Gerät |
| method | Informationen, über welche Weise das Gerät gefunden wurde (aktiv, passiv, sniffing etc.) |
Anmerkung: Falls über DeviceInfo weitere Informationen über das fremde Gerät
erhältlich sind, enthalten die ersten beiden byte des Feldes die IrLMP hint mask Es
können auch weitere 'Hint bytes' folgen. Schließlich enthält das DeviceInfo Feld noch
einen Nickname, ein Art Kurzname des Gerätes. Die Bedeutung der ersten zwei 'Hint
Byte' ist die folgende:
| Bit | Funktion Byte 1 | Funktion Byte 2 |
| 0 (LSB) | PnP Compatible | Telephony |
| 1 | PDA / Palmtop | File Server |
| 2 | Computer | rsvd |
| 3 | Printer | rsvd |
| 4 | Modem | rsvd |
| 5 | Fax | rsvd |
| 6 | LAN Access | rsvd |
| 7 | Extension (bedeutet daß weiteres Byte folgt) | Extension (bedeutet daß weiteres Byte folgt) |
Dieses Dienstelement kann zum Aktivieren und Deaktivieren des Sniff-Modes (siehe IrLAP)
verwendet werden.
| LM_Sniff.request(option) | Startet oder stoppt das sniffing (siehe IrLAP) |
| LM_Sniff.confirm(status, deviceAddress) | Liefert ein Ergebnis des sniffing |
| option | Start/Stop |
| status | gibt an ob die Verbindung aufgebaut oder abgelehnt wurde, und aus welchen Gründen |
| deviceAddress | die 32-bit IrLAP Geräte Adresse |
LM_Connect erzeugt eine Verbindung zu einer erkannten LSAP. Zu jedem Paar von LSAPs
kann es höchstens eine LM-MUX Verbindung geben.
| LM_Connect.request(Called LSAP, Requested QoS, Client Data) | versucht eine Verbindung aufzubauen |
| LM_Connect.indication(Calling LSAP, Resultant QoS, Client Data) | signalisiert einen Verbindungswunsch eines anderen Gerätes |
| LM_Connect.response(Calling LSAP, Client Data) | antwortet auf einen Verbindungswunsch |
| LM_Connect.confirm(Called LSAP, Resultant QoS, Client Data) | Bestätigung des Verbindungsaufbau |
| Called LSAP, Calling LSAP | die LSAP-ID des Anrufers bzw des Angerufenen |
| QoS | der Quality of Service, die Verbindungsparameter (siehe IrLAP) |
| Client Data | Daten, die schon beim Verbindungsaufbau mitgeschickt werden sollen. Typischerweise entscheidend, ob eine Verbindung akzeptiert wird oder nicht, bspw. durch die Übergabe eines Passworts etc. |
Trennt eine Verbindung. Diese Anfrage kann nicht verweigert werden.
| LM_Disconnect.request(Reason, Client Data) | bricht eine Verbindung ab |
| LM_Disconnect.indication(Reason, Client Data) | Zeigt einen Verbindungsabbruch an |
| Reason | Der Grund für den Verbindungsabbau |
| Client Data | Eventuelle weitere Daten des Programms |
Hiermit kann abgefragt werden, ob sich noch unbestätigte Daten in der Warteschlange
befinden. Dies ist vor allem im Bereich der Verbindungstrennung interessant.
| LM_Status.request() | Fordert einen Status an |
| LM_Status.indication(LinkStatus, LockStatus) | zeigt die Anforderung eines Status an |
| LM_Status.confirm(Unacked Data Flag) | liefert den Status |
| LinkStatus | enthält entweder OK, No progress (kein vorankommen) oder noisy (krach) |
| LockStatus | enthält entweder Keine Änderung, Locked (verschlossen) oder Unlocked (unverschlossen) |
| Unacked Data Flag | gibt an, ob noch Daten in der Warteschlange stehen |
Kann benutzt werden, um dem Link Management mitzuteilen, daß die Verbindung momentan
zwar nicht gebraucht, aber dennoch erhalten werden soll. Zu Beginn einer Verbindung wird
vom einem aktiven Zustand ausgegangen.
| LM_Idle.request(Req Mode) | Fordert einen Modus an (s.u.) |
| LM_Idle.confirm(status, Actual Mode) | Bestätigung der Anforderung |
| Req Mode / Actual Mode | der angeforderte bzw. aktuelle Modus, entweder activ oder idle |
| status | enthält Anzeige über Erfolg oder Mißerfolg der Anforderung |
Mit diesem Dienstelement läßt sich zwischen exklusivem Mode und Multiplexed Mode
umschalten.
| LM_AccessMode.request(Requested Mode) | Fordert einen Zugriffsmodus an |
| LM_AccessMode.indication(Resultant Mode) | Zeigt eine Anforderung eines Zugriffmodus an |
| LM_AccessMode.confirm(status, Actual Mode) | Bestätigung der Anforderung |
| Mode | der angeforderte bzw. aktuelle Zugriffsmodus, entweder Exclusive oder Multiplexed |
| status | enthält Anzeige über Erfolg oder Mißerfolg der Anforderung |
LM_Data sendet ein Datenpaket zum Ziel-LSAP. Das Senden ist verläßlich, jedoch wird
dem Sender der Zeitpunkt der Ankunft des Pakets nicht mitgeteilt. Sollte die unterliegende
IrLAP-Verbindung abbrechen, kann es zu Datenverlust kommen.
| LM_Data.request(Data) | Sendet ein Datenpaket (Data) |
| LM_Data.indication(Data) | Anzeige über das Erhalten eines Datenpaketes (Data) |
LM_UData sendet ein Datenpaket mit dringenden Daten. Dies erreicht den Zielort vor
ausstehenden normalen Datenpaketen. Diese Pakete werden nicht verläßlich gesendet.
| LM_UData.request(Data) | Sendet ein Datenpaket mit dringenden Daten (Data) |
| LM_UData.indication(Data) | Anzeige über das Erhalten eines Datenpaketes mit dringenden Daten (Data) |
Hiermit werden verbindungslose, nicht verläßliche Pakete an das Zielgerät gesendet.
Es gibt keine vorgesehene Möglichkeit zur Unterscheidung, für welchen LSAP auf einem
Gerät diese Nachricht bestimmt war.
| LM_ConnectionlessData.request(Data) | Sendet ein Datenpaket |
| LM_ConnectionlessData.indication(Data) | Anzeige eines Datenpaketes |
| LM_ConnectionlessData.confirm(status,[reason]) | Bestätigung der Sendung |
| Data | ein Datenpaket mit Programmdaten |
| status | enthält Anzeige über Erfolg oder Mißerfolg der Sendung |
| reason | optionaler Grund für einen Mißerfolg |
Jedes IrDA Gerät bietet den IAS (Informationszugriff-Dienst). Dieser verfügt über
die Information, welcher Dienst auf seinem Gerät möglich ist und bietet die
Möglichkeit, auf die Datenbasis eines anderen Rechners zuzugreifen. Die Informationen
sind notwendig, damit Clients ein korrekter Zugriff auf die Dienste des Servers möglich
ist. Wie schon erwähnt, ist vor allem der LSAP-SEL unabdingbar. Die Informationen werden
in verschiedenen Objekten innerhalb der Datenbasis untergebracht. Die IrDA-Spezifikation
beschreibt nur die Operationen, die zum Abrufen der Daten notwendig sind - wie die
Datenbank implementiert ist bzw. wie die Daten eingetragen werden ist Sache des jeweiligen
Systems.
Das Information Access Protocol (IAP) beschreibt das Protokoll, mit dem zwei IAS Instanzen
miteinander kommunizieren. Der Server ist immer am LSAP-SEL null. Das Protokoll benutzt
den verläßlichen Datentransfer von IrLAP.
Jeder Dienst kann Informationen in der Datenbasis unterbringen. Jedes Objekt in der Datenbank hat einen Klassennamen, eine eindeutige Kennziffer und eine Reihe von Attributen, die verschiedene Typen (wie Strings, Zahlen oder Binärdaten) und Werte annehmen können. Damit ist erlaubt, daß mehrere Objekte den selben Klassennamen und auch die selben Attributnamen haben (und sich nur durch die Kennziffer unterscheiden), und damit bei einer typischen Anfrage mit Übergabe von Klasse und Attributnamen eine Liste von Ergebnissen zurückgeliefert wird. Obwohl dies absichtlich spezifiziert wurde, schreibt IrDA in der Spezifikation zu IrDA Lite, daß auch für voll funktionsfähige Implementationen es die beste Methode sei, auf diese Liste zu verzichten und nur eindeutige Objektnamen zu verteilen.
Alle Dienstelemente bestehen aus einem request/confirm Paar, und sind bis auf
LM_GetValueByClass optional.
Mit diesem Dienstelement lassen sich Informationen über die Datenbasis abrufen, die in
den weiteren Dienstelementen benötigt werden, darunter auch die Anzahl der Objekte.
| LM_GetInfoBaseDetails.request(address) | Stellt eine Basisanfrage |
| LM_GetInfoBaseDetails.confirm(number of objects, max. object id) | liefert Informationen über die Datenbasis |
| address | 32-bit Adresse des Zielgerätes |
| number of objects | Anzahl der Objekte in der Datenbasis des Zielgerätes |
| max. object id | Größte Objektkennziffer, die momentan im Gebrauch ist |
LM_GetObjects liefert Informationen über Objekte; dies beinhaltet auch Informationen
über die Anzahl der Attribute pro Objekt. Durch wiederholtes Aufrufen dieser Funktion
(unter Verwendung von next id als first id im nächsten Aufruf) ist es
möglich, detaillierte Informationen über alle Objekte einer Datenbasis abzurufen.
| LM_GetObjects.request(address, first id, max. list, class name) | Fordert Objektinformationen an |
| LM_GetObjects.confirm(next id, list of (id, num. attributes, class name)) | liefert die Informationen |
| address | 32-bit Adresse des Zielgerätes |
| first id | Objektkennziffer des ersten Objekts in der zu liefernden Liste |
| max. list | Maximale Größe der zu liefernden Liste |
| class name | Name der Klasse; wird ein leerer String übergeben, sollen alle Klassen durchsucht werden |
| next id | Objektkennziffer des Objektes, daß sich dem letzten gelieferten Objekt anschließt |
| id | Objektkennziffer des aktuellen Objekts |
| num. attributes | Anzahl der Attribute des Objektes |
| class name | Klassenname des Objekts |
LM_GetValue liefert zu einem bestimmten Objekt den Wert eines Attributs, bzw. bei
Angabe mehrerer Attribute eine Liste.
| LM_GetValue.request(address, id, attribut name1, [attribute name2, ...]) | Anfrage nach Werten bestimmter Attribute eines Objekts |
| LM_GetValue.confirm(List of attribute values) | Liefert die Werte |
| address | 32-bit Adresse des Zielgerätes |
| id | Objektkennziffer |
| attribut name | Name des Attributs |
| value | Wert des Attributs. Falls der Attributname nicht gefunden wird, ist der Typ dieses Wertes 'missing' |
LM_GetValueByClass liefert die Werte des Attributs aller Objekte mit dem übergebenen
Klassen- und Attributnamen.
| LM_GetValueByClass.request(address,class name,attribute name) | Anfrage nach Wert eines bestimmten Attributes |
| LM_GetValueByClass.confirm(list of (object id, attribute value)) | Liefert eine Liste von Werten |
| address | 32-bit Adresse des Zielgerätes |
| class name | Name der Klasse |
| attribut name | Name des Attributs |
| id | Objektkennziffer |
| value | Wert des Attributs |
LM_GetObjectInfo liefert Informationen über ein Objekt, die für die Verwendung von
LM_GetAttributNames notwendig sind.
| LM_GetObjectInfo.request(address,id) | Stellt eine Anfrage für ein bestimmtes Objekt |
| LM_GetObjectInfo.confirm(lowest slot, highest slot, num. slot) | Liefert Informationen über das Objekt |
| address | 32-bit Adresse des Zielgerätes |
| id | Objektkennziffer |
| lowest slot | Erster Slot der gerade für für dieses Objekt benutzt wird |
| highest slot | Letzter Slot der gerade für für dieses Objekt benutzt wird |
| num. slot | Anzahl der Slots die gerade benutzt werden |
Hiermit lassen sich die Namen von Attributen herausfinden.
| LM_GetAttributNames.request(address,id,first slot,number of names) | Anforderung zum Erhalt der Attributnamen eines Objekts |
| LM_GetAttributNames.confirm(next slot, list of (attribute name, type)) | Liefert die Attributnamen |
| address | 32-bit Adresse des Zielgerätes |
| id | Objektkennziffer |
| first slot | Erster Slot nach dessen Attributnamen gefragt wird |
| number of names | Anzahl der Attributnamen die angefordert werden |
| next slot | Nummer des nächsten Slots nach dem letzten gelieferten Slot |
| attribute name | Attributname |
| type | Typ des Attributs |
 |
[Studienarbeiten: Kommunikation zwischen PDAs] |  |