Dezentraler Chat?

[Sanguis]

mh.. Ich mische mich dann auch mal ein.
Ich fürchte ihr überseht ein ganz erhebliches Sicherheitsproblem.
Wenn man das wirklich RICHTIG aufziehen will, wird man nicht drumrum kommen ein eigenes Protokoll zu basteln.
Wenn ich mit dem Client "nur" per FTP auf nen zentralen Server zugreife ode ein normales Datenbank Login verfahren nutze, dann kann ich als "User" nen einfachen Packet Sniffer dazwischen setzen und fein die Datenbank und FTP Passwörter auslesen. Es werden zwar hoffentlich nicht die Root passwörter sein.. aber das wären trotzdem Passwörter die dafür reichen würden den ganzen Server dienst zu stören.

DAS ist halt das hauptproblem bei einem Server in der Mitte. Die Verbindung zu selbigen sollte sicher aufgebaut werden können. 100%ige Sicherheit gibt es zwar nie. Aber man sollste es auch nicht ZU leicht machen.

[DataCool]

Hi,

Sanguis hat absolut recht, es muss natürlich ein eigenes Chat-/Kommunikationsprotokoll her mir dem über den "Men in the middle" kommuniziert wird.
Alles andere wäre ja geradezu eine Einladung zum Hacken.

Gruß Data

[Phantomix]

Jetzt mische ich mich auch mal ein.

Ich komme ja eigentlich aus der Gnutella-Ecke / VB-Ecke und hab dort schon einige größere Projekte hinter mir


