Die schrittweise Entstehung und Weiterentwicklung der Z80-Software für das TCP/IP-Netzwerk am KC85-System unter CAOS und CP/M.

Das KCNET läuft und nun benötigt man natürlich Software, um sich mit diesem völlig neuen Anwendungsgebiet des KC85 Systems auseinanderzusetzen. Damit das erfolgreich funktioniert, gibt es hier Tipps und Hinweise zu TCP/IP-Netzwerken allgemeiner Art, wobei die Abweichungen und Einschränkungen der KCNET-Software gegenüber anderen Systemen an der entsprechenden Stelle herausgearbeitet werden.

Grundgedanken

Was ich selbst vor einigen Jahren auch nicht für möglich und sinnvoll gehalten habe - wahrscheinlich hätte ich mich selbst für verrückt erklärt oder einfach nur belächelt - ist jetzt Realität. Der KC85 hat eine TCP/IP-Schnittstelle ins Ethernet-Netzwerk !!!

Was kann man nun damit machen? Das lässt sich aus heutiger Sicht noch gar nicht beantworten oder anders gesagt, die Möglichkeiten sind einfach endlos. Sicher werden viele Leute bei dieser Frage sofort an die üblichen Verdächtigen wie E-Mail, Telnet, FTP u.s.w. denken aber das ist nur ein Teil von dem, was man machen kann.

Es geht auch nicht unbedingt immer um die Verbindung von KC und PC oder KC und Internetserver, das KCNET-Interface ist der Schlüssel zu einer Basistechnologie. Die kann man durchaus auch für reine KC-Anwendungen einsetzen, welche nur von anderen KC's "verstanden" werden, denn das geht jetzt auch - die Vernetzung von 2 oder mehr KC85 per TCP/IP ohne irgendwelche "Hilfsrechner". 

TCP/IP hat sich als Kommunikationsstandard in den letzten Jahren immer mehr ausgebreitet, im Bereich der Mikrocontroller geht das beispielsweise zur Zeit rasend schnell. Das Resultat sind intelligente Netzwerkgeräte, welche per TELNET oder als Webserver eine Schnittstelle zur Aussenwelt bereitstellen - auch das ist ein breit gefächertes und sehr interessantes Gebiet, welches sich nun erforschen lässt.

TCP/IP an sich ist nur eine dumme aber sehr mächtige und universelle Möglichkeit beliebig Daten zu transportieren - per Internet fast in jede Ecke der ganzen Welt - mehr aber auch nicht. Die Intelligenz einer TCP/IP-Anwendung wird erst in der Applikationsschicht hinzugefügt, welche im Fall des KCNET vom Programmierer der Z80 Software bereitgestellt werden muss!

Wie bei allen anderen KC-Projekten benötigt man für eine Umsetzung von Anwendungen etwas Fingerspitzengefühl - vieles ist möglich aber nicht alles sinnvoll.

In den Fällen, wo nur Textinformationen verarbeitet werden, sollte es keine Engpässe geben, genauso wie bei der Übertragung von Binärdaten zwischen verschiedenen Systemen. Selbst im Grafik- oder Spielebereich sollten auf die Fähigkeiten des KC85 zugeschnittene Anwendungen über das Netzwerk möglich sein.

Sobald aber die Datenmengen in die Nähe des MByte-Bereiches kommen oder wo es um Echtzeitübertragung von beispielseise Video- oder Audiodaten geht, verdirbt die begrenzte Rechenleistung des niedrig getakteten Z80 ziemlich schnell den Spass an der Freude, so etwas lässt sich dann auch nur mit dem Einsatz externer Hardware sinnvoll verbinden, z.B. im Audiobereich.

Mittlerweile könnte ich fast selbst schon ein kleines Buch dazu schreiben, der Aufwand für einen Amateur, ein solches Projekt durchzuziehen, ist beträchtlich. Ich beschäftige mich zwar bereits einige Jahre mit der Thematik, wenn es aber dann an die Umsetzung und Programmierung geht, ist das noch einmal eine Klasse für sich.

