Verteiltes Nutzer- und Content-Matching in mobilen Kommunikationssystemen im Umfeld des PotatoSystems Bearbeiter:Mario Kubek Fachgebiet:Rechnerarchitekturen

Verteiltes Nutzer- und Content-Matching in

mobilen Kommunikationssystemen im

Umfeld des PotatoSystemsBearbeiter: Mario KubekFachgebiet: Rechnerarchitekturenverantw. Professor: Prof. Dr.-Ing. habil. Wolfgang FenglerHochschulbetreuer: Dr.-Ing. Jürgen NützelDatum: 19.09.2005

Technische Universität Ilmenau, Fachgebiet Rechnerarchitekturen

Diplomarbeit

Gliederung

2

1. Motivation2. Das PotatoSystem3. Der „Mobile Music Messenger“ (MMM)4. Die Architektur von JXME5. Rahmen eines mobilen P2P-Systems6. Das Matching-Verfahren

• Konzeption• Komponenten• Umsetzung

7. Zusammenfassung und AusblickDiplomarbeit M. Kubek, 19.09.2005

1. Motivation

3

• Erstellung eines mobilen Empfehlungssystems Verteiltes User-Matching im PotatoSystem Empfehlungsberechnung durch dezentrale Algorithmen

Einbettung in den „Mobile Music Messenger“ (MMM)

Programmierung in Java für mobile Endgeräte (J2ME)

• Skalierbarkeit des Systems im mobilen Kontext Variierende Teilnehmeranzahl Nachrichtenanzahl Nachrichtengröße Mobile Datenhaltung

Diplomarbeit M. Kubek, 19.09.2005

