Socket-Interface (5)

Nachdem ich Ihnen in den bisherigen Folgen die wichtigsten Funktionen für die Internet-Programmierung erläutert habe, geht es im letzten Teil um einige Problemlösungen abseits des eigentlichen Socket-Interface.

Das Socket-Interface sieht keine Funktionen für den Aufbau einer Internet-Verbindung zum Provider vor. Ein Umstand, der nicht weiter verwundert, wurde das Socket-Interface doch für Rechner entwickelt, die über Standleitungen fest in das Internet integriert sind. Der typische Anwender benötigt den Zugang zum Internet aber nicht ständig, sondern bindet seinen Rechner via Modem und Telefonleitung nur zeitweise an. Die in diesem Fall verwendete Internet-Zugangssoftware muss daher zusätzliche Funktionalität für den Umgang mit dem Modem haben und die für den Transport über die Modem-Verbindung notwendigen Protokolle wie PPP und SLIP beherrschen. Außer- dem sollte die Zugangssoftware eine Möglichkeit vorsehen, den Auf- und Abbau der Internet-Verbindung durch die Anwendung steuern zu lassen.

Automatisch

IConnect realisiert diesen Automatismus. Wie für GEM-Anwendungen üblich, ist das Protokoll für die Kommunikation mit IConnect über AES-Events realisiert. Prinzipbedingt kann daher ein TOS-Programm die Verbindung in das Internet nicht automatisch aufbauen. Allerdings darf dieser Nachteil gerade für eine Plattform, die wegen ihrer grafischen Oberfläche benutzt wird, nicht überbewertet werden; bisher gibt es mit dem Telnet-Client T2 erst eine reine TOS-Anwendung, die auf IConnect basiert.

Gestartet wird IConnect aber mit dem AV-Protokoll (Nachricht AV START-PROG) über den Desktop. Das hat den Vorteil, daß der Anwender nur einmal angeben muss, in welchem Verzeichnis sich IConnect befindet. Voraussetzung ist natürlich, daß der Anwender einen AV-fähigen Desktop (wie etwa jinne, MagiC-Desk oder Thing) einsetzt. Da Thing den übergebenen Pfad daraufhin überprüft, ob er mit einem Laufwerksbuchstaben beginnt, benutzen Sie entgegen der Dokumentation von IConnect als Pfad (C:\ ICONFSET.CFG). Wie die IConnect-spezifische Kommunikation funktioniert, ist in der Dokumentation ausführlich beschrieben.

Natürlich sollte Ihre Internet-Anwendung nicht einfach eine Verbindung aufbauen, sondern dem Anwender über eine entsprechende Konfiguration die Möglichkeit geben, ob und wie der automatische Verbindungsauf- und abbau vor sich gehen soll. Der Telnet-Client Teli geht folgendermaßen vor (s. Abbildung 1). Zunächst wird - falls gewünscht - IConnect gestartet. Wenn die Option "Verbindung aufbauen" nicht aktiviert ist, erscheint ein Fenster mit dem Hinweis auf die fehlende Internet-Verbindung (s. Abbildung 2). Der Anwender hat die Möglichkeit, einen Zugang in IConnect auszuwählen und den Aufbau der Verbindung über IConnect manuell zu veranlassen.

Durch einen Klick auf den Button "Verbunden" oder durch die Kommunikation mit IConnect erfährt Teli, daß die Internet-Verbindung eingerichtet ist und fährt mit der Programmausführung fort. Ist die Option Verbindung aufbauen" dagegen aktiviert, veranlaßt Teli IConnect, die Verbindung sofort aufzubauen, d.h. die Möglichkeit der Setup-Auswahl entfällt.

Das Protokoll von IConnect sieht ebenfalls vor, daß eine Internet-Verbindung durch eine Anwendung abgebaut wird. Da IConnect bisher nicht registriert, welche Anwendung den Aufbau einer Verbindung initiiert hat und wieviele mit dem Internet kommunizieren, muss sich Ihre Internet-Anwendung einer Einschränkung unterwerfen. Die Verbindung darf von einem Programm nur dann abgebaut werden, falls dieses Programm die Verbindung auch selbst eingerichtet hat. Dennoch kann es aber passieren, daß einer anderen Anwendung die Internet-Verbindung von der Initiierenden ungewollt geraubt wird -ein Umstand, der hoffentlich in einer der nächsten IConnect-Version geändert wird.