Mein Projektordner auf dem PC belegt mittlerweile 240 MB, wobei allein die Unterlagen zu TCP/IP, Netzwerken und ihren Protokollen über 140 MB Literatur enthalten. Das habe ich nicht nur gesammelt, sondern fast alles gelesen bzw. wenigstens mal überflogen.

Die Problematik bei der Programmierung der KCNET TCP/IP-Software lag deshalb nicht unbedingt darin, wie etwas programmiert werden muss, sondern mehr darin, was muss man programmieren oder womit fängt man günstigerweise an. Glücklicherweise ist diese Phase nun überstanden und ich habe unheimlich viel dabei gelernt.

Durch die weite Verbreitung, ständige Vervollkommnung und Weiterentwicklung der TCP/IP-Netzwerkprotokolle kann man leider immer nur Teilgebiete bearbeiten. Aber nun ist zumindest eine nachnutzungsfähige Basis für Z80-Systeme vorhanden und vielleicht gibt es später auch andere Programmierer, welche sich damit beschäftigen wollen und mitmachen - es lohnt sich!

Ich allein kann unmöglich 20 Jahre Rückstand in der Entwicklung von Z80 Netzwerk-Software für TCP/IP aufholen. Mein hauptsächliches Ziel, das Netzwerk bequem für die Übertragung von Daten zu benutzen, ist bereits erreicht. Die Nutzung diverser Dienste des Internet für den gleichen Zweck wird noch folgen.

Das benötigt alles seine Zeit, welche leider auch bei mir nicht unbegrenzt zur Verfügung steht. Das laufende Jahr war dort bereits sehr grenzwertig, was man vielleicht den folgenden Zeilen auch entnehmen kann. Andererseits habe ich es bisher rückblickend noch nicht bereut, da alles so funktioniert, wie ich mir das gedacht und natürlich auch gewünscht habe. 

Nach der erfolgreichen Inbetriebnahme der Hardware und Interface-Software begann im Januar die Planung und Umsetzung der Z80-Software. Da ich konzeptbedingt die Intelligenz der originalen Controllersoftware einfach in das Z80-System verlegt hatte, war klar - erst mal den WIZnet Treiber von C in Z80-Assembler übersetzen. Das ging ganz gut und verhältnismässig schnell.

Der Treiber macht auch keine besonders komplizierten Sachen, oft sind nur die Register des W5100 mit festgelgten Werten laut Datenblatt zu beschreiben, um eine bestimmte Funktionalität zu erreichen. Etwas aufwendiger gestaltete sich die Berechnung der KCNET-Adressen für den Transport von Netzwerkdaten aus dem Z80-System in die Sende- und Empfangspuffer der 4 Sockets an die richtige Stelle. Das wird aber im Datenblatt recht ausführlich erklärt, man muss es nur verstehen.

Danach wurden die Beispiele von WIZnet aus Abschnitt 5 des Datenblattes mit dem Urtreiber nachprogrammiert - an dieser Stelle war der KC85 dann das erste Mal online per TCP-Protokoll als Client und auch als Server. Anschliessend ging es weiter mit UDP, auf IP-Ebene und ganz unten auf der MAC-Ebene des Ethernet-Controllers, wo der TCP/IP-Stack gar nicht mehr benutzt wird.

Das hat alles mehr oder weniger auf Anhieb funktioniert und die Qualität und Inhalte des Datenblattes waren dort eine sehr gute Hilfe. Man konnte immer den C-Treibercode mit den Angaben im Datenblatt vergleichen und so lange am Z80-Code feilen, bis es fehlerfrei funktionierte.

