Mittlere und kleine Netzwerke

Unterschied zu Host-Systemen

In kleineren und mittleren Unternehmen sind die betriebswirtschaftlichen Datenhaltungsaufgaben nicht so komplex und die Bestände nicht so umfangreich, als dass für die Abarbeitung Mainframe-Leistung erforderlich wäre.

Andererseits kommen aus den kleinen und mittleren Unternehmen aufgrund der Vielzahl von Praxisbezügen Anwendungen, die in den grossen „Campus-Netzwerken” nicht vorgesehen waren. Ein „Campus-Netzwerken” hat im Wesentlichen die folgenden Aufgaben:

• Benutzerverwaltung,
• Datenhaltung,
• Publikation (Druck) und
• Benachrichtigung

Schon Anfang der 1980er Jahre standen mit Minicomputern (später Mikrocomputern) und „Local-Area-Network”, „LAN” (z.B. XNS, später IPX/SPX ARCNET, Vines und Appletalk, später auch IP über Ethernet) die Bausteine für kleine und mittlere Netzwerk-Architekturen zur Verfügung, und ein Markt für solche Lösungen konnte entstehen.

Quellen wie [ESR2003] äussern rückschauend eine gewisse Unwilligkeit der Entwickler von „Host-” und „Workstation-Betriebssystemen”, die schlechter ausgestattete Hardware der Personal-Computer mit äquivalenten Netzwerkfähigkeiten auszustatten. So bildete sich im betrieblichen Mittelstand eine Industrie, die relativ unabhängig von den etablierten Host-Architekturen insbesondere Lösungen für LANs erstellte. Hier wurden markt- und betriebswirtschaftliche Erwägungen wichtiger eingeschätzt als theoretische Erkenntnisse aus den Campus-Netzwerken. Bis heute kann eine solche Trennung in „Enterprise-” und „Consumer-Lösungen” in der IT-Branche ausgemacht werden.

Network Basic Input-Output-System, NetBIOS

Im Auftrag der IBM, Inc. entwickelte die Sytec Inc. (heute Hughes LAN Systems, Inc.) bis 1983 das „Network Basic Input-Output-System”, „NetBIOS” (Quelle: [NETBIOS]).

1987, im Zuge der Umsetzung von NetBIOS auf TCP/IP („NBT”) kam es zu einem Normierungsprozess, festgehalten in [RFC1001] und [RFC1002]. In der nachträglich angefertigten Standardisierung lautet die Selbstdarstellung wie folgt:

[RFC1001] schreibt in Abschnitt 3 („INTRODUCTION”):

„NetBIOS defines a software interface not a protocol.”

Desweiteren, in Abschnitt 4.1 („PRESERVE NetBIOS SERVICES”):

„NetBIOS is the foundation of a large body of existing applications.
It is desirable to operate these applications on TCP networks and to
extend them beyond personal computers into larger hosts. To support
these applications, NetBIOS on TCP must closely conform to the
services offered by existing NetBIOS systems.”

Die Implementierung einer „IP”-basierten Transportschicht wurde von den Herausgebern als Portierung einer bestehenden Netzwerk-Dienstleistungs-Infrastruktur mit festgelegtem Kommandosatz und Verhalten (in [RFC1002] als drei „Protocols” „Name Service”, „Session Service” und „Datagram Service” vorgestellt) auf eine andere unterliegende Schicht angesehen, so dass auch IP-vernetzte „Hosts” NetBIOS-Dienste anbieten bzw. abrufen können. Dabei muss NetBIOS über TCP/IP insbesondere „konform” zu existierenden Anwendungen bleiben.

[RFC1001] stellt in Abschnitt 9 („NetBIOS SCOPE”) ausdrücklich fest, dass „Broadcast”-Erreichbarkeit zwingende Vorbedingung zur Teilnahme an einem spezfischen IP-basierten NetBIOS-Netzwerkverbund (dem so genannte „NetBIOS Scope”) ist. Das Dokument beschreibt in („APPENDIX A”) zwar ein Verfahren auf der Basis von IGMP/Multicast, räumt jedoch in A-2 („CONSTRAINTS”) spezielle Anforderungen ein, unter anderem:

„The NetBIOS broadcast protocols were designed for a network that
exhibits a low average transit time and low rate of packet loss. An
IGMP based broadcast area must exhibit these characteristics. In
practice this will tend to constrain IGMP broadcast areas to a campus
of networks interconnected by high-speed routers and inter-router
links.”

Mit solchen Anforderungen blieb NBT inkompatibel zu den Client-Server-Infrastrukturen der TCP/IP-Host-Netzwerke. Es wurde eine Vielzahl voneinander unabhängiger lokaler Netze mit bis zu einigen Dutzend angeschlossenen PCs errichtet, die miteinander Dateiaustausch vornahmen und Druckaufträge absendeten. Das Interesse an TCP/IP als konsolidierende Technologie (vgl. [WINITNBIOS) und für den Zugriff aus Host-Systeme für netzweites Backup blieb aber bestehen.

Netware

Anfang der 1980er Jahre stellte die Novell, Inc. mit „Netware” ein „Netzwerkbetriebssystem” auf Basis von Xerox XNS vor, das für das PC-Betriebssystem CP/M (und bald daruf für MS-DOS auf IBM-PC) eine „Netzwerk-Dateifreigabe” implementierte.

Netware arbeitete auf der Basis des damals verbreiteten XNS-Schichtenmodells([PCMAGNWARE]) mit den Protokollen „Internetwork Packet Exchange”, „IPX” (Netzwerkprotokoll), „Sequenced Packet Exchange”, „SPX” (Client-Server-Protokoll) und „Netware Core Protocol”, „NCP” (zur Implementation von Anwendungen wie Dateizugriff und Druckerfreigabe). Netware verwendete desweiteren Xerox RPC (vergleiche [WPDERPCHIST]).

IPX ist (ähnlich wie UDP) ein verbindungsloses, „Datagram”-basiertes Protokoll zur Übertragung von Daten. Das auf IPX aufbauende SPX ermöglicht (in etwa wie TCP) die verbindungsorientierte, geprüfte Übertragung von Datenpaketen. Oberhalb von SPX implementiert NCP Systemaufrufe an das NOS (in Ermangelung einer frei zugänglichen Spezifikation des NCP siehe z.B. [WSNCP], [CSNCP]).

Das NCP ist die Entsprechung im Netzwerkbetriebssystem zu einer Spezifikation von Systemaufrufen in einem Supervisor/Kernel-basierten Host-Betriebssystem. Entfernte Wartungs- und Betreuungsaufgaben können damit gestaltet werden. Zur Implementation eigner RPC ist es jedoch prinzipiell nicht vorgesehen, da nicht erweiterbar, bzw. nicht mit frei vergebbaren Bereichen oder irgendwelchen Mechanismen zur Kommandodefinition versehen.

Netware bot hingegen eine eigene API zur Programmierung von Anwendungen an, die „NWAPI”.

Der Funktionsumfang und die Implementierung von Netware wirkten sich auf die Entwicklung der Microsoft-Netzwerk-Dateifreigabe aus, die ab den späten 1980er Jahren in dessen direkte Konkurrenz trat. Netware bot ab den frühen 1990er Jahren TCP/IP als Transportprotokoll alternativ zu IPX/SPX an, portierte die Features aber nur Schrittweise (vgl. [WPENNWHIST], Absatz 3).

Weiter zu Kapitel 5: Verteilte Objektsysteme