Vierte Programmieraufgabe

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

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 5. Jan 2010 20:04

Ich bin mir noch nicht sicher, wie das gleichzeitige Ausführung von 2 Snapshots sich auf die Ergebnisse und Ablauf der Algorithmus auswirkt.
So lange ich das nicht ausgetestet habe, mache ich keine Aussagen mehr.
Aber einzelne Snapshots sollen richtige Ergebnisse liefern.
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
Fl4sh
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 138
Registriert: 1. Okt 2007 21:48

Re: Vierte Programmieraufgabe

Beitrag von Fl4sh » 5. Jan 2010 22:00

Sorry, das sollte nicht so doof rüberkommen, wie es das vielleicht tat. Es ist nur so, dass ich mich auf TK1 und die Themen gefreut habe, ich aber jetzt dauernd durch irgendwelche Kleinigkeiten enttäuscht werde. War echt nicht persönlich gemeint!

OK, dann meldet bei mir jetzt einfach der Empfänger den Erhalt des Geldes an die GUI. Dachte ich hätte vielleicht etwas wichtiges falsch verstanden/übersehen.

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

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 5. Jan 2010 22:17

:-) Aber ihr habt doch auch viel neues gelernt oder? Und es kommen außerdem noch ein Paar spannenden Themen und Aufgaben auf euch zu.
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
Fl4sh
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 138
Registriert: 1. Okt 2007 21:48

Re: Vierte Programmieraufgabe

Beitrag von Fl4sh » 5. Jan 2010 22:54

Hehe... Klar! ;)

Noch eine Frage: In der Aufgabenstellung steht
"Das komplette Programm wird über die GUI gestartet, in dem der GUI Prozess die JGroup anlegt. Dann werden die drei
Konten gestartet und treten der JGroup bei, um die Kommunikation zu ermöglichen."

Laut JGroup-Doku wird ein neuer JGroup-Channel mit dem Eintritt des ersten Mitglieds erstellt. Soll die GUI also ein Mitglied der Group sein? Wenn ja: Warum?
Ich frage deshalb, weil jeder Konto-Thread sein "channel = new JChannel()" initialisiert und dann mit channel.connect("channelname") beitritt. Geht das so, oder soll das wirklich umständlicher gemacht werden?

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

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 6. Jan 2010 00:12

Gegenfrage:
Angenommen jeder Kontomanager sowie Monitor laufen auf verschiedenen Rechnern (wir sind doch bei verteilten Systemen, oder).
Wie willst du denn, die Kontomanager und gesamte System überwachen?
Fl4sh hat geschrieben:"channel = new JChannel()" initialisiert und dann mit channel.connect("channelname") beitritt
Hast du deine Frage nicht selbst beantwortet?
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
dEeP-fRiEd
Kernelcompilierer
Kernelcompilierer
Beiträge: 432
Registriert: 19. Okt 2005 00:58
Wohnort: Darmstadt
Kontaktdaten:

Re: Vierte Programmieraufgabe

Beitrag von dEeP-fRiEd » 6. Jan 2010 13:39

RomanMertyn hat geschrieben:Gegenfrage:
Angenommen jeder Kontomanager sowie Monitor laufen auf verschiedenen Rechnern (wir sind doch bei verteilten Systemen, oder).
Wie willst du denn, die Kontomanager und gesamte System überwachen?
Oh, ich habe das GUI einfach per Observer-Pattern (also nicht per JGroups Kommunikation) informiert.
Bei Multicasts wär's natürlich kein Problem das GUI auch beitreten zu lassen. Aber Unicasts kämen dann ja nicht zur GUI durch.
Heißt das jetzt also, dass bei jedem Unicast ein zusätzlicher an das GUI geschickt wird (damit dieses den Transfer anzeigen kann!)?
NOSCE TE IPSUM
visit: http://www.flicknetwork.net.tc

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

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 8. Jan 2010 17:31

