Überblick. Verteilte Systeme

Transkript

1 Überblick Wintersemester 2014/2015 Prof. Dr. Peter Mandl Verteilte Systeme Einführung und Überblick Zeitsynchronisation Wahl und Übereinstimmung RPC, verteilte Objekte und Dienste Verteilte Transaktionen Message Passing Middlewareplattformen Verteilte Architekturen Gruppenkommunikation Replikation Wechselseitiger Ausschluss Prof. Dr. Peter Mandl Verteilte Systeme Seite: 1

2 Literatur für diesen Teil Coulouris G., et al.: Distributed systems: concepts and design, 5. Auflage, Prentice-Hall, 2012 Tanenbaum, A., Steen, M.: Verteilte Systeme - Prinzipien und Paradigmen, 2. Auflage, Prentice-Hall, 2008 Weber, M.: Verteilte Systeme, Spektrum Akademischer Verlag, 1998 Ban, B.; Red Hat Inc: Reliable Multicasting with the JGroups Toolkit, Manual, JBoss Revision: 1.14 Seite: 2

3 Zielsetzung Zielsetzung der Vorlesung: - Der Studierende soll die grundlegenden Kommunikationsmechanismen für die Gruppenkommunikation verstehen und einschätzen können. - Der Studierende soll den Aufwand und die Machbarkeit der Implementierung von Multicast-Protokollen abschätzen können. Seite: 3

4 Überblick 1.Gruppenkommunikation, grundlegende Anforderungen 2. Semantik der Gruppenkommunikation 3. Implementierungsaspekte 4. Fallbeispiel: JGroups 5. Zusammenfassung Seite: 4

5 Gruppenkommunikation, Was ist das? Im Gegensatz zur Punkt-zu-Punkt-Kommunikation dient Gruppenkommunikation der Kommunikation von mehreren verteilten Prozessen innerhalb einer Anwendung - Mehr als 2 Teilnehmer - 1:m-Kommunikation: Sender sendet an mehrere Empfänger Verschiedene Kommunikationsmechanismen: Sinnvoll ist Multicast Gruppenmitglied Gruppenmitglied Gruppenmitglied Gruppenmitglied Nachricht an die Gruppe Gruppenkommunikation (Multicast) Gruppenmitglied Gruppenmitglied Kommunikationsmechanismen: - Broadcast - Multicast z.b. über multicastfähige Netzwerke wie Ethernet - Gruppenadresse notwendig Seite: 5

6 Motivation und Szenarien Es gibt viele Anwendungen, die Gruppenkommunikation benötigen Unterschiedliche Anforderungen an die Zuverlässigkeit und an die Sortierung der Nachrichten: - Chat-Anwendung Geringe Anforderungen - Verteilung von Aktienkursen in einem Handelsraum einer Bank Hohe Anforderungen - Cluster für hochverfügbare Anwendungen Hohe Anforderungen - Verschiedene Replikationsszenarien Unterschiedliche Anforderungen Seite: 6

7 Offene und geschlossene Gruppen Geschlossene Gruppe: Bekannte Mitglieder Offene Gruppe: Dynamisch variierende Mitglieder Geschlossene Gruppe Offene Gruppe Prozess mit eindeutiger ID Üblichere Variante: Aber Ausfallsituationen müssen behandelt werden Teilnehmer fällt aus und möchte danach wieder zur Gruppe! Seite: 7

8 Überblick 1. Gruppenkommunikation, grundlegende Anforderungen 2. Semantik der Gruppenkommunikation 3. Implementierungsaspekte 4. Fallbeispiel: JGroups 5. Zusammenfassung Seite: 8

9 Semantik der Gruppenkommunikation: Zuverlässigkeit- und Ordnungsgrade Zuverlässigkeitsgrade - Keine Zuverlässigkeit: Keine Garantie darüber, wie viele Empfänger eine Nachricht erhalten - k-zuverlässig: Es wird garantiert, dass mind. k Gruppenmitglieder eine Nachricht erhalten - Atomar: Es wird sichergestellt, dass alle oder keiner eine Nachricht erhalten Ordnungsgrade (in der Nachrichtenreihenfolge) - Ungeordnet: Überholen möglich (nicht sortiert) - FIFO-geordnet (FIFO-sortiert) - Kausal geordnet (kausal sortiert) - Total geordnet (vollständig sortiert) Seite: 9

