Nuclear Messaging System

[fat-lobyte]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo, werte Mitglieder, Programmierkollegen, Freunde,

ich darf euch heute das Projekt vorstellen, das im letzten Jahr meine gesamte Programmierarbeit eingenommen hat (auch wenn es nicht so viel war):
Es heißt "Nuclear Messaging System", oder kurz nuke-ms.

Was nuke-ms jetzt ist:

Zurzeit ist es ein sehr sehr rudimenteres Programm mit dem man über das Netzwerk (oder das Internet) Textnachrichten übertragen kann. Es kann noch nicht wirklich viel, ist nicht bequem und von Sicherheit kann keine Rede sein. Dennoch: es ist mein Projekt, und hoffentlich wird es noch wachsen.

Was nuke-ms werden sollte:

Ein verteiltes, sicheres und stabiles Sofortnachrichtensystem.
Verteilt bedeutet: anstatt nur einem Server, einem Anbieter und einem Besitzer die Übermittlung seiner Nachrichten anvertrauen zu müssen, kann man sich bei nuke-ms zu einem ganzen Netzwerk von Servern verbinden - die Nachrichten werden über alle Verbundenen Server zum Ziel weitergeleitet, natürlich vorausgesetzt das Gegenüber ist auch mit dem Netzwerk verbunden.
Sicher bedeutet: die Kommunikation ist von Endpunkt zu Endpunkt verschlüsselt, authentifizierung geschieht sowohl zwischen Server und Client als auch zwischen den gegenüberliegenden Clients.
Stabil bedeutet: sollte ein oder mehrere Server im Netzwerk ausfallen oder Nachrichten unzuverlässig weiterleiten, werden andere Routen zum Ziel gewählt.

Wo es nuke-ms gibt:

nuke-ms ist Freie Software, es wird unter der GNU General Public License Version 3 (GPLv3) veröffentlicht. Benutzen, Verändern und Verteilen sind nicht nur erlaubt sondern sehr erwünscht.
Das Projekt ist auf BerliOS Developer, eine deutsche Organisation zur Unterstützung der Entwicklung von Open Source Projekten, gehostet. Verschiedene Dienste wie zum Beispiel ein Git Repository, ein Bugtracker oder ein Wiki werden zur Verfügung gestellt. Ihr könnt euch die nuke-ms Projektseite hier ansehen: http://developer.berlios.de/projects/nuke-ms/

Ihr könnt euch die aktuellste Version aus dem Git Repository ziehen. Installiert dazu einfach Git und gebt dann folgendes in die Kommandozeile ein:
git clone git://git.berlios.de/nuke-ms

Ihr könnt euch auch das letzte release von der Projektseite herunterladen:

ftp://ftp.berlios.de/pub/nuke-ms/alpha/ ... src.tar.gz
Die ist die Quellcodeversion von nuke-ms mit Unix Zeilenenden (LF).

ftp://ftp.berlios.de/pub/nuke-ms/alpha/ ... -win32.zip
Dies ist die kompilierte win32 Version, alle Dateien haben Windows Zeilenenden (CR LF).

Die SHA 256 Prüfsummen für die Dateien sind:

Code: Alles auswählen

0eac6be449b90eca6ab9ccaeedd8f742b036878589b53b35dec9ec523d8363c7 *nuke-ms-0.1-src.tar.gz
9efd7482a9681dc580df95b4c19fdabcadab88936ccbb9bbfdc9857c732bfc4b *nuke-ms-0.1-win32.zip

Wie ihr nuke-ms Kompilieren könnt:

Als erstes seid auf die Datei "INSTALL.de.txt" bzw. "INSTALL.en.txt" im "doc" Unterverzeichnis verwiesen - dort findet ihr detaillierte Anweisungen zur installation. Die Kurzversion lautet:

Unter Linux:
CMake >= 2.6, wxWidgets >= 2.8 und Boost >= 1.35 installieren (die genauen Paketnamen für einige gängige Distributionen findet ihr in der "doc/INSTALL.*.txt"-Datei), dann folgendes aus dem Projektverzeichnis in die Konsole eingeben:

Code: Alles auswählen

cd build
cmake ../src
make

Schon solltet ihr die Ausführbaren dateien im "bin" Unterverzeichnis finden.