dEeP-fRiEd hat geschrieben:
RomanMertyn hat geschrieben:Gegenfrage:
Angenommen jeder Kontomanager sowie Monitor laufen auf verschiedenen Rechnern (wir sind doch bei verteilten Systemen, oder).
Wie willst du denn, die Kontomanager und gesamte System überwachen?
Oh, ich habe das GUI einfach per Observer-Pattern (also nicht per JGroups Kommunikation) informiert.
Bei Multicasts wär's natürlich kein Problem das GUI auch beitreten zu lassen. Aber Unicasts kämen dann ja nicht zur GUI durch.
Heißt das jetzt also, dass bei jedem Unicast ein zusätzlicher an das GUI geschickt wird (damit dieses den Transfer anzeigen kann!)?
Sie kämmen allerdings zum einen Teilnehmer, der die Informationen in dem GUI anzeigen würde. Mann muss sich allerdings überlegen wie man ein solcher Teilnehmer dann in der Gruppe identifiziert.

Ich habe übrigens schon die erste Abgabe erhalten, die die Anforderungen der Aufgabe absolut erfühlt. Auch mit den Multicast-Verteilung von Marker-Nachrichten. (Mehr Aufwand als ich gehofft habe, aber es funktioniert einwandfrei mit dem Standard-Stack)
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 » 8. Jan 2010 21:52

dEeP-fRiEd hat geschrieben: Heißt das jetzt also, dass bei jedem Unicast ein zusätzlicher an das GUI geschickt wird (damit dieses den Transfer anzeigen kann!)?
mir ist genau das auch noch nicht klar. Bisher habe ich der GUI durch Methodenaufruf mitgeteilt dass ein Geld-Transfer stattgefunden hat, diese hat dann auch wiederrum durch Methodenaufruf die Kontostände der entsprechenden Accounts abgefragt und sich aktualisiert.

Wenn ich nun per Unicast mitteilen will dass ein Transfer stattgefunden hat, dann müsste sich die GUI die Kontenstaende entweder selbst ausrechnen oder nochmal die Konten per Nachrichtenaustausch fragen. Irgendwie kommt mir das zu umstaendlich vor... wie solls denn sein??

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

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 8. Jan 2010 21:57

zu1u hat geschrieben:
dEeP-fRiEd hat geschrieben: Heißt das jetzt also, dass bei jedem Unicast ein zusätzlicher an das GUI geschickt wird (damit dieses den Transfer anzeigen kann!)?
mir ist genau das auch noch nicht klar. Bisher habe ich der GUI durch Methodenaufruf mitgeteilt dass ein Geld-Transfer stattgefunden hat, diese hat dann auch wiederrum durch Methodenaufruf die Kontostände der entsprechenden Accounts abgefragt und sich aktualisiert.

Wenn ich nun per Unicast mitteilen will dass ein Transfer stattgefunden hat, dann müsste sich die GUI die Kontenstaende entweder selbst ausrechnen oder nochmal die Konten per Nachrichtenaustausch fragen. Irgendwie kommt mir das zu umstaendlich vor... wie solls denn sein??
Wie wäre es denn, wenn du dem GUI einfach den aktuellen Stand nach jeder Transaktion per Unicast mitteilst?
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
Fl4sh
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 138
Registriert: 1. Okt 2007 21:48

Re: Vierte Programmieraufgabe

Beitrag von Fl4sh » 11. Jan 2010 01:11

Es stellt sich eben bei Unicasts die Frage woher ein Konto weiß, was ein anderes Konto ist oder was die GUI ist.
Insb. wenn man "theoretisch" mehrere GUIs unterstützen sollte. (Wegen verteilte Systeme und so ;))

