# simple p2p bootstrapping



## void7 (29. Dez 2011)

Hallo,
Ich bin am entwickeln einer p2p anwendung, und frage mich nun wie man ein einfaches bootstrapping realisieren sollte. Also dass sich die Peers untereinander kennenlernen. Es sollte relativ einfach bleiben, also kein distributed hashtable oder ähnliches.

Nun ich habe mir vorgestellt, dass es einen Server gibt, der zwar nicht teil des p2p netzwerkes ist, aber jedoch für einen neuen peer einen (oder mehrere?)  "Einstiegsknoten" bereitstellt. Nun das simpelste würde jetzt sein dass ein neuer peer sich diesen Entrypoint vom server holt. Somit kennt der peer mal einen peer. diesen Peer kann er nun fragen welcher peer er kennt... usw. Das setzt man quasi rekursiv fort. Das würde dann darin enden dass jeder peer jeden anderen peer kennt. Das ist nun natürlich nicht der Sinn der sache. 

Habt ihr hier tipps wie man das möglichst einfach (es muss nicht wahnsinnig ausgeklügelt sein) realisieren kann? Soll der Server immer nur den gleichen peer bereitstellen? Oder jene Peers die sich als letztes eingestiegen sind? Sollte man nur eine Ebene der "rekursion" beim bootstrappen machen? Wie stellt man sicher dass ein peer nicht völlig abgekapselt ist? etc..

p.s. jxta ist leider keine option, und andere frameworks haben sich als nicht so brauchbar herausgestellt. Das ganze würde ich mit sockets realisieren.


greetz


----------



## irgendjemand (29. Dez 2011)

also spontan fallen mir *auch von P2P-software* nur zwei möglichkeiten ein

1) verbindungs-server
stellt dir eine anlaufstelle bereit bei der sich ein neuer peer melden und um eine liste mit bereits im netzwerk vorhandenen peers fragen ...
auch hat es den vorteil mit STUN *-> google* einen verbindungsaufbau zu initiieren wenn der ziel-peer durch ein NAT geblockt ist

2) manuelle eingabe eines ziel-peer
hat meiner ansicht nach 2 nachteile
1) ziel-peer muss erreichbar sein *thema NAT und so*
2) man hat damit erstmal nur EINEN peer und kann *wenn man keine längere liste von möglichen entry-peers hat* nicht zum netz connecten ...


wie dann der neue peer die anderen peers findet ist eigentlich egal ... entweder vom server oder von anderen peers ...


----------



## void7 (29. Dez 2011)

hi & danke für die antwort.



irgendjemand hat gesagt.:


> wie dann der neue peer die anderen peers findet ist eigentlich egal ... entweder vom server oder von anderen peers ...



Okay hier liegt aber mein Problem.
Fangen wir einfach an.
Sagen wir der Server kennt 1 peer P1.

Ein zweiter peer P2 verbindet sich zum netzwerk. P2 kennt noch keine Peers also kontaktiert er mal den Server. Dieser gibt ihm P1 bekannt. Somit kennen sich P1 und P2.

Soll sich der Server nun P1 und P2 merken? Dann kriegt P3 vom server die Peers bekannt gegeben... Ich denke das ist nicht so eine gute Lösung wenn sich der Server quasi alle peers merkt.

Wäre es besser wenn man sagt, dass sich der server nur den letzten peer der sich verbunden hat merkt? das wäre P2.

P3 kontaktiert den server und bekommt P2 zugewiesen. P2 kennt P1 somit kann auch P3 von P1 erfahren... usw....  das hat zur folge dass P1 nur einen peer kennt und P100 kennt 99 ... etc...

auch nicht gut....


----------



## irgendjemand (29. Dez 2011)

void7 hat gesagt.:


> Sagen wir der Server kennt 1 peer P1.



gut ... dann kennt der server P1 ... kennt denn P1 auch S ?



void7 hat gesagt.:


> Ein zweiter peer P2 verbindet sich zum netzwerk. P2 kennt noch keine Peers also kontaktiert er mal den Server. Dieser gibt ihm P1 bekannt. Somit kennen sich P1 und P2.



NEIN ... P2 kennt dann S und P1 ... P1 aber nur S ... damit P1 was von P2 mitbekommt muss es ihm entweder der Server sagen oder P2 muss sich zu P1 connecten



void7 hat gesagt.:


> Soll sich der Server nun P1 und P2 merken? Dann kriegt P3 vom server die Peers bekannt gegeben... Ich denke das ist nicht so eine gute Lösung wenn sich der Server quasi alle peers merkt.



könnte man so machen *wäre mein persönlicher favorit* ...
klar ist das ne auslastung für den server ... aber zur not kann so die kommunikation über den server laufen falls die peers sich nicht dierekt verbinden können



void7 hat gesagt.:


> Wäre es besser wenn man sagt, dass sich der server nur den letzten peer der sich verbunden hat merkt? das wäre P2.



also wenn sich S nur den allerletzten peer merkt und dieser dann zufällig als erster disconnected / nicht mehr erreichbar ist hat der server überhaupt keine peers mehr in vorrat ... S sollte sich also mindestens die letzten 10 peers oder so merken



void7 hat gesagt.:


> P3 kontaktiert den server und bekommt P2 zugewiesen. P2 kennt P1 somit kann auch P3 von P1 erfahren... usw....  das hat zur folge dass P1 nur einen peer kennt und P100 kennt 99 ... etc...
> 
> auch nicht gut....



P2P is halt so ne sache und wird erst bei mehr als 10k peers interessant ...


----------



## void7 (29. Dez 2011)

irgendjemand hat gesagt.:


> also wenn sich S nur den allerletzten peer merkt und dieser dann zufällig als erster disconnected / nicht mehr erreichbar ist hat der server überhaupt keine peers mehr in vorrat ... S sollte sich also mindestens die letzten 10 peers oder so merken



ja da hast du natürlich recht.
Ich denke es ist eine akzeptable idee sich je nach größe des Netzwerks die letzten x peers am server zu merken.

Würde man für die kommunikation eher tcp oder udp heranziehen?


----------



## irgendjemand (29. Dez 2011)

für die kommunikation der clients unter ein ander vermutlich UDP *da du mit STUN / UDP Hole Punching eventuell vorhandene NAT router umgehen kannst ... TCP Hole Punching ist ziemlich schwer* ... ansonsten für die kommunikation mit dem server selbst würde ich TCP verwenden


----------

