Dezentraler Chat?

[MKX]

Hallo! Für die normalen Chats braucht man ja einen zentralen Server. Die Serveranwendung liegt aber als *.exe vor, die ich , weil ich keinen Windows- server habe, nicht ausführen kann. Vor kurzem habe ich von einem Dezentralen (=ohne server) Chat gehört. Geht das überhaupt, wie geht das und wie soll ich das in Delphi programmieren?

[chaosben]

Willkommen in der Delphi Praxis MKX! :hi:

chat AND programm

[MKX]

Vielen Dank! :corky:
Was ich noch nicht geschrieben habe: Das Programm sollte so ähnlich wie ICQ sein, d.h. übers Internet funktionieren und nich so ein Netzwerkchat sein.

[Sharky]

Hai MKX,

das Hauptproblem ist ja: Wie sollen die einzelenen Clients von einander wissen? Besonders ihre IP-Adresse muss den anderen Clients ja irgendwie bekannt werden. Innerhalb eines LANs könnte man das über einen regelmässigen Broadcast lösen. In den weiten des WANs kommst Du mit einem BC aber in der Regel nur bis zum nächsten Router.

Du brauchst also in jedem Fall eine zentrale Verwaltungsstelle für die IPs.

[Jonas1405]

Also..ich habe da auch schon mal drüber nachgedacht son kleinen Internet Messenger zu schreiben und habe ein paar Ideen: also ich habe mir gedacht, dass man als Server, den man ja irgendwie dringend braucht, einen Webserver nehmen könnte. Auf funpic.de kriegst du kostenlose webserver mit den FTP Zugangsdaten, mit denen kannst du dann per Prog auf den Webserver zugreifen. Dann würde ich einfach sämtliche wichtige Daten als INI Dateien auf dem Server speichern- wenn man dann mit wem chatten möchte würde ich da dann einfach die IP von dem in der Benutzer INI von diesem jemand speichern und dann bei direktem Chat Kontakt einfach die IP Adresse nehmen und "direkt" mit dem anderen Chatten (nicht so, dass du die Nachrichten auf dem Server zwischenspeicherst) (hab das ganze schon unter Delphi 4 Professional programmieren wollen hat aber net ganz so geklappt weil der beim FTP völlig sinnlos rumgemeckert hat und angelich keine INI Dateien kannte :wall: =) )

Gruß Jonas

[MKX]

Sind alle IP's im ganzen Internet unterschiedlich? Zum anderen: Jeder Client könnte seine IP auf meinen Webserver schicken, von wo aus sie den anderen Clients zu verfügung steht.

[sakura]

Nur mit Clients, welche hinter Proxies sitzen (z.B. AOL, Firmen-PCs, WLAN-Router, ...) sind meist per Standard nicht direkt über deren IP erreichbar ;)

...:cat:...

[MKX]

An firmen will ich ja auch nicht chatten. :lol: Hat jemand ein Programmbeispiel für so ein Projekt wie Jonas1405 meinte?

[Nicolai1234]

Zitat:

Zitat von MKX

An firmen will ich ja auch nicht chatten. :lol: Hat jemand ein Programmbeispiel für so ein Projekt wie Jonas1405 meinte?

aber einen Router hat fast jeder, der sich heute DSL anschafft.

[DGL-luke]

Das ist aber ein allgemeines problem von Routerkonfigurationen.

Eine allgemeine Lösung: Port Forwarding. :)

[MKX]

Zitat:

Zitat von DGL-luke

Eine allgemeine Lösung: Port Forwarding. :)

Was meinst du damit?

[DGL-luke]

port forwarding bedeutet, dass alles, was auf einem bestimmten port am router ankommt, an einen bestimmten PC weitergeleitet wird.

[dorisdoloris]

Zitat:

Zitat von Sharky

Hai MKX,

das Hauptproblem ist ja: Wie sollen die einzelenen Clients von einander wissen? Besonders ihre IP-Adresse muss den anderen Clients ja irgendwie bekannt werden. Innerhalb eines LANs könnte man das über einen regelmässigen Broadcast lösen. In den weiten des WANs kommst Du mit einem BC aber in der Regel nur bis zum nächsten Router.

Du brauchst also in jedem Fall eine zentrale Verwaltungsstelle für die IPs.

vielleicht wäre ja dieser Vorschlag eine Lösung