Unter Windows:
Bitte tut euch das nicht an. Ich habe dieses Opfer bereits gebracht, das Ergebnis könnt ihr euch von der Projektseite herunterladen (siehe Link oben).

Wie ihr nuke-ms benutzen könnt:
Seid hier auf die Datei README.de.txt bzw. README.en.txt hingewiesen, die eine kurze Beschreibung enthalten. Für die Ungeduldigen:
Den Server starten (nuke-ms-serv),
den Client starten (nuke-ms-client),
/connect <host>:34443 ins untere Textfenster des clients eingeben (<host> durch die IP-Addr. oder DNS-Namen des Rechners ersetzen, wo der Server läuft - also bei eurem Rechner localhost)
Nachrichten eintippen, mit Enter verschicken
Verbindung trennen mit /disconnect,
Beenden des Clients mit /exit, mit File -> Quit aus dem Menü oder einfach aufs X klicken.
Beenden des Servers durch "kilall nuke-ms-serv" aus einer anderen Konsole, oder durch drücken von Ctrl-C aus der Konsole des Servers.


Wo ihr Feedback abgeben könnt:
Ihr könnt eure Meinung, Bugreports, Patches oder andere Kommentare entweder in dieses Forum posten oder an die Mailingliste von nuke-ms. Die addresse ist folgende:
nuke-ms-users@lists.berlios.de
Um E-Mails an diese Liste senden zu können müsst ihr euch hier einschreiben:
https://lists.berlios.de/mailman/listinfo/nuke-ms-users

Nun seid ihr gefragt! Herunterladen, testen, schimpfen! Alles ist möglich!

mfg, fat-lobyte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqcIJQACgkQDUm8QWoJBit/tQCdH4tjIvUJtK6/4TiNn8LH7z6l
Au4AnRJN++pdJvJkUiVlFs9YbHGa11Nb
=diRo
-----END PGP SIGNATURE-----

[cloidnerux]

Verteilt bedeutet: anstatt nur einem Server, einem Anbieter und einem Besitzer die Übermittlung seiner Nachrichten anvertrauen zu müssen, kann man sich bei nuke-ms zu einem ganzen Netzwerk von Servern verbinden

Sicher bedeutet: die Kommunikation ist von Endpunkt zu Endpunkt verschlüsselt, authentifizierung geschieht sowohl zwischen Server und Client als auch zwischen den gegenüberliegenden Clients.

Naja, viele Server und dann ncoh Sicher, ich glaube das wird schweirig, denn es benötigt ja nur einen gecrackten Server um die Daten aufzuzeichenen und zu entschlüsseln, da ja der ganze Datenverkehr üben den selbigen lief.
Auch finde ich das ein wenig umständlich, da man als ICQ/IRC nutzer einfach nur verbinden drückt und es Funktioniert, wärend man bei nuke-ms darauf achten muss, mindestens 1 geleichen Sever zu haben, um mit dem anderen zu Chatten, was bei Technikgeeks und leghastenikern sehr schwierig wird

Aber nun mal zu erbaulicher Kritik:
Ich finde es gut das mal neue Ideen im IM gibt und ich selbst hatte schon häufiger vor mal selber einen IM zu schreiben.
Weiter so!

[nufan]

(die genauen Paketnamen für einige gängige Distributionen findet ihr in der "doc/INSTALL.*.txt"-Datei)

Nur so als Anmerkung: bei mir (Ubuntu 9.04) ist "libboost-thread1.35-dev" eine Abhängigkeit von "libboost-system1.35-dev".

/connect <host>:34443 ins untere Textfenster des clients eingeben (<host> durch die IP-Addr. oder DNS-Namen des Rechners ersetzen, wo der Server läuft - also bei eurem Rechner localhost)
Nachrichten eintippen, mit Enter verschicken
Verbindung trennen mit /disconnect,
Beenden des Clients mit /exit, mit File -> Quit aus dem Menü oder einfach aufs X klicken.

Willst du das noch mehr Richtung IRC-Kommandos ausbauen?

Beenden des Servers durch "kilall nuke-ms-serv" aus einer anderen Konsole, oder durch drücken von Ctrl-C aus der Konsole des Servers.

Nehme an ein Tippfehler, "killall".

Nun seid ihr gefragt! Herunterladen, testen, schimpfen! Alles ist möglich!

