should send datagrams with multicast

https://docs.oracle.com/javase/tutorial/networking/datagrams/broadcasting.html

Die Textzeilen werden vom Server durchnummeriert (beginnend bei 1) und stellen eine eindeutige ID für jede Textzeile dar. Ein Redakteur-Client hat sich beim Server vor dem Versenden einer Textzeile diese Nummer zu besorgen und in der Zustellung seiner Nachricht an den Server diese Nummer der Textzeile voranzustellen.
Da die dem Server zugestellten Textzeilen bzgl. der Nummerierung in zusammenhängender Reihenfolge erscheinen sollen und Nachrichten mit Textzeilen verloren gehen können bzw. in nicht sortierter Reihenfolge eintreffen können, arbeitet der Server intern mit einer Deliveryqueue (DLQ) und einer Holdbackqueue (HBQ).
In der Deliveryqueue stehen die Nachrichten, die an Clients ausgeliefert werden können, maximal *** viele Textzeilen. Dies wird durch die Größe der Deliveryqueue vorgegeben.
In der Holdbackqueue stehen alle Textzeilen, die nicht ausgeliefert werden dürfen.
Der Server fügt einer empfangenen Nachricht der Zeichenkette jeweils die Empfangszeit beim Eintrag in die Holdbackqueue und die Übertragungszeit beim Eintrag in die Deliveryqueue hinten/rechts mittels werkzeug:timeMilliSecond() an. Zudem fügt er dieser Nachrichten-Liste diese Zeitstempel mittels erlang:now() am Ende hinzu.
Ein Leser-Client bekommt auf Anfrage gemäß Nachrichtennummerierung eine noch nicht an ihn ausgelieferte und beim Server bekannte Textzeile geliefert. In einem Flag wird ihm mitgeteilt, ob es noch weitere, für ihn unbekante Nachrichten gibt. Zudem wird ihm explizit die Nummer dieser Nachricht übermittelt. Wenn der Leser-Client nach neuen Nachrichten beim Server anfragt, dort jedoch keine neuen bzw. überhaupt noch keine Nachrichten vorhanden sind, sendet der Server eine nicht leere dummy-Nachricht.
Ein Leser-Client, der seit ** Sekunden keine Abfrage mehr gemacht hat, wird beim Server vergessen. Bei einer erneuten Abfrage (nach dem Vergessen) wird er wie ein unbekannter Leser-Client behandelt.
Wenn in der Holdbackqueue von der Anzahl her mehr als 2/3-tel an echten Nachrichten enthalten sind, als durch die vorgegebene maximale Anzahl an Nachrichten in der Deliveryqueue stehen können, dann wird, sofern eine Lücke besteht, diese Lücke zwischen Deliveryqueue und Holdbackqueue mit genau einer Fehlernachricht geschlossen, etwa: ***Fehlernachricht fuer Nachrichtennummern 11 bis 17 um 16.05 18:01:30,580|. Es werden keine weiteren Lücken innerhalb der Holdbackqueue behandelt! In dem Sinne wird die Holdbackqueue in diesem Fall nicht zwingend geleert. Die Fehlernachrciht ist nur durch eine entsprechende Zeichenkette in der Nachricht zu erkennen. Ansonsten hat sie das Format einer ganz normalen Nachricht, d.h. das System kann eine Fehlernachricht nach Speicherung in der DLQ nicht mehr als solche erkennen!
Der Server terminiert sich, wenn die Differenz von aktueller Systemzeit und Zeit der letzten Abfrage eines Clients länger als seine Wartezeit beträgt, d.h. seine Wartezeit wird durch Abfragen der Clients erneut gestartet bzw. bestimmt die maximale Zeit, die der Server ungenutzt läuft.
Der Server verwendet drei ADTs: HBQ (Datei hbq.erl), DLQ (Datei dlq.erl) und CMEM (Datei cmem.erl) als Gedächtnis für die Leser-Clients. Diese dürfen hauptsächlich nur als Erlang-Liste ([ ]) realisiert werden! Als Hilfsstrukturen dürfen Tupel eingesetzt werden. Dazu sind die weiter unten aufgeführten Vorgaben zu beachten!
Die HBQ ist als entfernte ADT zu implementieren. Ihre Schnittstelle ist daher durch Nachrichtenformate beschrieben. Die DLQ oder das CMEM sind als lokale ADT zu implementieren. Daher sind deren Schnittstellen durch Funktionen beschrieben. Intern kann die DLQ bzw. das CMEM jedoch als externer Prozess realisiert werden!
Der Server ist in Erlang/OTP zu implementieren und muss auf jedem Rechner im Labor startbar sein! Bei der Verwendung von Eclipse kann das problematisch sein. Die steuernden Werte sind in einer Datei server.cfg anzugeben. Der Server ist unter einem Namen im lokalen Namensdienst von Erlang zu registrieren (register(,ServerPid)).