- automatische IP Aktualisierung durch den Chat-Clienten selber also bei jedem User local sobald er mit dem Client Online geht
- zu realisieren wäre dieses mit einem guten kostenlosen DNS-Service Z.b dieser "http://www.mtgsy.net" Vorteil wäre auf dem
Chatserver müsste nur noch die Domain dem wirklichem Chatnamen zugeordnet werden Z.b www.mustermann.de hääte die Zuordnung
"mustermann" für diesen Chat


Gruß: doris

[MKX]

Zitat:

Zitat von dorisdoloris

- automatische IP Aktualisierung durch den Chat-Clienten selber also bei jedem User local sobald er mit dem Client Online geht
- zu realisieren wäre dieses mit einem guten kostenlosen DNS-Service Z.b dieser "http://www.mtgsy.net" Vorteil wäre auf dem
Chatserver müsste nur noch die Domain dem wirklichem Chatnamen zugeordnet werden Z.b www.mustermann.de hääte die Zuordnung
"mustermann" für diesen Chat
Gruß: doris

:wiejetzt:

[dorisdoloris]

Du brauchst einen Chatserver der die IP's auswertet da führt wohl kein Weg dran vorbei wie du die IP's der einzelnen User Aktualisieren könntest hab ich ja nun schon erwähnt. Eine andere Möglichkeit wäre das der einzusetzende Chatclient direkt bei den Usern jeweils die IP ausliehst und sie dann an den Chatserver sendet mal dumm ausgedrückt so in etwa "hallo hier ist die IP 192.168.1.1 und ich bin der mit dem Chatnicknamen so und so" somit könnte jetzt die IP dem User zugeordnet werden. Du musst auch dazu keinen Windowsserver haben es reicht aus wenn du dir einen Chatserver Programmierst und ihn dann ganz normal auf deinem Rechner laufen lässt. Vorraussetzung ist das du dann immer Online bist um erreichbar zu sein oder du mietest einen vServer Prigrammierst den Chatserver für das einzusetzende Linuxsystem und hast dann einen immer erreichbaren Sever ;-). was besseres fällt mir dazu auch nicht ein :-)

[Jonas1405]

Jupp genau!! Das habe ich gemeint!! Und zu den IPs: ich meine man kann irgendwie, irgendwo mit der IP-Adresse eines Rechners diesen anzeigen von daher müssen alle IP Adressen unterschiedlich sein!!

Jonas :dance: :dance: :dance: :dance: :dance: :dance: :dance: :dance: :dance:

Zitat:

Zitat von MKX

Sind alle IP's im ganzen Internet unterschiedlich? Zum anderen: Jeder Client könnte seine IP auf meinen Webserver schicken, von wo aus sie den anderen Clients zu verfügung steht.

[faithman]

Mann könnte das ganze auch als so ne Art lebendes Netz oder so anlegen, ich stelle mir das so vor.
Da viele DSL Nutzer zwecks download sowieso immer on sind könnte ja jeder Client gleichzeitig Server sein, also jmd. der in das netz will braucht die Addr. eines anderen Teilnehmers und der sendet ihm dann die Addr. aller anderen und dann synchronisieren sie sich wieder - wie so ne art link-state algorithmen bei routern.

Is natürlich ghanz schön aufwendig - aber es ist ne möglichkeit...
Müsste nur noch etwas weitergedacht werden.

cu Faithmnan

[Puhbaehr]

Und was passiert wenn alle mal gleichzeitig nicht on sind? Dann haben alle wenn sie Neuverbinden eine neue IP-Adresse und keiner kann sich mehr erreichen. Irgendwer müsste dann allen seine neue IP geben damit jeder wieder on kann.
Du wirst um einen zentralen Server nicht drumherum kommen. Du brauchst zumindest irgendwas das ständig die gleiche IP-Adresse hat, oder anders ausgedrückt: Du brauchst einen Rechner dessen IP-Adresse jeder Client kennt. Auf diesem Rechner (Server) liegt wiederrum die IP-Liste von den Clienten.
Das Prinzip den Chatclient auch als Server laufen zu lassen ist eine prima Idee, funktioniert aber nur wenn es mindestens eine feste IP-Adresse gibt.

Gruß, Robert

[DataCool]

Hi,