Angetrieben von diesen ersten Erfolgen wurde anschliessend festgelegt, nicht nur den Grundtreiber zu implementieren, sondern gleich Nägel mit Köpfen zu machen und auch die komplette Socket-Schnittstelle von WIZnet, welche natürlich auch nur in C vorlag, umzusetzen.

Ich sah diesen zusätzlichen zeitlichen Aufwand von einigen Wochen als Investition in die Zukunft, welche die Programmierung von Netzwerkprotokollen vereinfachen und später wesentlich mehr Zeit einsparen würde, als dafür zunächst aufzubringen war.

Die Socket-Routinen wurden nicht 1:1 übernommen, sondern so geändert, dass man etwas näher an der BSD-Definition liegt, was die einzelnen Funktionen betrifft, das ist in meinen Augen kompatibler als die Variante von WIZnet.

Aus heutiger Sicht war das eine absolut richtige Entscheidung, man merkt bei der Programmerstellung kaum noch etwas vom Chip oder etwa dem KCNET-Protokoll der Schnittstelle, das wird alles schön hinter den Socket-Funktionen versteckt, so dass man sich voll auf die Anwendung konzentrieren kann.

Man benötigt mittlerweile für eine standardmässige UDP- oder TCP-Anwendung noch nicht einmal die Kenntnis irgendwelcher Adressen im KCNET-Interface. Sobald Daten zu senden oder zu empfangen sind, ruft man die Socket-Funktionen mit der Quell- bzw. Zieladresse des Z80-Systems auf und überlässt ihnen dann den Transport der Daten in Eigenregie. 

So entstand im Verlauf der gesamten Entwicklung eine gut strukturierte und damit verhältnissmässig einfach zu benutzende Software-Schnittstelle für das KCNET TCP/IP-Interface, welche auch den grössten Teil der Entwicklungszeit beanspruchte.

Grundsoftware

Wenn man eine Software-Schnittstelle entwickelt, benötigt man natürlich auch ein Programm, womit man die einzelnen Funktionen austesten kann. Bis zur Version 1.2 des Interface wurde das ausschliesslich unter CP/M mit CPMNET.COM durchgeführt, was parallel immer weiterentwickelt wurde.

Da man CP/M auf dem KC85 nur mit Diskettenerweiterung D004 benutzen kann, wurde Mitte des Jahres fast die komplette Funktionalität des Programmes in das CAOS-Programm CAOSNET.KCC transferiert, was auf allen KC's ausser dem Ur-KC85/2 laufen sollte. Ich kann das nicht testen, da ich nur KC85/4+ Geräte besitze.

Ende des Jahres wurde die Entwicklung der KCNET-Grundsoftware mit der Version 1.5 abgeschlossen. Diese Version synchronisiert die Funktionalität beider Programme 1:1, so dass es keine Unterschiede mehr gibt.

Diese beiden Programme sind damit die Referenzsoftware für das KCNET-Interface. Die Quellcodes stehen komplett im Downloadbereich zur Verfügung, sie sind für den Microsoft-Assembler M80 und kompatible geeignet. Ohne D004 muss man alle Programmieraktivitäten z.B. in einen Emulator auf den PC auslagern, das funktioniert auch unter Windows, die komplette Software wurde so programmiert.

Die beiden Programme zeigen den Gebrauch aller Schnittstellenfunktionen des KCNET-Protokolls und enthalten Beispiele für die mögliche Programmierung der verschiedenen Schichten des W5100 mit den üblichen Protokollen eines TCP/IP-Stacks. Auch die "unnützen" Menübefehle ICMP- und MAC-Socket aus der frühen Entwicklungsphase wurden in der Testsoftware gelassen.

KCNET Socket-API

Wie auf dem Bild zu sehen ist, unterteilt sich die Software-Schnittstelle logisch in drei Schichten, welche mit Hilfe der Menü-Funktionen der analog vorhandenen Menüs von CAOSNET bzw. CPMNET angesprochen und erprobt werden können.