Ich möchte nochmal zusammenfassen, weil ich irgendwie Angst habe etwas falsch verstanden zu haben.
Ein Konto führt einen Snapshot aus, und verschickt per Multicast die Snapshot-Marker. Die jeweiligen anderen Kontos empfangen die Anfrage, speichern den aktuellen State (also hier den Kontostand) und recorden die Verbindungen zu den anderen Konten bis von diesen auch ein Snapshot-Marker empfangen wurde. Bis hierhin ist es ja ganz klar... Jetzt müssen die States aber auch zum Initiator des Snapshots verschickt werden. Hierfür verschicken wir in den Snapshot-Markern die Initiator-Adresse mit.
Ein einzelnes Konto kann seinen gespeicherten State "vergessen", also den Snapshot als erledigt ansehen, wenn es von allen anderen Konten auch einen Snapshot-Marker bekommen hat. (Also alle Recordings gestoppt wurden). Die Recordings müssen dann auch noch an den Initiator geschickt werden.
Problem Nr. 1: Die GUI ist auch im JGroups-Channel eingetragen. Woher weiß ein Konto hinter welcher Adresse ein Konto oder die/eine GUI steckt? Das Konto würde also theoretisch ewig einen toten Kanal zur GUI überwachen. Bisherige Lösung: Die GUI agiert wie ein Konto und antwortet bei einem Snapshot-Marker einfach mit einem.
Das Initiator-Konto des Snapshots wartet nun also bis es von jedem anderen Konto einen State empfangen hat und jeweilige (auch leere) Recodings. Leere Recordings, da der Initiator ja sonst nicht weiß ob irgendwann noch ein Recording kommt... (auch hier gibt es die Problematik mit der GUI.) Hat der Initiator alle Infos erhalten kann er die Recordings mit den States verarbeiten und kennt nun die gültigen Zustände des Gesamtsystems. Diese Daten werden nun (auch über JGroups) an die GUI übermittelt.

Wir haben nun noch folgende Problematik: Unicast-Messages überholen Multicast-Messages. Daher wollten wir ausschließlich Multicasts verwenden und den Empfänger in die Message schreiben. Die Empfänger entscheiden dann, ob die Nachricht relevant für sie ist.
Das widerspricht jedoch dieser Anforderung:
"Kommunikation über JGroups: Marker messages als Multicast (außer zur Initialisierung) und Kontobewegungen
als Unicast"

Und was ist genau mit "Initialisierung" gemeint?

Danke schonmal! :)

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

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 11. Jan 2010 01:27

Fl4sh hat geschrieben: Problem Nr. 1: Die GUI ist auch im JGroups-Channel eingetragen. Woher weiß ein Konto hinter welcher Adresse ein Konto oder die/eine GUI steckt? Das Konto würde also theoretisch ewig einen toten Kanal zur GUI überwachen.
Lässt sich ganz einfach mit dem JChannel.setName(String) vor dem JChannel.connect(String) umgehen.

Oder einfach sicherstellen, dass GUI-steuernde Knoten als erster gestartet wird und dann an den JChannel.getView().getMembers().firstElement() die entsprechende Nachrichten verschicken.
Fl4sh hat geschrieben: Wir haben nun noch folgende Problematik: Unicast-Messages überholen Multicast-Messages. Daher wollten wir ausschließlich Multicasts verwenden und den Empfänger in die Message schreiben. Die Empfänger entscheiden dann, ob die Nachricht relevant für sie ist.
Das widerspricht jedoch dieser Anforderung:
"Kommunikation über JGroups: Marker messages als Multicast (außer zur Initialisierung) und Kontobewegungen
als Unicast"
Implementiert an der Stelle von Multicast ein B-Multicast an der Stellen wo es gefordert wird.
Fl4sh hat geschrieben: Und was ist genau mit "Initialisierung" gemeint?
Eventuelle Verteilung von gemeinsamen Geldmenge. Was anderes fehlt mir so auf die schnelle nicht ein.

Ich sitze gerade an der Musterlösung. Also verfolgt diesen Thread und "Mutlicastet" die Nachrichten an die Kommilitonen. :D
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
Fl4sh
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 138
Registriert: 1. Okt 2007 21:48

Re: Vierte Programmieraufgabe

Beitrag von Fl4sh » 11. Jan 2010 01:58