10 Zuverlässigkeitsgrade Atomar Atomar bedeutet: Alle nicht fehlerhaften Gruppenmitglieder erhalten eine Nachricht oder keines der Mitglieder - Ordnung nicht festgelegt - Wichtig z.b. bei verteilter, replizierter Datenbank, bei der alle Änderungsoperationen in allen Repliken ausgeführt werden müssen (da ist aber auch die Reihenfolge wichtig) Probleme, die gelöst werden müssen: - Absturz eines Gruppenmitglieds: Alle anderen müssen vom Ereignis erfahren und es behandeln - Gruppenmitglied kommt wieder dazu: Recovery notwendig - Neues Mitglied kommt zur Gruppe hinzu (bei offenen Gruppen) Seite: 10

11 Zuverlässigkeitsgrade Virtuelle Synchronität (1) Die Gruppe kann sich immer verändern während Nachrichten gesendet werden Def. Sicht (View) bzw. Gruppensicht : - Alle Gruppenmitglieder sehen die Gruppe gleich Problem: Gruppe ändert sich (durch Ausfall eines Mitglieds) und es ist gerade eine Nachricht unterwegs - Alle bekommen die Nachricht oder keiner Virtuell synchron bedeutet soviel wie atomar während einer Gruppensicht - Man spricht auch von einem virtuell synchronen Multicast = zuverlässiger, aber nicht geordneter Multicast Seite: 11

12 Zuverlässigkeitsgrade Virtuelle Synchronität (2) Herausforderung: Multicasts finden zwischen Sichtänderungen statt - Die Änderung einer Sicht stellt eine Grenze dar, die eine Multicast- Nachricht nicht überschreiten darf - Alle Multicasts während einer Sicht werden abgeschlossen, bevor die neue Sicht wirksam wird P1 tritt der Gruppe bei P3 stürzt ab P3 kommt wieder zurück P 1 t P 2 P 3 Tanenbaum (2008) P 4 G = {P1, P2, P3, P4} G = {P1, P2, P4} G = {P1, P2, P3, P4} Nachricht wird nicht ausgeliefert Seite: 12

13 Ordnungsgrade im Zusammenhang Keine Ordnung FIFO- Ordnung Kausale Ordnung Totale Ordnung Totale Ordnung erfüllt auch die Bedingungen einer kausalen Ordnung usw. Achtung: Atomar bedeutet nicht unbedingt geordnet! Seite: 13

14 Ordnungsgrade: FIFO-geordnet (1) Alle Gruppennachrichten desselben Senders kommen bei den anderen Mitgliedern in der gesendeten Reihenfolge an Beispiel bei 5 Gruppenmitgliedern ohne Konsistenzprobleme: P 1 P 2 P 3 P 4 P 5 send(msg1) receive(msg1) Zeit send(msg2) receive(msg2) receive(msg1) receive(msg1) receive(msg2) receive(msg2) receive(msg1) receive(msg2) Seite: 14

15 Ordnungsgrade: FIFO-geordnet (2) Mögliches Konsistenzproblem durch Übertragung, die nicht den FIFO- Regeln entspricht P 1 P 2 P 3 P 4 P 5 send(msg1) receive(msg1) Zeit send(msg2) receive(msg2) receive(msg1) receive(msg1) receive(msg2) receive(msg2) receive(msg1) Das wäre eine Verletzung der FIFO-Ordnung! receive(msg2) Seite: 15

16 Ordnungsgrade: FIFO-geordnet (3) Konsistenzprobleme sind zudem trotz der FIFO-Ordnung möglich Beispiel bei 5 Gruppenmitgliedern mit Konsistenzproblemen: P 1 P 2 P 3 P 4 P 5 send(msg1) receive(msg1) send(msg2) Zeit Mögliches Problem! receive(p2, msg2) receive(p1, msg1) Seite: 16