m Folgenden wird die Schnittstelle des Servers für einen Client beschrieben.

            /* Abfragen einer Nachricht */
            Server ! {self(), getmessages}
            receive {reply,[NNr,Msg,TSclientout,TShbqin,TSdlqin,TSdlqout],Terminated} 
            Beispiel:  Server ! {<7016.50.0>, getmessages}
                              receive {reply,[15,  "0-pclient@KI-VS-<0.64.0>-KLC: 15te_Nachricht. C Out: 29.04 08:43:24,871| HBQ In: 29.04 08:43:24,879|  DLQ Out: 29.04 08:43:35,551| ", {1430,289804,872001}, {1430,289804,880000}, {1430,289804,880003},  {1430,289815,551001}],true}

            /* Senden einer Nachricht */
            Server ! {dropmessage,[INNr,Msg,TSclientout]},
            Beispiel:  Server ! {dropmessage,[93, "0-pclient@KI-VS-<0.64.0>-KLC: 93te_Nachricht. C Out: 29.04 08:43:38,569|", {1430,289818,569001}]}

            /* Abfragen der eindeutigen Nachrichtennummer */
            Server ! {self(),getmsgid}
            receive {nid, Number} 
            Beispiel:  Server ! {<7016.50.0>, getmsgid}
                             receive {nid, 42}

getmessages: Fragt beim Server eine aktuelle Textzeile ab. self() stellt die Rückrufadresse des Leser-Clients dar. Als Rückgabewert erhält er eine für ihn aktuelle Textzeile (Zeichenkette) zugestellt (Msg) und deren eindeutige Nummer (NNr). Zudem erhält er die Zeitstempel explizit (erstellt durch erlang:now(),TSclientout,TShbqin,TSdlqin,TSdlqout).Mit der Variablen Terminated signailiert der Server, ob noch für ihn aktuelle Nachrichten vorhanden sind. Terminated == false bedeutet, es gibt noch weitere aktuelle Nachrichten, Terminated == true bedeutet, dass es keine aktuellen Nachrichten mehr gibt, d.h. weitere Aufrufe von getmessages sind nicht notwendig.

dropmessage: Sendet dem Server eine Textzeile (Msg), die den Namen des aufrufenden Clients und seine aktuelle Systemzeit sowie ggf. irgendeinen Text beinhaltet, zudem die zugeordnete (globale) Nummer der Textzeile (INNr) und seine Sendezeit (erstellt mit erlang:now(), TSclientout).

getmsgid: Fragt beim Server die aktuelle Nachrichtenummer ab. self() stellt die Rückrufadresse des Redakteur-Clients dar. Als Rückgabewert erhält er die aktuelle und eindeutige Nachrichtennummer (Number).

Kollisionen:

• Bei Kollisionen gelten die beteiligen Pakete als nicht empfangen bzw. nicht auswertbar
• Der kollisionsfreie Betrieb muss nach endlicher Zeit erreicht werden und darf nicht
  wieder verlassen werden. (Voraussetzung: Anzahl der Stationen nicht grösser als die
  Zahl der Slots im Frame.)