Teli bietet für das Abbauen der Internet-Verbindungen zwei Möglichkeiten an: Die Verbindung wird abgebaut, nachdem Teli die letzte Verbindung zu einem Tel-net-Server beendet hat oder beim Beenden von Teli.

Nur keine Hemmungen

Im vierten Teil haben wir uns ja bereits mit dem Umgehen des blockierenden Verhaltens einiger Sockel-Funktionen beschäftigt: Mit der Funktion sfcntlQ kann das Blocking abgeschaltet werden. Leider hat sfcntlQ keinen Einfluß auf gethost-byname(). Mit einem weiteren, auf AES-Events basierenden Protokoll, läßt sich aber auch hier Abhilfe schaffen. IConnect startet nach dem erfolgreichen Aufbau einer Internet-Verbindung ein Programm namens RSDAEMON. Diesem GEM-Programm können Sie nun eine Nachricht via AES-Event schicken, die den aufzulösenden Hostnamen enthält. Der RSDAEMON ruft nun seinerseits gethost-bynameQ auf und wartet, bis er ein Ergebnis erhält, das er dann an Ihre Internet-Anwendung wiederum via AES-Event schickt (Einzelheiten s. Dokumentation zu IConnect). Der Vorteil liegt auf der Hand: Ihre Anwendung kann GEM-typisch während der DNS-Abfrage weiterhin die Nachrichtenschleife abarbeiten und beim Eintreffen der Antwort mit der eigentlichen Internet-Kommunikation fortfahren.

Fadenscheinig

Eine weitere - in meinen Augen sehr elegante - Art, die Probleme des blockierenden Verhaltens aller(!) Sockel-Funktionen zu umgehen, ist die Verwendung von Threads. Diese sind die Fortführung des Mullilasking auf Ebene der Programme, d.h. in einem Programm können mehrere Aufgaben gewissermaßen gleichzeitig ab-gearbeilel werden. Im Falle des Sockel-Interface bietet es sich nun an, die komplette Kommunikation - angefangen bei gethostbyname() über conneclQ oder accept() bis recv() und send() - in jeweils einen eigenen Thread zu verfrachten. Das Hauptprogramm verarbeitet wie gewohnl die Nachrichten der Benutzeroberfläche und muss sich kaum um die Internet-spezifische Funktionalität kümmern.

Sowohl N.AES (MiNT sei Dank) als auch MagiC stellen Threads zur Verfügung -auf die Diskussion, welches Betriebssystem nun echte Threads bietet und welches nicht, will ich mich hier nicht einlassen.

Für die Implementierung einer solchen Anwendung müssen Sie sich nur Gedanken machen, wie der jeweilige Thread mit dem Hauptprogramm über den Status der Internet-Verbindung und wie er das Ergebnis übermittelt. So könnten die Threads den Status über Flags mitteilen, die vom Hauptprogramm regelmäßig abgefragt werden (evnt_timer()). Wesentlich schöner ist die Kommunikation über AES-Events: Der Thread schickt seinen Status mittels appl writeQ an das Hauptprogramm, das diese als Ereignis in seiner Nachrichtenschleife verarbeitet. Der umgekehrte Pfad wird beschriften, falls das Hauptprogramm einem Thread zusätzliche Kommandos geben muss. Das Multithreading könnte von einem findigen Entwickler gar soweit ausgebaut werden, daß das Socket-Interface komplett auf eine AES-Events basierende GEM-Schnitt´stelle abgebildet wird.

Am Ende...

der Grundlagen des Socket-Interface angelangt, hoffe ich, daß Sie Laune bekommen haben, das eine oder andere Programm für das Internet zu entwickeln -gerade für die TOS-Plattform gilt es noch einige Lücken zu schließen. Für weitergehende Fragen oder Probleme bei der Entwicklung mit dem Socket-Interface möchte ich Sie auf die Webpage http:// www.camelot.de/~zulu/ verweisen.