17 Ordnungsgrade: Kausale Ordnung (1) Wenn eine Nachricht m a kausal abhängig von einer anderen Nachricht m b ist, erhalten alle Gruppenmitglieder m b vor m a Kausal unabhängige Nachrichten sind aber ungeordnet Es geht also um den Zusammenhang von Ereignissen - Ursache vor Wirkung - Kann auch anders wahrgenommen werden: Triebwerksgeräusch (Ursache) hört man erst, nachdem man ein Flugzeug schon gesehen hat (Wirkung) Definition: Kausalität (Quelle: Weber, M.: Verteilte Systeme, 1998) - Ereignisse: e 1, e 2, e 3 - e 1 < e 2 : e 2 ist kausal abhängig genau dann, wenn e 1 Auswirkungen auf e 2 haben kann - Zwei Ereignisse sind dann kausal unabhängig wenn weder e 1 < e 2 noch e 2 < e 1 gilt - Transitivität gilt auch - Die Relation < definiert hier eine partielle Ordnung (Halbordnung) auf der Menge der Ereignisse Seite: 17

18 Ordnungsgrade: Kausale Ordnung (2) Kausalitätserhaltende Ordnung ist auch eine FIFO-Ordnung Beispiel innerhalb eines sequentiell ablaufenden Prozesses: Kausal geordnete Sende- und Empfangsereignisse (s = Sendeereignis, r = Empfangsereignis): s1 < s2 < r1 < s3 < r2 P 1 s1 s2 r1 s3 r2 t Ankommende Nachricht Das Empfangen einer Nachricht ist kausal abhängig vom vorhergehenden Absenden derselben: s1 < r1, s2 < r2 und r1 < s2 s1 < r2 (Transitivität) P 1 r1 s2 Mögliche Abhängigkeit! Siehe auch Happened-Before-Relation! t P 2 s1 r2 Seite: 18

19 Ordnungsgrade: Kausale Ordnung (3) Beispiel mit 5 Gruppenmitgliedern für eine kausal geordnete Gruppenkommunikation: P 1 t P 2 P 3 P 4 P 5 Seite: 19

20 Ordnungsgrade: Kausale Ordnung (4) Beispiel mit 5 Gruppenmitgliedern für eine nicht kausal geordnete Gruppenkommunikation: P 1 t P 2 P 3 P 4 P 5 FIFO-Ordnung wäre aber hier erfüllt; hier trivial, da P1 und P2 jeweils nur eine Nachricht senden Seite: 20

21 Ordnungsgrade: Totale Ordnung Alle Gruppenmitglieder empfangen bei totaler Ordnung alle Nachrichten in der gleichen Reihenfolge Die Reihenfolge kann aber beliebig sein, sie muss nur für alle Gruppenmitglieder gelten Um totale (= globale) Ordnung zu erreichen, wird ein zusätzliches Ordnungskriterium eingeführt, z.b. eine globale eindeutige Prozess-Id Totale Ordnung ist sehr aufwändig zu implementieren In praktischen Fällen ist kausale Ordnung oder FIFO-Ordnung ausreichend Seite: 21

22 Variante: Zuverlässiger, aber nicht sortierter Multicast Bedeutung: - Virtuell synchron, - aber keine Garantien zur Ordnung bzw. Auslieferung der Nachrichten Beispiel: P 1 sendet zwei Nachrichten, die in unterschiedlicher Reihenfolge bei den Gruppenmitgliedern ankommen P 1 send(m1) send(m2) t P 2 P 3 Nachricht 1 kommt an: Nachricht 2 kommt an: Seite: 22

23 Variante: Zuverlässiger, FIFO-sortierter Multicast Bedeutung: - Virtuell synchron und - eingehende Nachrichten von demselben Prozess werden in derselben Reihenfolge ausgeliefert, in welcher der Prozess sie sendet Beispiel: P 1 sendet zwei Nachrichten, die in gleicher Reihenfolge bei den Gruppenmitgliedern ankommen P 1 send(m1) send(m2) t P 2 P 3 Nachricht 1 kommt an: Nachricht 2 kommt an: Aber: FIFO-Reihenfolge nicht global über alle Prozesse! Seite: 23

24 Variante: Zuverlässiger, kausal sortierter Multicast Bedeutung: - Virtuell synchron und - potenzielle (!) Kausalität zwischen den Nachrichten wird beibehalten Beispiel: P 1 und P 4 senden je zwei Nachrichten P 1 send(m1) send(m2) t P 2 m1 m3 m2 m4 P 3 P 4 send(m3) send(m4) Implementierung mit Vektor-Zeitstempeln möglich Seite: 24