RomanMertyn hat geschrieben:
Fl4sh hat geschrieben: Problem Nr. 1: Die GUI ist auch im JGroups-Channel eingetragen. Woher weiß ein Konto hinter welcher Adresse ein Konto oder die/eine GUI steckt? Das Konto würde also theoretisch ewig einen toten Kanal zur GUI überwachen.
Lässt sich ganz einfach mit dem JChannel.setName(String) vor dem JChannel.connect(String) umgehen.
Jetzt steh ich echt auf dem Schlauch... mit setName(String) gebe ich dem Channel doch einen Namen, nicht aber dem "Prozess", der sich connected? Oder soll garnicht alles über einen Channel laufen? D.h. ein Konto verbindet sich mit zwei "Gruppen": Eine in der alle anderen Konten sind und eine in der sich die GUI befindet?

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

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 11. Jan 2010 02:00

Schau dir noch mal die jdoc von JGroups an. Ich glaube du verstehst die Funktionalität hinter dem JChannel falsch.
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

vinzenz
Neuling
Neuling
Beiträge: 9
Registriert: 22. Okt 2009 00:35

Re: Vierte Programmieraufgabe

Beitrag von vinzenz » 11. Jan 2010 02:28

hi

ich seh die ganze diskussion erst jetzt, sollte wohl öfters mal ins forum schauen ^^.

das problem mit der fifo ordnung hatte ich ebenfalls. ich denke aber nicht, dass das ein bug ist. vielmehr liegen die sequenznummern auf einer höheren ebene im protokollstack, nachdem dieser sich bereits in multicast und unicast aufgeteilt hat. sie laufen also getrennt voneinander: unicast und multicast messages sind jeweils in fifo ordnung, aber zusammen nicht. das hängt auch damit zusammen, dass man pro sender keine enheitliche sequenznummer für beides verwenden kann. ein sender schicke beispielsweise einen multicast mit nummer 5, danach aber einen unicast an einen einzelnen knoten (logischweise mit nummer 6). welche nummer vergibt der selbe sender für seinen nächsten multicast? ein knoten erwartet die 7, alle anderen eine 6...
dieses dilemma lässt sich nicht so leicht umgehen. also habe ich mit meinem übungspartner entschieden, die fifo ordnung einfach selbst herzustellen. dazu fügt man der nachricht einen eigenen header hinzu, der bei einem unicast unsere eigene sequenznummer enthält. für einen multicast muss jeder empfänger "seine" nächste sequenznummer mitgeschickt bekommen (über eine hashmap von addressen auf sequenznummern im header). is halt ein bisl aufwand, weil man eine liste aller anderen knoten speichern muss, dazu für jeden eine sequenznummer und eine warteschlange. damit muss in der receive funktion die nummer überprüft werden und die nachrichten in der richtigen reihenfolge an eine deliver funktion weitergegeben werden, die die eigentliche funktionalität enthält.
für die warteschlangen empfiehlt sich ein ConcurrentSkipListSet, damit kann man die nachrichten über einen eigenen comparator nach sequenznummern sortieren.
eine liste aller anderen konten kann man sich mit der viewAccepted methode halten. ich bin davon ausgegangen, dass es nur einen observer gibt und dieser die gruppe erstellt hat, dann gibt view.getCreator dessen addresse. nimmt man noch die eigene addresse raus, hat man eben alle anderen konten.

der fall von mehreren observern sollte, glaube ich, laut aufgabenstellung gar nicht behandelt werden, oder? zumindest ginge das, wenn man den observern zur identifikation mit channel.setName eigene namen gibt ("observer 1", ...), dann kann man theoretisch auch über diese eine liste führen und sie über alle transaktionen benachrichtigen etc. das haben wir jetz aber nicht umgesetzt.

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

Re: Vierte Programmieraufgabe

Beitrag von RomanMertyn » 11. Jan 2010 02:32

vinzenz hat geschrieben: der fall von mehreren observern sollte, glaube ich, laut aufgabenstellung gar nicht behandelt werden, oder?
Stimmt
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

Antworten

Zurück zu „Archiv“