"Mentor" und "Mentee" Peers für Junior Upgrades zum Server

Forum for developers

"Mentor" und "Mentee" Peers für Junior Upgrades zum Server

Beitragvon Orbiter » Sa Mai 11, 2013 10:56 am

ich überlege nun wie man den Junior-Peers einen offenen Port über andere Senior Peers durchreichen kann, damit auch Junior Peers durchsuchbar werden können.
Dabei habe ich folgendes Konzept:

- (a) Ein Senior Peer muss einem Junior Peer einen Server Port 'durchreichen'. Ist dies erfolgreich, erlangt der Senior Peer einen neuen Peer-Status, er darf sich dann 'Mentor' nennen. Der Junior Peer bekommt auch einen Upgrade und heisst dannn 'Mentee'.
- (b) Ich habe zwei Optionen in Betracht gezogen, wie der Mentor zum Mentee routen könnte:
(1) entweder per http und dem Host-Namen, der in http/1.1 obligatorisch ist damit ein Server multi-Hosting machen kann. Als Hostnamen würde dann die yacyh-domäne in Betracht kommen, also <peer-hash>.yacyh. Das wäre eine ziemlich transparente Sache. Nachteil: der Mentor kann theoretisch 'mitlauschen'. Daher Option (2):
(2) der Mentor operiert als https-Proxy, routet also über das http:CONNECT Kommando transparent zum Mentee. Das erfordert aber, dass der Mentee seinen Server mit einem ssl Key ausgestattet hat und den https Server Port an den Mentor übergibt. Das erfordert aber, dass der Mentee einen default ssl Schlüssel hat, das habe ich gestern eingecheckt.
- (c) Wenn der Mentor nun also nun ein transparenter https Proxy ist, dann muss man sicherstellen, dass das nicht jeder missbrauchen kann. Es muss also eine Anmeldephase geben, bei der ein Client des Mentors zeigt, dass er ein YaCy Peer ist und auch einen Suchindex hat, den der Mentor testen kann bevor er dem Junior den Mentee-Status gibt.
- (d) damit der Mentee keine Belastung für RAM und IO des Mentors ist, darf der Mentor beim 'Durchreichen' weder zwischenspeichern noch IO machen. Das geht leicht, ein transparenter Proxy braucht fast nichts.
- (e) damit der Mentor einen guten upstream hat, muss dafür ein Root Server o.ä. vorhanden sein. Das können wir ja inzwischen identifizieren, das sind die 'Node Candidates'. Ein Junior sollte also nur Node Candidates anfragen, um einen Mentor zu bekommen und somit Mentee zu werden. Alternativ kann ein Peer direkt benannt werden können, damit man das selbst managen und testen kann.
- (f) Damit ein Routing zu einem Mentee möglich wird, muss der Mentee seinen Mentor im eigenen Seed benennen. Damit diese Info nicht zu schnell veraltet, sollte ein Mentee bei jedem Start den gleichen Mentor um Routing bitten.
- (g) Analog zu (f) muss ein Mentor einen wiederkehrenden Mentee bevorzugt aufnehmen, wenn er diesen schon vorher mal akzeptiert hat. Ansonsten kann ein Mentor natürlich einen Mentee ablehnen, wenn er über eine Kapazitätsgrenze ist. Wo diese Grenze ist, müssen wir herausfinden.
- (h) Default-Einstellungen: ein Senior Peer sollte per default Mentees akzeptieren, jedoch sollte es eine Funktion geben, dies auszuschalten. Aber per default eben an, sonst machts keiner. Wem die Sicherheitsmechanismen zu gering sind, damit getestet werden kann dass ein Mentee auch ein YaCy Peer ist, der kann das ja ausschalten. Wir müssen also sehr stark an (c) arbeiten, damit das mehr oder weniger sicher ist.
- (i) Für Mentor und Mentee sollten Visualisierungen in die Netzgrafik und Tabelle, das habe ich schon mit neuen Icons vorbereitet. Entsprechend sollte die Statistik dann von mehr aktiven Peers berichten.
- (j) Folgeeffekt von (i): wir wissen ja gar nicht wieviele Junior Peers momentan vorhanden sind, wir wissen nur welche Junior Peers überhaupt mal beim eigenen Peer 'geklingelt' haben. Das sind wahrscheinlich viel weniger als tatsächlich vorhanden sind aber gleichzeitig ist die Zahl viel höher als aktive Peers vorhanden sind. Wenn dieser Effekt bei den Mentees behoben werden sollte, muss ein Mentor davon berichten welche Mentees bei ihm gemeldet sind. Dies könnten wir schonmal vorab 'simulieren', indem Node Peers in ihrem hello respone auch bekannte junior peers mit angeben.