schon in Delphi mit Indy geschrieben, ist als freeware unter www.telwell.de online ;-)

Bei Probs helfe ich Dir gerne, bin sowieso am überlegen das ganze früher oder später OpenSource zu machen.

Gruß Data

[hardy1234]

Hi,

ich mach gerade sowas. Das Problem haben die Anderen hier im Forum schon richtig beschrieben, das ist und bleibt der Router. Der setzt die tatsächliche IP des Clients in die zugewiesene IP des Providers um und merkt sich dann den internen Client zu der Verbindung.

Gelöst kriegt man das nur mit der "man in the middle" Methode. Du brauchst also mindestens einen Server der die IP-Adressen aller Clients die online sind vorhält. Das läßt sich verhältnismäßig leicht mit nem LINUX-Rechner (kann auch Windoofs mit LAMP sein) und Apache2 lösen. Dafür holt man sich bei Dyndns.org ne URL die vom Router jeweils refreshed wird.

Dann installiert man, z.B. mit Firebird (weil kostet nix) ne passende Datenbank und legt hinter das ganze nen Server der auf die DB zugreift und alle Clients speichert (mit nick und ip). Der Client muß dann selbst seine IP auffrischen, falls die sich ändern sollte, was manchmal ziemlich exessiv vom Provider ausgelöst wird (macht der um die IP's wieder frei zu kriegen).

Jeder Client fragt dann beim Server an und der trägt dessen URl ein und gibt ne Liste mit den Clients zurück.

Bleibt das Problem mit dem Maskerading vom Router. I.d.R. kannst du 2 Clients übers Internet nicht direkt verbinden wenn beide hinter nem Router kleben. Dazu muss dann das Protkoll am Router freigegeben werden. Das kannst Du Otto Normalverbraucher aber kaum beibringen. Die Router sind in dieser Hinsicht meistens nicht besonders Benutzerfreundlich.

Am Ende ist also immer besser einen richtigen "man in the middle"-Server zu proggen und dem das Weiterleiten der Messages zu überlassen. Ist die einzig sichere Lösung das Problem mit den Routern zu umgehen.

Das läuft bei ICQ auch nicht anders. Das sind alles IRC-Chats die untereinander noch verknüpft werden können. Damit hast Du dann mehrere Server laufen, die die Vermittlung untereinander regeln.

Leider werden solche Server aber auch oft "gefloodet", das heißt massenweise Clients eingetragen bis der einknickt.

[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:

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. :shock:

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 :P 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

:coder2:

[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 :D) 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 ;)

[Phantomix]

@Puhbaehr

Ja, ich habe ein wenig viel von Gnutella geredet, es geht mir weder darum, Dateien zu verschicken, noch leute lange warten zu lassen bis sie chatten können. und im prinzip ist ein "channel"-system genau das richtige für Einsteiger und Profis!

Zitat:

P2P wäre weniger etwas für Leute die nur Briefe schreiben, Mails schreiben, chatten Smile Aber grade die einfachen Leute brauchen wir.

Da bin ich wie gesagt anderer Meinung. Ja ein p2p client ist etwas komplizierter einzurichten. Aber es spricht ja nichts dagegen, daß der Servent eine Art Webchat-funktionalität mit anbietet und intern einen client dafür emuliert :) so schwer ist das nicht zu programmieren!

Zitat:

Aber Firewalls werden den normalen User daran hindern einen Server zu eröffnen.

Das ist leider richtig und mir fällt auch keine Patentlösung ein außer eine Community die solchen "neulingen" hilft (portforwarding etc), und auch einige Anreize, daß man eingehende Verbindungen akzeptieren kann wie file transfer zwischen zwei clients und so.

Zitat:

Wie viele davon treffen wir in einem einfachen HTTP-Chat wie Lycos, YaHoo!, Uboot usw.?

Man kann ja zusätzlich noch einen Zentralen server aufsetzen mit einer kleinen login-maske und so :P

Zitat:

Deswegen halte ich es für ungünstig das Thema in den Chat zu verlagern und kann verstehen wenn er ausstirbt

Affirmative.

Zitat:

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

P2P != filesharing ;) Das ist ein Problem in der heutigen Terminologie, vorallem wenn es darum geht P2P zu verbieten weil filesharing schlecht ist (was auch wieder grundlage für endlose diskussionen ist...)