• Bei kleinen Änderungsraten der Referenzzeit (bis 1⁄4 Slotlänge pro Frame) dürfen keine
  Kollisionen auftreten.

add message protocol

Bei der Initialisierung des Clients (z.B. beim Aufruf) wird seine Lebenszeit gesetzt. Ist diese Zeit erreicht, terminiert sich der Client.

zuerst editor, dann wieder leser

wie zwischen beiden switchen?

Der Leser-Client fragt nach der Rolle als Redakteur-Client solange aktuelle Textzeilen beim Server ab, bis er alle erhalten hat und stellt sie in seiner GUI dar. Alle unbekannten Textzeilen werden ihm also einzeln übermittelt bzw. pro Anfrage erhält er nur genau eine unbekannte Textzeile. (Leser-Client und Redakteur-Client kennen sich eigentlich nicht, werden jedoch sequentiell ausgeführt!). Der Leser-Client merkt sich die vom Server erhaltenen Nachrichtennummern und fügt einer als Leser-Client erhaltenen Nachricht, die durch sein Redakteur-Client erstellt wurde, die Zeichenfolge ******* an, etwa 6te_Nachricht. C Out: 11.11 21:12:58,720|(6); HBQ In: 11.11 21:12:58,720| DLQ In:11.11 21:13:01,880|.*******; C In: 11.11 21:13:07,190|

Der Lese-Client wertet die mitgelieferten Zeitstempel mittels der in dem Modul werkzeug.erl vorgegebenen Funktionen (validTS/1, lessTS/2, diffTS/2, now2stringD/1,) aus. Sollte eine Nachricht aus der Zukunft kommen (beim Server von einem Redakteur-Client (TSclientout,TShbqin), beim Lese-Client vom Server (TSdlqin,TSdlqout)) ist dies mit der entsprechenden Zeitdifferenz (diffTS/2, now2stringD/1,) der Zeichenkette mit anzufügen.

Um Nachrichten zu empfangen:
ClientPID ! {reply, Message, Terminated}

und terminate

transported messages have this format:

• Byte 0: Stationsklasse ('A'=0 oder 'B'=1)
• Byte 1 – 24: Nutzdaten. (Darin Byte 1 – 10: Name der sendenden Station.)
• Byte 25: Nummer des Slots, in dem die Station im nächsten Frame senden wird.
• Byte 26 – 33: Zeitpunkt, zu dem dieses Paket gesendet wurde. Einheit: Millisekunden
  seit dem 1.1.1970 als 8-Byte Integer, Big Endian.

Ein Redakteur-Client sendet in bestimmten Abständen, d.h. alle **** Sekunden, eine Textzeile an den Server, die seinen Namen (sein Rechnernamen (zB lab18), die Praktikumsgruppe (zB 1) und die Teamnummer (zB 03), also "lab18103" beinhalten) und seine aktuelle Systemzeit (die der Sendezeit enstprechen soll) beinhaltet und ggf. anderen Text, zum Beispiel 0-client@lab18-<0.1313.0>-C-1-03: 22te_Nachricht. Sendezeit: 16.05 18:01:30,769|(22);.Diese **** Sekunden Wartezeit sind zwischen der Anforderung einer eindeutigen Nachrichtennummer beim Server und vor dem senden der Nachricht an den Server vorzunehmen.

Der Abstand von **** Sekunden wird nach dem Senden von 5 Textzeilen jeweils um ca. 50% per Zufall vergrößert oder verkleinert. Die Zeit **** darf nicht unter 2 Sekunde rutschen.

Der Redakteur-Client fragt nach dem Senden von 5 Textzeilen eine eindeutige Nachrichtennummer beim Server ab, ohne ihm eine zugehörige Nachricht zu übermitteln. In seinem log ist dies zu vermerken, etwa: 121te_Nachricht um 16.06 09:55:43,525| vergessen zu senden ******

