Emule mod mit I2P netzwerk unterstüzung

[Stulle]

Ich weiß nich ob du mich nicht verstehen willst oder ob ich so undeutlich schreibe! I2P verändert die Kommunikation zwischen den Clients! Will ich umsteigen, muß ich die Kommunikation umstellen. Wie in deinem ersten Post schon stand, es muß von TCP-IP auf I2P umgestellt werden. Und das fängt wieder das Problem an was ich schon mindestens zum 3. Mal nenne: entweder zweigleisig oder eingleisig und langsam! In jedem Falle wird es nix ohne weiteres. Darum wird so schnell niemand so ein System einbauen. Wenn eMule doch irgendwann in den "sicheren" Bereich geht, dann wird sicher eher auf die Lösung von Jed McCaleb genommen, der seines Zeichens eDonkey Gründer ist und momentan an einem sicheren client arbeitet.

MFG Stulle

PS: Hör auf irgendwas zu zitieren und dann am besten noch 3 Posts hintereinander! 1. Board Rules --> keine Doppelposts; 2. Wenn du etwas zitierst, dann gibt es die "Quote" Funktion! 3. Wenn du Fremdinhalte zitierst mußt du schon Links angeben! Und bitte, wiederhole nicht dauernd die selben Erläuterungen über Ziel usw. Wir haben es doch verstanden, sind ja nicht alle miterinander kirre!

[MAtrixNet]

Ich will nur wissen ob interesse besteht das ein modder so was Programmiert ?


mehr infos über I2P
board.planetpeer.de

[Stulle]

Das habe ich doch bereits in meinem letzten Thread gesagt. Die offiziellen Devs werden sicher nix tun um die Abwärtskompitabilität des Netzwerkes zu unterbinden! Und ich denke auch nicht, dass ein anderer eMule coder das tun würde!

MFG Stulle

[Xman]

hab mal kurz die Seite überflogen und das was Du sagtest..
mir fallen dazu nur zwei Dinge ein:
um wirklich anonym zu sein, darf keine Client->Client Kommunikation stattfinden, sonst weiß ja schließlich Client A die IP von Client B... also muß ein oder mehrere Client C dazwischengeschalten werden. Das Problem dabei: die Bandbreite geht verloren... und genau wegen dieses Problems gibt es auch noch keine "Anonymisierung" für emule. Sollten wir mal Uploadkapazitäten von >1MBit haben sieht die Sache anders aus.
Des weiteren: weißt Du wie kompliziert und arbeitsaufwendig es ist Deine Idee in emule einzubauen ? Wahrscheinlich würde es für einen sehr guten Modder so einige Monate intensiver Arbeit benötigen.

[MAtrixNet]

Die devs vom Emule-project.net werden glaub auch nichts tun.

Habe gedacht das vieleicht ein modder interesse hätte!.
Noch was mir Intressiert das mit socks4a proxy das ja nicht richtig funktioniert oder?
stimmt das?siehe link:http://archives.seul.org/or/talk/Aug-2004/msg00017.html


Weil ich selber mit socks4a auch gestestet habe.

mfg

matrixnet

[MAtrixNet]

um wirklich anonym zu sein, darf keine Client->Client Kommunikation stattfinden, sonst weiß ja schließlich Client A die IP von Client B... also muß ein oder mehrere Client C dazwischengeschalten werden. Das Problem dabei: die Bandbreite geht verloren... und genau wegen dieses Problems gibt es auch noch keine "Anonymisierung" für emule.

Ja das stimmt schon, aber sollte nur über I2P laufen dann gibts keine konflikte mit normalen emule usern.
Bei I2P kann ein emule I2P nicht direct zu emule I2P kommunizieren, sondern


I2Pemule nimmt kontakt zu I2P und der gibt die daten weiter zu einem anderen I2Pemule

[aalerich]

Ja gut, und wer ist I2P?
Der hat nämlich massig für ihn nutzlosen Traffic...

Mit fragenden Grüßen
aalerich

[MAtrixNet]

du weist doch was I2P ist oder? kennst nicht?

[Mrothyr]

Zitat von aalerich

Ja gut, und wer ist I2P?
Der hat nämlich massig für ihn nutzlosen Traffic...

Hmm, der würde aber recht gut damit leben, daß Traffic für ihn über andere Nodes anonymisiert wird.