@supermuckl
Wenn schon verschlüsselung, dann synchron, bei asynchron wäre erheblicher mehrtraffic zu erwarten. Allerdings der Schlüsselaustausch kann mit public key verfahren gemacht werden :) ich schlage da blowfish vor und RSA oder DH1080 zum schlüsselaustausch

Zitat:

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

Wir haben geplant gehabt, daß ein client 2 oder 3 verbindungen hat, jeder server den client mit seinen verbindungen kennt, und so die optimale route für ein paket auswählt ("ok der client ist an serverA, serverB und serverC... serverB ist am nahesten also schick ichs dorthin")

Das Problem ist allerdings, daß selbst nach dem Prinzip Pakete verloren gehen können, wenn ein server offline geht, und noch nicht alles weitergeleitet hat. in so einem fall schlage ich vor daß die server sich gegenseitig überwachen und wenn einer offline geht, sollen clients pakete nochmal senden, die verloren gegangen sind (ja das ist ein ziemlicher implementierungsaufwand, ich bin da für bessere Vorschläge offen)

Zitat:

ausserdem würde ich kreuzverbindungen unter den servern einrichten, damit es keine netsplits geben kann..

Jeder Server sollte mit jedem Server innerhalb so eines Netzwerksegmentes verbunden sein (bei 10 Servern heißt das 9 TCP Verbindungen, das ist zu verkraften)

Zitat:

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.

meine Meinung :) ich lade morgen mal die textfiles hoch, sind ca 30 kbyte englischer text, da steht aber im wesentlichen das drin was ich bisher gesagt hab

Zitat:

einfach ein paar fest-ip server (rootserver) auf linuxbasis

Es spricht nichts dagegen, eine p2p applikation auf linux zu portieren und dort laufen zu lassen :)

Zitat:

auch services wie nickserv,chanserv usw ausgedacht und teilweise implementiert.

da bin ich allerdings dagegen, wenn es um p2p gehen soll :) einerseits widerspricht nickname registrierung dieser philosophie, andererseits wäre es schwer/garnicht realisierbar



Und last but not least, wäre es auch denkbar ein kleines zusatzprogramm zu schreiben für IRC-benutzer daß auf der einen seite P2P und auf der anderen Seite IRC simuliert, dann können bereits vorhandene clients auch benutzt werden

[Puhbaehr]

Zitat:

Zitat von Phantomix

Zitat:

...wäre weniger etwas für Leute die nur Briefe schreiben, Mails schreiben, chatten Smile Aber grade die einfachen Leute brauchen wir.

Da bin ich wie gesagt anderer Meinung. Ja ein p2p client ist etwas komplizierter einzurichten. Aber es spricht ja nichts dagegen, daß der Servent eine Art Webchat-funktionalität mit anbietet und intern einen client dafür emuliert :) so schwer ist das nicht zu programmieren!

Mir ging es ja nicht um einen Webchat. Mir ging es darum, dass die Software einfacher einzurichten ist als z.B. ICQ, nämlich ohne ...:

Zitat:

Aber Firewalls werden den normalen User daran hindern einen Server zu eröffnen.

...

Zitat:

Zitat:

auch services wie nickserv,chanserv usw ausgedacht und teilweise implementiert.

da bin ich allerdings dagegen, wenn es um p2p gehen soll :) einerseits widerspricht nickname registrierung dieser philosophie, andererseits wäre es schwer/garnicht realisierbar

Woran sollte ich dann jemanden erkennen/wiedererkennen. An seiner IP? :) Irgendwas muss es da geben.

So, erstmal Gute Nacht ;)

[Phantomix]

Zitat:

Woran sollte ich dann jemanden erkennen/wiedererkennen. An seiner IP? Smile Irgendwas muss es da geben.

So, erstmal Gute Nacht

Den Nickname :P Ja ich weiß der lässt sich faken. das ist ein problem dass sich klären lässt aber worauf ich noch kein allheilmittel hab ;)


Und so eine Software einfacher einrichtbar als ICQ zu machen ist nicht zwangsläufig sache des Netzwerkprotokolls ;) DAUs kennen eben nur den browser und von daher ist ein webchat-zusatz nichtmal eine absurde idee. außerdem gibts auch viele DAUs die ICQ benutzen können...


Nacht auch! :)