Bis jetzt läuft alles ohne Probleme, vom Kompilieren bis hin zum verschicken auf dem Localhost.
Für dich gilt das Gleiche wie für Dirty Oerti: als Tester stehe ich immer bereit

Ich finde es gut das mal neue Ideen im IM gibt und ich selbst hatte schon häufiger vor mal selber einen IM zu schreiben.

Ich habs wie ihr wahrscheinlich mitbekommen habt auch mal probiert
Lief auch nicht schlecht, man konnte damit Nachrichten und Dateien verschicken. Ausfallsicherheit/Verschlüsselung hatte der aber keine ^^

[Kerli]

Naja, viele Server und dann ncoh Sicher, ich glaube das wird schweirig, denn es benötigt ja nur einen gecrackten Server um die Daten aufzuzeichenen und zu entschlüsseln,

Naja, wenn der Server keine Ahnung von der Verschlüsselung hat wird es auch schwierig etwas herauszubekommen. Der "Server" falls es denn so einen gibt weiß ja nur wem er das Paket weiterleiten soll, und das muss ja noch nicht einmal der endgültige Empfänger sein. Und wenn man dann nicht nur einen sondern zb 2 oder mehr Verschlüsselungsalgorithmen in verschiedenen Reihenfolgen einsetzt wird es für einen Angreifer sehr schwer an den eigentlichen Inhalt zu gelangen.

Auch finde ich das ein wenig umständlich, da man als ICQ/IRC nutzer einfach nur verbinden drückt und es Funktioniert,

Naja, bei ICQ brauchst du ja auch die Nummer deines Gegenüber, sonst geht da auch nichts. Aber das ist ja auch noch nicht der letzte Stand vom Programm. Glaube ich zumindest

Außerdem würde ich gar nicht so stark auf Server setzten sondern das ganze eher als Peer-To-Peer System auslegen und Server noch höchstens für die Kontaktaufnahme zwischen den Peers verwenden. Erstens werden die Server dadurch entlastet und zweitens läuft man nicht in Gefahr von gecrackten Servern abgehört zu werden.

Unter Windows:
Bitte tut euch das nicht an. Ich habe dieses Opfer bereits gebracht,

Das kann ich nur bestätigen. Unter Windows programmieren ist wirklich anstrengen. Das letzte Mal wie ich wxWidgets geschafft habe zu kompilieren hat das schon einmal mehr als eine halbe Stunde gebraucht. Nicht zu vergessen die Zeit bis es einmal so weit war...

Eins muss ich noch einmal loben, nämlich die Dokumentation. So eine ausführliche Dokumentation die noch dazu in Deutsch und Englisch vorhanden ist findet man leider wirklich allzu selten. Weiter so

[fat-lobyte]

Naja, viele Server und dann ncoh Sicher, ich glaube das wird schweirig, denn es benötigt ja nur einen gecrackten Server um die Daten aufzuzeichenen und zu entschlüsseln, da ja der ganze Datenverkehr üben den selbigen lief.

Kerli hat es schon richtig gesagt: verschlüsselt wird die Nachricht vom Client, entschlüsselt wird die Nachricht vom Client des Gegenübers. Der Server sollte zu keinem Zeitpunkt die Möglichkeit haben in die Nachrichten der Clients hineinzusehen.

Nur so als Anmerkung: bei mir (Ubuntu 9.04) ist "libboost-thread1.35-dev" eine Abhängigkeit von "libboost-system1.35-dev".

Ist das so? Naja, ändert nichts daran dass man beide Installieren muss. Also insofern hab ich keinen Fehler gemacht Nein stimmt schon, hab ich übersehen. Aber man könnts auch so auslegen dass ich betonen will dass man beide Bibliotheken braucht ^^

Willst du das noch mehr Richtung IRC-Kommandos ausbauen?

Ob das IRC Kommandos werden weiß ich nicht. Was ich aber ausbauen wollte ist die vollständige Steuerung des Clients aus der Kommandozeile. Klicken sollte man können - aber nicht müssen.

Nehme an ein Tippfehler, "killall".

Richtig, danke.

Bis jetzt läuft alles ohne Probleme, vom Kompilieren bis hin zum verschicken auf dem Localhost.

Das freut mich.

Für dich gilt das Gleiche wie für Dirty Oerti: als Tester stehe ich immer bereit

Das freut mich noch mehr Ich werde auf das angebot zurückkommen.

Lief auch nicht schlecht, man konnte damit Nachrichten und Dateien verschicken. Ausfallsicherheit/Verschlüsselung hatte der aber keine ^^

Wow, da hast du ja schon mehr geschafft als ich... Das kann es natürlich auch noch nicht.

Außerdem würde ich gar nicht so stark auf Server setzten sondern das ganze eher als Peer-To-Peer System auslegen und Server noch höchstens für die Kontaktaufnahme zwischen den Peers verwenden. Erstens werden die Server dadurch entlastet und zweitens läuft man nicht in Gefahr von gecrackten Servern abgehört zu werden.
Da ist was dran. Ich dachte eigentlich daran den "Server" auch an einem normalen Userrechner laufen zu lassen. Der Client verbindet mit localhost und der Server macht die eigentliche Arbeit des Verbindungsaufbaus.

Eins muss ich noch einmal loben, nämlich die Dokumentation. So eine ausführliche Dokumentation die noch dazu in Deutsch und Englisch vorhanden ist findet man leider wirklich allzu selten. Weiter so

Dankesehr, das hat mich einiges gekostet. Vor allem die Zeit (und vor allem die Nerven) die ich in den Windowsteil reingesteckt habe war nicht so wenig.



Also ich bedanke mich für die Kommentare und das Lob, aber ich hab noch ne Frage an die Werten Reviewer: Hat denn schon jemand in den Code gekuckt? Weil an sich ist die reine Anwendung ja noch nicht so interessant.

mfg, fat-lobyte