I2P ist, wenn ich mich recht erinnere, ein Seitenprodukt der Freenet-Entwicklung. Statt daß wie im Freenet halt ein virtueller Datenspeicher geschaffen wird wird per I2P ein virtuelles Netzwerk definiert, dessen "Netzwerkadressen" kryptographische Schlüssel sind.

Real ist es so, daß die Pakete von Nutzer A an Nutzer B über Nutzer N gesendet werden - wobei Nutzer A nicht weiß, welche Netzadresse Nutzer B hat, da dies Nutzer N (bzw N+x) ermittelt. Hat viel vom oft zitierten "Onion-Routing" an sich.

Im konkreten Fall ist es (aus dem Kopf) so, daß Nutzer A zu Nutzer B eine persistente Verbindung aufbaut, indem in der Phase des Verbindungsaufbaus sein Paket über mehrere Stationen zur Tunnelverschleierung gesendet werden und auf der Seite von Nutzer B ebenso über mehrere Stationen zur Tunnelendeverschleierung gerutet werden. Diese Kette von Stationen bietet jetzt quasi eine Mixkette nur für diese eine persistente Verbindung. Da jedes Tunnelende aus n Stationen besteht weiß keine Station des Tunnelendes, ob die nachgeordnete Station Empfänger oder Mix ist. Gefunden wird diese Kette durch eine Implementierung des XOR-Algorithmus, der ja auch als "Kademlia" bei Emule Verwendung findet. Dieser Mechanismus wird für jede Verbindung durchlaufen (auch für jedes UDP-Paket, was eventuell durchgeleitet wird), so daß sich keine festen Verbindungen ausbilden können. Geschützt werden die Daten durch Ende-Ende-Verschlüsselung (asymmetrische Verschlüsselung, I2P-Adresse ist gleichzeitig öffentlicher Schlüssel) und Node-Node-Verschlüsselung (symmetrisch) - weswegen auch die plausible Verneinung betreffs der Kenntnis des Inhaltes (analog Freenet/Entropy) möglich ist.

Realisiert ist I2P in Java, was es mir eher unsympathisch macht - braucht man doch noch eine VM auf dem Rechner. Bei einem Arbeitsplatzrechner mit Mainstream-Betriebssystem ja noch machbar - auf nem Exoten oder gar auf einem Router ist das doch eher die Ausnahme. ANSI-C zum Selbstkompilieren wäre die bessere Idee.

Ich hab vor Ewigkeiten mal ein Emule-Modding mit Ziel I2P geprüft (das Thema "Anonymisierung" taucht ja auch hier regelmäßig auf). Ein Problem verleidete mir die Lösung (wenn man davon absieht, daß Neuimplementierung von Emule für I2P wahrscheinlich die einfachere Lösung wäre) - wenn ich mich geirrt habe, wäre ich für eine entsprechende Korrektur dankbar: Emule arbeitet intern nicht mit einem Abstraktionslayer für die Verbindungen, sondern das gesamte Verbindungsmanagement setzt direkt auf die IP-Adresse auf. I2P dagegen arbeitet mit kryptographischen Adressen bzw. mit entsprechend angepaßten DNS-Namen. Es wäre erforderlich gewesen, das gesamte Connection-Management neu zu implementieren, um neben den IP-Adressen auch I2P-Adressen zu unterstützen. Ein Problem, das auch im Hinblick IPv6 akut werden dürfte. Kademlia verteilt entsprechend auch keine I2P-Adressen bei der Quellensuche, der Rewrite eines Emule-Servers für I2P, um zumindest mit Indexservern arbeiten zu können, wäre angesagt gewesen.

Allgemein gesagt: Ich bin sicher, es gibt Interesse für ein I2P-Emule. Und ich teile auch nicht die geäußerte Meinung, daß dem Netzwerk die Nutzer fehlen würden. Emule selbst hatte ebensowenig wie Overnet/Kademlia von Anfang an hunderttausende Nutzer.