Ganz unten und der Hardware am nächsten stehen die Befehle des KCNET-Protokolls, welche an jeder KCNET-Aktion beteiligt sind. Aus verschiedenen Gründen enthält dieses Protokoll zusätzliche Servicefunktionen für das Host-System mit dem Z80, welche für die Umsetzung bestimmter immer wiederkehrender Software-Bestandteile von Netzwerkprogrammen benötigt werden. Sie werden intern von der Firmware des Interface nebenbei mit erledigt und haben mit dem WIZnet TCP/IP-Stack direkt nichts zu tun.

Eine Stufe höher in der Mitte befinden sich vor allem diverse Routinen, welche für die Einstellung der Register-Parameter des W5100 benötigt werden und die Unterprogramme für den Transport von Daten aus dem Z80-System in die Sende- bzw. Empfangspuffer der W5100-Sockets und zurück.

Das eigentliche API für Programmierer steht dann schliesslich ganz oben und stellt die BSD-Sockets ähnliche Schnittstelle für Assemblerprogramme bereit. Grundsätzlich werden nur die Hauptregister des Z80 für Parameter benötigt, welche auch durchgehend immer in der gleichen Art und Weise entsprechend der Z80-Philosophie benutzt werden:

• Register A enthält die Socket-Nummer
• Register E bzw. DE enthalten Parameter
• Register HL und falls notwendig DE enthalten Adressen
• Register BC enthält Zähler

Um das Prinzip der Socket-Programmierung zu verstehen, kann und sollte man sich bezüglich W5100 mit seinem Datenblatt auseinandersetzen und in unzähligen Dokumenten über TCP/IP und darauf basierenden Netzwerken nachlesen, wie zum Beispiel:

Ein Grund für die grosse Verbreitung und Nutzung von TCP/IP für Netzwerke ist die freie Verfügbarkeit von technischen Informationen. Die oben aufgeführten Dokumente haben die Entwicklung und Umsetzung von TCP/IP für den Z80 und damit das KC85-System erst ermöglicht. Deshalb soll an dieser Stelle auch ein herzlicher Dank an die Autoren der interessanten und detaillierten Unterlagen gehen, welche uneigennützig für die Allgemeinheit im Internet zur Verfügung stehen!

Hinter den Menüpunkten des Netzwerk-Menüs von CAOSNET bzw. CPMNET verstecken sich schliesslich die Programmbestandteile, welche als Netzwerk-Programme bezeichnet werden. Das sind normalerweise Programme, welche die Socket-API benutzen, um mehr oder weniger sinnvolle Dinge für den Computer-Anwender mit Hilfe des Netzwerkes und seiner Dienste zu erledigen.

Jedes Programm, welches einen (oder mehrere) Netzwerkdienst(e) in Anspruch nehmen will, muss die Sprache dieses Dienstes beherrschen - welche als Netzwerk-Protokoll bezeichnet und in sog. RFC's vorgeschlagen, diskutiert und schliesslich definiert oder verworfen wird.

Von diesen Protokollen gibt es für TCP/IP-Netzwerke mehrere hundert, welche alle beliebig und gleichzeitig im Netzwerk benutzt werden dürfen - mich wundert es immer wieder, dass das überhaupt noch so reibungslos funktioniert!

Das verwendete Prinzip ist immer das gleiche, Socket besorgen, öffnen, Daten verarbeiten, Socket schliessen. Das unterscheidet sich also nicht oder kaum von anderen Schnittstellen. Allerdings gibt es auch im Netzwerk immer das Henne-Ei-Problem oder anders gesagt, wer fängt zuerst an.

TCP/IP regelt das auf eine ganz klare Art und Weise, indem der Netzwerk-Prozess einen Socket PASSIV oder AKTIV öffnet und damit zum SERVER- oder CLIENT-Programm wird:

• SERVER = PASSIV: SOCKET -> BIND -> LISTEN
• CLIENT = AKTIV: SOCKET -> (BIND) -> CONNECT