[Xin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manchmal übertreibst Du es mit der Sicherheit auch ein wenig ;->

Was nuke-ms werden sollte:

Ein verteiltes, sicheres und stabiles Sofortnachrichtensystem.
Verteilt bedeutet: anstatt nur einem Server, einem Anbieter und einem Besitzer die Übermittlung seiner Nachrichten anvertrauen zu müssen, kann man sich bei nuke-ms zu einem ganzen Netzwerk von Servern verbinden - die Nachrichten werden über alle Verbundenen Server zum Ziel weitergeleitet, natürlich vorausgesetzt das Gegenüber ist auch mit dem Netzwerk verbunden.

Warum wird nicht einfach die IP ausgetauscht und man verbindet sich direkt?
Warum nicht für jede Nachricht einen neuen Server auslosen, so dass eine Kommunikation immer über neue Wege geht und jemand, der einen Server zum Abhören nutzt bestenfalls Bruchstücke einer Unterhaltung überhaupt zu sehen bekommt?
Warum sollte ich einen Server hosten, über den Terabytes von verschlüsselten Daten gehen... moment Terabytes? Wer soll das bezahlen... Ich mache keinen Server für Deinen IM auf. ^^
Also über alle Server das zu routen macht die Sache langsam und teuer - hier musst Du noch mal ran.

Stabil bedeutet: sollte ein oder mehrere Server im Netzwerk ausfallen oder Nachrichten unzuverlässig weiterleiten, werden andere Routen zum Ziel gewählt.

Wie werden neue Server erkannt und tote Server verworfen.


Ich habe es noch nicht ausprobiert (out of time error...), aber ich habe ja bald mal ein paar Tage Urlaub.
(Mal gucken, was vom Urlaub überbleibt, ich verplane ihn ja schon seit einer Woche... )

[fat-lobyte]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manchmal übertreibst Du es mit der Sicherheit auch ein wenig ;->

Da gings um die Hashes der Dateien auf dem FTP Server. Ich finde nicht dass ich übertreibe, immerhin kann man somit mit ziemlicher Sicherheit sagen dass die Pakete von mir kommen.

Warum wird nicht einfach die IP ausgetauscht und man verbindet sich direkt?

1. Nicht jede (oder eher nur sehr wenige) Firewall lässt das so einfach zu.
2. Außerdem sind IP-Adressen nur dann einfach zu benutzen, wenn sie Statisch sind. Wenn man jedes mal vorher anrufen muss bevor man chatten will geht der Sinn verloren

Warum nicht für jede Nachricht einen neuen Server auslosen, so dass eine Kommunikation immer über neue Wege geht und jemand, der einen Server zum Abhören nutzt bestenfalls Bruchstücke einer Unterhaltung überhaupt zu sehen bekommt?

Könnte man machen. Das Aufwand/Nutzen Verhältnis stimmt aber nicht. Es gibt effektivere Methoden um sichere Kommunikation zu ermöglichen.

Warum sollte ich einen Server hosten, über den Terabytes von verschlüsselten Daten gehen... moment Terabytes? Wer soll das bezahlen... Ich mache keinen Server für Deinen IM auf. ^^

Warum sollte überhaupt jemand einen Server hosten, den andere Verwenden können? Wieso gibt es Tor Router, wieso gibt es freie DNS Server, wieso gibt es Internetrouter? Wieso gibt es überhaupt infrastruktur?
Das mit den Terrabytes hast du gesagt.
Hier die Idee dazu:
Es gibt Systeme aus mehreren Teilnehmern, die sich selbst regulieren. Jedes einzelne Mitglied handelt für sich, es handelt ohne Sinn für "die Gesellschaft" - man könnte fast sagen egoistisch. Und doch führt das Zusammenspiel dieser Egoisten doch zu einem funktionierenden System. Hält ein Mitglied sich nicht an die Regeln, fliegt er raus. Ich glaube daran (und wenn ich nicht daran glauben würde, könnte ich gleich aufhören) dass es möglich ist ein solches System zu erschaffen. Das Protokoll, die Regeln müssten so ausgelegt und Ausbalanciert werden, dass ein Systemzusammenbruch zwar möglich ist (das kann ich nun wirklich nicht verhindern), allerdings sehr schwierig. Einen Systemzusammenbruch darf es nicht wegen einzelnen Individuen geben sondern nur dann wenn ein großer Teil des Netzwerkes sich nicht an die Regeln hält.
In diesem zusammenhang dachte ich daran dass jeder Server nur das leistet, was er leisten kann - was er leisten will. Fühlt er sich ausgenutzt von bösen hackern, drosselt er einfach die Geschwindigkeit zum betreffenden Runter.

Also über alle Server das zu routen macht die Sache langsam und teuer

Richtig. Aber ich habe nicht gesagt dass ich über alle Server routen werde. Das ist keine reimplementierung von Tor, hier gehts nicht darum vollige Anonymität zu gewährleisten.
Es wird natürlich versucht den kürzesten und billigsten weg zu finden. Sollte dieser über mehrere Server führen - so sei es.

Wie werden neue Server erkannt und tote Server verworfen.

Tote server ganz einfach: zu lange antwortzeiten, zu hoher paketverlust oder wenn der "einfach nimmer da is".
Neue server sind schon schwieriger. Ich dachte daran sie entweder manuell an netze zu hängen oder eine Art Authentifizierungshierarchie (wie bei TLS) aufzubauen, und neue Authentifizierte Server einfach verbinden zu lassen. Vielleicht können sich über umwege verbundene Server auch quervernetzen - alles ist möglich.

hier musst Du noch mal ran.

Ich habe es noch nicht ausprobiert (out of time error...),

Tu dir keinen Zwang an. Ist auch ehrlichgesagt nicht so interessant, bis jetzt kann man mit netcat und einer mit Python zusammengehackten GUI mehr erreichen.
Vielleicht sollte ich was klarstellen: bis jetzt tut das ding erstmal "nix". Meine fehlende Definition der Protokolle, der Features und die Analyse der schwierigkeiten mögen für viele wie Planlosigkeit aussehen. Aber:
Ich bin 20 Jahre alt, war ein Gymnasiast und studiere in keiner (im engeren sinne) mit Informatik verbundenen Richtung. Ich habe das Know-How für meine Pläne nicht. Woher sollte ich es auch haben? So, nun kann man sagen meine Pläne sind Wahnwitzig. Man könnte sagen, jaja geht in Richtung OS der Zukunft. Vielleicht. Vielleicht aber auch nicht.
Was ich jetzt gerade tue ist erstmal eine gute Basis zu schaffen. Das bedeutet: eine gute Codebasis mit einer netten kleinen "Supportlibrary", eine gute Dokumentationsbasis. Zu dieser Basis gehört auch Know-How in der Versionsverwaltung, beim Build-System und und und...
Was ich bis jetzt habe sind Ideen. Diese Ideen versuche ich festzuhalten und mich während des schreibens der Basis ein bisschen ins Thema einzulesen. Nach der Codebasis kommt die Experimentierphase - und die Phase des Denkens und Lesens. Ich werde viel Theorie benötigen, viele Konzepte verstehen müssen. Und dann... naja so weit will ich noch nicht denken.
Zusammengefasst: dass ich jetzt kritische Fragen nicht ausreichend Beantworten kann bedeutet nicht automatisch, dass mein Konzept falsch ist. Vielleicht ist es das, vielleicht ist es das nicht. Aber das werde ich erst in Zukunft wissen.

Meine Aufgabe besteht im Moment darin den Code so auszubauen, dass ich mir später nicht ins Fleisch schneide. Das ist schon schwierig genug. Ich hab schon feedback bekommen wie "Das nervt dass ich immer ein echo bekomme". Ja. Das liegt am Server, der wird sowieso neu gemacht wenn der Client Akzeptabel ist. "Ich finds blöd dass nie ein Name dabeisteht". Ja, find ich auch. Aber dafür das zu ändern hab ich die Infrastruktur nicht. Was ich machen kann (und ws. auch werde) ist ein kleiner Hack, der einfach vor jeden verschickten String den Namen setzt - aber das kann jeder Idiot. Was ich will ist eine passende Repräsentation von Userdaten im Code und in der Paketkodierung.

Dieses Projekt ist nicht fürs jetzt ausgelegt. Wie gesagt, es ist im moment ziemlicher Müll. Aber vielleicht ändert sich das noch irgendwann.

ps.: Wenn du das tatsächlich ganz gelesen hast, hast du mehr Zeit investiert als du gebraucht hättest um nuke-ms auszuprobieren Wie gesagt, es kann echt noch nicht so viel

[nufan]

Lief auch nicht schlecht, man konnte damit Nachrichten und Dateien verschicken. Ausfallsicherheit/Verschlüsselung hatte der aber keine ^^

Wow, da hast du ja schon mehr geschafft als ich... Das kann es natürlich auch noch nicht.

Auf jeden Fall hat deiner ein schöneres GUI ^^
Wobei Ausfallsicherheit brauche ich keine, da direkt von Client zu Client connected wird (Peer-to-Peer per IP). Also komplett ohne Server. In (weiter, seeehr weiter) Zukunft plane ich mit einem zentralen Server, der Kontakte verwaltet, da wie erwähnt der IP-Austausch übers Internet umständlich ist, über (W)LAN gehts ja noch.
Aber das ist deine Projektvorstellung, ich will nicht abschweifen

Unter Windows:
Bitte tut euch das nicht an. Ich habe dieses Opfer bereits gebracht, das Ergebnis könnt ihr euch von der Projektseite herunterladen (siehe Link oben).

Qt macht es da sehr einfach. Die selben 4 Konsolenbefehle wie unter Linux (und den anderen unterstützten Betriebssystemen) reichen zum Projektfile und Makefile erstellen, Kompilieren und Ausführen.

Also ich bedanke mich für die Kommentare und das Lob, aber ich hab noch ne Frage an die Werten Reviewer: Hat denn schon jemand in den Code gekuckt? Weil an sich ist die reine Anwendung ja noch nicht so interessant.

Ja, hab kurz reingeguckt. Scheint recht gut strukturiert (von den Ordnern her) und gut dokumentiert. Ansonsten hab ich zu wenig Ahnung von wxWidgets/boost bzw. fehlen mir noch einige C++-Kenntnisse um alles zu verstehen.

Ich habe es noch nicht ausprobiert (out of time error...), aber ich habe ja bald mal ein paar Tage Urlaub.

Habe auch Urlaub, anschließend Schule, also bin ich wieder Vollzeit-Progger

[fat-lobyte]

Hallo Leute!

Es gibt News bei nuke-ms!

Soeben habe meinen Branch in den Master Branch gemergt. In meinem Branch waren Änderungen enthalten, die die Byte Ordnung der übertragenen Nachrichten von Big Endian auf Little Endian umgestellt haben.

Diese Änderung habe ich eingeführt, da ich finde dass die Kodierung in Little Endian sinvoller ist, denn das bedeutet für alle Systeme mit Little Endian (also die üblichen Intel und AMD Prozessoren) einen kleinen Performancevorteil weil die Byteordnung nicht konvertiert werden muss - ich bin mir nämlich ziemlich sicher, dass das mein Programm zum überwiegenden Teil nur auf Little Endian Systemen laufen wird.

Das bedeutet, dass Clients vor dem Commit 0f85367 nicht mit Clients nach diesem Commit kompatibel sind.


Um diese Änderungen zu testen, habe ich übrigens das Programm auf einem PowerPC System getestet und es hat funktioniert!
Ein Dankeschön deswegen an das Team von QEMU, Debian und Aurelien Jarno der auf seinem Blog QEMU Images von Debian Installationen auf vielen verschiedenen Architekturen ausgestellt hat.

Änderungen mit "git pull" holen ausprobieren, Meinung sagen!

mfg, fat-lobyte

[Dirty Oerti]

Tag

So, jetzt hab ich endlich auch mal Zeit, meinen Senf zu deinem (wie ich finde) sehr interessantem Projekt abzugeben.
Also grab ich das jetzt mal hoch.

Ich finde die Idee gut, einen neuen IM zu konstruieren.
Was mir an deinem Projekt besonders gefällt sind deine Ansprüche an dein Programm: Verteilt, sicher, stabil
Was mir nicht gefällt ist deine Idee, den Traffic über Server zu leiten (wie Xin schon eingeworfen hat).
Das belastet die Server und macht den User zusätzlich ein ganzes Stückchen abhängiger von den Servern als er (oder sie) es eh schon ist.

Was mir jetzt gerade so für Gedanken gekommen sind:

Was natürlich toll wäre (ich weiß nicht, inwieweit sich das mit deinen Überlegungen decken kann oder soll oder will oder....):

Eine eindeutige Identifikation der Teilnehmer über (z.B.) PGP-Schlüssel. Sprich: Jeder Teilnehmer ist EINDEUTIG und ohne Zweifel identifizierbar, aber nur auf seinen Schlüssel.
Ob dieser Schlüssel nun Hans Meier aus Dortmund gehört oder Sun Tai aus Hongkong sollte nicht (bzw schwer) nachweisbar sein.
Das dumme daran ist, dass sich das nicht mit meiner zweiten Überlegung vereinbaren lässt:
Die Server dienen als reine Kontaktbörsen. Sie verteilen nur IP-Adressen nach Schlüsseln.
Wie man meine beiden Ideen aber dennoch zusammenbringen kann:

Die Server fungieren als Vermittler. Ich erkläre das am besten mal an einem Beispiel:

Hans Meier hat eine öffentliche Kennung (A), die er auf die Server (denen er vertraut) legt.
Nun möchte Sun Tai mit ihm in Kontakt treten.
Dazu schickt er eine Anfrage nach Hans Meier (z.B. Suchdaten in einem Formular o.ä.) an die Server, die er kennt.
Die Server kennen sich (möglichst alle) untereinander. Dadurch macht es nicht, wenn Hans Kennung auf einem Server liegt, den Sun nicht kennt.
Suns Server kontaktieren einfach die ihnen bekannten Server, und die wiederum die ihnen bekannten bis Hans gefunden wurde (hier darf man eine Abbruchbedingung aber nicht vergessen).

Wurde die Kennung nun gefunden, es ist also sichergestellt, das ein Hans Meier im Netzwerk existiert, dann schickt der Server, der die Kennung gespeichert hat (und damit als einziger die wahre Identität von Hans Meier in Form seiner IP kennt) eine Nachricht an Hans. Ab hier fallen mir 2 unterschiedliche, weitere "Wege" ein:

Nummer eins, sicherer, aber Traffic-kostender:
Möchte Hans nun mit Sun chaten, schickt Hans seine Nachricht an seinen Server, der schickt sie an Suns Server und dieser wiederum an Sun.
So kennt Sun Hans nicht direkt (nur über ihre Kennungen, also nicht die IPs) und auch umgekehrt nicht. Einzige Schwachpunkte stellen nun die beiden Server dar - Hans Server für Hans und Suns Server für Sun.

Nummer zwei, schneller aber erfordert mehr "Vertrauen" der User untereinander:
Wenn Hans nun bereit ist, sich mit Sun zu unterhalten, dann antwortet Hans seinem Server entsprechend, woraufhin dieser die IP von Hans an Sun schickt. Ab hier herrscht direkte Kommunikation.

Schön wäre natürlich, wenn dein Messenger....auch..erweiterbar wird. Vorallem im Bezug auf die Art der ausgetauschten Daten. Damit meine ich Bilder, Filme, OnlineSpiele, ...