Reliability

Moderator: Praktikum: Kommunikation in Peer-to-peer-Netzen

Xaero
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 173
Registriert: 8. Feb 2006 20:06

Reliability

Beitrag von Xaero » 8. Jan 2008 14:35

Hallo,
habe eine allgemeine Frage:
Wenn ich z.B. wie in der vorgegebenen Datei aus dem applicationscode 2 100 Knoten habe und 1000 Cyclen die Simulation laufen lasse, dann habe ich sehr sehr viele PositionUpdates. Ich versuche in allen Knoten alle neue Nachrichten zu speichern und dann bekomme ich eine Exception, weil die Hashmap nicht groß genug ist. Wie kann ich das Problem lösen, damit ich die Reliability auswerten kann? Kann man einfach die Simulation auf 100 Zyklen reduzieren oder weniger Knoten nehmen, damit die HashMap nicht zu groß wird?

Benutzeravatar
Goldfinger
Erstie
Erstie
Beiträge: 21
Registriert: 18. Okt 2004 16:41
Kontaktdaten:

Re: Reliability

Beitrag von Goldfinger » 26. Feb 2008 17:07

Hallo,
Du musst ja nicht alle Nachrichten in jedem Knoten für immer aufheben. Ab und an bereinigen macht schon Sinn, da der Speicherverbrauch sonst immens ist (wie du ja selber festgestellt hast).

Um die Reliability auszuwerten, schreibe den Status
Knoten x, Event y, empfangen/gesendet, Anzahl Hops usw.
doch einfach in eine Logdatei. Die lässt sich dann auch einfach auswerten.

So machen wir das zumindest. Für die Logfiles nutzen wir
http://logging.apache.org/log4j/index.html

Das funktioniert ganz gut.
Tja, wären Sie früher da gewesen, wären Sie auch nicht nass geworden...

Xelord
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 225
Registriert: 23. Okt 2004 09:49

Re: Reliability

Beitrag von Xelord » 7. Mär 2008 22:20

Also ist Reliability die Relation zwischen empfangenen Events und gesendeten Events auf einem Knoten ?

Benutzeravatar
Goldfinger
Erstie
Erstie
Beiträge: 21
Registriert: 18. Okt 2004 16:41
Kontaktdaten:

Re: Reliability

Beitrag von Goldfinger » 7. Mär 2008 23:23

Reliability gibt an bei wieviel Knoten im Schnitt die Nachrichten auch wirklich ankommen, im Prinzip ein Maß für den Verbreitungsgrad der Nachrichten.

Beispiel:
Wenn durchschnittlich 90 Knoten von insgesamt 100 Knoten eine Nachricht erhalten, beträgt die Reliability 0.9 bzw 90%
Tja, wären Sie früher da gewesen, wären Sie auch nicht nass geworden...

Xelord
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 225
Registriert: 23. Okt 2004 09:49

Re: Reliability

Beitrag von Xelord » 8. Mär 2008 00:03

Danke.
Im System, dass nur initial Nachrichten bekommt, verteilt es sich gut.
Aber beim laufenden System wird die Abdeckung immer weniger und ich weiß nicht so genau woran es liegt.

BastiS
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 224
Registriert: 3. Nov 2005 19:12
Kontaktdaten:

Re: Reliability

Beitrag von BastiS » 8. Mär 2008 10:09

Eigentlich sollte sich die Reliability meinem Verständnis bei längerer Laufzeit bei einem Wert einpendeln. Zu Beginn ist sie natürlich sehr hoch, da kaum Nachrichten im System sind und diese somit sehr zuverlässig zugestellt werden, und mit der Zeit sinkt sie dann (das müsste recht schnell gehen).
Aber irgendwann sollte ein konstanter Zustand erreicht werden.

Xelord
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 225
Registriert: 23. Okt 2004 09:49

Re: Reliability

Beitrag von Xelord » 8. Mär 2008 15:23

Danke,
kannst du mal ein Verteilungswert mit eurer Konfig posten ?
Wenn es geht mit den Randomfunktionen aus dem Paper

Benutzeravatar
Goldfinger
Erstie
Erstie
Beiträge: 21
Registriert: 18. Okt 2004 16:41
Kontaktdaten:

Re: Reliability

Beitrag von Goldfinger » 9. Mär 2008 00:02

Wir kommen auf die 90% die in dem Paper stehen. Wichtig dabei sind allerdings die 40 Nachrichten pro Runde!

Hier mal Messwerte: (vordere Zahl entspricht Nachrichten pro Runde, hintere Reliability)

Code: Alles auswählen

10	 0,977735273
25	 0,941904291
40	 0,900971273
55	 0,846865719
75	 0,753002473
100	0,648085818
125	0,57254656
Config ansonsten war:

Code: Alles auswählen

random.seed 323783232378
simulation.cycles 550
network.node p2plab.GameNode

control.shf Shuffle
network.size 125
 
protocol.lnk IdleProtocol

protocol.lpb ttlab.latest.Lpbcast
protocol.lpb.linkable lnk
protocol.lpb.viewsize 15
protocol.lpb.subsize 50
protocol.lpb.unsubsize 20
protocol.lpb.eventIDssize 60
protocol.lpb.eventssize 20
protocol.lpb.fanout 3

init.rnd WireKOut
init.rnd.protocol lnk
init.rnd.k 20
Tja, wären Sie früher da gewesen, wären Sie auch nicht nass geworden...

Antworten

Zurück zu „Praktikum: Kommunikation in Peer-to-Peer-Netzen“