Wie man am Namen der letzten Funktion schon erkennen kann, fängt damit das CLIENT-Programm immer mit der Datenübertragung an, indem es Daten an ein darauf wartendes SERVER-Programm schickt.

Ganz allgemein besteht also eine TCP/IP Netzwerk-Anwendung aus einem Server- und einem Clientprogramm, welche miteinander kommunizieren. Das Clientprogramm ist immer der aktive Teil der Anwendung, welches dem Serverprogramm sagt, was es zu machen hat. Das folgende Bild zeigt das Prinzip schematisch, welches genau so auf das KCNET-Interface zutrifft:

An dieser Stelle gibt es Einschränkungen durch den W5100. Er enthält erstens kein Loopback-Interface, so dass beispielsweise ein PING-Befehl auf die eigene Netzwerk-Adresse nicht beantwortet wird und zu einer Fehlermeldung führt. Zweitens können die Sockets untereinander auch nicht kommunizieren. Das heisst im Klartext, dass TCP/IP-Anwendungen auf dem gleichen Z80-System - im Gegensatz zu anderen Systemen - auch nicht untereinander kommunizieren können.

Demzufolge ist die Kommunikation zwischen Server- und Clientprogrammen auf dem gleichen Computer mit dem KCNET-Interface nicht möglich. Da weder CAOS noch CP/M Multitasking oder Multithreading beherrschen, ist das auch nicht notwendig oder besonders sinnvoll.

Der TCP/IP-Stack des KCNET-Interface ist demzufolge auch nicht in die Software des Betriebssystems eingebettet, sondern funktioniert prinzipiell eher wie eine normale Schnittstelle zur Peripherie. Da der W5100 mehrere Sockets hat, kann man in einem Anwendungsprogramm aber trotzdem die folgenden Beispiele umsetzen, wobei das Programm in einer Schleife alle benutzten Sockets nacheinander bedienen kann. Der TCP/IP-Stack hat für jeden Socket einen Datenpuffer von je 2 kByte für den Empfang bzw. das Senden von Daten, so dass er in der Zwischenzeit vollkommen autonom seiner Arbeit nachgehen kann:

• Nutzung mehrerer verschiedener Netzwerkdienste parallel
• Betrieb von Client- und Server-Programm des gleichen Dienstes
• Aufbau mehrerer Verbindungen zwischen Client und Server / Server und Client
• Aufbau mehrerer Verbindungen zu verschiedenen Servern als Client
• Entgegennahme von Verbindungsanforderungen von mehreren Clients als Server
• u.s.w.

Wenn das Interface nicht mit sich selbst sprechen kann, braucht man einen anderen Gesprächspartner. Das kann nun ein anderer KC85 mit einem KCNET-Interface, ein PC mit Netzwerkanschluss oder auch ein Internet-Server sein. man benötigt also allgemein immer einen zweiten Netzwerkteilnehmer, welcher als PEER bezeichnet wird.

Wie sich das mit den Netzwerk-Adressen des eigenen Computers und des Peer verhält, kann im Beitrag zur Netzwerk-Konfiguration nachgelesen werden. Die nachfolgenden Ausführungen gehen davon aus, dass das eigene KCNET-Interface konfiguriert ist und funktionsfähig am Netzwerk hängt.

Die Netzwerk-Adresse des anderen Netzwerk-Teilnehmers wird in den beiden Testprogrammen im Netzwerk-Menü ganz oben hinter PEER: angezeigt. Direkt darunter kann man hinter LOCAL: seine eigene Adresse sehen.

Die Netzwerk-Adresse des gewünschten Servers kann in allen Client-Funktionen der beiden Testprogramme beim Start der Funktion eingegeben werden, die entsprechende Anzeige wird nach dem Beenden der Funktion und Rückkehr in das Netzwerk-Menü aktualisiert.