[Phantomix]

hier sind mal alle textdateien sowie ein kleiner client (der bisher aber nur halbherzig irc kann, und in vb programmiert ist - am besten ignorieren, es geht um die Textdateien)

MoonChat Protocol work

am wichtigsten ist wahrscheinlich das was JLH mal zusammengefasst hat aus einem chatlog...
2005-02-22-jlh-chat-0.txt

allerdings sind paar Punkte verbesserungswürdig davon.

[MKX]

:coder2:
Ich hab mir 2 Möglichkeiten überlegt:

:idea: 1. Der 1 Client im Chatnetz sucht beim starten nach einer *.txt-
Datei auf einem Webserver, die die IP des Clienten enthält, der
auch als Server funktioniert. Findet er eine falsche IP oder
keine Datei fungiert er selbst als Server und stallt die IP
auf den Server.

:idea: 2. Jeder neue benutzer bekommt auf einem Webserver(z.B.funpic)
einen eigenen Ordner mit einer Textdatei. Beim starten des
Chats wird ein Ordnerindex erstellt. Wenn jmnd. mit jmdn.
chatten will, wird die TXT-Datei im jwlgen. Ordner heruntergeladen, die Antwort eingefügt,dann upgeloadet. Beim anderen
chatklient geht das genauso.

[DataCool]

Hi MKX,

leider beides nicht ganz bis zum Ende gedacht. !!

Zitat:

1. Der 1 Client im Chatnetz sucht beim starten nach einer *.txt-
Datei auf einem Webserver, die die IP des Clienten enthält, der
auch als Server funktioniert. Findet er eine falsche IP oder
keine Datei fungiert er selbst als Server und stallt die IP
auf den Server.

Was ist wenn man selbst kein Server seien kann, weil man hinter Router, etc. hängt ?
Warum mit Dateien arbeiten ? Du lädst die Datei runter, trägst gegenenfalls Deine IP mit ein und lädst wie wieder hoch ?! Was passiert, wenn Du gerade im obenen genannten Vorgang bist, und parallel jemand anderes auch gerade nen Upload macht ?

Einzige sinnige Lösung auf dem Server ne DB z.B. MySQL und die Client Request mit PHP in die DB schieben bzw. die Infos für den Client aus der DB lesen.

Zitat:

2. Jeder neue benutzer bekommt auf einem Webserver(z.B.funpic)
einen eigenen Ordner mit einer Textdatei. Beim starten des
Chats wird ein Ordnerindex erstellt. Wenn jmnd. mit jmdn.
chatten will, wird die TXT-Datei im jwlgen. Ordner heruntergeladen, die Antwort eingefügt,dann upgeloadet. Beim anderen
chatklient geht das genauso.

Hier das gleiche Problem wie oben schon genannt, nur hier an dieser Stelle noch extremer !
Mal angenommen Du chattest mit jemanden und beide Chat-Partner schreiben gleichzig einen neuen Satz.
Viel Spass beim Upload der Chat-Textdatei ;-)

Gruß Data

[MKX]

Das ist in der Tat ein Problem. Weiß jemand eine Lösung, oder kann in MySql oder PHP programmieren und zeigen, wie man so etwas programmiert?

Mal am Rande: Wie funktioniert ICQ dann noch, bei all den Problemen?

[DataCool]

Hi,

also ich habe das bei "meinem" Messenger mit PHP, MYSQL und Kommunikationsserver als Men in the Middle gelöst!
Ist also alles machbar, aber da steckt wirklich ne Menge Arbeit hinter.

Allein kaum oder nur mit sehr sehr viel Zeit machbar.

Gruß Data

[LH_Freak]

Also wir wollten das bei unserem MUH Messenger auch mit MySQL Server lösen.
Bis jetzt haben wir nur ein Problem mit dem Router.

[alias5000]

Also zur Einstiegsfrage nochmal zurück (ich muss zugeben, dass ich die Seiten dazwischen nicht gelesen habe, weils einfach zu viel ist und nicht direkt zur Frage zu gehören scheint. Ansonsten einfach ignorieren).

Klar gibt es die Möglichkeit eines Dezentralen chats!
Suche hier mal nach LanChat2 oder geh auf www.LanChat2.de , dann weißt du, dass es das gibt.


P.S.:Ich schreibe grade davon ne neue Version.