• Starts the ggt process with:
  • WorkingTime
  • TerminationTime
  • Quota
  • GGTName (<PraktikumsgruppenID><TeamID><Nummer des ggT-Prozess><Nummer des Starters>)
  • Coordinator
  • NameService
• Der ggT-Prozess meldet sich beim Koordinator mit seinem Namen an (hello) und beim Namensdienst (rebind). Er registriert sich ebenfalls lokal auf der Erlang-Node mit seinem Namen (register). Der ggT-Prozess erwartet dann vom Koordinator die Informationen über seine Nachbarn (setneighbors).

example for sendy: sendy: 585 (495924); berechnet als neues Mi 429.

initial reading phase:
read for frame size seconds
-> determine which station number is still free, choose that number to send (that is done)

other reading phases:
read for
frame size - (frame size / station count) seconds

-> enter sending phase

Start the nameservice with a port as start parameter

take random slot from the free ones

send only in the middle of my time slot : currentTime % (slot * (frame-size / slots-count) / 2) = 0

wait until my slot is over: currentTime % (slot * (frame-size / slots-count) ) = 0

start reading messages

Der Server verwendet drei ADTs: HBQ (Datei hbq.erl), DLQ (Datei dlq.erl) und CMEM (Datei cmem.erl) als Gedächtnis für die Leser-Clients. Diese dürfen hauptsächlich nur als Erlang-Liste ([ ]) realisiert werden! Als Hilfsstrukturen dürfen Tupel eingesetzt werden. Dazu sind die weiter unten aufgeführten Vorgaben zu beachten!

Die HBQ ist als entfernte ADT zu implementieren. Ihre Schnittstelle ist daher durch Nachrichtenformate beschrieben. Die DLQ oder das CMEM sind als lokale ADT zu implementieren. Daher sind deren Schnittstellen durch Funktionen beschrieben. Intern kann die DLQ bzw. das CMEM jedoch als externer Prozess realisiert werden!

Im Folgenden wird die Schnittstelle des CMEM des Servers beschrieben. Das CMEM darf nur vom Server aus angesprochen werden!

            /* Initialisieren des CMEM */
            initCMEM(RemTime,Datei)

            /* Löschen des CMEM */
            delCMEM(CMEM)

            /* Speichern/Aktualisieren eines Clients in dem CMEM */
            updateClient(CMEM,ClientID,NNr,Datei) 

            /* Abfrage welche Nachrichtennummer der Client als nächstes erhalten darf */
            getClientNNr(CMEM,ClientID)

initCMEM(RemTime,Datei): initialisiert den CMEM. RemTime gibt dabei die Zeit an, nach der die Clients vergessen werden Bei Erfolg wird ein leeres CMEM zurück geliefert. Datei kann für ein logging genutzt werden.

delCMEM(CMEM): löscht den CMEM. Bei Erfolg wird ok zurück geliefert.

updateClient(CMEM,ClientID,NNr,Datei): speichert bzw. aktualisiert im CMEM den Client ClientID und die an ihn gesendete Nachrichtenummer NNr. Datei kann für ein logging genutzt werden.

getClientNNr(CMEM,ClientID): gibt die als nächstes vom Client erwartete Nachrichtennummer des Clients ClientID aus CMEM zurück. Ist der Client unbekannt wird 1 zurück gegeben.

• ziele
• umsetzung der fachlichen architektur

sync time dependent on the received messages and the stations class

Die Stationen sollen in die Klassen A und B unterteilt werden. Die Zeiten sollen grundsätzlich auf UTC basieren.

Die Uhr einer Station der Klasse A wird als hinreichend genau betrachtet. Die Uhren dieser Stationen sollen sich im Rahmen der Möglichkeiten untereinander synchronisieren. Beim Start soll eine anfängliche Abweichung von der UTC einstellbar sein.

Die Uhren der Stationen der Klasse B gelten als nicht hinreichend genau. Sie müssen sich mit den Uhren von Stationen der Klasse A synchronisieren.