25 Variante: Zuverlässiger, kausal sortierter Multicast Beispiel mit einer Verletzung der Kausalität, da P 2 Nachricht m3 vor m2 empfängt P 1 send(m1) send(m2) receive(m3) t P 2 receive (m1) m3 m2 P 3 P 4 receive(m2) send(m3) Seite: 25

26 Diskussion Message Queueing mit Publish Subscribe versus Gruppenkommunikation Vorteile, Gemeinsamkeiten, Unterschiede und Möglichkeiten der Kommunikationsmodelle diskutieren! Seite: 26

27 Überblick 1. Gruppenkommunikation, grundlegende Anforderungen 2. Semantik der Gruppenkommunikation 3. Implementierungsaspekte 4. Fallbeispiel: JGroups 5. Zusammenfassung Seite: 27

28 Implementierung Modell (1) Grundlegendes Modell der Implementierung auf einem System: - Ankommende Nachrichten gehen in eine Rückhaltewarteschlange - Auslieferungsbedingungen (Reihenfolge, Konsistenz) müssen erfüllt werden - Dann erst gehen Nachrichten in eine Auslieferungswarteschlange - Von dort aus Auslieferung an die Anwendung Seite: 28

29 Implementierung Modell (2) Eingangs- und Ausgangswarteschlangen einer Middleware zur Verarbeitung von Nachrichten zur Gruppenkommunikation Applikation Kommunikationsschicht Anwendung mit Nachrichtenverarbeitung Auslieferung Unterschied: Empfang und Auslieferung einer Nachricht! Betriebssystem Rückhalte- Warteschlange Auslieferungswarteschlange Pufferung möglich Wenn Auslieferungsgarantien erfüllt sind Eingehende Nachrichten werden empfangen Quelle: in Anlehnung an Coulouris (2012) Seite: 29

30 Implementierung Modell (3) Middlewareschicht Auf jedem Knoten läuft eine Instanz der Middleware mit mindestens zwei Diensten: send (multicast) und deliver Rechner 1 Rechner 2 Rechner n Anwendung Anwendung Anwendung send deliver send deliver send deliver Multicast- Middleware Zustellungslogik Multicast- Middleware Multicast- Middleware send send send receive receive receive Weitere Dienste: join, leave Netzwerk Seite: 30

31 Implementierung über Punkt-zu-Punkt-Nachrichten Implementierung abhängig vom Netzwerk Senden einer Multicast-Nachricht einzeln an alle Gruppenmitglieder - Einfach zu implementieren - Keine Garantie für die Ankunft der Nachrichten - Keine Ordnung - Ineffizient, da viele Nachrichten gesendet werden - Möglich über TCP oder UDP Je komplizierter die Anforderungen an den Ordnungsgrad und die Zuverlässigkeit, umso mehr muss man auf Punkt-zu- Punkt-Verbindungen zurückgreifen - Aber zusätzliche Funktionalität muss implementiert werden Seite: 31

32 Implementierung über vorhandene Multicast-Mechanismen Nutzung von im Netzwerk verfügbaren Mechanismen: Broadcast, Multicast - Beispiel: IP-Multicast über UDP-Sockets - Im WAN wird für das Multicasting noch IGMP (IGMPv6) benötigt Viel genutzt in OSPF, Web-Radio, IPTV - IPv6-Multicasting Auch diese Mechanismen reichen nur für die Implementierung von unzuverlässigen und ungeordneten Gruppenkommunikation aus Verbesserung der Zuverlässigkeit und/oder der Ordnung erfordert zusätzliche Mechanismen Seite: 32

33 Implementierung der Zuverlässigkeit, total geordneter Multicast Eindeutige Sequenznummern über alle Nachrichten erforderlich - Implementierung über eine Gruppenkommunikations-Middleware Pufferung beim Empfänger - Nachrichten erst an Anwendung geben, wenn fortlaufende Sequenznummern ohne Lücken vorhanden sind Generierung der Sequenznummern, drei Varianten: - Zeitstempel einer eindeutigen, gemeinsamen logischen oder physikalischen Uhr verwenden - Zentraler Sequencer, an den alle Nachrichten gesendet werden, nutzen (siehe Amoeba) - Spezielles Protokoll zur Abstimmung der Sequenznummern (z.b. über ein Token-basiertes Protokoll) Seite: 33

