WBA2
Mündliche Prüfung
Mündliche Prüfung
-
- 1 / 79
-
Flashcards
Definition Middleware (ist auch eine Softwarekomponente)
Systeme, auf denen Softwarekomponenten laufen, können damit untereinander interagieren. Liegt zwischen Betriebssystem und Anwendung, ist aber systemnahe Software.
Betriebssysteme können unterschiedlich sein. Systeme können unterschiedliche Architekturen haben
Eine Schicht eines Software-Schichtenmodells die logisch zwsichen der Anwendungsebene und der Betriebssystemebene abstrahiert und die Aspekte der Verteiltheit vor dem Nutzer verbirgt. Verteilte Systeme manifestieren eine solche Schicht indem sie Anwendungen und allgemeiner Dienstnutzern eine einheitliche Schnittstelle bieten , die von den Eigenheiten der unterschiedlichen Betriebssysteme und Netztechnologien abstrahieren. Eine Middleware ist eine Softwarekomponente, hat Schnittstellen und stellt Softwarekomponenten der Anwendungsebene diverse Dienste zur Verfügung. Middleware überbrückt Heterogenität in Betriebssystemen , Rechnerarchitekturen und Programmiersprachen .
Paradigma Client-Server
Client-Server
In the basic client-server model, processes in a distributed system are divided into two (possibly overlapping) groups. A server is a process implementing a specific service, for example, a file system service or a database service. A client is a process that requests a service from a server by sending it a request and subse- quently waiting for the server's reply.
UDP:
when a client requests a service, it simply packages a message for the server, identifying the service it wants, along with the necessary input data. The message is then sent to the server. The latter, in turn, will always wait for an incoming request, subsequently process it, and pack- age the results in a reply message that is then sent to the client.
-> effizient aber Nachrichten könnten beim Transport korrupt werden und es gibt keine Fehlerbehandlung, außerdem ist UDP nicht idempotent. In Local Area Networks wird UDP aufgrund der Performance oft bevorzugt, in Wide Area Networks muss für verlässliche Kommunikation auf TCP zurückgegriffen werden.
Paradigma Peer-to-Peer
In decentralized archi- tectures we often see an equal role played by the processes that constitute a dis- tributed system, also known as peer-to-peer systems. In peer-to-peer systems, the processes are organized into an overlay network, which is a logical network in which every process has a local list of other peers that it can communicate with. The overlay network can be structured, in which case deterministic schemes can be deployed for routing messages between processes. In unstructured networks, the list of peers is more or less random, implying that search algorithms need to be deployed for locating data or other processes.
Prozesse kommunizieren durch asynchrone (synchrone) Nachrichten, kein Warten wie bei Client-Server
MPI is designed for parallel applications and as such is tailored to transient communication. It makes direct use of the underlying net- work..Also, it assumes that serious failures such as process crashes or network partitions are fatal and do not require automatic recovery.
MPI assumes communication takes place within a knowngroup of processes. Each group is assigned an identifier. Each process within a group is also assigned a (local) identifier. A (group/D, process/D) pair therefore uniquely identifies the source or destination of a message, and is used instead of a transport-level ad- dress. There may be several, possibly overlapping groups of processes involved in a computation and that are all executing at the same time.
Publish Subscribe Paradigma
- Nachrichten nicht adressiert, sondern publiziert.
applications simply send messages to logical contact points, often described by means of a subject. Likewise, applications can indicate their interest for a specific type of message, after which the communication mid- dleware will take care that those messages are delivered to those applications.
The basic idea is that processes publish events after which the middleware ensures that only those processes that subscribed to those events will receive them.
Transaktion in einem verteilten System?
- kontrollierte Veränderung des Systemzustandes in einem verteilten System
- atomar (Transaktion ganz oder gar nicht ausgeführt)
- Konsistenz (Nach Ausführung der Transaktion muss der Datenbestand in konsistenter Form sein, genau wie zu Beginn der Transaktion)
- Isolation: Bei gleichzeitiger Ausführung mehrerer Transaktionen dürfen sie sich nicht gegenseitig beeinflussen
- Persistenz: Auswirkungen einer Transaktion müssen im Datenbestand dauerhaft bestehen bleiben
Erklären Sie das Three-Tier Paradigma und gehen Sie darauf ein, warum die Trennungen zwischen Präsentationslogik, Anwendungslogik und Ressource-Management wichtig sind!
Paradigma Multi tier
- tier: Reihe
- wie AWL, PL und Datenhaltung auf verschiedene Systeme in einem verteilten System verteilt werden können
two-tier:
- Teil der Präsentationslogik auf dem Client, AWL und Datenhaltung auf dem Server.
Vorteil: Gleiche AWL über verschiedene PL ansprechbar. Z.B. Verschiedene Arten von Endgeräten benötigen unterschiedliche PL
three-tier:
- Trennung von AWL und Datenhaltung verbunden durch Middleware. AWL kann auf anderem Prozess bzw. BS laufen als Datenhaltung, weniger Abhängigkeit.
Klare konzeptionelle Trennung von AWL und Datenhaltung -> über Schnittstellen Daten austauschen. Komponenten können einfacher ersetzt werden.
Das 3-Tier Paradigma beschreibt ein Paradigma für Systemarchitekturen, die das Ziel verfolgt einzelne Systemkomponeten durch besonders lose Kopplung leicht austauschbar oder erweiterbar zu machen.
In einigen Fällen muss der Server, der Anfragen von Clients entgegennimmt, auch als Client gegenüber anderen Servern fungieren.
Bsp: Bei der Organisation von Webseiten dient das User Interface (Präsentationslogik) als Einstiegspunkt für eine Seite, welches als Client Requests an einen Application Server (Anwendungslogik) richtet, der für die generelle Verarbeitung zuständig ist (z.B. Algorithmen zur Prüfung von Warenbeständen), wobei der Application Server wiederrum als Client fungiert und Requests an einen Datenbank-Server richtet.
Erklären Sie das Paradigma Cloud Computing und gehen Sie auf die Begriffe IaaS, PaaS und SaaS ein!
- irgendwo im Netz nutzbare Services mit Contracts
- IaaS: virtuelle Maschinen, Server, Plattenkapazität, Load Balancing (Bsp: Amazon S3)
- PaaS: Datenbankumgebungen, Webserver, Development Tools
- SaaS: Email Service, Systeme für Kundenkommunikation für Unternehmen
Was versteht man unter transienter, was unter persistenter Kommunikation?
With persistent communication, a message that has been submitted for transmission is stored by the communication middleware as long as it takes to deliver it to the receiver. In this case, the middleware will store the message at one or several of the storage facilities shown in Fig. 4-4. As a consequence, it is not necessary for the sending application to continue execution after submitting the message. Likewise, the receiving application need not be executing when the message is submitted.
In contrast, with transient communication, a message is stored by the com- munication system only as long as the sending and receiving application are exe- cuting. More precisely, in terms of Fig. 4-4, the middleware cannot deliver a mes- sage due to a transmission interrupt, or because the recipient is currently not active, it will simply be discarded. Typically, all transport-level communication services offer only transient communication. In this case, the communication sys- tem consists traditional store-and-forward routers. If a router cannot deliver a message to the next one or the destination host, it will simply drop the message.
Erklären Sie welche Softwarekomponenten beim Remote Procedure Call (RPC) ausgeführt werden! Gehen Sie auch auf die Darstellung der Daten ein!
Beim Remote Procedure Call (RPC) sieht es für Client als auch für Server Maschine aus, als würde ein lokaler Methodenaufruf durchgeführt. Im wesentlichen kann ein RPC mit den folgenden Software komponenten durchgeführt werden :
Aufrufender Prozess- Führt einen lokalen Methodenaufruf durch
Client Stub - Führt Parameter Marshalling durch , verpackt also die Parameter der aufrufenden Methode in eine geeignete Netzdarstellung.
Server Stub - Führt i.d.R recieve() aus und blockiert während er auf requests wartet. Bei Empfang eines requests führt diese Komponente ein unmarshalling durch und übergibt ruft eine Serverprozedur auf.
Server Prozess - Implementiert die übers Netzwerk aufrufbare Methode
Zusätzlich : Komponenten und Vorgehensweisen die Call by Reference nutzbar machen
Große RPC-Systeme wie DCE enthalten eine Reihe Komponenten um die oben genannten Komponenten weitesgehend automatisiert zu generieren.
Ein Generator für eindeutige Identifier (Uuidgen genannt) , um jede Interface Definition eindeutig benennen zu können
Eine Sprache zur Definition eines Interfaces , unabhängig von der gewählten Programmiersprache des Client Programms (IDL)
Ein IDL - Compiler um aus dem Interface Def. File Stubs und Header file zu generieren
Besondere Beachtung muss bei RPC der Datendarstellung gewidmet werden.
Ein Call by Reference Mechanismus , wie er von vielen Programmiersprachen verwendet wird, erfüllt nur in einem einheitlichen Adressraum seinen Zweck.In verteilten Anwendungen differieren die beteiligten Kommunikationspartner jedoch auf vielen Ebenen (OS, Hardwarearchitektur , Zahlendarstellung.. ). Um diesen Unterschieden Rechnung zu tragen
Was versteht man unter little endian ?
Der Begriff little Endian bezieht sich auf Systemarchitektur spezifische Konventionen zur Zahlendarstellung auf Bitebene. Man unterscheidet grundsätzlich Big Endian und Little Endian. In der Little-Endian Zahlendarstellung wird das geringwertigste Byte and die kleinste Speicheradresse geschrieben.
Beispiel : Dezimal : 8
Binär : 1 0 0 0 , Most Significant Bit ist die 1
Big Endian : 1 0 0 0 (Sun SPARC )
Little Endian : 0 0 0 1 (Intel)
Was versteht man unter einer Interface Definition Language (IDL)?
Eine Sprache die es erlaubt mit einer standardisierten Syntax die Schnittstelle für die Nutzung einer verteilten Anwendung zu spezifizieren . Die meist verbreiteten Sprachen bieten jedoch lediglich die Möglichkeit diese Schnittstellen bezüglich ihrer Syntax (Methodennamen , Returnvalues , Parameter) zu beschreiben. Die jeweilige Semantik die die jeweiligen Operationen vereinnahmen wird meist informell in Form natürlicher Sprache definiert.
Die meisten RPC-Systeme stellen eine solche Sprache zur Verfügung , damit Client und Serverprogramme völlig unabhängig voneinander implementiert werden können und sich nur auf ein Interface einigen müssen .
Was ist die Rolle eines Directory Servers beim RPC?
Um einen RPC ausführen zu können muss ein Client zunächst den Kommunikationsendpunkt identifizieren , mit dem er kommunizieren möchte. Ein solcher Kommunikationsendpunkt besteht im wesentlichen aus zwei Komponenten, der Adresse des Servers ,der einen bestimmten Dienst zur Verfügung stellt, sowie der Adresse eines lauschenden Prozesses auf diesem Server (Port). Ein Directory Server (Verzeichnis-Server!) stellt die Zuordnungsinformation zwsichen Dienst und Serveradresse bereit. Die Prozessadresse kann dann bei dem Server nachgefragt werden. Im Falle von DCE-RPC übernimmt eine weitere Softwarekomponente , der DCE Dämon, die Aufgabe diese Prozessadresse bereitzustellen .
Im Allgemeinen ist ein Directory Service ein Service ,der die Location aller Ressourcen im System kennt und bereitstellt. Im Falle einer RESTful Webanwendung wird die Aufgabe des Directory Services vom DNS übernommen.
Was sind die Basis Operationen an der Schnittstelle zu einer Message Queue?
PUT: Sender ruft Put auf, um eine Nachricht an das darunter liegende System zu senden, die an den Queue angefügt wird (nonblocking)
GET: Ein autorisierter Prozess kann die am längsten wartende Nachricht in einem Queue entfernen (blocking). Der aufrufende Prozess wird nur blockiert solange der Quee nicht leer ist
POLL: Wenn der Queue leer ist oder eine spezifische Nachricht nicht gefunden werden kann, fährt der aufrufende Prozess einfach fort (nonblocking)
Notify: Wenn eine Nachricht in der Queue vorliegt, wird eine Callback Funktion ausgeführt. Meist als Daemon auf Empfänger-Seite integriert, der den Queue ständig auf neue Nachrichten prüft.
Was versteht man unter Quality of Service (QoS) bei der Stream Kommunikation?
Timing (and other nonfunctional) requirements are generally expressed as Quality of Service (QoS) requirements. These requirements describe what is needed from the underlying distributed system and network to ensure that, for ex- ample, the temporal relationships in a stream can be preserved. QoS for continu- ous data streams mainly concerns timeliness, volume, and reliability
QoS Anforderungen:
The required bit rate at which data should be transported.
The maximum delay until a session has been set up (i.e., when an ap- plication can start sending data).
The maximum end-to-end delay (i.e., how long it will take until a data unit makes it to a recipient).
The maximum delay variance, or jitter.
The maximum round-trip delay.
Erklären Sie das Konzept der Namespaces!
Namespaces sind ein Konzept das es erlaubt gleiche Namen als Identifier für unterschiedliche Dinge(bei XML Elemente oder Attribute) zu verwenden. So ist in einem Namespace ein Element immer eindeutig identifiziert , (z.B das HTML table Element folgt genau definierten Regeln) , um den identifier “table” jedoch nicht zu blockieren, nutzt man namespaces. In XML ist das Namespace Konzept über Präfixe realisiert , namespaces werden im <Schema> Element festgelegt.
--
Kombination verschiedener Vokabulare in einem Dokument erzeugt Mehrdeutigkeiten
URL für jede (Unter-) Sprache
Präfix für Namen von Elementen (foo). Wird eindeutig durch Bindung an eine URI
Universelle Eindeutigkeit von Vokabularen
Standard Namensraum definiert durch xmlns attribut
Auch Attribut Namen können Präfix haben
XSLT
xml daten sollen in verschiedenen formen dargestellt werden (pdf, doc, html)
xml data files und stylesheets sowie transformationsregeln, die die transformation in die darstellungsformen spezifizieren
Rest Constraints
adressierung (ressourcen definieren. bekommen eine uri. alle ressourcen weltweit eindeutig durch uri ansprechbar)
repräsentationen (datenbestand menschen- oder maschinenlesbar)
zustandslosigkeit (interaktion zwischen nutzer und anbieter speichert serverseitig keinen zustand (session)) -> bessere Skalierbarkeit
allgemeingültige Operationen (get, post, put, delete, gelten für alle Ressourcen)
Hypermedia (Ressourcen untereinander durch Links verbunden)
Entwurf einer Rest Architektur (Schritte)
- bestimmung der ressourcen und verknüpfungen
- ressourcen gruppieren
- einstieg in den dienst durch eine einzige uri mit verweis auf alle anderen ressourcen
- für jede ressource wird festgelegt welche http methode sie unterstützt und welche semantik sich dahinter verbirgt
- uri kann eine repräsentation in xml, html, etc. liefern
uri ist unabhängig von repräsentation! sollte nicht nach dem datenformat benannt werden
- Erklären Sie Sinn und Funktionsweise von AJAX! Gehen Sie auch darauf ein, welche Vorgänge asynchron sind.
asynchron: Nachricht versendet und nicht auf Resultat gewartet, keine zeitliche Kopplung
Aktivitätsfluss: Im Browser Ajax Engine läuft ein Programm in JS, interagiert mit dem Nutzer. Wenn Daten benötigt werden, werden sie vom Server angefordert.
Austausch von Daten zwischen Ajax Engine und Server und Kommunikation des Ajax Engine mit Nutzer ist entkoppelt, nicht synchronisiert
Client-Server bleibt synchron, nur die Interaktion des Nutzers entkoppelt von anderer Interaktion
Ajax: Asynchronität im Browser, synchrone Client-Server Interaktion
Pull? (Ajax)
Pull (Ziehen): Regelmäßig Daten vom Client beim Server abgerufen. Üblich bei nicht zeitkritischen Daten, Dropbox
Push(Ajax)
Push (Schieben): Echtzeitkommunikation, initiiert von Client, Server löst Nachrichtenübertragung aus, bei zeitkritischen Daten
Asynchronität mit HTTP (Polling, Long Polling, Websockets)
Polling: sehr häufige Anfragen vom Client. Events werden nicht sofort erkannt
Long Polling: Client sendet Request an Server und wird nicht sofort beantwortet. Erst Antwort wenn Ereignis verfügbar. Problem: Timeout, Events können verloren gehen wenn sie eintreffen bevor neues Event ankommt
Websocket: Protokoll auf Basis von HTTP, Client schickt upgrade request an server, dadurch Wechsel des Protokolls. Unter den gleichen Adressen kommt bestehende Verbindung zustande, jederzeit können beide Nachrichten verschicken, bietet Asynchronität zwischen Browser und HTTP Client.
Einordnung Websockets:
TCP (Adressierung: IP+Port, Duplex: ja, Inhalt: Bytestreams, Verbindung: ja)
HTTP (Adressierung: URI, Duplex: nein, Inhalt: XML/MIME, Verbindung: nein)
Websockets (Adressierung: URI, Duplex: ja, Inhalt: Text und Bytestreams, Verbindung: ja)
Fat Ping vs. Light Ping
Nachricht von Server.
Fat: Server sendet mit Nachricht auch den Payload
Light: Nur Benachrichtigung ohne Payload.
Ereignisorientierter Architekturstil?
basiert auf Erzeugung, Übermittlung, Verarbeitung von Ereignissen.
Komponenten im System kommunizieren asynchron über Ereignisse
Ereignis: relevante Änderung eines Zustands in dem betrachteten System
Erklären Sie Message oriented Middleware
Message-oriented Middleware, erlauben verschiedenen Komponenten Nachrichten asynchron auszutauschen
Warteschlangen bzw. Queues für Nachrichten, die auf Übertragung oder Verarbeitung warten. Asynchrones Versenden stellt Empfang des Empfängers nicht sicher, übermittelndes System muss Nachricht cachen, beide Systeme müssen nicht sychron kommunizieren damit Nachricht ankommt
Publish Subscribe Prinzip?
Nachrichtenabsender (Anbieter) sendet Nachrichten nicht direkt an Empfänger, sondern publiziert sie in eine nachrichtenorientierte Middleware. Nachricht hat z.B. Beteff
Abonnenten müssen System sagen, welche Nachrichten mit welchem Betreff sie empfangen wollen.
Middleware muss Nachrichten, die zu bestimmten Thema publiziert wurden, an alle Subscriber übermitteln
Schnittstellen einer Nachrichtenwarteschlange?
Put (Append Message to queue)
Nachricht aus Warteschlange holen
-> synchron Get (Blockieren bis eine Nachricht in der Warteschlange ist)
-> asynchron Poll (Schauen ob eine Nachricht vorhanden ist, nicht blockieren)
Notify (Push: Wenn eine Nachricht eintrifft, ein Programm für die Verarbeitung aufrufen)
Was ist JMS?
Spezifikation einer Schnittstelle zum einheitlichen Zugang zu ereignisorientierten Middleware Systemen.
JMS und der durch diese angesteuerte Dienst unterstützen zwei unterschiedliche Ansätze zum Versenden von Nachrichten, zum einen die Nachrichtenwarteschlange(englisch queue) für sogenannte point-to-point Verbindungen und zum anderen ein Anmelde-Versendesystem (engl. topic) für Publish-Subscribe-Kommunikation:
- Bei der Warteschlange sendet der Sender an eine Queue, an der ein oder mehrere Empfänger hängen. Ist kein Empfänger verfügbar, kann die Nachricht optional gespeichert werden und potentielle Empfänger können sie jederzeit später abholen. Für den Fall nur eines Empfängers, kann man dies am besten mit einem Paketdienst vergleichen. Jede Sendung hat genau einen Empfänger. Ist dieser nicht zu Hause, kann er sich die Sendung zu einem beliebigen Zeitpunkt später abholen. Bei mehreren Empfängern wird bei der Zustellung der Nachrichten sichergestellt, dass jede eingereihte Nachricht exakt einmal zugeteilt wird. Hierdurch lässt sich Load Balancing realisieren, bei dem Empfänger beliebig hinzugefügt und entfernt werden können.
- Bei dem Anmelde-Versendesystem werden die Nachrichten an ein Topic geschickt, auf das eine beliebige Anzahl von Empfängern hört. Wird die Nachricht nicht konsumiert, weil kein Empfänger sich an das Topic angemeldet hat, dann ist dies unerheblich. Man kann dies am besten mit einem Fernsehsender vergleichen (Broadcasting). Entweder man schaltet den Fernseher ein und sieht die Nachricht oder man lässt den Fernseher aus und sieht die Nachricht nicht. Wahlweise können die Nachrichten auch zwischengespeichert werden (durable-subscription).
Um JMS nutzen zu können, wird ein JMS-Provider benötigt, der die Topics, Queues und Sessions verwaltet. (z.B. ActiveMQ)
Was ist XMPP?
offener Standard für die Echtzeitkommunikation
- Extensible Messaging and Presence Protocol
- Offene Technologie zur Echtzeit-Kommunikation, wobei XML als Basis-Format zum Austausch von Informationen genutzt wird
- Man kann von XML von einer zu einer anderen Entität in nahezu Echtzeit versenden
- Open standard (keine Lizenzen)
- Definiert genau wie HTTP für das Web die Protokolle und Datenformate für Real-Time Apps
- Dezentralisierte Client-Server Architektur
o Trennung von Zuständigkeiten
o einfacher zu verwalten als P2P
o robust weil jeder einen XMPP Server starten kann
o Server sind für die Durchsetzung von Sicherheitsregeln zuständig (User Auth, channel encrypt)
Clients sind sehr einfach, Komplexität auf dem Server
- Unterschied zu Web:
o Web verwendet keine Inter-Domain Connections (Server untereinander verbunden, Federation) sondern der Browser fragt zusätzliche Ressourcen durch weitere GETs ab
- Unterschied zu Email:
o Beim Senden einer Email verbindet sich der Client zu dem eigenen Email Server, der die Zielroute bestimmt (Server untereinander verbunden, Federation) aber die Nachricht könnte durch mehrere hops geroutet werden, bis sie am Ziel ankommt
- Beim Senden einer XMPP Nachricht verbindet sich der eigene Server direkt zum anderen Server (kein Spoofing, kein Spam)
Wie funktionieren Push Dienste?
SMS (Wap): 160 Zeichen, als SMS, Kosten für SMS
-> Dauerhafte Verbindung zu jedem einzelnen Server: Implementierungsaufwand, Komplexität, Firewalls
mehrere Anwendungen, mehrere Verbindungen, Prozesse
Polling zum aufrechthalten der Verbindung,
Belastung des Servers
Lösung: Plattform abhängige Push Dienste
Apple Push Notification Service (APNS)
Google Cloud Messaging (CGM)
Windows Push (WNS)
Grundlagen:
Endgerät bekommt Nachrichten von einem Provider. Provider hinterlegt Nachricht bei Plattform Anbieter. Dieser übernimmt die Aufgabe an das Endgerät zu übermitteln.
Push via GCM/APNS?
- für alle Apps eine Verbindung
- Informationsanbieter haben keine Serverlast
- keine redundaten Prozesse
- weniger Implementierungsaufwand
- Abhängigkeit vom Provider
- Datenschutz
Paradigma Stream?
- keine endlich große Nachricht
- Information übermittelt als Folge von Datenpaketen in zeitlicher Ordnung
- bei anforderndem System zeitlich eng gekoppelt an die Übertragung wiedergegeben
- es können auch Messwerte gestreamt werden, nicht nur Mediendaten
Vergleich: FTP übertragt erst, dann Wiedergabe
Paradigma Multicast:
- oft sendende Systeme, die die gleiche Nachricht oder gleichen Stream an Vielzahl von Empfängern schicken
- mit Req-res oder Mess-pass: Sendendes System müssen Bandbreite für jedes empfangene System vorsehen
- Lösung: IP Protokoll erlaubt Multicast, wobei Stream an mehrere Empfänger vom sendenden System nur einmal gesendet wird und Netzwerk für Verteilung zuständig ist
Was ist das XMPP message stanza?
Message
- Bei <message/> handelt es sich um die Standard „push“ Methode, um Informationen von einem Punkt zu einem anderen zu übermitteln
- Messages werden normalerweise nicht angekündigt, oft in IM, Groupchat, Alerts, Notifications genutzt
- Type
o Normal (genau wie E-Mail)
o Chat (werden in einer „real-time“ session ausgetauscht)
o Groupchat (chatroom)
o Headline (für Alerts und Notifications, keine Antwort erwartet)
o Error (wenn ein Fehler auftritt sendet die erkennende Entität diesen Typ zurück)
- Zusätzlich: „to“ und „from“ Adresse, wobei „from“ nicht vom sendenden Client übermittelt wird sondern durch den sendenden Server gesetzt wird (kein Spoofing)
- Payload Child Attribute (<body />, <subject />)
XMPP Presence Stanza?
Presence
- Erlaubt die Ansicht der Verfügbarkeit von anderen Entitäten
- Nur durch vorherige Autorisierung möglich (subsription request muss erlaubt werden, danach können Nutzer Status Updates erhalten
- <presence/> stanza ist spezialisiertes publish-subscribe
- meist erweitert durch „away, nicht stören“ statt nur „online“ oder „offline“
- presence meist im roster angezeigt (Kontaktliste), der roster enthält Liste von JIDs und Status von presence subscriptions bei anderen Entitäten
- Server ist für Ermittlung und Fetching von presence Daten zuständig
XMPP IQ Stanza
IQ
- Info/Query stanza
- Bietet Struktur für Req-Res Interaktionen
- Ähnlich zu GET/POST/PUT
- Nur ein Payload (message: unendlich), der die Aktion auf dem Empfänger bestimmt
- Sendende Entität muss immer eine Antwort bekommen
- Req und Res sind durch id Attribut verfolgbar (durch anfragende Entität generiert und durch empfangende Entität in Antwort eingefügt)
- Type
o Get (HTTP GET, fragt z.B. nach Anforderungen um einen Account zu registrieren)
o Set (HTTP POST/PUT, anfragende Entität schickt Informationen oder macht eine Anfrage)
o Result (empfangende Entität gibt Ergebnisse der get Operation zurück (Informationen die für die Registrierung des Accounts benötigt werden) oder bestätigt den set request (Status Code 200)
o Error (empfangende Entität bzw. der XMPP Server benachrichtigt die anfragende Entität, dass der GET oder SET Request nicht verarbeitet werden konnte (ähnlich HTTP Status Codes)
- IQ vs Message: genau wie TCP vs. UDP
- Wie kann eine Multi-Party-Kommunikation mit XMPP verwirklicht werden?
presence an den raum
raum sendet allen teilnehmern ein presence stanza mit status des neuen mitglieds
man selber kriegt die presence stanzas der anderen und möglicherweise bereits gesendete nachrichten mit entsprechendem flag
für private kommunikation: message mit type = chat an die room jid eines anderen senden
raum verlassen: presence mit type unavailable an die eigene room jid senden, wird dann allen anderen mitgeteilt
- Wie wird eine Publish/Subscribe Kommunikation in XMPP verwirklicht?
- Subscribing von Clients auf Nodes mittels IQ set stanzas und empfangen von Notifications einer Node (Bereits mit presence stanzas realisiert (group chat))
- Eine JID im Subscription IQ set stanza kann entweder auf ein spezielles Gerät verweisen oder für alle Geräte gelten, sodass alle subscribed werden
- Das Subscribe element spezifiziert die Node, auf die man subscribed und die jid für die subscription
- Wenn die Subscription erfolgreich war, sendet der Server IQ stanza mit type result zurück und ergänzt den subscription tag um attribut-value subscribed
- Unsubscribe: Mittels iq set stanza und „unsubscribe“ child element. Server antwortet mit iq result
Publishing
- Iq set stanza mit publish tag, eingepackt in xml element pubsub mit namespace auf pubsub protokoll
- Item tag umhüllt den Payload
- Entry element ist der Payload und enthält standardmäßig Atom Content mit spezifischen tags wie published, updated, summary, title
- Jedoch ist pubsub der payload egal weil es nur übermittelt, jedes XML Element kann im Payload enthalten sein
Notification
- Nachdem ein neues Item gepublished wurde, werden alle Subscriber benachrichtigt
- PubSub Notifications werden als „message“ stanza gesendet, da nicht bekannt ist ob der Subscriber gerade online ist. Entscheidung wird dem Empfänger-Server überlassen
- Event Element enthält bis auf anderen Namespace die Informationen von publish element des Publishers
- Entry Payload ist gleich wie Publisher entry tag Inhalt
Payload
- Payload muss nicht immer gesendet werden (Türklingel Metapher)
- Payload könnte auf einer anderen Node liegen
- Wenn kein Payload, dann Verweis auf item id
Items
- Bereits gepublishte Benachrichtigungen müssen nicht unbedingt persistent gespeichert werden
- Manchmal will ein Client aber Informatioenn von vergangenen Benachrichtigungen erfahren
- IQ get mit items child element mit Verweis auf die node enthält die gewünschten Items