• Der Starter (mit eindeutiger Nummer) erfragt beim Koordinator die steuernden Werte (getsteeringval) asynchron und erwartet einen entsprechenden Rückruf (steeringval).
• Der Starter liest aus der Datei ggt.cfg die weiteren Werte aus: die Erlang-Node des Namensdienstes, der Name des Koordinators, die Nummer der Praktikumsgruppe und die Nummer des Teams.
• Der Starter startet die ggT-Prozesse mit den zugehörigen Werten:
  1. der Verzögerungszeit
  2. die Terminierungszeit
  3. der Startnummer dieses Prozesses (also der wievielte gestartete ggT-Prozess er ist)
  4. seine eindeutige Starternummer
  5. die Praktikumsgruppennummer
  6. die Teamnummer
  7. sowie die benötigten Kontaktdaten für den Namensdienst
  8. und den Koordinator
  9. und die Abstimmungsquote als konkrete Anzahl
• Beim starten des Starters wird ihm seine Starternummer mitgegeben.

Da die dem Server zugestellten Textzeilen bzgl. der Nummerierung in zusammenhängender Reihenfolge erscheinen sollen und Nachrichten mit Textzeilen verloren gehen können bzw. in nicht sortierter Reihenfolge eintreffen können, arbeitet der Server intern mit einer Deliveryqueue (DLQ) und einer Holdbackqueue (HBQ).
In der Deliveryqueue stehen die Nachrichten, die an Clients ausgeliefert werden können, maximal *** viele Textzeilen. Dies wird durch die Größe der Deliveryqueue vorgegeben.
In der Holdbackqueue stehen alle Textzeilen, die nicht ausgeliefert werden dürfen.

Der Server verwendet drei ADTs: HBQ (Datei hbq.erl), DLQ (Datei dlq.erl) und CMEM (Datei cmem.erl) als Gedächtnis für die Leser-Clients. Diese dürfen hauptsächlich nur als Erlang-Liste ([ ]) realisiert werden! Als Hilfsstrukturen dürfen Tupel eingesetzt werden. Dazu sind die weiter unten aufgeführten Vorgaben zu beachten!

Die HBQ ist als entfernte ADT zu implementieren. Ihre Schnittstelle ist daher durch Nachrichtenformate beschrieben. Die DLQ oder das CMEM sind als lokale ADT zu implementieren. Daher sind deren Schnittstellen durch Funktionen beschrieben. Intern kann die DLQ bzw. das CMEM jedoch als externer Prozess realisiert werden!

Wenn in der Holdbackqueue von der Anzahl her mehr als 2/3-tel an echten Nachrichten enthalten sind, als durch die vorgegebene maximale Anzahl an Nachrichten in der Deliveryqueue stehen können, dann wird, sofern eine Lücke besteht, diese Lücke zwischen Deliveryqueue und Holdbackqueue mit genau einer Fehlernachricht geschlossen, etwa: ***Fehlernachricht fuer Nachrichtennummern 11 bis 17 um 16.05 18:01:30,580|. Es werden keine weiteren Lücken innerhalb der Holdbackqueue behandelt! In dem Sinne wird die Holdbackqueue in diesem Fall nicht zwingend geleert. Die Fehlernachrciht ist nur durch eine entsprechende Zeichenkette in der Nachricht zu erkennen. Ansonsten hat sie das Format einer ganz normalen Nachricht, d.h. das System kann eine Fehlernachricht nach Speicherung in der DLQ nicht mehr als solche erkennen!

in der ausführlich beschrieben wird, wie das System zu starten ist!

params:

• interfaceName
• mcastAddress
• receivePort
• stationClass
• message bytes

log eveverything or log nothing

documentation for the starter

should receive multicast datagrams

https://docs.oracle.com/javase/tutorial/networking/datagrams/broadcasting.html

send in time slot middle with the message from the queue packed into datagram

kill the communicator: shutdown server thread and thread pool

instance of objectbroker to null

display received message onto console

MSG_List := [NNr,Msg,TSclientout,TShbqin,TSdlqin,TSdlqout]:
[Integer X String X 3-Tupel X 3-Tupel X 3-Tupel X 3-Tupel]

