P2P-Spiel-Prototyp

[trimoq]

Hallo liebe Community,
seit einigen Wochen beschäftige ich mich mit P2P-Anwendungen und wage zu behaupten, die Grundzüge verstanden zu haben.
Da das ganze recht interessant klingt kam ich mit folgender Idee auf:
Ein kleines Spiel(rumlaufen in JME3, läuft in ausreichendem Maße) auf Basis eines P2P-Netzwerkes zu entwickeln.
Nun zum Haken an der ganzen Sache, womit implementiert man sowas in Java?
- JXTA/JXSE macht einen sehr toten eindruck
- SharkFW ist denk ich dazu nicht so ganz geeignet
- Was eigenes mit Multicast machen geht im Internet ja leider nicht
- Hat jemand Erfahrungen mit freepastry(FreePastry)?
Jetzt würde ich mich über Anregungen und Ideen freuen, welche Libraries, Protokolle oder Frameworks man hierfür nehmen könnte um zumindest einen Prototyp (10 Peers?) zu entwickeln.
Liebe Grüße
Trimoq

 

[Sen-Mithrarin]

naja was ist das haupt-problem von kleinen p2p-netzen > irgendwann fällt das netz auseinander da die peers sich nicht mehr finden

man braucht also entweder einen festen stamm an peers ... dann könnte man aber auch gleich server nehmen ... oder baut das ganze so auf das man auch nach längerer zeit wieder mit dem netz verbinden kann

damit so ein p2p-netz stabil laufen kann müssen die internen listen so groß sein das man auch wie gesagt nach längerer abwesenheit immer mindestens einen peer wiederfindet um sich wieder mit dem netz zu verbinden

auch braucht man einen guten algorithmus der dann eine p2p-verbindung überhaupt aufbauen kann
hat man zwei peers hinter NAT-firewalls, die von ein ander aber nichts wissen und auch keinen anderen kanal zur kommunikation haben können diese trotzdem keine verbindung aufbauen
also muss man hier dann entweder, gerade bei NAT-firewalls, für port-forwarding sorgen oder z.b. über STUN-server einen verbindungsaufbau ermöglichen

erst bei netzen die groß genug sind und algorithmen die sowas trotzdem hinbekommen, z.b. das zyklisch durch die gesamte liste gelaufen wird bis dann "zufällig" eine verbindung zustande kommt, bleibt so ein netz stabil


ganz problematisch : bootstraping > wie kommt ein neuer client ins netz rein ohne einen anderen peer zu kennen, sich komplette listen zu besorgen oder server zu nutzen


du siehst also : gerade bei "kleinen" p2p-netzen gibt es noch zusätzliche probleme zu denen die es eh schon gibt

 

[trimoq]

Danke für deine Einschätzung Sen-Mithrarin.
Wenn man die Listen auf einem, sagen wir "Backup-Server", von mir aus auch mehrern speichert, ließe sich so einer vergleichsweise einfach auf einem Webserver implementieren oder verschätze ich mich da?
Dieser könnte die EntryPoints bzw Bootstrap-IPs verwalten und würde, in der Theorie auch bei einem zeitweise 100% inaktiven Netzwerk, die Funktionsfähigkeit garantieren. Ein zentraler Server wie der oben beschriebene würde natürlich den P2P-Ansatz etwas stören aber naja, einen Tod muss man sterben
FreePastry bietet ein anscheinend gut funktionierendes UPnP an, werde mich auf jeden fall da mal reinarbeiten, wenn das natürlich nicht so toll funktioniert, dann hast du wohl recht, was die Umsetzbarkeit angeht.

 

[Sen-Mithrarin]

UPnP ist schon mal gar nicht so der falsche ansatz, allerdings war das mehr eine mode-erscheinung als wirklich sinnvoll

UPnP bietet über eine definierte schnittstelle die möglichkeit einen NAT-router vom netzwerk aus so zu steuern das man sich nicht selbst um die port-freigaben kümmern muss sondern dies dem code überlässt

der grund warum ich "modeerscheinung" sage ist damit begründet das die idee an sich zwar recht gut ist, jedoch auch recht schnell wieder als zu großes sicherheitsrisiko in verruf geraten ist weil es so z.b. backdoors ein sehr einfaches eindringen ins netzwerk erlaubt

viele router-hersteller bietet weiterhin UPnP an, einige haben es standardmäßig auch aktiviert, viele jedoch liefern aktuelle firmwares mit deaktiviertem UPnP aus


man kann es also verwenden, sollte sich aber nicht drauf verlassen
auf jeden fall sollte man mindestens einen zentralen server bereitstellen der
1) für die verfügbarkeit von bootstrap-listen sorgt
2) einen prüf-punkt für UPnP bildet in dem man nach vermutlich erfolgreichem triggering direkt testet ob es denn auch wirklich geklappt hat
3) als STUN-server agiert um im notfall über normales hole-punching eine verbindung zu ermöglichen


ich will dein vorhaben um gottes willen nicht grundsätzlich nur negativ betrachten, sondern dir vorab versuchen aufzuzeigen welche zusätzlichen probleme es gerade bei kleineren netzen geben kann


auch ein schönes beispiel ist IRC
normalerweise ist IRC so aufgebaut das eine nachricht über verschiedene server zum ziel gelangt
jetzt kann es aber zur sog. "netz-separation" kommen wenn ein wichtiger server ausfällt und somit das eigentlich gesamte netz in zwei unabhängige teilnetze zerfällt
eine lösung wäre das die server untereinander mehrere routen bilden, das erhöt aber gleichzeitig auch den verwaltungsaufwand da so nachrichten natürlich entweder mehrfach unterwegs sein können oder durch ungünstigen zufall sogar in einem loop hängen bleiben
sowas muss dann von der de-zentralen steuerung erkannt und korrigiert werden was wieder einen höheren protokoll overhead verursacht

gleiches kann auch bei einem recht engmaschig verbunden p2p-netz auftreten wenn z.b. durch ausfall mehrerer nodes zwischen zwei größeren bereichen des gesamt-netzes nur noch sehr wenige verbindungen bestehen
brechen diese mit der zeit zusammen ohne das rechtzeitig für ersatz gesorgt wird so erhält man mit unter zwei von einander unabhängige netze die in sich aber weiter "normal" funktionieren
dieser zustand bleibt dann so lange bestehen bis eine node online kommt die wieder beide netze miteinander verbindet und so über z.b. DHT das netz von selbst wieder mehrere alternative routen aufbauen kann

bei großen netzen spielt sowas eher weniger eine rolle da es dort meist sehr viele nodes gibt die mit vielen anderen nodes verbunden sind und so die stabilität des netzes gewährleisten, aber dieser effekt tritt dann erst mit 4 bis 5 stelliger node-zahl ein ... kleinere netze würde ich als grundsätzlich gefährdet ansehen
und dazu kommen wie schon erwähnt robuste algorithmen die halt zyklisch solche prüfungen durchführen und wenn nötig zur sicherheit alternative routen erzeugen bevor das risiko zu groß wird


an sich eine wirklich gute idee die mich auch persönlich interessiert, aber bei dieser "größe" vermutlich schwer umsetzbar wird