Vierte Programmieraufgabe

Benutzeravatar
EwigerGast
Mausschubser
Mausschubser
Beiträge: 59
Registriert: 22. Jun 2005 19:14

Vierte Programmieraufgabe

Beitrag von EwigerGast » 9. Dez 2009 11:01

Soll das ganze auf einem Rechner laufen oder auf mehreren?
It took 3 C-64 to fly to the Moon, but it takes a Pentium to run Windows ;)

Benutzeravatar
EwigerGast
Mausschubser
Mausschubser
Beiträge: 59
Registriert: 22. Jun 2005 19:14

Re: Vierte Programmieraufgabe

Beitrag von EwigerGast » 9. Dez 2009 16:35

Update:

Ich frage deshalb:

Wenn auf einem Rechner drei Threads laufen, tritt folgendes Problem auf: Angenommen t1 schickt einen Multicast per jgroups. Die Netzwerkkarte empfaengt den Multicast und leitet ihn an den aktuell laufenden Thread (t1) weiter. Die anderen Threads (t2, t3) haben keine Moeglichkeit an diese Nachricht heranzukommen. Dieses Problem wuerde auf verschiedenen Rechnern nicht auftreten.

Die Entwicklung des Programmes an drei Rechnern gleichzeitig gestaltet sich bisher als schwierig.

Hat schon jemand eine Loesung fuer dieses Problem gefunden?
It took 3 C-64 to fly to the Moon, but it takes a Pentium to run Windows ;)

Benutzeravatar
Mergian
Mausschubser
Mausschubser
Beiträge: 48
Registriert: 7. Feb 2008 11:41

Re: Vierte Programmieraufgabe

Beitrag von Mergian » 9. Dez 2009 20:46

Um ehrlich zu sein, weiß ich nicht genau wie JGroups intern agiert, aber ich habe nicht das Problem.

Habe 3 Threads die alle mit dem Channel verbunden sind und interne Adressen haben "MeinPC-123456" <-- werden von JGroups generiert.

Multicast über channel.send(new Message(null,channel.getLocalAddress(),"MESSAGE")); fertig. Der zweite Parameter ist nicht nötig, kann auch null sein, jedoch weiß man dann, vonwem der Multicast kommt.

RomanMertyn
Mausschubser
Mausschubser
Beiträge: 71
Registriert: 7. Jun 2006 18:47
Wohnort: Darmstadt
Kontaktdaten:

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 10. Dez 2009 17:46

EwigerGast hat geschrieben:Update:

Ich frage deshalb:

Wenn auf einem Rechner drei Threads laufen, tritt folgendes Problem auf: Angenommen t1 schickt einen Multicast per jgroups. Die Netzwerkkarte empfaengt den Multicast und leitet ihn an den aktuell laufenden Thread (t1) weiter. Die anderen Threads (t2, t3) haben keine Moeglichkeit an diese Nachricht heranzukommen. Dieses Problem wuerde auf verschiedenen Rechnern nicht auftreten.

Die Entwicklung des Programmes an drei Rechnern gleichzeitig gestaltet sich bisher als schwierig.

Hat schon jemand eine Loesung fuer dieses Problem gefunden?
Wenn dies auftriet ist der Protocol Stack von JGroups falsch konfiguriert. Ein Multicast soll grundsätzlich immer alle Knoten erreichen, die in einer Gruppe sind.
Ich werde die Loesungen auf jeden Fall nur auf einem Rechner testen.
Es ist auf jeden Fall sinnvoll, sich die Beispiele von Anwendungen anzusehen, die mit JGroups mitgeliefert werden. (Stichworte: MessageListener, GroupChangeListener)
There are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
C.A.R. Hoare

zu1u
Mausschubser
Mausschubser
Beiträge: 64
Registriert: 6. Nov 2006 20:14

Re: Vierte Programmieraufgabe

Beitrag von zu1u » 16. Dez 2009 23:11

Sollen denn mehrer Prozesse überlappend ein snapshot-taking initiieren können?
Oder können wir davon ausgehen, dass kein weiterer snapshot von einem der Prozesse angefordert wird, solange noch einer erstellt wird?

wie sieht es außerdem mit der Anforderung "Die Nachrichten müssen in der richtigen Reihenfolge beim Empfänger bearbeitet werden" aus
geht es dabei darum, dass der Algorithmus die folgenden Assumptions hat?
- perfect communication: no loss, corruption, reordering or duplication of
messages occurs, and messages sent will eventually be delivered
- unidirectional FIFO channels

müssen wir dazu eine extra Protocol Stack Configuration verwenden oder reicht dafür die 'default'?