so TS should be 3-Tupel, but erlang:now() does not return 3-Tupel and werkzeug:timeMilliSecond() also does not return 3-Tupel

so how should the timestamps be generated? why 3-tupel?

client nameservice interface in mware_lib

rebind blocks the stream

Start server socket at given port

Object servant, String name

create proxy class that implements the stub and calls the methods over the orb remotely

resolve an alias to object

narrowcast should make the proxy from the given object ref

call local object that is found by the alias in local registry of nameserviceproxy

• Ein ggT-Prozess hat den Namen ?????, wobei ????? eine Zahl ist, die sich wie folgt zusammensetzt:
  <PraktikumsgruppenID><TeamID><Nummer des ggT-Prozess><Nummer des Starters>, also z.B. ist in der Praktikumsgruppe 4 von dem Team 03 ein zweiter ggT-Prozess von ihrem ersten Starter gestartet worden, so erhält dieser ggT-Prozess den Namen 4321. In der Kommunikation mit externen Prozessen wird dieser Name als atom verwendet, wenn er nicht als Absender dient (From)!
• Der ggT-Prozess meldet sich beim Koordinator mit seinem Namen an (hello) und beim Namensdienst (rebind). Er registriert sich ebenfalls lokal auf der Erlang-Node mit seinem Namen (register). Der ggT-Prozess erwartet dann vom Koordinator die Informationen über seine Nachbarn (setneighbors).
• Vor einer ggT-Berechnung erwartet der ggT-Prozess vom Koordinator seine Zahl Mi (setpm). Der ggT-Prozess kann zu jeder Zeit zu einer neuen Berechnung aufgefordert werden!
• Der ggT-Prozess reagiert auf die jeweiligen Nachrichten. Wenn er z.B. eine Zahl erhält (sendy) führt er den ggT-Algorithmus aus. Ändert sich seine Zahl dadurch (also hat er echt etwas berechnet), informiert er zusätzlich den Koordinator darüber, indem er diesem seinen Namen, seine neue Zahl und die aktuelle Systemzeit überträgt (briefmi). Ändert sich seine Zahl dadurch nicht, macht der ggT-Prozess gar nichts und erwartet die nächste Nachricht.
• Für eine ggT-Berechnung braucht er jedoch eine gewisse Zeit (die Verzögerungszeit), die ihm vom Starter bei der Initialisierung mitgegeben wurde. Dies simuliert eine größere, Zeit intensivere Aufgabe. Der ggT-Prozess soll in dieser Zeit einfach nichts tun (timer:sleep).
• Der ggT-Prozess beobachtet die Zeit seit dem letzten Empfang einer Zahl (sendy oder setpm). Hat diese ** Sekunden überschritten (Terminierungszeit), startet er eine Terminierungsanfrage (multicast,vote). Es wird von ihm zu einer Zeit nur genau eine Terminierungsanfrage gestartet. Eine weitere kann frühstens dann gestartet werden, wenn zwischenzeitlich eine Zahl (sendy, setpm) an ihn gesendet wurde!
• Ist die Terminierungsanfrage erfolgreich durchgeführt (voteYes ist bzgl. der Quote oft genug eingegangen), sendet er dem Koordinator eine Mitteilung über die Terminierung der aktuellen Berechnung, die seinen Namen, den errechneten ggT (sein aktuelles Mi) und seine aktuelle Systemzeit beinhaltet. Zudem zählt er seine erfolgreich gemeldeten Terminierungsmeldungen und notiert dies in seinem log. Wenn ein ggT-Prozess eine Anfrage nach der Terminierung (vote) erhält: ist seit dem letzten Empfang einer Zahl mehr als /2 ( halbe) Sekunden vergangen, dann antwortet er dem Initiator mit voteYes (explizites Zustimmen). Sonst ignoriert er die Nachricht (implizites ablehnen).

read messages from stdin

message bytes from vessel

send to in channel of station

start the server, create a client, rebind something
resolve the reference