Hinter den Adressen der beiden Kommunikationspartner kann man eine weitere Zahl sehen, welche durch einen Doppelpunkt abgetrennt dargestellt wird. Dahinter verbirgt sich die Angabe für den PORT, welcher für die Kommunikation auf der Transportschicht (s.u.) zwischen Client- und Serverprogramm benutzt wird.

Das ist das Unterscheidungsmerkmal für die Daten von mehreren parallel laufenden TCP/IP-Prozessen, welche die gleiche Netzwerk-Adresse verwenden.

Die Port-Angabe ermöglicht einem TCP/IP-Programm trotz identischer Netzwerk-Adresse mehrere parallele Verbindungen gleichzeitig zum Peer aufzubauen und sie ermöglicht überhaupt erst den Betrieb verschiedener TCP/IP-Programme (Netzwerkprotokolle) parallel und gleichzeitig auf der gleichen Netzwerk-Adresse - so wie wir das vom PC gewohnt sind.

Diese beiden Parameter - Netzwerk-Adresse (32 Bit) und PORT (16 Bit) - werden nun ähnlich der BSD-Definition als SOCKET (48 Bit) bezeichnet und über diese Sockets wird die gesamte Kommunikation der TCP/IP-Software abgewickelt. Der Socket stellt einen Kommunikationsendpunkt für die Software zur Verfügung, welchem die Daten einer Applikation übergeben werden bzw. von dem die Applikation Daten erhält.

Im folgenden Bild ist das schematisch für die Kommunikation zwischen HTTP-Client auf Host A (Webbrowser) und HTTP-Server auf Host B (Webserver) einmal dargestellt:

Aus der Sicht des Z80-Programmierers ist das vergleichbar mit anderen Schnittstellen und ähnelt beispielsweise der Programmierung von seriellen oder parallelen Kanälen eines Z80-Systems, wobei es natürlich auch Unterschiede gibt.

Die Netzwerkschnittstelle ist flexibler und leistungsfähiger aber von der Handhabung läuft alles genauso ab, Schnittstelle öffnen / Daten lesen bzw. schreiben / Schnittstelle schliessen. Das Prinzip der TCP/IP-Sockets ist der Schlüssel dazu und wenn man das verstanden hat, kann man relativ einfach Netzwerkprogramme schreiben.

Da ein Socket gleichzeitig auch die Schnittstelle zur Transportschicht des TCP/IP-Stacks ist, kann bzw. muss man ein vorhandenes Transportprotokoll des TCP/IP-Stacks benutzen, was beim Aufruf der API-Funktion SOCKET des TCP/IP-Treibers mit angegeben werden muss.

Die zwei Transportprotokolle, welche mit dem TCP/IP-Treiber für den W5100 benutzt werden können, heissen TCP (Transmission Control Protocol) bzw. UDP (User Datagram Protocol), die Unterschiede kann man in den oben angegebenen Literaturquellen nachlesen.

Je nach gewähltem Transportprotokoll wird ein TCP-Socket als Stream Socket und ein UDP-Socket als Datagram Socket bezeichnet. Alle gängigen und bekannten Netzwerk-Anwendungen basieren auf diesen beiden Transport-Protokollen, von speziellen Anwendungen einmal abgesehen.

Wie man in der letzten Abbildung sehen kann, können sich die Portnummern von Client- und Serverprogramm, welche miteinander kommunizieren, auch unterscheiden. Allerdings muss das Clientprogramm als aktiver Teil der Anwendung die Portnummer und Netzwerk-Adresse des Servers kennen, damit es aktiv die Verbindung zum Server überhaupt herstellen kann.

Das Serverprogramm wiederum muss genau mit diesem Port gestartet worden sein und passiv auf die Verbindungsaufnahme durch das Clientprogramm warten, wobei es die Portnummer des Clientprogrammes aber nicht kennen muss.

Diese Zusammenhänge muss man beim Experimentieren mit den TCP- und UDP-Socketfunktionen der Testprogramme beachten, sonst wird es nicht funktionieren!

Der Hauptunterschied zwischen TCP- und UDP-Transportprotokoll besteht darin, dass vor einer Übertragung von Daten per TCP eine Verbindung zum Peer hergestellt werden muss, mit UDP ist das nicht notwendig, man schickt die Daten einfach an den Peer-Socket ab und geht davon aus, dass sie auch ankommen. 

In der nachfolgenden Abbildung werden die grundsätzlichen Merkmale und Unterschiede von TCP- und UDP-Transportprotokoll noch einmal zusammenfassend dargestellt:

In der Regel schreibt ein definiertes Netzwerk-Protokoll vor, ob es die Daten per TCP oder UDP transportieren möchte, es gibt auch Protokolle, welche die Datenübertragung per UDP oder TCP gestatten.

Für die Umsetzung spezieller Dienste in einem Netzwerk reicht es nicht aus, den TCP/IP-Stack ausschliesslich per UDP oder TCP auf der Transportschicht ansprechen zu können.

Fast allen fortgeschrittenen PC-Anwendern ist die Nutzung des bekannten PING-Kommandos in der Kommandozeile von MSDOS bekannt, womit man u.a. überprüfen kann, ob ein anderer Teilnehmer des Netzwerkes erreichbar ist.

Dieses Programm arbeitet eine Schicht tiefer auf IP- bzw. Internet-Schicht mit einem vorhandenen TCP/IP-Stack. Ganz unten befindet sich schliesslich noch die Netzwerk-Schicht, wo im Fall des KCNET die physische Übertragung der Daten per Ethernet geregelt wird, siehe folgende Abbildung:

Auch diese beiden Schichten können mit Hilfe der KCNET-Software benutzt werden. In den Testprogrammen gibt es zwei Funktionen im Netzwerk-Menü, ICMP- bzw. MAC-Socket, welche bereits während der frühen Experimentierphase programmiert wurden und für die Demonstration genau dieser Sachverhalte und Möglichkeiten im Programm belassen wurden.

Beide Beispiele stammen aus dem Datenblatt des W5100, sie wurden allerdings nicht nur nachprogrammiert, sondern um einige Ausgaben erweitert, so dass man auf dem Bildschirm auch etwas sehen kann.

Im Oktober 2008 wurden die letzten Änderungen und Ergänzungen an der Socket-Schnittstelle vorgenommen und die noch fehlende DNS-Funktionalität ergänzt. Mit Hilfe des DNS-Protokolls ist man nun in der Lage, in jeder Netzwerk-Anwendung mit den gängigen Domain-Namen zu arbeiten, statt namenlose und schlecht zu merkende IP Netzwerk-Adressen verwenden zu müssen.

Der DNS-Client wird per INCLUDE Befehl in ein Projekt eingebunden (Datei DNSC-xx.INC, siehe folgende Tabelle) und per Aufruf der beiden Hauptfunktionen benutzt. Das kann man sich auch wieder in den Quellen der entsprechenden Netzwerkprogramme anschauen, welche bei Notwendigkeit davon Gebrauch machen.

Wenn man im lokalen Netzwerk einen DNS-Dienst zur Verfügung hat, kann man auch dort andere Netzwerkteilnehmer über ihre Namen erreichen, was den Komfort bei der Benutzung von Netzwerkprogrammen erheblich steigert.

Damit ist auch die Grundlagenarbeit für das TCP/IP-Netzwerk am KC85 oder anderen Z80-Systemen abgeschlossen und es stehen bereits eine ganze Menge an Quelltexten und damit nachnutzbare Softwarebestandteile zur Verfügung.

Alle Quellen zusammen werde ich zukünftig als "KCNET-Software" bezeichnen, nachfolgend eine Zusammenfassung von relevanten Dateien in Kurzform mit den wichtigsten Angaben: