Viele Computernutzer wählen sich heutzutage nicht mehr direkt ins Internet ein, sondern verwenden Router bzw. Firewalls, die einem ganzen Netz per NAT den Zugang zum Internet ermöglichen. Ein Nebeneffekt eines NATs ist, dass es normalerweise ohne zusätzliche Vorkehrungen (z.B. Port-Forwarding) seitens des Administrators der Firewall nicht möglich ist, Dienste, die auf Systemen hinter dem NAT angeboten werden, von außen zu erreichen. Direkte Verbindungen zwischen zwei Systemen, die sich beide hinter jeweils einer solchen Firewall befinden, sind nahezu unmöglich.

Nahezu; denn einige Programme wie z.B. Skype oder Hamachi können trotzdem direkte Verbindungen zwischen zwei derart konfigurierten Systemen aufzubauen. Das hier zu entwickelnde Chat-Programm soll dies ebenfalls beherrschen.

Ziel ist es, eine Chat-Software zu entwickeln, mit der zwei Anwender über das Internet direkt miteinander kommunizieren können, auch wenn sie sich hinter NAT-Firewalls befinden. Die Verbindung zwischen den beiden Rechnern wird dabei über einen Dritten, den Server ausgehandelt. Die Daten selbst werden danach jedoch nur direkt von Client zu Client ausgetauscht. Dabei gilt:

• Es gibt verschiedene Ansätze, die Verbindung zwischen den Clients zu vermitteln. Diese haben jeweils ihre Vor- und Nachteile und wo das eine Verfahren fehl schlägt mag ein anderes Erfolg haben. Daher kann es sinnvoll sein, mehrere Protokolle zu implementieren und diese der Reihe nach durchzuprobieren.
• Es muss mindestens ein Protokoll selbst implementiert werden, ohne dass auf existierende Bibliotheken oder Programme von Dritten zurückgegriffen wird.
• Dabei kann entweder ein existierendes, spezifiziertes Protokoll wie STUN oder TURN eingesetzt, oder ein eigenes spezifiziert, dokumentiert und implementiert werden. In letzterem Fall wäre ein HTTP-basiertes Protokoll denkbar.
• Da zur Kommunikation zwischen den Clients wahrscheinlich UDP eingesetzt werden wird, muss eine eigene Sicherungsschicht bedacht werden. Diese soll sicherstellen, dass verlorengegangene Pakete bemerkt werden.
• Die Vermittlung zwischen den Clients geschieht unter Zuhilfenahme eines Servers. Hier kann je nach Protokoll ein existierender öffentlicher (STUN) Server verwendet oder eine eigene Software implementiert werden.
• Wenn eine eigene Server-Software implementiert wird und das Protokoll ausreichend spezifiziert bzw. dokumentiert ist, genügt es, wenn der Vermittlungs-Server als Prototyp vorliegt; das Augenmerkt dieser Aufgabe liegt auf dem Client.
• Zwei Benutzer sollen sich ohne großen Aufwand (ohne z.B. erst manuell IP-Adressen austauschen zu müssen) miteinander verbinden können. Die Entscheidung ist frei, ob die Verbindungen ad-hoc über einmalige Sessions vermittelt werden, oder auf dem Server eine Benutzerliste mit Online-Status geführt wird.
• Es ist zu überlegen, ob es Sinn macht, die Daten zwischen den einzelnen Instanzen verschlüsselt und/oder komprimiert zu übertragen.

Die Client-Software sollte sowohl unter Linux als auch unter Windows übersetzbar und funktionsfähig oder zumindest mit geringem Aufwand anpassbar sein. Der Client selber kann als grafische oder Konsolenanwendung umgesetzt werden. Die Server-Software, falls selbst implementiert, sollte unter Linux oder einem anderen Unix-Derivat laufen.

Jedes Team kann ab Ende Oktober einen Shell-Account auf einem Linux-Server erhalten und eine eigene IP-Adresse zum Testen. Bitte nehmt hierzu Kontakt mit Malte Stretz (ii5822) auf.

Da die Software plattformunabhängig sein soll und einiges an low-level Socket-Programmierung nötig sein wird, ist eine Umsetzung in C oder C++ empfehlenswert. Insbesondere wenn eine grafische Oberfläche erstellt werden soll, sollte ein entsprechendes Toolkit wie etwa Qt 4.x, GTK+ 2.x, wxWidgets 2.x, etc. verwendet werden. Die Software muss auf einem RZ-Rechner übersetzbar sein. Auch für Konsolenanwendungen empfiehlt sich, eine Bibliothek wie GLib oder QtCore einzusetzen, um sich auf das eigentliche Problem konzentrieren zu können.

Natürlich ist es auch möglich, die Anwendung in einer anderen Sprache zu implementieren. Dies sollte vorher mit Herrn Schmidt abgestimmt werden.

Für die Implementierung der Serverseite ist es wahrscheinlich am praktikabelsten, nur das Nötigste in C zu implementieren und den Rest in einem CGI-Script; die Sprache kann hier, so weit verfügbar, frei gewählt werden.

Zur Kompression der Daten kann z.B. die zlib verwendet werden, Verschlüsselung ließe sich mit QCA, OpenSSL oder GnuPG implementieren.

Die folgenden Artikel sollten als Einführung hilfreich sein:

• UltraVNC NAT2NAT connections
• Jürgen Schmidt: Der Lochtrick: Wie Skype & Co. Firewalls umgehen, c't 17/06, S. 142
• Daniel Bachfeld, Dr. Andreas Steffen: VPN-Knigge: VPN-Protokolle und Standards, c't 07/06, S. 114
• Wikipedia: NAT Traversal