2. Das PotatoSystem (http://www.potatosystem.com)

4

• Gemeinschaftsprojekt der 4FO AG und Fraunhofer IDMT• ermöglicht legalen Verkauf digitaler Daten über das Internet • Spezialisierung auf Musikvertrieb für Künstler und Labels

• keine Kopierschutz-mechanismen

• Nutzer-Homepage zum Musikverkauf

• Käufer erhalten neben Musik ein Wiederverkaufs-recht

• User-Matching im Waren-korb

• Liste TOP-10-Downloads


3. Der „Mobile Music Messenger“ (MMM)

5

• Mobile Erweiterung des PotatoSystems J2ME-Programm für aktuelle Mobiltelefone Kommunikation mittels P2P-System JXME 1.0

• Funktionen: Verwaltung einer Buddy-Liste Musik-Chat

Verwaltung eines persönlichen Musik-Profils (PMP) in Links

Versand der Musik-Links innerhalb der Community

Unterscheidung der Links nach Kaufinformation

Vorhören der Musik

Kauf von Songs durch WAP 2.0 Browser


4. Die Architektur von JXME 1.0 („JXTA für J2ME“)

6

JXTA-CommunityJXTA-Community

JXME-Peers

JXME-Peer

Rendezvous-Peers

JXME-Relays

•Komponenten des P2P-Systems: Mobile Peers Relay-Peers

Rendezvous-Peers

•Kommunikation: Relays als Vermittler

zwischen JXME-Peers

Nachrichenaustausch in JXTA-Binärformat über HTTP-Protokoll

Binärformat enthält keine XML-Strukturen

Pipes: virtuelle Kommunikationskanäle


5. Rahmen eines mobilen P2P-Systems

7

•Mobile Datensitzungen: meist kurz und möglicherweise instabil

•Verteiltes Wissen: Wissen der Peers durch Dynamik mobiler Communities oft nicht verfügbar

•Skalierbarkeit: Einbeziehung möglichst vieler Teilnehmer Stabilität des Systems bei großer Nutzeranzahl und Nachrichtenmenge

Beschränkung der Größe ausgetauschter Nachrichten sinnvoll

•Mobile Datenhaltung: Persistenz in aktuellen Mobiltelefonen möglich

J2ME bietet: RMS (mind. 8 kByte) oder FileConnection-Klassen

effiziente Strukturierung der Daten nötig


6. Das Matching-Verfahren (Konzeption)

8

•Idee: Mobiles, dezentrales User-Matching im MMM Lieblingssongs des PMP als Auftrag (Künstler und Titel pro Link)

Verteilte Empfehlungsberechnung durch angefragte Peers

Erweiterung: Nutzung gesicherter Auftragsdaten•Ansatz:

Ber. lokaler PMP-Ähnlichkeit und Ähnlichkeit gesicherter Auftragsdaten

Matching-Mengen: exaktes Matching, Künstler-Matching und Restmenge

Profilähnlichkeit durch Schwellwerte bestimmt:

Empfehlungen: neben Peer-Kennungen max. vier Songs des PMP und jeweils max. zwei Songs der höchstens drei ähnlichsten Peers

unda bAnzahl passender Songs Anzahl passender Songs>S >S

Anzahl d. Songs im Auftrag Anzahl d. Songs im Profil


6. Das Matching-Verfahren (Komponenten)

9

•Teilnehmer pro Auftrag: ein Auftraggeber n Auftragnehmer

•Nachrichten (Nutzdaten) pro Auftrag:

ein Empfehlungsauftrag max. 10 Empfehlungsnachrichten

•Komponenten des Verfahrens: Auftragserstellung Auftragsbearbeitung Empfehlungsbehandlung RMS zur Datensicherung elementare Peer-Aktivitäten pro Auftrag

Empfehlungsberechnung aus lokalem PMP

Berechnung der Ähnlichkeit mit gesicherten Profilen anderer Nutzer

Empfehlungsberechnung der drei ähnlichsten Nutzer

Senden der Empfehlungsergebnisse

Filterung und Darstellung der Empfehlungen

Auswahl und Versand zu vergleichender Daten

Sicherung der empfangenen Auftragsdaten

Berechnung der Ähnlichkeit mit lokalem PMP


6. Das Matching-Verfahren (Umsetzung)

10

•Auftragserstellung (anfragender Peer): Max. fünf PMP-Einträge als Auftrag Bestimmung der Suchart (Nutzer oder Musik) Auftragsnummer enthalten Auftragsversand an Propagate-Pipe (Multicast)

•Auftragsbehandlung (angefragte Peers): Sicherung der Auftragsdaten im RMS

Ähnlichkeitsberechnung und Empfehlungsauswahl

Speicherung der Empfehlung nach Auftragsnummer bis Versand

Öffnung einer Pipe (FlagPipe) mit Auftragsnummer als Namen

•Empfehlungsbehandlung (anfragender Peer): Hilfs-Peer: Anforderung von max. 10 Empfehlungen durch FlagPipes

Empfehlungsdarstellung ohne Duplikate


JXTA-Relay

6. Das Matching-Verfahren (Auftragsversand)

11

Peer3 PMP-Einträge:

K1T1, K2T2, K1T3

gekauft

K2T4 n. gekauft

gesicherte Anfragen:


K2T2, K4T3 gekauft

K2T5 n. gekauft


K1T1, K1T2 Peer6

K1T1, K1T2, K4T5

Peer6

Auftraggeber

MMM-Programm


K1T1, K2T2K5T3, K6T4

gekauft

Hilfs-Peer inaktiv


Song K1T1…Titel T1 des Künstlers K1

JXTA-Relay

K1T1, K2T2

K1T1, K2T2

K1T1, K2T2


11

Auftraggeber

MMM-Programm



gekauft

Hilfs-Peer wartet


K1T1, K2T2, K1T3

gekauft

K2T4 n. gekauft



K2T2, K4T3 gekauft

K2T5 n. gekauft


K1T1, K1T2 Peer6

K1T1, K1T2, K4T5

Peer6

a

b

S =0.4S =0.1

(Auftragsnr.)

(Auftragsnr.)

(Auftragsnr.)


JXTA-Relay


11


K1T1, K2T2, K1T3

gekauft

K2T4 n. gekauft



K2T2, K4T3 gekauft

K2T5 n. gekauft


K1T1, K1T2 Peer6

K1T1, K2T2 Peer1

K1T1, K1T2, K4T5

Peer6

K1T1, K2T2 Peer1

Auftraggeber

MMM-Programm



gekauft

Hilfs-Peer wartet

a

b

S =0.4S =0.1


JXTA-Relay

6. Das Matching-Verfahren (Empfehlungsberechnung)

12

Empf. berechnet (FlagPipe

öffnen)

Empf. berechnet (FlagPipe

öffnen)

Empf. berechnet

(FlagPipes)


K1T1, K2T2, K1T3

gekauft

K2T4 n. gekauft



K2T2, K4T3 gekauft

K2T5 n. gekauft


K1T1, K1T2 Peer6

K1T1, K2T2 Peer1

K1T1, K1T2, K4T5

Peer6

K1T1, K2T2 Peer1

Auftraggeber

MMM-Programm



gekauft

Hilfs-Peer aktiv

a

b

S =0.4S =0.1


JXTA-Relay

6. Das Matching-Verfahren (Empfehlungsversand)

13

Empf. anfordern

Empf. anfordern

Empf. anfordern

Auftraggeber

MMM-Programm



gekauft

Hilfs-Peer aktiv


K1T1, K2T2, K1T3

gekauft

K2T4 n. gekauft



K2T2, K4T3 gekauft

K2T5 n. gekauft


K1T1, K1T2 Peer6

K1T1, K2T2 Peer1

K1T1, K1T2, K4T5

Peer6

K1T1, K2T2 Peer1


JXTA-Relay

6. Das Matching-Verfahren (Empfehlungsversand)

13

Peer3: K1T3,

K2T4

Peer6: K1T2

Peer4: K4T3, K2T5

Peer6: K1T2, K4T5

Empfehlungen

Auftraggeber

MMM-Programm



gekauft

Hilfs-Peer inaktiv


K1T1, K2T2, K1T3

gekauft

K2T4 n. gekauft



K2T2, K4T3 gekauft

K2T5 n. gekauft


K1T1, K1T2 Peer6

K1T1, K2T2 Peer1

K1T1, K1T2, K4T5

Peer6

K1T1, K2T2 Peer1


6. Das Matching-Verfahren (Empfehlungsbehandlung)

14

Auswertung der maximal 10 Empfehlungen:

Duplikatefilterung gefundener Nutzer und Songs

getrennte Nutzer- und Song-Darstellung unterschiedliche Darstellung empfohlener

Nutzer und Songs nach Kategorie

Empfang der Empfehlungsobjekte

Extraktion der Daten empfohlener Nutzer

Duplikatefilterung

Darstellung empfohlener Nutzer nach Kategorie

[Modus Nutzersuche]

[Modus Song-Suche]

Extraktion empfohlener Songs

Duplikatefilterung

Einordnung in Empfehlungsmatrix


7. Zusammenfassung und Ausblick

15

•Zusammenfassung: mobiles, skalierbares Empfehlungssystem auf JXME-Basis komplett verteilte Empfehlungsberechnung Wissen in der Community durch Sicherung der Auftragsdaten

vergrößert Einbettung als Komponente in den MMM

•Zukünftige Entwicklungen: Nutzung weiterer Metadaten zur Empfehlungsberechnung

effizientere Kommunikation ohne HTTP-Protokoll in JXME 2.0

Empfehlungsversand per SMS an nicht erreichbare Teilnehmer durch PushRegistry der J2ME


Vielen Dank für die Aufmerksamkeit!

Fragen?

Documents

Verteiltes Nutzer- und Content-Matching in mobilen Kommunikationssystemen im Umfeld des PotatoSystems Bearbeiter:Mario Kubek Fachgebiet:Rechnerarchitekturen