34 Implementierung Bestätigungen für einen zuverlässigen Multicast n Gruppenmitglieder n - 1 Bestätigungen, die beim Sender ankommen Bestätigungen könnten auch verloren gehen erneut senden Sender wird überschwemmt mit Bestätigungsnachrichten - Feedback-Implosion - Sendepuffer muss lange aufgehoben werden E 1 S ACK E 2 E n-1 Hohe Nachrichtenkomplexität, wie kann man zuverlässiges Multicasting skalierbar implementieren? Seite: 34

35 Implementierung Nicht hierarchische Feedback-Steuerung Optimierung des Bestätigungsverfahrens durch Reduktion der Bestätigungsnachrichten z.b. im SRM-Protokoll (Scalable Reliable Multicasting) - Nur fehlende Nachrichten werden gemeldet NAK an die ganze Gruppe - Empfänger verzögert aber seine NAK-Nachricht um eine zufällige Zeit und horcht auf NAK-Nachrichten anderer Gruppenmitglieder Ziel: Einsparung von NAK-Nachrichten - Nachteilig: Verzögerungen Timer-Behandlung bei großen Gruppen ist schwierig Weitere Verbesserung durch hierarchische Feedbacksteuerung Seite: 35

36 Implementierung Hierarchische Feedback-Steuerung Hierarchisches zuverlässiges Multicasting - Lokale Koordinatoren Geben Nachrichten weiter Übernehmen evtl. spätere erneute Anforderung - Beispiel: Vereinfacht mit nur einem Sender E S LAN K WAN-Verbindung K LAN W E = Empfänger K = Koordinator S = Sender W = Wurzel Quelle: Tanenbaum (2008) Seite: 36

37 Implementierung der virtuellen Synchronität Sender kann ausfallen, bevor alle Gruppenmitglieder seine Nachricht erhalten haben Sicht muss für alle gleich sein Alle Gruppenmitglieder bewahren die Nachricht auf, bis sie wissen, dass alle anderen sie sicher erhalten haben - Nur stabile Nachrichten dürfen an Anwendung ausgeliefert werden Monitoring und Synchronisation erforderlich - Jeder Prozess kann eine Sichtänderung (Ausfall eines Mitglieds) erkennen - Nachricht über Sichtänderung wird an alle gesendet - Daraufhin senden alle ihre Kopien aller instabilen Nachrichten an alle Mitglieder - Anschließend wird eine Flush-Nachricht gesendet Anzeige, dass nächste Sicht eingerichtet werden kann Dies ist nur eine Implementierungsvariante, man könnte z.b. auch mit Koordinatoren arbeiten Seite: 37

38 Überblick 1. Gruppenkommunikation, grundlegende Anforderungen 2. Semantik der Gruppenkommunikation 3. Implementierungsaspekte 4.Fallbeispiel: JGroups 5. Zusammenfassung Seite: 38

39 Überblick über vorhandene Lösungen ISIS (1986, Ken Birman), Folgesystem: Horus (Ken Birman u.a., 90er Jahre) - ISIS implementiert mehrere Multicast-Varianten CBCAST: Kausal geordneter Multicast auf Basis von Vektoruhren ABCAST: Total geordneter Multicast auf Basis eines zentralen Sequencers... - Wird wohl heute noch in der New Yorker Börse eingesetzt Ken Birman Professor of Computer Science Cornell University Java Groups = JGroups: Toolkit der offenen Java-Welt - Ursprünge auch an der Cornell University (Birman) - Entwickler: Bela Ban Seite: 39

