Z80-Programm für das Kennenlernen und Ausprobieren des KCNET-Interface mit einem KC85 unter CAOS oder CP/M. Nach Anpassung von wenigen Parametern in der Datei KCNET.INC und erneute Übersetzung der CP/M-Variante sollte diese mit jedem CP/M kompatiblen System ab Version 2 sofort funktionieren.
Nach etwas Theorie - leider geht es nicht ohne - wird es hier nun langsam praktischer. Ein TCP/IP-Stack ohne Software ist wertlos, egal ob er an einem Controller oder Z80 hängt. Da das für mich ebenfalls absolutes Neuland war, was meine Programmieraktivitäten auf dem KC85-System betrifft, hat es ein wenig gedauert mit fertigen Programmen aber irgendwann ist es dann soweit.
Im folgenden Artikel geht es um das Universalwerkzeug zum Test der KCNET Hard- und Software. Das Programm kann gleichzeitig als Lernspielzeug für die Durchführung der ersten Netzwerk-Experimente eingesetzt werden, um die Funktionsweise von TCP/IP-Programmen als Client oder Server im Netzwerk zu verstehen.
Allgemeines
Mit der fünften Hauptversion wurde die funktionale Weiterentwicklung beendet und das endgültige Leistungsspektrum festgelegt. Die beiden Programme CAOSNET.KCC und CPMNET.COM sind nun absolut identisch, was die einzelnen Menüs und ihre Funktionen betrifft. Entsprechend dem Programmnamen ist das eine für die CAOS-Betriebsart eines KC85 gedacht, das andere kann man nur unter CP/M benutzen.
Im KC85 System wird für beide Programme ein Modul M052 in einem beliebigen Modulschacht benötigt. Mit anderen CP/M kompatiblen Systemen muss für die Nutzung von CPMNET.COM eine entsprechend angepasste Variante (siehe Datei KCNET.INC) von CPMNET.COM verwendet werden. Im System ist dann hardwaremässig eine direkt programmierbare KCNET-Schnittstelle bereitzustellen, welche über die in der Datei KCNET.INC eingetragenen Parameter angesprochen werden kann.
Die beiden Programme stellen die Referenzsoftware für das KCNET-Interface dar, da nahezu alle Möglichkeiten der Treiberschnittstellen damit demonstriert werden. Vom Nutzen her gesehen, sind sie vor allem für die Diagnose und den Test des Netzwerkes gedacht. Die Quellcodes stehen komplett 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, dass funktioniert auch unter Windows, die komplette Software wurde so programmiert.
Die anschliessende Vorstellung der Testfunktionen und ihre Programmierung lässt sich damit für Interessierte nachvollziehen. Die beiden Programme zeigen den Gebrauch aller Schnittstellenfunktionen des KCNET-Protokolls und enthalten einige Beispiele für die mögliche Programmierung der verschiedenen Schichten des TCP/IP-Stacks W5100 mit den gängigen Protokollen. Auch die relativ nutzlosen Menübefehle ICMP- und MAC-Socket wurden aus diesem Grund im Testprogramm gelassen.
In den Menü-Abschnitten wird nicht mehr zwischen CAOS oder CP/M unterschieden, alle Testfunktionen sind absolut identisch. Für die Eingabe von Werten per Tastatur gilt prinzipiell immer, wenn man gar nichts eingibt, kommt man aus der Eingabe ohne Veränderungen wieder heraus, ein Abbruch erfolgt unter CP/M mit ESC oder CTRL-C und unter CAOS mit BRK, soweit das möglich ist.
Da beide Programme die Software-Schnittstelle des KCNET testen und demonstrieren sollen, wurde alles in drei Menüs verpackt, so dass man passend zur Softwarelogik auf 3 Ebenen Funktionen aufrufen kann.
CAOSNET.KCC
CAOSNET.KCC ist ein ganz normales CAOS-Programm, welches man von Kassette oder Diskette/HDD mit LOAD bzw. FLOAD laden kann. Das Programm läuft im Arbeitsspeicher des Grundgerätes ab Adresse 200H bis knapp unter 4000H (ab Version 1.6 wird im IRM der Bereich von BD00H bis BDFFH zusätzlich benötigt) und trägt nach dem Laden 3 neue Befehle in das CAOS-Menü ein, womit die 3 Testmenüs des Programmes aufgerufen werden können:
CPMNET.COM
Wenn man mit einem KC85 System unter CP/M arbeiten möchte, benötigt man mindestens einen geladenen Treiber für die KCNET-Schnittstelle des Moduls M052 im Grundgerät.Wenn man sich eine ZPIO-Variante mit einer entsprechendend angepassten Include-Datei KCNET.INC übersetzt hat, sind intern bereits alle notwendigen Treiber enthalten und das Programm kann im jeweiligen System sofort eingesetzt werden.
Unter dem originalen MikroDOS des KC85 gibt es für die Systemverwaltung das Dienstprogramm MSYSG.COM, mit dem der zur Verfügung stehende Standard-Koppeltreiber NET.KOP in das System eingebunden werden kann. Das wird in den Handbüchern zum D004 beschrieben. Dieser Treiber benutzt die Koppelschnittstelle des KC85-Systems zum Grundgerät, er kann sowohl mit KC85/3 als auch KC85/4+ eingesetzt werden.
Durch die kontinuierliche Weiterentwicklung von ZAS, der Steuerschleife im Grundgerät D001, gibt es ab Version 1.3 von ZAS eine weitere Möglichkeit. Mit dieser Version führt ZAS die Speicher- und Treiber-Verwaltung im freien RAM des Grundgerätes D001 ein. Für diese Konstellation gibt es die wesentlich schnellere Treiberkombination M052.DRV+NET.DRV, welche man mit Hilfe des Ladeprogrammes DRIVER.COM in das Grundgerät D001 laden und aktivieren kann.
DRIVER.COM kann darüber hinaus auch mit Standard-Treibern *.KOP umgehen, so dass man damit alle Treibervarianten flexibel und sogar im "fliegenden Wechsel" benutzen kann und das ältere MSYSG.COM eigentlich nicht mehr benötigt.
Da Systemtreiber im Grundgerät D001 eine KC85-spezifische Angelegenheit darstellen, spielt die verwendete CP/M-Version im D004 dort keine Rolle. Man muss nur auf die Gesamtkombination von D001 und D004 des KC85-Systems achten. Da *.DRV Treiber von ZAS abhängig sind und dieses bis zur Version 1.5 nur für den KC85/4+ zur Verfügung stand, gelten die Einschränkungen laut der nachfolgenden Tabelle:
ZAS Version |
NET.KOP | M052.DRV+NET.DRV | |||
(ZAS3V16.ZAS) | (ZAS4V16.ZAS) | KC85/3 |
KC85/4+ | KC85/3 |
KC85/4+ |
0.0 (originale Steuerschleife) | ja | ja | nein | nein | |
1.0 | ja | ja | nein | nein | |
1.1 | ja | ja | nein | nein | |
1.2 | ja | ja | nein | nein | |
1.3 |
ja | ja |
nein | ja | |
1.4 |
ja | ja |
nein | ja | |
1.5 |
ja | ja | nein | ja | |
1.6 (siehe oben) |
ja | ja | ja | ja |
Das Testprogramm CPMNET.COM lässt sich nur starten, wenn einer der beiden Treiber gefunden wird. Wenn beide Treiber vorhanden sind, benutzt das Programm automatisch M052.DRV+NET.DRV.
Die M052-Treiber für CP/M befinden sich im Downloadbereich bei der CP/M-Software. Im Archiv befindet sich noch ein weiterer Treiber NETI.KOP, welcher die KCNET-Schnittstelle des M052 komplett per Interrupt betreibt. Er trägt nur experimentellen Charakter und ist gleichwertig zum Standard-Treiber NET.KOP.
Da unter CP/M eine Menüverwaltung wie unter CAOS nicht vorhanden ist, enthält das Programm eine eigene Menüsteuerung. Man wechselt mit den Buchstaben I, T und N zwischen den Menüs und ruft dort ebenfalls mit Buchstaben oder Ziffern, welche angezeigt werden, die einzelnen Funktionen auf, mit Q bzw. X kann das Programm jederzeit beendet werden.
Ab Version 1.6 von CPMNET.COM kann man Parameter in der Kommandozeile nutzen, um sofort in ein bestimmtes Programm-Menü zu gelangen, standardmässig gelangt man ohne Parameter immer in das Netzwerk-Menü:
CPMNET [-h|v] [-itn] | ||
-h|v | - | Hilfe bzw. Version anzeigen und CPMNET.COM beenden |
-i | - | Interface-Menü aufrufen |
-t | - | TCP/IP-Menü aufrufen |
-n | - | Netzwerk-Menü aufrufen |
INTERFACE-MENU
Das Interface Menü bildet den grössten Teil des KCNET-Protokolls direkt ab und reicht die Werte von/an die entsprechende Menü-Funktion durch:
Ganz oben werden die Versionen der Firmware und Hardware des KCNET-Interface angezeigt, rechts steht der aktuelle Netzwerkstatus, welcher beim Aufruf des Menüs abgefragt wird. Das sind beispielsweise die Ergebnisse der Protokollfunktionen 9,10 und 11.
Mit der ersten Gruppe der Menübefehle kann man, ähnlich dem Debugger der Diagnose-Schnittstelle, den RAM und damit den W5100 im KCNET-Interface lesen und beschreiben. Die PIO hat keinen Schreibzugriff auf KCNET-Adressen kleiner 8000H. Damit ist man in der Lage den W5100 "zu Fuss" zu programmieren, siehe Beispiel im Artikel zur "Inbetriebnahme".
Wenn man sinnvolle Aktionen auslösen will, sollte man sich mit dem Datenblatt des W5100 auseinandersetzen, welches man von der Website http://www.wiznet.co.kr herunterladen kann. Entweder man sucht dort nach "W5100 Datasheet" oder schaut im Download-Bereich selbst nach.
Der TCP/IP-Stack W5100 ist im KCNET-Interface von 8000H bis FFFFH zu erreichen, zu allen Angaben im Datenblatt ist also ein Offset von 8000H zu addieren, so dass sich die folgenden Anfangsadressen ergeben:
COMMON REGISTERS | 8000 H |
|
SOCKET REGISTERS |
8400 H |
|
TX MEMORY |
C000 H |
|
RX MEMORY |
E000 H |
Der RX MEMORY des W5100 ist nur lesbar, man kann zwar Daten mit einem Schreibbefehl in diesen Bereich abschicken, sollte sich aber beim Zurücklesen nicht wundern, wenn etwas Anderes angezeigt wird.
Der Befehl ZEIGER bzw. POINTER ist vor dem Gebrauch der Funktionen SBYTES / LBYTES bzw. WRBYTES / RDBYTES aufzurufen. Er legt die Anfangsadresse im KCNET fest, wo von diesen Befehlen geschrieben / gelesen wird. Diese Adresse wird bei der Abarbeitung der einzelnen Bytes automatisch erhöht.
Die untere Gruppe liest diverse Informationen aus dem Interface aus und zeigt sie an. KENNUNG / ID ist die Bezeichnung des Stacks. TIMER gibt den momentanten Zählerstand des unendlich laufenden Millisekundenzählers (0-59999 ms) zurück.
SERVER / SERVER IP-ADDRESSES gibt die Inhalte der 8 Speicherplätze für IP-Adressen des Interface zurück.
Bei einer manuellen Konfiguration wird eine eingegebene Gateway IP-Adresse automatisch auch für den DNS-Server übernommen, wenn dieser noch nicht konfiguriert sein sollte. Man spart sich dann die manuelle Eingabe des DNS-Servers, da in den meisten Heimnetzwerken diese beiden IP's identisch sind, der (Hardware-)Router ist gleichzeitig Gateway und lokaler DNS-Server.
DYNPORT / DYNAMIC PORT gibt die nächste dynamische Port-Nummer aus dem Bereich 49152-65535 zurück, welche von Netzwerkprogrammen für den Aufbau ausgehender Verbindungen mit einem beliebigen Port genutzt werden kann. Das wird beispielsweise beim Aufruf von CONNECT der Socket-Schnittstelle benutzt, wenn der Socket vorher nicht mit BIND an einen bestimmten lokalen Port gebunden wurde.
FEHLER / COMMAND ERRORS ist eine Information für den Programmierer oder auch Anwender von Netzwerkprogrammen. Der zurückgegebene Wert entspricht den bisher aufgetretenen Fehlern bei der Interface-Kommunikation mit Hilfe der KCNET-Protokoll-Befehle, welcher normalerweise immer 0 sein sollte. Wenn sich der Wert bei der Nutzung von Programmen erhöht, wird die Syntax des Protokolls nicht eingehalten. Das Interface setzt sich dann nach einer Wartezeit von 524 ms selbst zurück, zählt diese Ereignisse aber mit.
TCP/IP-STACK MENU
Das TCP/IP-Stack Menü enthält Befehle für die manuelle Einstellung der wichtigsten statischen Parameter des TCP/IP-Stacks W5100 und zwei Funktionen für die Anzeige und das Zurücksetzen der gesamten Konfiguration:
Ganz oben wird die aktuelle IP-Adresse und Subnetzmaske für das Interface angezeigt und ob eingehende PING Echo-Anforderungen beantwortet werden sollen oder nicht (PING-Block Mode).
Mit Hilfe dieses Menüs lassen sich diverse Parameter des W5100 anzeigen oder ändern, weiterführende Informationen und Erläuterungen dieser Parameter sind wieder im Datenblatt des W5100 zu finden:
CAOS |
CP/M |
Register |
Bedeutung |
IPADRESSE |
IP-ADDRESS |
SIPR |
KCNET IP-Adresse im Netzwerk |
SUBNETZMASKE |
SUBNETMASK |
SUBR |
KCNET Subnetzmaske |
GATEWAY |
GATEWAY | GWR |
KCNET Gateway (IP-Adresse des Routers) |
EMAC |
MAC-ADDRESS |
SHAR |
KCNET Ethernet MAC-Adresse (nur lesbar) |
RETRYTIME | RETRY-TIME | RTR |
Zeit bis TCP-Sendewiederholung erfolgt (RTR*100µs) |
RETRYCOUNT | RETRY-COUNT | RCR | Anzahl der TCP-Sendewiederholungen bis TCP-Timeout |
PINGECHO |
PING-ECHO | Bit 4 MR |
Antwort auf PING-Anforderung ein/aus |
SOCKETS |
SOCKET-MODE |
Bit 0-3 Sn_MR |
Betriebsart des Sockets n |
Die Funktion INFO / IP-CONFIG gibt die aktuelle TCP/IP-Konfiguration des Stacks ähnlich dem MSDOS-Kommando "IPCONFIG" in Form einer komletten Übersicht aus. Dieses Kommando ist deshalb immer die Anlaufstelle Nummer 1, wenn man die aktuellen Parameter wissen bzw. überprüfen will. Auch bei Fehlfunktionen oder merkwürdigem Verhalten von Netzwerkprogrammen sollte man zuerst diese Funktion aufrufen und die Parameter kontrollieren.
Mit RESET wird der komplette Stack zurückgesetzt, wobei man eine bestehende Netzwerkkonfiguration erhalten oder löschen lassen kann. Das wäre die zweite Massnahme bei Unklarheiten oder Störungen - der gesamte TCP/IP-Stack wird neu initialisiert und muss danach wieder normal funktionieren.
Eine manuelle Konfiguration der Netzwerkparameter wird ebenfalls in diesem Menü vorgenommen und umfasst mindestens die Eingabe gültiger Parameter für die IP-Adresse und Subnetzmaske. Anschliessend sollte der CAOS- bzw. CP/M-Rechner im Netzwerk auf PING-Kommandos antworten (siehe Artikel Netzwerk-Konfiguration).
Wenn man auch auf Dienste ausserhalb des eigenen Netzwerkes, z.B. im Internet, zugreifen möchte, muss auch die IP-Adresse des Netzwerk-Gateway eingetragen werden, das ist im Normalfall die IP-Adresse des Routers im Netzwerk. Diese IP-Adresse wird auch automatisch als IP-Adresse für den DNS-Server im Netzwerk übernommen, wenn dieser noch nicht konfiguriert wurde.
Wenn man in seinem Netzwerk einen DHCP-Server zur Verfügung hat. sollte man die Konfiguration der Netzwerkparameter dem DHCP-Client des KC85 überlassen, so wie das im Beitrag zur Netzwerk-Konfiguration beschrieben wurde.
Mit der Funktion EMAC / MAC-ADDRESS wird die Ethernet-MAC-Adresse des KCNET-Interface angezeigt.
Mit den beiden Funktionen für RETRY TIME und RETRY COUNT (siehe Datenblatt W5100) können die Werte für die Reaktion des TCP/IP-Stacks auf Timeout-Zustände einer bestehenden TCP-Verbindung eingestellt werden.
Mit dem Kommando PING ECHO kann man die Beantwortung von PING Echo-Request-Paketen aus dem Netzwerk durch Echo-Reply-Pakete des W5100 ein- und ausschalten.
Das Kommando SOCKETS / SOCKET MODE listet die aktuellen Betriebszustände der 4 Sockets des W5100 auf, das ist ganz nützlich, um zu sehen, ob reservierte Sockets durch die Netzwerkprogramme ordnungsgemäss freigegeben werden - eigentlich sollte dort immer viermal FREI bzw. FREE zu sehen sein.
NETZWERK MENU
In diesem Menü sind alle Netzwerkfunktionen der beiden Testprogramme zusammengefasst, neben 3 Befehlen, welche die Arbeit mit umgesetzten offiziellen RFC-Protokollen ermöglichen, gibt es 5 Funktionen, welche die grundsätzliche Arbeitsweise der Schichten des TCP/IP-Stacks veranschaulichen sollen:
Grundlagen und Erläuterungen zu den nachfolgend verwendeten Begriffen und Bezeichnungen können im Artikel Netzwerk-Software nachgelesen werden, sie werden deshalb an dieser Stelle nicht noch einmal aufgeführt.
Im oberen Bereich sieht man seine eigene IP-Adresse und den aktuellen Port für die Kommunikation auf UDP- bzw. TCP-Ebene. Hinter PEER steht das noch einmal, das sind die Angaben für den Netzwerkteilnehmer, mit dem die letzte Kommunikation stattgefunden hat. Alle Funktionen des Netzwerkmenüs, wo Daten über das Netzwerk transportiert werden, erfordern neben dem eigenen KC85 einen anderen Netzwerkteilnehmer.
Wenn im Netzwerk eine Auflösung von Namen per DNS funktioniert (das probieren wir gleich aus), kann man auch mit den Domainnamen des lokalen Netzwerkes arbeiten. Für die Auflösung von Domainnamen muss der Gateway und DNS-Server konfiguriert sein (siehe Artikel zur Netzwerk-Konfiguration).
Wenn man eine Clientfunktion startet, muss man neben dem Namen bzw. der IP des Servers auch die Portnummer des Serverprogrammes kennen. Die Angabe des Netzwerk-Teilnehmers mit dem man kommunizieren will, erfolgt dann immer in der Form:
IP:Port | oder | Domainname:Port |
Damit man die Portnummer nicht jedesmal eingeben muss, kann man sie vorher mit der Funktion PEER PORT einstellen. In diesem Fall ist dann lediglich die Eingabe von IP bzw. Domainname notwendig, den Doppelpunkt und die Portangabe lässt man weg. Die aktuelle Portnummer wird oben in der PEER-Zeile hinter dem Doppelpunkt angezeigt.
Eine Serverfunktion startet grundsätzlich mit der oben angezeigten Portnummer hinter LOCAL, welche man vorher mit der Funktion LOCAL PORT entsprechend einstellen muss. Ein Serverprogramm muss die Portnummer des PEER nicht kennen, da sich dieser selbst aktiv meldet.
Je nachdem, ob der KC85 jetzt als Client oder Server im Netzwerk funktionieren soll, ist auf die Angabe bzw. Einstellung der richtigen Parameter zu achten, sonst werden die Experimente mit den TCP- und UDP-Socketfunktionen nicht funktionieren!
Als Kommunikationspartner im Netzwerk wird bei den meisten Anwendern ein Windows PC dienen. Da wir das Interface testen wollen, benötigen wir daher auf der PC-Seite ein Programm, welches TCP- bzw. UDP-Rohdaten, das sind Netzwerkdaten ohne Protokoll, so wie sie ankommen, empfangen und anzeigen bzw. umgekehrt entgegennehmen und senden kann.
Dafür ist das Hercules-Utility von http://www.hw-group.com (siehe dort Bereich SOFTWARE oder per Suchfunktion) ideal geeignet, da es für alle drei TCP/UDP-Socket Funktionen von CAOSNET bzw. CPMNET die passenden Gegenfunktion für den Test der Kommunikation integriert hat. Auf der Herstellerseite ist das sogar alles in deutsch beschrieben und eine Installation auf dem PC ist auch nicht notwendig, einfach die HERCULES.EXE starten und verwenden, im Bild sieht man beispielsweise die Einstellung für den Test eines UDP-Sockets:
Nach dem Start des Programmes wählt man mit den Reitern ganz oben die entsprechende Seite aus, trägt IP-Adresse (Module IP) und den entsprechenden Port des KC85 ein und kann dann wie mit einem Terminalprogramm Textnachrichten verschicken und empfangen.
Die nachfolgende Tabelle fasst die Problematik mit den Portnummern und den zugeordneten Bezeichnungen in beiden Programmen noch einmal zusammen, bevor es zu den einzelnen Funktionen des Netzwerkmenüs geht:
KC85-Funktion | Port | Port | HERCULES-Funktion | |
TCPSERVER | LOCAL | <= | Port Connect | TCP Client |
TCPCLIENT | PEER |
=> | Port Listen | TCP Server |
UDPSOCKET (Empfänger) | LOCAL | <= | Modul-IP Port | UDP (Sender) |
UDPSOCKET (Sender) | PEER | => | Local Port | UDP (Empfänger) |
DHCP CLIENT
Diese Funktion startet die automatische Netzwerk-Konfiguration für das Interface durch den DHCP-Dienst des lokalen Netzwerkes, wenn entweder die IP-Adresse oder Subnetzmaske nicht konfiguriert sind. Voraussetzung dafür ist ein DHCP-Server im Netzwerk, welcher selbständig gefunden wird.
Es werden insgesamt 7 Versuche unternommen, eine Konfiguration vom Server zu erhalten, wobei schrittweise die Wartezeit zwischen den einzelnen Anfragen immer weiter erhöht wird, um auch in "schlechten" Netzwerken eine Antwort zu bekommen - selbst in Ballenstedt hat es spätestens im vierten Anlauf immer geklappt :-). Der gesamte Vorgang kann bis zu ca. 60s dauern und wird danach mit einer Timeout Meldung abgebrochen.
Beim Aufruf der Funktion muss man für den KC85 einen Computer-Namen angeben. Dieser Name wird vom DHCP-Dienst an den DNS-Dienst des lokalen Netzwerkes weitergereicht, wenn dieser vorhanden und entsprechend konfiguriert ist. Gibt man nichts ein, wird die Funktion abgebrochen. Der gesamte Vorgang kann auch vorzeitig mit Hilfe der o.g. Abbruchtasten beendet werden.
Wie das DHCP-Protokoll funktioniert, kann man in RFC 2131 nachlesen, beispielsweise auf www.rfc-editor.org.
Der gleiche Client ist im CP/M Konfigurationsprogramm NCFG.COM (siehe Software -> CP/M) eingebaut, dort muss der KC85-Name als Argument in der Kommandozeile oder einer vordefinierten Konfiguration der Datei NCFG.INI angegeben werden. Die Daten, welche der DHCP-Client empfängt, überschreiben immer eventuelle bereits eingetragene andere Parameter, wie beispielsweise Gateway oder DNS-Server IP-Adresse, wenn sie in der Antwort des DHCP-Servers zurückgegeben werden.
Wenn die Kommunikation zwischen DHCP-Client und DHCP-Server erfolgreich war, wird eine komplette Liste mit allen erhaltenen Parametern auf dem Bildschirm ausgegeben und gleichzeitig das KCNET-Interface damit konfiguriert.
PING CLIENT
Hinter dieser Funktion steckt ein erwachsener ICMP-Client/Server. Was das ist und wozu das gut ist, steht im Artikel zur Netzwerk-Konfiguration. Das ICMP-Protokoll wird in RFC 792 beschrieben. Die Leistungsfähigkeit des Client liegt mittlerweile irgendwo zwischen den Windows- und Linux-Clients, welche dort mit dem Betriebssystem geliefert werden.
Da es davon auch eine Einzelvariante PING.COM für CP/M gibt, wird die Funktionalität dort beschrieben (siehe Software -> CP/M).
Unter CAOS werden alle Parameter direkt am Bildschirm abgefragt. Unter CP/M steht nach dem Start der Funktion unten PING _ und der Cursor blinkt. Jetzt kann einmalig ENTER gedrückt werden, worauf die komplette Hilfe ausgegeben wird und wieder PING _ vor sich hin blinkt. Nach Eingabe der optionalen Parameter und des obligatorischen Zieles, werden entsprechend PING-Requests gesendet und die Antworten oder Fehlermeldungen ausgegeben.
Das Ziel kann auch als Domain-Name eingegeben werden, die IP-Adresse wird dann im Hintergrund durch eine DNS-Abfrage entsprechend aufgelöst.
DNS CLIENT
Diese Funktion ist der Zugang zum sogenannten Resolver. Der ist für die Umwandlung von Domainnamen in numerische 32 Bit IP-Adressen oder umgekehrt zuständig. Normalerweise bekommt man den unter anderen Betriebssystemen gar nicht zu Gesicht, da er meist im Hintergrund arbeitet aber immens wichtig ist. Ohne ihn müssten wir alle Internet-Adressen als IP-Adresse eingeben, was dem Internet sicher nicht zum Durchbruch verholfen hätte.
In RFC 1034/1035 wird DNS beschrieben, wobei es zahlreiche ergänzende Dokumente gibt, wie beispielsweise RFC 2929, RFC 3696 oder RFC 4343.
Der Resolver des KC85 stellt nur die Grundfunktionalität eines DNS-Clientprogrammes zur Verfügung, was in 99,9 % aller Fälle für ein Heimnetzwerk ausreicht.
Nach dem Start der Funktion kann man nun einen beliebigen Domainnamen eingeben und ENTER drücken, worauf die entsprechende IP-Adresse als Ergebnis ausgegeben wird oder eine Fehlermeldung (die Ursachen der möglichen Fehlermeldungen kann man im Quelltext der Datei DNSCxx.INC nachlesen). Ein DNS SERVER ERROR 3 bedeutet beispielsweise, dass kein Host mit dem eingegeben Namen gefunden wurde.
Der umgekehrte Weg kann dafür benutzt werden, herauszufinden, ob eine lokale Auflösung von Hostnamen im Heimnetzwerk zur Verfügung steht. Also die IP-Adresse des KC85 eingeben und ENTER, wenn ein Name zurückgegeben wird, kann man den KC unter diesem Namen dann auch im lokalen Netz ansprechen. Wenn nicht, müssen in allen Netzwerkanwendungen als Ziel immer und auschliesslich die IP-Adressen der lokalen Rechner im eigenen Netzwerk angegeben werden!
Für Ziele im Internet trifft das natürlich nicht zu. Dort werden die Hostnamen über die DNS-Server Eures Internet-Providers aufgelöst und das sollte immer funktionieren!
TCP SERVER
Mit dieser Funktion wird der KC85 zum TCP-Server im Netzwerk. Nach dem Start tut sich erst mal nicht viel, es erfolgt eine Meldung, dass der Server auf dem eingestellten lokalen Port läuft und auf einen Client wartet.
Jetzt kann man mit der TCP-Client Funktion des o.g. HERCULES Programmes mit den in der Tabelle dargestellten Parametern eine Verbindung herstellen, indem man CONNECT betätigt. Der KC gibt daraufhin eine entsprechende Meldung am Bildschirm aus, wo man sehen kann, wer sich verbunden hat.
Nun kann man auf dem KC mit ENTER bzw. TAB (CPMNET.COM) einen Text eingeben, welcher nach Bestätigung an den CLIENT gesendet und dort im Fenster 'Received/Sent data' ausgegeben wird. Umgekehrt kann der CLIENT natürlich auch Nachrichten an den KC-Server schicken, welche dieser auf der Konsole ausgibt.
Das lässt sich nun unendlich fortsetzen, bis einer der beiden Teilnehmer die Verbindung beendet. Das kann sowohl clientseitig als auch serverseitig erfolgen. Wenn der Client die Verbindung kappt, wird der Server auf dem KC85 sofort neu gestartet. Er wartet dann wieder auf die Verbindungsaufnahme von Clients, siehe oben.
Mit >E< kann der KC85 bei bestehender Verbindung in den Echomodus umgeschaltet werden, siehe Artikel zum KCNET 1.2, wo diese Betriebsart genauer erläutert und für die Ermittlung der Schnittstellengeschwindigkeit eingesetzt wurde.
TCP CLIENT
Das ist das Gegenstück zur TCP-Server Funktion, jetzt muss man erst HERCULES als TCP-Server starten.
Anschliessend kann man die TCP-Client Funktion auf dem KC85 aufrufen, den PC mit HERCULES als Ziel eingeben und bestätigen. Als Zielangabe sind der PC-Name (nur mit DNS) oder die IP-Adresse und optional der Port, durch Doppelpunkt getrennt, zulässig. Wenn kein Port angegeben wird, benutzt das Programm den oben angezeigten PEER-Port.
Nach dem Herstellen der Verbindung, bestehen genau die gleichen Möglichkeiten, Daten auszutauschen, wie bei der Server-Funktion.
UDP SOCKET
Die UDP-Socket Funktion entspricht von der Funktionalität her den beiden TCP-Funktionen. UDP arbeitet aber verbindungslos. D.h., man kann nach dem Öffnen des UDP-Sockets auf dem KC85 und auf dem PEER-PC Daten senden und empfangen, wobei der Sender die Portnummer des Empfängers kennen muss, sonst kommt nichts an, siehe Tabelle!
Beide Teilnehmer - oder mehrere untereinander - können Daten gleichzeitig senden und empfangen. Deshalb muss man vor dem Senden einer Nachricht auch jedesmal das Ziel wie oben neu eingeben. Aus diesem Grund wird eine UDP-Kommunikation auch als multiplexfähig bezeichnet.
Nachteil von UDP - man weis nicht, ob die gesendeten Daten auch ankommen, da keine Verbindung zwischen den Teilnehmern aufgebaut wird. Man kann das sehen, wenn beispielsweise HERCULES auf dem PC beendet wird. Der KC kann immer noch Daten an den PC schicken, was mit OK bestätigt wird - die werden dort aber nachweislich nicht mehr entgegengenommen!
ICMP SOCKET
Die Funktion ICMP SOCKET arbeitet auf IP-Ebene und zeigt an, wenn ein anderer Rechner den KC85 anpingt. Wenn man auf dem Bildschirm des KC etwas sehen will, muss man an dessen IP-Adresse also PING-Pakete schicken.
Wenn man einen Socket des W5100 im IPRAW-Mode öffnet, wird die interne automatische Beantwortung von PING-Requests abgeschaltet und der Software überlassen.
Der KC85 beantwortet solche Nachrichten dann nicht mehr, da das in dieser einfachen Socket-Funktion nicht implementiert ist. Man bekommt deshalb auf dem pingenden Rechner nur Timeouts gemeldet, obwohl der KC online ist und funktionsfähig am Netzwerk hängt.
MAC SOCKET
Die Funktion (E)MAC SOCKET zeigt schliesslich noch bestimmte Inhalte und Informationen von eingehenden Ethernet-Frames an, welche für den KC85 bestimmt sind. Auf diese Art und Weise arbeiten die meisten Netzwerk-Sniffer, mit denen das Netzwerk auf der tiefsten möglichen Schicht der Netzwerk-Schnittstelle angezapft und abgehört werden kann.
Das ist für die Diagnose von Netzwerkstörungen unentbehrlich und war mir beispielsweise auf der PC-Seite während der Entwicklung als schnelle Möglichkeit sehr behilflich, die Netzwerkdaten, welche der KC85 sendet, anzuschauen. Die waren natürlich auch oft falsch - dann kommt weiter oben im eigentlichen Netzwerkprogramm nichts an, da das Protokoll nicht eingehalten wird!
Das ist eine sehr nützliche Geschichte für neue Programme, siehe www.wireshark.org.