Ich wäre für einen sanften Migrationsweg. Ähnlich wie heute die Ressourcen des Overnet den Kademlia-Nutzern (und umgekehrt) über das klassische Emule-Netz zur Verfügung stehen könnte der Wechsel zu einem Anonymisierungssystem wie I2P auf die Art sanft vollzogen werden. Nutzer kommen dann von selbst - ich denke nur dran, wieviele "Early Adopters" die Kademlia-Quellensuche damals hatte, obwohl sie noch gar nicht offiziell implementiert war, sondern nur in einigen Betas auftauchte (ich selbst bin deswegen damals von Sivka zu Morph geswitcht). Auch Webcache hatte nich gleich von Anfang hunderttausende Nutzer, sondern brauchte erst mal einen beschränkten Test, ehe man es auf den Normalnutzer loslassen konnte. Und nebenbei: Es taugt nichts, Diskussionen über eisnchlägige Lösungsansätze mit "hat nicht genug Nutzer" wegzuprügeln - die Nutzerzahl eines Netzes ist primär ein Henne-Ei-Problem, das die Entwicklerseite nun mal nur an einer Seite (nämlich dem Angebot einer zusätzlichen Funktion) angehen kann.

Den Vergleich mit Eh-Em-Krüpt find ich verfehlt - das war eine Abzocke und kein echtes Anonymisierungskonzept.

Was die User-Anzahl betrifft: I2P ist als Netzwerklayer konzipiert. Emule wäre eine der Applikationen, die das Netzwerk benutzen. Das Netzwerk benötigt viele User, um dem Anonymisierungsanspruch gerecht zu werden und die Geschwindigkeit zu steigern - die Portierung vieler Applikationen auf das Netzwerk würde jeder Applikation zugute kommen (im Gegensatz zu einem rein auf Emule beschränkten Anonymisierungs-Layer). Ein Vorteil wäre außerdem, auf das doch recht fragwürdige Kreditsystem verzichten zu können - Clients, die nicht uploaden, also sich nicht als Mix einsetzen lassen, würden rein protokollbedingt bereits aus dem Netzwerk fallen. Das Netzwerk organisiert sich weitgehend selbst - da ist Uploadkapazität zwingend notwendig (da Kontroll-Messages nicht über getrennte Kanäle gehen).

CU

PS: Ich hab das aus dem Kopf repetiert - ich habe mir I2P letztmalig vor einem Jahr angesehen und weiß nicht, welche Änderungen bis heute vorgenommen wurden. Konzeptionell ist es aber definitiv interessant (auch wenn ich das Tunnelkonzept nur suboptimal finde - ein echter Onion-Router wäre mir lieber).

[MAtrixNet]

danke ein gutes beitrag von dir .

es gibt einige erneuerungen in I2P,
unter http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/history.txt?rev=HEAD
kannst all änderungen anschauen.

seit september 2004 gibts ja I2P Bittorrent wenn du es nicht mitbekommen hast.
und alle anderen dienste wie I2P mail(POP3 / SMTP), I2P Irc,freenet proxies usw, einige mengen von eepseiten sogar ein google basiertes suchmaschine für I2P,usw brauche hier nicht aufzählen siehst wenn du mal vorbei schaust bei i2P.



mfg

matrixnet

[MAtrixNet]

Bald in den nächsten Tagen wird es wohl eine frühe alpha version von
vom orginal gnutella client Phex der umgeändert in ein I2P gnutella client i2phex rauskommen.

sieh ein log vom Developer :

2005-04-30

First connections tests are succesfull. I could connect two clients. But the second attempt resulted in the clients going wild...once they knew hosts, the tried to connect to them again and again, ignoring that they connect to the same destinations. Turned out to be a bug when comparing destinations...now I know about the significants of 'equals' and 'hashCode' functions at least.

What is working right now: connection to known destinations, destinations are also distributed throughout the network, you can browse a destinations (and look what this destinations is sharing), you can download files from a destinations (swarm downloading not tested up to now), and even the chatting function of phex is working just fine in i2phex.

What is not working right now: well, i guess alot. but the search seems not to work. somehow, search queries are not send out to the network...I didn't debug that yet, so this is probably a simple error. Alot of things are not tested yet and could work, or couldn't (like banlists, favorites list, bandwidth control, etc, etc.). User interface not adapted one bit. Options dialog now contains things that are not needed for i2phex anymore...will do that sometime later.