Bitte mithelfen das durchzudenken, was kann man verbessern, was habe ich übersehen?
Orbiter
 
Beiträge: 5787
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon Huppi » Sa Mai 11, 2013 1:35 pm

Das klingt spannend! Der Wert der Junior-Peers könnte so deutlich erhöht werden.
Huppi
 
Beiträge: 898
Registriert: Fr Jun 29, 2007 9:49 am
Wohnort: Kürten

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon LA_FORGE » Di Mai 14, 2013 3:13 pm

Absolut genial, Michael! Hut ab!

Das das Netz weitaus größer ist als yacystats.de anzeigt habe ich ja schon vor einiger Zeit herausgefunden. Man muss nur mal Wireshark ein paar Stunden mitlaufen lassen und auf dem Port wo yacy "von außen" erreichbar ist mitlauschen und sich die IPv4 Endpoints anzeigen lassen (Menü Statistics => Endpoints). Es ist unfassbar, aus welchen Teilen der Welt dort Verbindungen zusammenkommen :-)
LA_FORGE
 
Beiträge: 552
Registriert: Sa Okt 11, 2008 5:24 pm

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon LA_FORGE » Mi Jun 12, 2013 8:09 pm

<klugscheisser>

Verschlüsselte Verbindungen zwischen den Peers wäre super, dann würde auch sowas nicht mehr passieren :D

</klugscheisser>
LA_FORGE
 
Beiträge: 552
Registriert: Sa Okt 11, 2008 5:24 pm

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon Orbiter » Do Jun 13, 2013 9:19 am

LA_FORGE hat geschrieben:Verschlüsselte Verbindungen zwischen den Peers wäre super

genau so soll das auch laufen, als Vorbereitung dazu gibts ja nun die SSL-Option, die du unter /ConfigBasic.html am Flag "with SSL (https enabled)" einschalten kannst. Bei einem Mentee würde das automatisch aktiviert werden.
Orbiter
 
Beiträge: 5787
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon LA_FORGE » Fr Apr 04, 2014 9:46 am

Kommt die Funktion mit Mentor & Mentee erst in der 2.0 oder schon früher?
LA_FORGE
 
Beiträge: 552
Registriert: Sa Okt 11, 2008 5:24 pm

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon Orbiter » Fr Apr 04, 2014 5:41 pm

im Januar hatte ich gehofft das bis heute zu schaffen damit die YaCyPi Peers das nutzen können. Ich bin aber nicht so weit gekommen das zu schaffen, zu viele andere Aufgaben waren auch wichtig.
So kann ich auch keine Roadmap nennen, das kommt wenn mal Zeit dazu ist...
Orbiter
 
Beiträge: 5787
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon Erik_S » Sa Sep 06, 2014 5:13 pm

Hallo,