Für einen dezentralen Chat brauchst du dringend ein gutes Protokoll, lasst mal diese http/ftp sache, das ist käse (sry)
Es existieren bereits Lösungsansätze dafür, wie man ein beliebig großes Chatnetzwerk aufbauen kann mit vielen servern und vielen clients, wo auch berücksichtigt wird daß chatserver nicht so stabil sein müssen wie server im internet (DSL geht ja öfter mal offline und so... beim chatten nervt sowas wenn der gegenwärtige server grad alle verbindungen verliert


Es gibt bisher 2-3 "Proposal"-Texte die so etwas sehr ausführlich beschreiben, aber noch kein 100% fertiges protokoll.
Ich bin bereit weiter darüber zu diskutieren, würde es aber begrüßen wenn sich daraus so etwas wie ein team entwickelt welches das protokoll entwickelt.



Das Routerproblem mit der öffentlichen IP adresse lässt sich leicht lösen, wenn man eine Verbindung zu einem Server herstellt, denn dann weiß dieser Server bereits, von wo die Verbindung kam (IP-Adresse, zufallsport) und kann ggf dem client die öffentliche ip-adresse zusenden

[Puhbaehr]

Hallo!

Nicht schlecht deine Idee mit den Team... Soweit gut, nur...

Zitat von Phantomix:

...
Das Routerproblem mit der öffentlichen IP adresse lässt sich leicht lösen, wenn man eine Verbindung zu einem Server herstellt...

Wie kann ein Client eine Verbindung zu einem Server herstellen wenn er keine IP kennt?
Wenn es viele hunderte Server gibt kein Problem. Noch besser wenn sie über mehrere Kontinente verteilt sind (wegen Zeitverschiebung) da die Chance höher ist das immer einer Online ist (wobei die Zeit bis ein Server mit aktueller IP gefunden wird sehr hoch sein kann). Wenn du mindestens einen mit einer festen IP hast super, aber dann wird sich dieser oder diese wenigen innerhalb kurzer Zeit zum Stammserver, also zum Hauptserver womit das Prinzip hinüber wäre. Aber wenn es nur ein paar wenige sind und doch mal alle Offline sind und alle dazu eine dynamische IP?
Ok, man könnte Hosts anlegen bei denen die IP regelmäßig aktualisiert wird (dyndns). Aber damit hättest du wieder mindestens einen Server. Nämlich der der auf dem die IPs zu den Hosts stehen.

Gruß, Robert

Edit: Mir fällt grad ein, nicht nur das Thema Chat hat dieses Problem. Ich denke da nur an den Versuch P2P Serverunabhängig zu machen.

[Phantomix]

Das ist auch ein bereits gelöstes Problem

In Gnutella wurde dieses Problem durch Programme auf server-rechnern gelöst die dann aktuelle ip-adressen ausspucken... gut das läuft auf zentralen servern, aber niemand hindert dich daran, dir selbst so etwas einzurichten! So in der Art kann man das organisieren. Außerdem kann der client ja IP-adressen von "guten" servern (die das netzwerk als oft-online einschätzt) lokal speichern und probieren.

ja es dauert vielleicht ne minute länger bis man verbunden ist, aber es funktioniert idiotensicher.

[Puhbaehr]

Ok, wenn du diesen Kompromiss eingehst Aber das würde von der Aufgabenstellung "dezentraler Chat" abgehen. Irgendwo ist dieser dann doch zentral. Oder anders gesagt: Ohne eine "Zentrale" funktioniert es nicht auf ewig.

Aber auf der anderen Seite bin ich dafür mal ein Pilotprojekt zu starten. Vielleicht sind ja doch die "Server/Clienten" öfter Online als gedacht und sie schaffen es immer irgendwo eine Verbindung zu halten, dass also immer einer online ist.
Allerdings - nächstes Problem - muss jeder Rechner wirklich jeden Rechner der zum Netzwerk gehört in einer Liste führen. Gut, angesichts der heutigen Kapazitäten sollte das auch kein Problem sein. Mmh... ich stell mir diesen Chat trotzdem sehr "hängend" vor wenn er verbindet... ob das stabil läuft? Aber ich bin für einen Versuch!

[Phantomix]

Wenn jemand eine DSL-Flatrate hat kann er das ja 24/7 laufen lassen ohne dass es ihm weh tut! und als host/ip kann man dann ja dyndns.org oder no-ip.com adressen nehmen



dieser "kompromiss" wurde bisher in keiner p2p applikation vernünftig gelöst, weil es einfach keine Lösung gibt!
ed2k? hat zentrale server. Morpheus? basiert auf Gnutella Kazaa? na lassen wir das mal


es wäre insofern p2p daß es keine zentralen Server in einem derartigen Netzwerk gibt sondern dieser "ip-registrierungs-dienst" ohne das netzwerk und vice-versa existieren können. es muss eben nur genügend aktive IP-adressen geben die der client kennt.


Zitat:
Allerdings - nächstes Problem - muss jeder Rechner wirklich jeden Rechner der zum Netzwerk gehört in einer Liste führen.

Nein. Ich bin für eine IRC-ähnliche struktur mit "channels" und dem dahinter liegenden netzwerk. außerdem sollte die größe eines netzwerksegmentes auf sagen wir 10 server und 500 clients beschränkt sein. nennen wir das mal eine "bubble" (der topologische aufbau den ich dazu erarbeitet hab erklärt den begriff genauer*g*)

jeder client kann in mehreren dieser "bubbles" sein und so, wenn er will, das ganze netzwerk erreichen. allerdings müssen die server einer "bubble" alle clients der selben "bubble" kennen.

[Phantomix]

ich hab eigentlich auch schon vor ewigkeiten im irc einen diskussionschannel für sowas eingerichtet nur ist der im moment ziemlich leer. vielleicht kommt ja ne diskussion zustande, würde mich freuen

irc.p2pchat.net:6667 channel #moonchat

[Puhbaehr]

moonchat ^^

Gnutella? edonkey kenn ich, KaZaA...wer kennt kazaa nicht? morpheus kenn ich zumindest vom hören her, aber Gnutella? Muss man sich erstmal schlau machen. Also lebt dieses Prinzip des serverlosen "Kommunizierens" ja eigentlich schon. D.h. das Protkoll nutzen und zum Chatprotokoll umsetzen. Was wäre denn das Projekt wirklich gänzlich ohne jeglichen Einsatz eines einzigen Servers zu starten? Ist Anfangs sicher schwer...aber nicht unmöglich.
"Große Chats" verlieren selbst Nachts ihre Besucher nicht. Es sind immer ein paar die lange bis in die Nacht hinein tippen und welche die bereits am frühen morgen tippen. Wenn sich das also wirklich als so groß entwickeln sollte wäre immer jemand da.
Würden wir als Beispiel sagen: 06.06.2006 ist offizieller Logintermin an dem ein einziger seine IP als "Startserver" hergibt und sämtliche Clients zu dieser Verbinden. Sämtliche Clients senden ihre IP an diesen Server wodurch neue Clients diese IPs mitnehmen können. Sobald ein Client seine IP erstmals freigegeben hat fungiert er als Server. Einziges Problem das ich noch sehe:
P2P wäre weniger etwas für Leute die nur Briefe schreiben, Mails schreiben, chatten Aber grade die einfachen Leute brauchen wir. Deswegen sollte jeder das Protokoll nutzen können. Warum auch nicht die Schwester dafür begeistern? Aber Firewalls werden den normalen User daran hindern einen Server zu eröffnen. Aber genau diese Gruppe brauchen wir ebenfalls um das Netzwerk stark zu machen. Und mal ehrlich: Wie viele "normale" Leute, also solche die den PC am Monitor einschalten wollen (kennt jeder ) und die eigentlich nur eine Maus mit zwei Tasten kennen, treffen wir im IRC-Channel? Wie viele davon treffen wir in einem einfachen HTTP-Chat wie Lycos, YaHoo!, Uboot usw.? Ok, wenn das Netzwerk groß genug wäre könnte man auf ein paar serverlose Clienten verzichten. Wäre ein Versuch.
Das ganz aber mit dem "P2P-Gnutella" zu vergleichen wäre ein Fehler. Denn zum Daten ziehen muss ich schonmal länger on bleiben. Aber um jemanden "Hallo!" zu sagen überhaupt nicht.


Zu deinem IRC-moonchat...viele der hier anwesenden sind Tagsüber arbeiten oder schauen nicht regelmäßig hier vorbei, sondern nur wenn es was Neues gibt oder die Langeweile drückt. Somit wäre ein Chat zum diskutieren ungünstig da dafür ein paar mehr anwesend sein müssten. Alle folgenden Interessierten würden den Chat nicht Live mit erleben und könnten ihren "Senf" nicht mehr so recht dazu geben. Im Forum schon. Deswegen halte ich es für ungünstig das Thema in den Chat zu verlagern und kann verstehen wenn er ausstirbt

Edit: Mit P2P meine ich die Saugstuben. Ich merke gerade, dass das Wort P2P mit der Zeit als Name für etwas verwendet wurde das die Technologie die P2P ermöglicht nur nutzt. P2P = Peer to Peer

[supermuckl]

wenn ihr das wirklich hin bekommt und für die problemchen lösungen findet, dann würde ich für die gesamte texterei von user zu user eine asynchrone verschlüsselung vorschlagen, damit keiner, der gerade als server fungiert, mitlesen kann.
so würde dann z.b. jeder user in einem channel mit den anderen usern hin und zurück eine RSA public key session aufgebaut haben.
so wären die server nicht in der lage die texte mitzulesen. das steuer protocol sollte jedoch transparent sein.
wegen dem problem, das man ja mal seinen rechner auch ausschalten kann wenn man gerade server ist und die leute durch einen durch chatten, würde ich ein protocol entwickeln, wo ein client mit mehreren servern gleichzeitig verbunden ist, aber nur mit einer verbindung arbeitet
wenn nun eine abreisst (egal ob die aktive oder die "standby" verbindung) wird eine neue zu einem server aufgebaut, dessen IP mit einem broadcast an den nächsten server bzw aus der cached ip liste genommen wird.
ausserdem würde ich kreuzverbindungen unter den servern einrichten, damit es keine netsplits geben kann.. ein genügend intelligentes protocol muss dann auch da her, damit es keine doppelten messages gibt. auch IDs und TTLs usw müssten eingeführt werden.
das ganze wird meiner meinung nach SEHR schwer, aber machbar.
und dann würde ich das mit reinem TCP/IP aufbauen und net mit webservern.
auch die IP listen usw mit mysql oder sonstwas verwalten. User und channelverwaltung ebenso

auch würde ich das netzwerk teil p2p mäßig aufbauen. einfach ein paar fest-ip server (rootserver) auf linuxbasis (kylix lässt grüßen) mit mysql als datenbank und rückrad
und der rest user server und clients.
also heterogen.
auch ein loadbalancing müsste sich eventuell überlegt werden wenn ich mir da so überlege. sonst connecten alle auf die static server und dann ists wieder ein abklatsch vom irc.
allerdings von vornherein auf verschlüsselter basis!

ich hab mal so etwas angefangen (eigenes irc protocol) mit rsa verschlüsselung mit windows/linux commandozeilen server und mirc-like client.
ich hab das projekt nach monaten aufgegeben aus "kein bock mehr" gründen.
die datenbank war eigenentwicklung und das protocol auch.
als tcp endpunkte kam indy zum einsatz und gecoded unter D6 ent und K3 ent

jedenfalls hat es / tut es ziemlich stabil. auch floodprotection und hack-angriff und bruteforce abwehr eingebaut. auch services wie nickserv,chanserv usw ausgedacht und teilweise implementiert.

naja dann mal viel erfolg