I also had a quick talk with jrandom. We think that i2phex will be put under CVS as a seperate module (like bt-i2p). Maybe later, it could be bundled together with i2p for releases. We'll see. Before putting anything in CVS, i want to clean up some things, adapt the ant script and put in some docs, to make it as painless as possible for others to try out. Maybe a mailing list will be available, as well as a channel in irc. But it will take about a week before I release something, please bear with me. Be happy that something came out of this, as i really didn't expect this.

Once in CVS, an announcement will be made, and then hopefully some users will help me test this early alpha version.

schade das kein modder momentan interesse hat an I2P Emule!

[Xman]

und schade, daß Du nicht verstehen willst was aalerich und ich sagten.

[aalerich]

@ Mrothyr und MAtrixNet:

Im Grunde ist das ja alles klar. Technischen Verstand habe ich zwar keinen aber selbst ich weiß, daß es (mit erheblichem Programmieraufwand) möglich ist, auch p2p wirklich sicher zu machen. Die Frage ist die nach dem Preis dafür!

Die Masse der Nutzer hat 16 kb/s Uploadkapazität, davon werden 12 kb/s für das Filesharing freigegeben. Bei allen proxybasierten Lösungen müssen die Daten zu mindestens einem Nutzer hochgeladen und von diesem dann weitergesendet werden, der diese Daten selbst gar nicht braucht. Wenn also Mrothyr eine Datei zu MAtrixNet schicken will lädt er sie erst zu mir hoch. Ich schicke sie dann weiter zu MAtrixNet. Das braucht aber einen Teil meines Uploads. Mein Upload an Daten, die ich hochladen will wird zwangsläufig reduziert und wer von mir etwas haben will bekommt unweigerlich weniger. Und das geht allen Nutzern solcher Netzwerke so, es ist nicht zu ändern. Von den 12 kb/s Upload stehen dann also 6 kb/s zum Hochladen zur Verfügung und die anderen 6 kb/s werden zum Durchleiten der anonymisierten Daten anderer Nutzer verwendet. Ich speise also unter dem Strich in ein solches Netzwerk nur noch 6 kb/s effektiv an Daten ein; von mir kann man also nur noch halb so viel herunterladen. Und ich kann logischerweise von den anderen Nutzern eben auch nur noch mit halber Geschwindigkeit herunterladen. Tatsächlich wird das sogar noch schlechter aussehen, da der "Verwaltungsaufwand", sprich: der Overhead zusätzlich steigt.

Nutzer mit richtig dickem Upload können das verschmerzen. Ich habe 64 kb/s Uploadkapazität. In einem proxybasierten Netzwerk hätte ich also rein rechnerisch einen Downlad-Dauerdurchschnitt von ca. 32 kb/s zu erwarten. Das ist sicherlich nicht schlecht, nur kann ich im normalen Eselnetzwerk eben mit 64 kb/s rechnen. Und wer nur 16 kb/s Kapazität hat müßte dann eben mit ca. 8 kb/s leben; setzt er das Limit bei 12 kb/s blieben noch 6 kb/s. Overhead eingeschlossen. Da liegt der Hase im Pfeffer!

Dennoch sehe ich Hoffnung für die Zukunft, die Uploadkapazitäten werden wohl auch gegen den Widerstand mächtiger Kreise steigen. Und dann wird die Sache ernsthaft interessant. Versöhnlich sage ich es mal so: Solche Entwicklungen sind ihrer Zeit einfach voraus...

Mit freundlichen Grüßen
aalerich

[Januar1956]

Zitat von aalerich

@

Dennoch sehe ich Hoffnung für die Zukunft, die Uploadkapazitäten werden wohl auch gegen den Widerstand mächtiger Kreise steigen. Und dann wird die Sache ernsthaft interessant. Versöhnlich sage ich es mal so: Solche Entwicklungen sind ihrer Zeit einfach voraus...

Mit freundlichen Grüßen
aalerich

Nichts desto trotz, ist es selbstverständlich wichtig, alle Türen aufzuhalten, für den Fall der Fälle.

Januar

[Mrothyr]

Zitat von aalerich

Im Grunde ist das ja alles klar. Technischen Verstand habe ich zwar keinen aber selbst ich weiß, daß es (mit erheblichem Programmieraufwand) möglich ist, auch p2p wirklich sicher zu machen. Die Frage ist die nach dem Preis dafür!

Die Frage ist eher - welchen Preis zahlen wir, wenn wir nicht vorbereitet sind? Bereits heute kann dich irgendein amoklaufender Anwalt mit einer pauschalen Beauftragung nur durch die Behauptung von Urheberrechtsverletzungen zu hohen finanziellen Aufwendungen zur _Abwehr einer Abmahnung_ zwingen. Momentan schützt die Masse der User noch den EInzelnen - nur wie lange dauert es, bis auf der anderen Seite genauso automatisiert Abmahnungen rausgehen könne, weil unsere freundliche Justizministerin eingeknickt ist und den "Rechteinhabern" ein Auskunftsrecht gegenüber dem Provider zugesteht? Und du dann nur wegen einer geeselten OOo-Kopie ne Abmahnung wegen Verletzung von MS-Urheberrechten bekommst?

Zitat von aalerich

Nutzer mit richtig dickem Upload können das verschmerzen. Ich habe 64 kb/s Uploadkapazität. In einem proxybasierten Netzwerk hätte ich also rein rechnerisch einen Downlad-Dauerdurchschnitt von ca. 32 kb/s zu erwarten. Das ist sicherlich nicht schlecht, nur kann ich im normalen Eselnetzwerk eben mit 64 kb/s rechnen. Und wer nur 16 kb/s Kapazität hat müßte dann eben mit ca. 8 kb/s leben; setzt er das Limit bei 12 kb/s blieben noch 6 kb/s. Overhead eingeschlossen. Da liegt der Hase im Pfeffer!

Du setzt technisch an - und es ist unbestritten, daß das technische Problem im steigenden Transfervolumen und der asymmetrischen Anbindung zu sehen ist. Wobei deine Rechnung noch optimistisch ist - ein einzelner Mix dazwischen schützt nicht gegen MitM-Attacken. Das Nutzdaten-Transfer-Verhältnis wird noch gravierend schlechter als 1:2 sein.

Aber: Unabhängig der entstehenden Datenraten wird man in Zukunft überlegen müssen, wer wann welche Dateien freigibt. Grad repressive Gesetzgebung mit überbordenem Rechtsmittelaufwand wie in Deutschland gibt wenig strafrechtliches, dafür aber umso mehr zivilrechtliches Risiko speziell im vorprozessualen Bereich.

[/QUOTE]Dennoch sehe ich Hoffnung für die Zukunft, die Uploadkapazitäten werden wohl auch gegen den Widerstand mächtiger Kreise steigen. Und dann wird die Sache ernsthaft interessant. Versöhnlich sage ich es mal so: Solche Entwicklungen sind ihrer Zeit einfach voraus...[/QUOTE]

Mag sein. Aber nur wer seiner Zeit voraus ist kann auch mit einer fertigen Lösung aufwarten, wenn die Zeit da ist

Ich find I2P so interessant, weil da IMO von der richtigen Richtung her das Problem angegangen wird. Ich war ja einige Zeit bei Entropy aktiv (mein Node läuft immer noch) - aber in meinen AUgen haben eigenständige Clients keine ZUkunft, da damit die einzelnen Applikationen um die Netzkapazität konkurrieren. I2P definiert einen Netzwerklayer, auf den die einzelnen Applikationen aufsetzen - und wo die Applikationen nicht um die Netzwerkkapazität konkurrieren. Damit wird ein I2P-Webbrowser, der eine EEP-Site ansurft, auch seine eigene Upstream-Kapazität dem Netz zur Verfügung stellen, obwohl er selbst eigentlich nur Downstream benötigt. Dies kann bei entsprechender Netzgröße schon gravierende Vorteile bringen.

Persönlich wollte ich eigentlich einen virtuellen Netzadapter für mein OpenBSD schreiben, der I2P auf ein lokales IPv6-Subnetz mappt und so beliebigen IPv6-kompatiblen Applikationen das I2P-Netz zur Verfügung stellt (ich halte die direkte Anpassung von Applikationen für einen grundsätzlichen Design-Fehler). Allerdings ist das mangels Zeit in der Planungsphase stecken geblieben

Ja, ich sehe das heute mehr oder weniger als Technologiestudie - was nicht heißt, daß man morgen nciht darauf zurückgreifen muß. Daß ich paranoid bin heißt nicht, daß niemand hinter mir her ist

CU