40 Fallbeispiel JGroups Überblick JGroups ist ein Toolkit für die zuverlässige Multicast- Kommunikation Open-Source-Projekt stand unter GNU Lesser General Public Licence jetzt unter Apache Licence 2.0 ( Zuverlässiger Multicast, in Java implementiert Multicast-Schicht über verschiedenen Transportschichten realisiert Unterstützung von - zuverlässiger Übertragung in einer Gruppe - atomarem Multicast - total geordnetem Multicast Abstraktion: Channels (ähnlich wie Sockets) Seite: 40

41 Fallbeispiel JGroups Stack Konfigurierbarer Stack, in dem verschiedene vordefinierte Protokolle auf Basis eines Transportprotokolls oder eines höheren Protokolls (JMS) enthalten sein können Unterstützt mehrere Plattformen Gruppenmitgliedschaften verwalten Ordering-Protokolle (FIFO, kausal, total) Zuverlässige Übertragung im Unicast und Multicast, Retransmission, Mit Sequencer oder Token-basiert Fragmentierungsschicht UDP mit IP Multicast TCP JMS Auch Verschlüsselung kann konfiguriert werden TCP IP Siehe Seite: 41

42 Fallbeispiel JGroups Funktionen Überblick über die JGroups-Funktionalität - Gruppen können erzeugt und entfernt werden - Gruppen können über LAN und/oder WAN verteilt sein - Prozess zu Gruppe zuordnen und entfernen (join, leave) - Mitgliederüberwachung und Notifikation bei Eintritt, Austritt und bei einem Absturz eines Mitglieds - Entfernen von abgestürzten Mitgliedern - Senden von Gruppennachrichten - Senden von Einzelnachrichten (point-to-point) - Empfangen von Nachrichten über sog. Message-Listener (receive) Seite: 42

43 Fallbeispiel JGroups JGroups-API JGroups ist als Java-Package implementiert Um Gruppenmitglied zu werden, muss ein Anwendungsprozess einen Channel (Java-Bezeichnung: JChannel) erzeugen Die Eigenschaften eines Channels werden in einer Konfigurationsdatei festgelegt (XML-basiert) Anschließend muss ein connect-aufruf getätigt werden, in dem der Name der Gruppe angegeben wird Anwendung JChannel connect close JGroups Java-Klasse JGroups Java-Klasse JGroups Java-Klasse JGroups-Stack (konfigurierbar) Seite: 43

44 Fallbeispiel JGroups Codebeispiel // Codeausschnitt zum Erzeugen eines JGroup-Channels und // zum Verbinden mit einer Gruppe // Gruppe wird in JGroups Cluster genannt import org.jgroups.jchannel.*; public class MyClass { JChannel ch; } public static void main( ) { ch = new JChannel(); ch.connect( MyGroup ); } Channel erzeugen unconnected connect() disconnect() connected Zustandsautomat für einen JGroup-Channel close() closed close() Seite: 44

45 Fallbeispiel JGroups JGroups-Konfiguration XML-basierte Notation: Stack eingebettet in <config </config> <config> <UDP mcast_addr="${jgroups.udp.mcast_addr: }" mcast_port="${jgroups.udp.mcast_port:45588}" max_bundle_size="60000"... <PING timeout="2000 /> <pbcast.nakack use_mcast_xmit="false" gc_lag="0 retransmit_timeout="300,600,1200,2400,4800 discard_delivered_msgs="true"/> <UNICAST timeout="300,600,1200,2400,3600"/> <pbcast.stable stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/> <VIEW_SYNC avg_send_interval="60000" /> <pbcast.gms print_local_addr="true" join_timeout="3000" view_bundling="true"/> <FC max_credits=" " min_threshold="0.10"/> </config> Siehe JGroups-Manual Seite: 45

46 Fallbeispiel JGroups Einsätze JBoss Application Server - High-Availability-Lösung für Application-Server-Cluster - Failover von Session Beans (stateful, stateless) usw. - High-Availability JNDI - - JBoss EHCache - Caching-Lösung JBoss Instanz 1 JBoss Instanz 2 JGroups JBoss Instanz 3 JBoss Instanz 4 Partition Seite: 46

47 Überblick 1. Gruppenkommunikation, grundlegende Anforderungen 2. Semantik der Gruppenkommunikation 3. Implementierungsaspekte 4. Fallbeispiel: JGroups 5.Zusammenfassung Seite: 47

48 Zusammenfassung Es gibt viele Multicast-Ansätze - Je höher die Anforderungen an die Sortierung (Ordnungsgrad) und die Zuverlässigkeit, desto aufwändiger die Implementierung - Die Anwendung gibt die Vorgaben für die Implementierung Abgrenzung zu verteilten Transaktionen: - Zuverlässiger (atomarer) Multicast befasst sich mit dem verteilten Festschreiben der Auslieferung von Nachrichten - Verteilte Transaktionen befassen sich mit dem verteilten Festschreiben (Commit) von ganzen Transaktionen (mehrere Operationen) Diskussion: - Bedeutet Auslieferung einer Nachricht schon die erfolgreiche Verarbeitung? Seite: 48