Benutzeravatar
MisterD123
Geek
Geek
Beiträge: 811
Registriert: 31. Okt 2006 20:04
Wohnort: Weiterstadt

Re: Vierte Programmieraufgabe

Beitrag von MisterD123 » 17. Dez 2009 13:14

Unicast-Nachrichten überholen im Standard-Setup die Multicast-Nachrichten. Das Problem *sollten* wir durch konfigurieren eines Protokollstack lösen, aber es ist sich zur Zeit keiner mehr sicher, ob das möglich ist. Mein Tipp: Entwickle zunächst mit dem Standard-Protokoll-Stack (der bereits reliable FIFO für unicast channel garantiert) und führe multicasts durch multiple unicasts durch. Roman wird im Forum vermutlich demnächst noch etwas zu dem Thema posten, wenn er mehr weiß. die Aufgabe ist neu und wir haben dieses Problem ihm gestern erst nahegebracht. Solltest du's aber schaffen, nen passend konfigurierten Protokoll-Stack zu basteln, sag mal bescheid ;) aber uns wurde gesagt, wir sollen uns da erstmal keine großen gedanken drüber machen.

Benutzeravatar
Tigger
Kernelcompilierer
Kernelcompilierer
Beiträge: 404
Registriert: 26. Okt 2007 17:35
Wohnort: Hofheim
Kontaktdaten:

Re: Vierte Programmieraufgabe

Beitrag von Tigger » 22. Dez 2009 12:04

MisterD123 hat geschrieben:Mein Tipp: Entwickle zunächst mit dem Standard-Protokoll-Stack (der bereits reliable FIFO für unicast channel garantiert) und führe multicasts durch multiple unicasts durch.
Allerdings ist dann die Verwendung von jGroups sinnlos, denn reliable FIFO ist auch schon für unicasts über tcp garantiert. Außerdem widerspräche die Implementierung eines Multicasts durch multiple unicasts dem, was wir in der Vorlesung gelernt haben. Eine andere Möglichkeit wäre ausschließlich Multicasts zu verwenden und jede Nachricht mit einer ReciverID auszustatten, damit der Empfänger sie sich raus fischen kann.
Der JBoss Issue Tracker empfiehlt genau dieses Vorgehen: http://jira.jboss.org/jira/browse/JBMESSAGING-868

Benutzeravatar
MisterD123
Geek
Geek
Beiträge: 811
Registriert: 31. Okt 2006 20:04
Wohnort: Weiterstadt

Re: Vierte Programmieraufgabe

Beitrag von MisterD123 » 22. Dez 2009 19:11

ja in der Aufgabenstellung steht Multicasts für Marker-Nachrichten, allerdings steht da auch Unicast für Transfer-Nachrichten. Ich wollte nicht sagen, dass das eine alternative gute oder richtige Implementierung ist, sondern die einfachste Möglichkeit, das Problem der überholt werdenden Multicasts zu lösen ohne gleich irgendwelche großartigen Algorithmen zu implementieren. Alles über Multicast zu senden ist natürlich genauso möglich, aber da find ich einfach den Multicast durch ein simples for(Address adr : channel.getView().getMembers()) channel.send(adr, ..); noch einfacher.

Wie gesagt Roman wollte sich das mal anschauen und dann weitere Infos dazu posten, solange würd ich mir halt nen möglichst einfachen workaround für das Problem suchen; von Endversion war ja noch nie die rede.

RomanMertyn
Mausschubser
Mausschubser
Beiträge: 71
Registriert: 7. Jun 2006 18:47
Wohnort: Darmstadt
Kontaktdaten:

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 25. Dez 2009 21:09

Ich habe mir eine Lösung ausgearbeitet, die die Nachrichten in der richtigen Reihenfolge ausliefert. Bitte testen und die Ergebnisse posten.

Im Anhgang ist ein Src-Ordner ohne(!!!) JGroups. Implementiert sind ein Sender, der abwechselnd Multicast- und Unicast-Nachrichten sendet, und ein Empfänger, der den Empfang der Nachrichten in der Console quitiert. Simulation startet einen Empfänger und 3 Sender. Die Nachrichten sollten in den richtigen (testen !!!) Reihenfolge beim Empfänger ankommen.

Konfiguration der Channel könnt ihr in der Klasse AbstractNode ablesen.

Für die Richtigkeit keine Haftung :roll:

Ansonsten Guten Rutsch!!!
Dateianhänge
JGroupsTestConfiguration.rar
(3.25 KiB) 53-mal heruntergeladen
There are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
C.A.R. Hoare

Benutzeravatar
MisterD123
Geek
Geek
Beiträge: 811
Registriert: 31. Okt 2006 20:04
Wohnort: Weiterstadt

Re: Vierte Programmieraufgabe

Beitrag von MisterD123 » 26. Dez 2009 00:40

Ich habe deinen Configuration-String einfach mal in unseren bisher nur mit multiplen Unicasts funktionierenden Algorithmus eingebaut und die mehreren Unicasts wieder durch einen einzelnen Multicast ersetzt, und meine Testbench, welche im 3-Sekundentakt den Snapshot ausführt bis der Snapshot eine falsche Summe an Geld im System findet, lief einige Messungen lang fehlerfrei, doch brach dann wieder ab:

Code: Alles auswählen

1261782846 Causing Bob (Kellerkind-29389) to issue next Recording.
1261782846 Recording done. Evaluating results: Invalid sum of money!
Muting brokers.
=============================
Recording report:
 - Process Kellerkind-59096 holding 1368
   - Channel Kellerkind-59096 to Kellerkind-29389:  Channel total: 0
   - Channel Kellerkind-59096 to Kellerkind-22422:  Channel total: 0
   - All outgoing channels from Kellerkind-59096 total: 0
 - Process Kellerkind-29389 holding 1458
   - Channel Kellerkind-29389 to Kellerkind-59096:  Channel total: 0
   - Channel Kellerkind-29389 to Kellerkind-22422:  Channel total: 0
   - All outgoing channels from Kellerkind-29389 total: 0
 - Process Kellerkind-22422 holding 374
   - Channel Kellerkind-22422 to Kellerkind-59096: 115,7, Channel total: 122
   - Channel Kellerkind-22422 to Kellerkind-29389: 76,52,5, Channel total: 133
   - All outgoing channels from Kellerkind-22422 total: 255
Recorded sum of money in the system: 3455
In der letzten Zeile ersichtlich: Der Snapshot hat eine Geldsumme von 3455 gemessen, jeder Broker wurde aber nur mit 1111 gestartet, es gibt also nur 3333 geld eigentlich im System.

Muting Brokers in der dritten Zeile heißt so viel wie die einzelnen Prozesse wurden angewiesen, keine Transfers mehr zu machen. Kurz danach ist relativ sichergestellt, dass alle channels leer sind, also das überholen der Nachrichten den Algorithmus nicht mehr kaputt machen kann, da nurnoch der Status der einzelnen Prozesse aufsummiert werden muss. Drei Sekunden später startet meine Testumgebung dann also den Algorithmus erneut:

Code: Alles auswählen

1261782849 Causing Bob (Kellerkind-29389) to issue next Recording.
1261782849 Recording done. Evaluating results: Valid sum of money!
Killing brokers.
=============================
Recording report:
 - Process Kellerkind-59096 holding 1797
   - Channel Kellerkind-59096 to Kellerkind-29389:  Channel total: 0
   - Channel Kellerkind-59096 to Kellerkind-22422:  Channel total: 0
   - All outgoing channels from Kellerkind-59096 total: 0
 - Process Kellerkind-29389 holding 1061
   - Channel Kellerkind-29389 to Kellerkind-59096:  Channel total: 0
   - Channel Kellerkind-29389 to Kellerkind-22422:  Channel total: 0
   - All outgoing channels from Kellerkind-29389 total: 0
 - Process Kellerkind-22422 holding 475
   - Channel Kellerkind-22422 to Kellerkind-59096:  Channel total: 0
   - Channel Kellerkind-22422 to Kellerkind-29389:  Channel total: 0
   - All outgoing channels from Kellerkind-22422 total: 0
Recorded sum of money in the system: 3333
Wie zu sehen ist, die Channels sind leer und alle Prozesse zusammen halten aber immernoch 3333 Geldeinheiten in Summe, also war der Algorithmus mit dem Multicast an irgendeiner stelle fehlerhaft.

Dieser Fehler ist reproduzierbar solange ich deinen Protokollstack und Multicasts verwende, das ist derselbe fehler, der auch mit dem Standard-Protokollstack auftritt. Sobald ich den Multicast aber wieder durch multiple Unicasts ersetze läuft meine Testumgebung ewig ohne einen Fehler zu finden (mein "rekord" liegt bei etwa einer halben stunde, ich habe die testläufe natürlich immer von hand irgendwann abgebrochen weil sie eben nie einen fehler finden werden), was mich darauf schließen lässt, dass auch dein Protkoll-Stack das Überholen der Nachrichten nicht verhindert.

Ich habe mir auch nochmal die udp.xml angeschaut: Die Protokollschichten, die du verwendest, stehen in exakt der selben reihenfolge auch in der standard-konfiguration für JChannels, nur dass die standardkonfiguration noch einige zusätzliche Protkollschichten dazwischen hat. Von daher vermute ich, dass dein Protokoll-Stack einfach nur ein gutes stück schneller arbeitet als die Standardkonfiguration, und deshalb der Fall ganz einfach weniger oft eintrifft.

Die Messungen, die mein System mit Standard-Protokoll-Stack und multicasts fehlerhaft aufnimmt fallen auch wesentlich schlimmer aus (da werden aus den 3333 plötzlich 60000 geldeinheiten statt nur 3500 oder mal 5000, was auf wesentlich längere übertragungszeiten für die Multicasts deutet), und meistens direkt bei der ersten messung, was mich in dieser Vermutung bestärkt.

Von daher: Ich bin mir sehr sicher, dass du noch keine Lösung für das Problem gefunden hast, sondern nur sein auftreten unwahrscheinlicher gemacht hast durch verringerte Verzögerungszeiten bei den Multicasts.

RomanMertyn
Mausschubser
Mausschubser
Beiträge: 71
Registriert: 7. Jun 2006 18:47
Wohnort: Darmstadt
Kontaktdaten:

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 28. Dez 2009 21:40

Ja, du hast Recht. Unterm geringfügig gesteigertem Last habe ich wieder das Problem. Versuche es mal mit dem frischen Version von JGroups 2.8 (21.12.2009). Ansonsten greifen wir auf B-Multicast zurück.
There are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
C.A.R. Hoare

Benutzeravatar
MisterD123
Geek
Geek
Beiträge: 811
Registriert: 31. Okt 2006 20:04
Wohnort: Weiterstadt

Re: Vierte Programmieraufgabe

Beitrag von MisterD123 » 29. Dez 2009 18:15

Tests mit JGroups 2.8.0

Also Standard-Protokollstack, direkt die erste Messung:
"Recorded sum of money in the system: 9519"

und dein Protokollstack, zweite Messung (erste war noch richtig):
"Recorded sum of money in the system: 3901"

B-Multicast (also multiple unicasts) mit Standard-Protokollstack: funktioniert.

Also genau das selbe Problem. ;(

Benutzeravatar
Fl4sh
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 138
Registriert: 1. Okt 2007 21:48

Re: Vierte Programmieraufgabe

Beitrag von Fl4sh » 5. Jan 2010 18:23

Wie sieht denn jetzt die "Lösung" aus? Ich find das langsam ein wenig komisch... Übungen die aus der Wertung fallen, Klausuren mit Themen, die nicht in der Vorlesung drankame. Jetzt Übungen die nicht wirklich gehen... :(

Aber ok, ich habe auch eine Frage (zum bereits bekanntne Problem):

Wie bekommt die GUI die Veränderungen der Überweisungen für die Log mit? Meldet das der Empfänger des Geldes oder der Sender?

RomanMertyn
Mausschubser
Mausschubser
Beiträge: 71
Registriert: 7. Jun 2006 18:47
Wohnort: Darmstadt
Kontaktdaten:

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 5. Jan 2010 18:53

Fl4sh hat geschrieben:Wie sieht denn jetzt die "Lösung" aus? Ich find das langsam ein wenig komisch... Übungen die aus der Wertung fallen, Klausuren mit Themen, die nicht in der Vorlesung drankame. Jetzt Übungen die nicht wirklich gehen... :(
Die Übungen die nicht gehen - finde ich übertrieben.
Ich möchte mich zwar dafür entschuldigen, allerdings müsst ihr auch zugeben, dass dieses spezielles Problem noch nicht mal unter den offenen Bugs auftaucht.
Fl4sh hat geschrieben: Aber ok, ich habe auch eine Frage (zum bereits bekanntne Problem):
Wie bekommt die GUI die Veränderungen der Überweisungen für die Log mit? Meldet das der Empfänger des Geldes oder der Sender?
Das bleibt dir überlassen. Das ist übrigens ein gutes Thema für eine Diskussion über Transaktionsverwaltung in verteilten Systemen (allgemein, nicht auf die Aufgabe bezogen).
There are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
C.A.R. Hoare

zu1u
Mausschubser
Mausschubser
Beiträge: 64
Registriert: 6. Nov 2006 20:14

Re: Vierte Programmieraufgabe

Beitrag von zu1u » 5. Jan 2010 19:46

zu1u hat geschrieben:Sollen denn mehrer Prozesse überlappend ein snapshot-taking initiieren können?
Oder können wir davon ausgehen, dass kein weiterer snapshot von einem der Prozesse angefordert wird, solange noch einer erstellt wird?
wie sieht es mit dieser Frage aus?

Antworten

Zurück zu „Archiv“