Orbiter hat geschrieben:(a) Ein Senior Peer muss einem Junior Peer einen Server Port 'durchreichen'. Ist dies erfolgreich, erlangt der Senior Peer einen neuen Peer-Status, er darf sich dann 'Mentor' nennen. Der Junior Peer bekommt auch einen Upgrade und heisst dannn 'Mentee'.
Das "durchreichen" ist das Problem, wenn Junior nicht von außen erreichbar ist kann er eben auch nicht vom Mentor bei ankommenden TCP-Verbindungen auf den (vermutlich) zusätzlichen TCP-Server-Port am Mentor informiert werden. Das bedeutet das Junior, wenn er Mentee werden will, eine permanente TCP-Verbindung von sich zum Mentor aufbauen muss über die dann die für ihn beim Mentor ankommenden TCP-Verbindungen getunnelt werden können. Dazu reicht ein HTTP-Proxy in jedem Fall nicht aus, das CONNECT-Kommando erstellt keinen Server-Socket am WWW-Interface des Proxys sondern leitet eine Verbindung von einem Client (am LAN-Interface des Proxys) nach außen weiter, der Nutz-Inhalt dieser Verbindung muss dabei nicht zwingenst HTTP oder HTTPS sein aber das spielt für YaCy ja keine Rolle.
(bei den Proxy-Interface-Namen habe ich an dieses Bild gedacht: http://docs.endian.com/archive/2.1/imag ... figure.png , das soll auch keine Schleichwerbung sein sondern war nur das erst beste was die Bildsuche ergab)

Orbiter hat geschrieben:- (b / 1) entweder per http und dem Host-Namen, der in http/1.1 obligatorisch ist damit ein Server multi-Hosting machen kann. Als Hostnamen würde dann die yacyh-domäne in Betracht kommen, also <peer-hash>.yacyh. Das wäre eine ziemlich transparente Sache. Nachteil: der Mentor kann theoretisch 'mitlauschen'.
Aber über eine HTTP-Verbindung vom Mentee zum Mentor können eben keine neuen Verbindungen vom Mentor zum Mentee aufgebaut/getunnelt werden.

Orbiter hat geschrieben:- (b / 2) der Mentor operiert als https-Proxy, routet also über das http:CONNECT Kommando transparent zum Mentee. Das erfordert aber, dass der Mentee seinen Server mit einem ssl Key ausgestattet hat und den https Server Port an den Mentor übergibt. Das erfordert aber, dass der Mentee einen default ssl Schlüssel hat, das habe ich gestern eingecheckt.
Auch eine Verschlüsselung zwischen Mentee und Mentor ändert an den Grenzen des HTTP:CONNECT nichts. Nebst dessen das wenn die Daten den Mentor nach Außen (ins öffentliche Internet) verlassen sind sie unverschlüsselt und damit vom Mentor mitlesbar. Der Mentor (wie jede andere Art Proxy auch) kann grundsätzlich immer mitlesen außer der Mentee (Client) benutzt echte Ende-zu-Ende-Verschlüsselung, aber dann kennt der Mentor immer noch die IP-Adresse des Kommunikationspartners. Aus diesem Grund ist das Tor-Netz ja so komplex.

Orbiter hat geschrieben:- (c) Wenn der Mentor nun also nun ein transparenter https Proxy ist, dann muss man sicherstellen, dass das nicht jeder missbrauchen kann. Es muss also eine Anmeldephase geben, bei der ein Client des Mentors zeigt, dass er ein YaCy Peer ist und auch einen Suchindex hat, den der Mentor testen kann bevor er dem Junior den Mentee-Status gibt.
Egal wie toll der Anmeldevorgang auch sein mag er ist definitiv umgehbar und damit ist der Mentor ein öffentlicher transparenter Proxy und das wäre für jeden Betreiber eines Root-Servers der perfekte Albtraum.
Zum Austricksen könnte ich mir vorstellen das man ein Client-Programm baut das einem intern laufenden YaCy-Junior-Peer als externes HTTP-Proxy dient, dieses Client-Programm fängt dann alle Dinge die für die Mentor-Mentee-Sache relevant sind ab und leitet alle Requests des internen YaCy-Junior-Peers nach außen (über den Mentor) durch. Bei der Anmeldung benutzt dieses Client-Programm den internen YaCy-Junior-Peer um sich dem Mentor gegenüber auszuweisen nur ohne das der interne YaCy-Junior-Peer was davon hat. Auch eine Verschlüsselung würde nichts nutzen da die Schlüssel des YaCy-Junior-Peers ja abgreifbar sind (selbst Closed-Source-Programme sind da nicht sicher) und somit das Client-Programm alles mitlesen und auch ändern kann. Abschließend bräuchte dieses Client-Programm nur noch ein weiteres Proxy-Interface (beliebigen Typs) über das dann "böse" Dinge über den Mentor geleitet werden können.

Orbiter hat geschrieben:- (h) Default-Einstellungen: ein Senior Peer sollte per default Mentees akzeptieren, jedoch sollte es eine Funktion geben, dies auszuschalten. Aber per default eben an, sonst machts keiner. Wem die Sicherheitsmechanismen zu gering sind, damit getestet werden kann dass ein Mentee auch ein YaCy Peer ist, der kann das ja ausschalten. Wir müssen also sehr stark an (c) arbeiten, damit das mehr oder weniger sicher ist.
Wenn das wirklich Default würde wäre das ein sehr gutes Argument YaCy zu deinstallieren. Die meisten Leute die ich kenne mögen es nicht wenn Sicherheitslecks (und ein transparender Proxy ist ein enormes Sicherheitsleck) per Default aktiv sind. Mit keiner Maßnahme an Punkt (c) lässt sich dieses Sicherheitsleck stopfen, höchstes minimal verkleinern.

Mir ist natürlich klar das die Junior-Peers eine beachtliche Ressource sind und es wäre echt toll damit das YaCy-Netzwerk spürbar zu vergrößern aber den Weg über einen transparenten Proxy halte ich persönlich für sehr gefährlich.
Was ist den das genaue Ziel der Aktion, also welche Features sollen Juniors als Mentee bieten können?

Ich denke das wichtigste wäre das der Index (also der Speicherplatz) der Mentees für das Netzwerk als ganzes nutzbar werden soll aber dafür müsste der Mentor doch nur seine Mentees mit in der globalen Seed-Liste veröffentlichen und sich selber jeweils als Mentor ausgeben (anstatt IP-Adresse und Port), ich denke mal dass das nicht das große Problem ist. Dann könnte der Mentor die Suchanfragen, die eigentlich an einen Mentee gerichtet sind, an seinem öffentlichen Interface entgegennehmen und nach erfolgreicher Prüfung das es sich dabei auch wirklich um eine korrekte Suchanfrage handelt diese an den Mentee weiterreichen. Ebenso sollten alle HTTP-Requests die den Mentor erreichen aber im Host-Feld des HTTP-Headers einen *.yacy-Host spezifizieren der einem seiner Mentees entspricht an eben den betreffenden Mentee weitergeleitet werden. Vom Mentee nach außen gehende Verbindungen sollten nicht über den Mentor gehen sondern direkt vom Mentee zum gewünschten YaCy-Peer laufen, das funktioniert ja jetzt schon. Bleibt als Problem nur die Art der Verbindung zwischen Mentee und Mentor, man benötigt ein Protokoll das mehrere HTTP-Verbindungen parallel und auch in Richtung vom Server (Mentor) zum Client (Mentee) durchleiten kann. Ich bin mir da nicht ganz sicher aber ich glaube HTTP2 sollte das können, da wird vom Client eine TCP-Verbindung zum Server aufgebaut und anschließend werden beliebige HTTP-Requests in beliebiger Richtung über diese eine TCP-Verbindung ausgetauscht, TLS-Verschlüsselung ist auch schon mit drin. Wenn gewünscht schaue ich mir HTTP2 noch mal genauer an um zu klären ob das wirklich Out-of-the-Box taugt.
Dieses Vorgehen würde erreichen das auch die Juniors zu nutzbaren YaCy-Peers werden aber eben keinen transparenten Proxy bedeuten. Nebst dessen das die Last auf den Mentors relativ klein bleibt da nur Verbindungen zum Mentee über den Mentor müssen aber Verbindungen vom Mentee direkt (ohne Mentor) ablaufen, gerade letzteres stellt sicher das ein Mentor kein (transparenter) Proxy wird.

Grüße
Erik

edit:
Orbiter hat geschrieben:- (b / 2) der Mentor operiert als https-Proxy, routet also über das http:CONNECT Kommando transparent zum Mentee.
Ah, Du meinst der Mentee soll einen Server-Port anbieten an den der Mentor sich wendet um bei ihm ankommende Verbindungen die für den Mentee bestimmt sind weiterzureichen. Aber gerade der Umstand das ein Junior-Peer nicht von außen erreichbar ist (weil er z.B. hinter einem nicht managbaren NAT steckt) macht ihn doch erst zum Junior und damit ist es eben auch unmöglich das der Mentor (der aus Sicht des Junior-Peers ja "Außen" ist) ihn erreichen kann.
Erik_S
 
Beiträge: 185
Registriert: Sa Aug 30, 2014 11:13 am

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon LA_FORGE » So Nov 01, 2015 4:08 pm

http://www.cs.stir.ac.uk/courses/ITNP99 ... addadZ.pdf

Habe ich gerade gefufnden. Evtl. hilfreiches Dokument zu dieser Thematik. Wäre auch eine Implementierung über UDP für die YaCy <=> YaCy Kommunikation denkbar oder ist der Aufwand dafür zu hoch?
LA_FORGE
 
Beiträge: 552
Registriert: Sa Okt 11, 2008 5:24 pm

Re: "Mentor" und "Mentee" Peers für Junior Upgrades zum Serv

Beitragvon biolizard89 » Mi Nov 25, 2015 1:08 am

I'm not sure if this has been suggested elsewhere, but why not just use Tor hidden services for peer communication? It gives you NAT punching that works quite well, and as a free bonus you get location anonymity.
biolizard89
 
Beiträge: 61
Registriert: Do Jan 03, 2013 12:42 am


Zurück zu YaCy Coding & Architecture

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron