-
TECHNISCHER HINTERGRUND DER ERFINDUNG
-
1. Technisches Gebiet der Erfindung
-
Die
Erfindung betrifft allgemein die Technologie von Computernetzen.
Insbesondere betrifft die vorliegende Erfindung die Verwaltung von
Client-Anforderungen in Netzwerken auf Client-Server-Basis.
-
2. Beschreibung der verwandten Technik
-
Das
Internetprotokoll (IP) ist ein Netzwerkschichtprotokoll, das durch
viele Firmennetze, Regierungsnetze und das öffentliche Internet weltweit
genutzt wird. Die IP-Netzwerkschicht unterstützt viele persönliche,
technische und Geschäftsanwendungen,
wie z. B. elektronische Post bzw. Email, elektronische Geldüberweisungen,
Verarbeitung medizinischer Aufzeichnungen und ähnliche Datenübertragungen.
IP ist ein verbindungsloses Netzwerkschichtprotokoll, das Adressier-,
Leitweglenkungs- und Steuerungsfunktionen für das Senden und Empfangen
von Datagrammen über
ein Netzwerk durchführt.
Die Netzwerkschicht lenkt Pakete von der Quelle zum Ziel. Ein IP-Datagramm ist ein
Datenpaket, das einen Kopfteil und einen Datenteil aufweist. Der Kopfteil
enthält
ein Kopfteilsegment fester Länge
und ein optionales Segment variabler Länge. Der Datenteil enthält die über das
Netzwerk zu übertragenden Informationen.
Als verbindungsloses Protokoll erfordert IP keinen vordefinierten
Weg, der mit einer logischen Netzverbindung assoziiert ist. Daher
steuert das IP nicht die Datenwegnutzung. Wenn eine Netzvorrichtung
oder Leitung nicht verfügbar
wird, bietet das IP den Mechanismus, der benötigt wird, um Datagramme um
den betroffenen Bereich herum zu lenken.
-
Das Übertragungssteuerungsprotokoll
(TCP) ist ein Transportschichtprotokoll, das verwendet wird, um
eine zuver lässige,
verbindungsorientierte Transportschichtverbindung zwischen Computersystemen bereitzustellen.
Die Netzwerkschicht stellt Dienste für die Transportschicht bereit.
Unter Anwendung eines Zweiwege-Quittungsaustauschschemas stellt
TCP den Mechanismus für
die Einrichtung, Unterhaltung und Beendigung logischer Verbindungen
zwischen Computersystemen bereit. Die TCP-Transportschicht nutzt
IP als ihr Netzwerkschichtprotokoll. Zusätzlich stellt TCP Protokollkanäle bereit,
um Mehrfachprogramme, die auf einer einzigen Vorrichtung laufen,
durch Einbeziehen der Ziel- und Ursprungsanschlußnummer bei jeder Nachricht
zu unterscheiden. TCP führt
Funktionen aus wie z. B. die Übertragung
von Byte-Strömen,
Datenflußdefinitionen,
Datenempfangsbestätigungen,
Neuübertragungen
verlorener oder verstümmelter
Daten und Multiplexen von mehreren Verbindungen über eine einzelne Netzverbindung.
Schließlich
ist TCP verantwortlich für
die Einkapselung von Informationen in eine Datagrammstruktur.
-
Interprozeßkommunikations-(IPC-)Transaktionen
können über verschiedene
Computernetze auftreten, die verschiedene Kommunikationsmodelle nutzen.
Das dominierende Modell für
die Kommunikation zwischen zwei Computern basiert auf einer Client-Server-Beziehung.
Unter Nutzung dieser Beziehung gibt ein Client-Computer (der "Client") eine oder mehrere
Befehlsanforderungen an einen Server-Computer (den "Server") aus. Der Server
erfüllt die
Befehlsanforderungen des Client, indem er gemäß der Anforderung auf notwendige
Ressourcen zugreift und anwendbare Befehle entsprechend ausführt. Der
TCP/IP-Standard veranlaßt
IPC-Transaktionen in Erfüllung
dieser Client-Server-Beziehung,
die zu einem Problem führt.
Mit steigender Client-Zahl vermindert
sich die Fähigkeit
des Servers, die Anforderungen der Clients (bzw. der dienstanfordernden Geräte) zu erfüllen. Daher
erfordern zum Beispiel Befehlsanforderungen von mehreren Clients
für die Übertragung
von Dateien von der gleichen Quelle (z. B. dem Server) mehr Zeit
zur Ausführung
durch den Wirts-Server. Wichtiger ist, daß mehrere Befehlsanforderungen,
die an den gleichen Server gerichtet sind, eine Überfüllung von Datenwegen erzeugen und
das Netzwerk verlangsamen.
-
Es
wurden verschiedene Methoden angewandt, um diese Überfüllung in
der Technologie zu bewältigen.
Die erste Methode erfordert die vorherige Zuweisung von Puffern
für Pakete
durch Reservieren von Speicherplatz in Zwischenservern (d. h. Servern auf
der Strecke), um die Pakete vorübergehend
zu halten. Diese Methode ist kostspielig für Netzbetreiber. Eine zweite
Methode erfordert das Verwerfen von Paketen, wenn kein Platz für den Empfang
des Pakets beim Zielverarbeitungsrechner (Host) ist, oder wenn ein
Paket nicht vor Ablauf einer vorgegebenen Zeitdauer (z. B. 255 Sekunden)
erfaßt
wird. Diese Methode verursacht eine Verzögerung im Netzwerk, da sie
eine nochmalige Übertragung
von Paketen infolge Datenverlusts erfordert. Eine dritte Methode
erfordert eine Begrenzung der Anzahl von Paketen in dem Kommunikationsmedium
eines Netzwerks (d. h. eines Teilnetzes). Diese Methode vermindert
den Nutzen des Netzwerks und erhöht
die Ausgabe von 'Netzwerk
besetzt'-Signalen. Eine vierte
Methode erfordert das Senden von "Drossel"-Paketen zum Ursprungs-Server, um die
Eingabegeschwindigkeit zu verlangsamen, wenn der Server überlastet
wird. Diese Methode verursacht Datenverlust und erfordert das erneute
Senden von Paketen.
-
Wenn
ein Server überlastet
ist, weist der Server außerdem
eine Clientanforderung zurück,
indem er dem Client rät,
sich an einen anderen Server zu wenden. Dieser Ansatz erfordert,
daß eine
bereits bestehende Client-Server-Sitzung beendet und die Client-Anwendung
modifiziert wird, um diese Funktionalität zu unterstützen. Zum
Beispiel offenbart das Dokument "Distributed
Packet Rewriting" von
Bestavros A., Crovella M., Liu J., Martin D., Boston University,
1. Dezember 1997, ein Verfahren zur Weiterleitung von Client-Anforderungen
durch verteiltes Umschreiben von Paketen. Daher besteht in der Technologie
ein Bedarf für
ein Verfahren zur effizienteren Verwaltung der Servernutzung in
Netzwerken auf Client-Server-Basis. Das Verfahren sollte existierenden
Kommunikationsprotokollen entsprechen, ohne eingerichtete Nachrichten-
und Signalgabestrukturen zu stören.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Um
die Beschränkungen
der verwandten Technologie zu überwinden,
bietet die Erfindung ein System und ein Verfahren zur Verwaltung
von Client-Server-Anforderungen in Computernetzwerken bzw. Rechnerverbänden gemäß den beigefügten Ansprüchen 1,
2 und 8, 9. Die Erfindung steht im Einklang mit bestehenden Kommunikationsprotokollen und
unterstützt
diese, wie z. B. TCP/IP, um eine Datenwegüberfüllung aufgrund vielfacher Client-Anforderungen
zu vermindern. Zudem ist die Anwendung der Erfindung für Clients
transparent, wodurch die Störung
von bereits eingerichteten Client-Server-Verknüpfungen vermieden wird.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Die
obigen und weitere Aspekte, Merkmale und Vorteile der Erfindung
werden durch Bezugnahme auf die nachstehende ausführliche
Beschreibung, die in Verbindung mit den beigefügten Zeichnungen zu lesen ist,
besser verständlich.
Dabei zeigen:
-
1 ein
Blockschaltbild, das die Struktur eines TCP-Transportpakets einer Transportschicht
beschreibt;
-
2 ein
Blockschaltbild, das die Struktur eines IP-Kopfteils einer Netzwerkschicht beschreibt;
-
3 ein
Blockschaltbild eines beispielhaften Netzwerks;
-
4 ein
Blockschaltbild eines durch die Erfindung genutzten Client-Server-Netzwerks;
-
5 ein
Ablaufdiagramm, das die Entscheidungsschritte darstellt, die durch
den in 4 dargestellten Vermittler ausgeführt werden;
-
6 ein
Ablaufdiagramm, das die Entscheidungsschritte darstellt, die durch
den in 4 dargestellten Server ausgeführt werden.
-
AUSFÜHRLICHE
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
-
Die
Erfindung stellt einen Vermittler (Broker) für die Verwaltung von Client-Anforderungen
in Client-Server-Computernetzwerken bereit. Die Erfindung unterstützt existierende
Kom munikationsprotokolle, wie z. B. TCP/IP, um die Überfüllung von
Datenwegen aufgrund vielfacher Client-Anforderungen zu vermindern.
Außerdem
ist die Anwendung der Erfindung für Clients (Dienstanforderer)
transparent, wodurch eine Störung
bereits bestehender Client-Server-Verknüpfungen vermieden wird. Der "transparente" Aspekt der vorliegenden
Erfindung bezieht sich auf die Fähigkeit
des Vermittlers, Client-Anforderungen
unter Verwendung eines Fremdservers auszuführen, ohne daß sich der
Client bewußt
ist, daß ein Fremdserver
eingesetzt wird.
-
Um
die Funktionsweise und die Vorteile der Erfindung verständlicher
zu machen, wird eine Beschreibung einer typischen Paketstruktur
gegeben. 1 zeigt ein Blockschaltbild,
das die Struktur eines TCP-Pakets 100 in einer Transportschicht
beschreibt. Der Begriff "Paket" bezieht sich gewöhnlich auf
eine Nachrichteneinheit, einschließlich Daten- und Steuersignalen,
die in einer Netzwerkschicht übertragen
wird. Der Begriff "Nachricht" bezieht sich gewöhnlich auf
die zu übertragenden
Nutzerinformationen oder Daten. Eine Nachricht kann von beliebiger
Länge sein,
daher ist es Sache der Transportschicht (d. h. des TCP bzw. Übertragungssteuerungsprotokolls),
die Nachricht in mehrere Pakete zur Übertragung zu zerlegen oder
zu unterteilen.
-
Wie
in 1 dargestellt, weist der TCP-Kopf 102 ein
Ursprungsanschlußfeld 104 auf,
gefolgt von einem Zielanschlußfeld 108 mit
jeweils 16 Bit, um die Endpunkte einer Netzwerkverbindung zu kennzeichnen.
Die Erfindung findet Anwendung bei der Unterstützung aller Systemanschlüsse, die
durch das Ursprungsanschlußfeld 104 gekennzeichnet
werden. Jeder "Host"-Computer bzw. Verarbeitungsrechner kann
für sich
selbst festlegen, wie seine Anschlüsse zuzuweisen sind. In einem
Netzwerk bezieht sich der Begriff "Host" bzw.
Wirt auf einen von einer Gruppe von Computern, die für die Ausführung von
Nutzeranwendungen (d. h. Programmen) vorgesehen sind. Der TCP-Kopf 102 umfasst
ferner ein Folgenummernfeld 112, gefolgt von einem Huckepack-Quittierfeld 116.
TCP nimmt beliebig lange Messungen von Anwenderprozessen an, zerlegt
sie in TCP-Datagramme von nicht mehr als 65536 Bytes, und sendet jedes
Datagramm als ge trenntes Paket. Daher ist die Folgenummer 112 ein
32-Bit-Wort, das die Reihenfolge des Datagramms in der ursprünglichen
Nachricht anzeigt. Das Huckepack-Quittierfeld 116 wird
von einem empfangenden Computer benutzt, um den Empfang eines bestimmten
Pakets zu zeigen. Ein TCP-Kopflängenfeld 120 von
4 Bits folgt auf das Huckepack-Quittierfeld 116, um anzuzeigen,
wie viele 32-Bit-Wörter
in dem TCP-Kopf 102 enthalten sind. Diese Information wird
benötigt,
da der Kopf 102 ein Optionsfeld 160 von variabler
Länge enthält, das
Daten übermittelt, über die
eine Vereinbarung durch den Ursprungsverarbeitungsrechner und den
Zielverarbeitungsrechner getroffen werden kann.
-
Nach
mehreren ungenutzten Bits 122 folgen auf das TCP-Kopflängenfeld 120 sechs
1-Bit-Marken. Die erste 1-Bit-Marke ist URG 124, die auf
1 gesetzt wird, wenn ein Dringend-Zeiger 156 benutzt wird,
und die sonst auf 0 gesetzt wird. Der Dringend-Zeiger 156 wird
verwendet, um eine Byte-Versetzung gegenüber der gegenwärtigen Folgenummer 112 anzuzeigen,
bei der dringende Daten zu finden sind. Die zweite 1-Bit-Marke ist
ACK 128, die auf 1 gesetzt wird, wenn ein Paket eine Quittung
trägt, und
sonst auf 0 gesetzt wird. Eine Verbindungsantwort trägt zum Beispiel
eine Quittung, daher wird ihr ACK-Bit 128 auf 1 gesetzt,
und sonst wird es auf 0 gesetzt. Die dritte 1-Bit-Marke ist EOM 132, die
das Ende einer Nachricht anzeigt, wenn sie auf 1 gesetzt ist. Im
letzten Paket einer Nachricht ist das EOM-Bit 132 auf 1
gesetzt. In allen anderen Paketen ist das EOM-Bit 132 auf
0 gesetzt. Die vierte 1-Bit-Marke ist RST 136, die verwendet
wird, um eine Verbindung zurückzusetzen,
die wegen einer Verzögerung
oder eines Ausfalls des Verarbeitungsrechners durcheinandergeraten
ist. Eine Verzögerung
des Verarbeitungsrechners kann wegen einer Überfüllung des Netzwerks mit Paketen
auftreten. Ein Ausfall des Verarbeitungsrechners (gewöhnlich als "Absturz" bezeichnet) kann
durch verschiedene Ereignisse verursacht werden, wie z. B. Stromausfall,
ein Rücksetzen des
Verarbeitungsrechners oder einen Fehler in der Anwendungssoftware
des Verarbeitungsrechners. Die fünfte
1-Bit-Marke ist SYN 140, die verwendet wird, um Synchronisierung
für eine
Verbindungsanforderung herzustellen. Eine Verbindungsanforderung
weist ein auf 1 gesetztes SYN-Bit 140 und ein auf 0 gesetztes
ACK-Bit 128 auf, um anzuzeigen, daß die Huckepack-Quittung 116 nicht
in Gebrauch ist. Wie oben festgestellt, trägt die Verbindungsantwort eine
Quittung, wobei ihr SYN-Bit 140 und ihr ACK-Bit 128 auf
1 gesetzt sind. Die sechste 1-Bit-Marke ist FIN 144, welche
die Freigabe einer Verbindung anzeigt. Das FIN-Bit 144 wird
auf 1 gesetzt, um anzuzeigen, daß der Sender keine Daten mehr
aufweist, und wird sonst auf 0 gesetzt.
-
Die
Ablaufsteuerung im TCP wird unter Verwendung eines Gleitfensters
von variabler Größe gehandhabt.
Ein 16-Bit-Fensterfeld 148 wird
benutzt, um anzuzeigen, wie viele Bytes ein Ursprungsverarbeitungsrechner über die
durch einen Zielverarbeitungsrechner quittierte Anzahl von Bytes
hinaus senden kann. Auf das Fensterfeld 148 folgt ein Kontrollsummenfeld 152,
um zuverlässige
Verbindungen bereitzustellen. Ein Übertragungsfehler kann durch
den Zielverarbeitungsrechner erfaßt werden, indem er die Kontrollsumme
auf die gleiche Weise wie der Ursprungsverarbeitungsrechner berechnet
und sie mit dem Wert im Kontrollsummenfeld 152 vergleicht.
Der Wert im Kontrollsummenfeld 152 wird durch den Ursprungsverarbeitungsrechner
durch Aufsummieren aller Daten, die als 16-Bit-Wörter betrachtet werden, und
anschließendes
Umwandeln der resultierenden Summe in ihr Einerkomplement berechnet,
eine normale Computeroperation. Auf das Kontrollsummenfeld 152 folgt
das oben beschriebene Dringend-Zeigerfeld 156. Auf das
Dringend-Zeigerfeld 156 folgt ein
Optionsfeld 160 zur Übertragung
optionaler Daten, wie z. B. Puffergrößen, während des Einrichtungsvorgangs
der Verbindung. Auf das Optionsfeld 160 folgt ein Datenfeld 170.
Das Datenfeld 170 weist die Nachricht auf, die über das
Computernetz zu übertragen
ist. Zum Beispiel könnte
die Nachricht ein Textverarbeitungsdokument, ein Computerprogramm,
ein Digitalbild, digitalisierte Sprachinformation für einen
Telefonanruf, eine Email-Nachricht usw. sein.
-
2 zeigt
ein Blockschaltbild, das die Struktur eines IP-Kopfes in der Netzwerkschicht
beschreibt. Wie oben festgestellt, weist ein IP-Datagramm einen
IP-Kopf 200 auf, an den sich ein Datenfeld 260 anschließt. Der
IP-Kopf 200 enthält
einen festen Abschnitt von 20 Byte und einen optionalen Ab schnitt
von variabler Länge.
Der feste Abschnitt von 20 Byte des IP-Kopfes 200 enthält ein Versionsfeld 204,
das verfolgt, zu welcher Version das Internetprotokoll des Datagramms
gehört.
Durch Einbeziehen der Version 204 in jedes Datagramm ist
es möglich,
Protokolle zu ändern,
während
das Netzwerk arbeitet. Da der IP-Kopf 200 nicht von konstanter
Länge ist,
wird ein IP-Kopflängenfeld
(IHL-Feld) 208 in dem IP-Kopf 200 bereitgestellt,
um die Länge des
IP-Kopfes 200 in 32-Bit-Wörtern anzuzeigen. Nach Definition
des IP ist der Minimalwert der IHL 208 gleich 5. Auf das
IHL-Feld 208 folgt ein "Dienstart"-Feld 212,
das dem Verarbeitungscomputer ermöglicht, das Teilnetz über die
erforderliche Dienstart zu informieren. Durch vordefinierte Dienstarten
sind verschiedene Kombinationen von Zuverlässigkeit und Geschwindigkeit
möglich.
Auf das "Dienstart"-Feld 212 folgt
ein "Gesamtlängen"-Feld 216, das
die Gesamtzahl aller Bits in dem Datagramm enthält, d. h. sowohl Kopf- als
auch Datenbits. Die maximale Größe des "Gesamtlängen"-Felds 216 ist 65536
Bytes.
-
Die
IP-Netzwerkschicht kann jedes TCP-Datagramm in kleinere Fragmente
quer über
das Netzwerk zerlegen. Das Elementarfragment besteht aus 8 Bytes.
Da die Größe eines
Datagramms maximal 65536 Bytes beträgt, gibt es maximal 8192 Fragmente
pro Datagramm. Daher wird hinter dem "Gesamtlängen"-Feld 216 ein
Kennzeichnungsfeld 220 verwendet, um einem Zielverarbeitungsrechner
zu ermöglichen,
festzustellen, zu welchem Datagramm ein neu ankommendes Fragment
gehört.
Alle Fragmente, die zu dem gleichen Datagramm gehören, enthalten
im Kennzeichnungsfeld 220 den gleichen Wert. Nach einem
ungenutzten Bit folgen zwei 1-Bit-Felder dem Kennzeichnungsfeld 220.
Das erste 1-Bit-Feld ist ein "Nicht
fragmentieren"-Bit
("DF"-Bit) 224.
Wenn das DE-Bit 224 auf 1 gesetzt ist, dann werden Netzwerk-Gateways (Verbindungsrechner) angewiesen,
das Datagramm nicht zu fragmentieren, da das Ziel nicht in der Lage
ist, die Fragmente zu ihrem ursprünglichen Datagramm zu rekonstruieren. Das
zweite 1-Bit-Feld ist ein "Mehr
Fragmente"-Bit ("MF"-Bit) 228.
Das MF-Bit 228 wird als Gegenprüfung gegen das Gesamtlängenfeld 216 verwendet, um
sicherzustellen, daß im
rekonstruierten Datagramm keine Fragmente fehlen. Ausgenommen im letzten
Frag ment ist in allen Nachrichtenfragmenten das MF-Bit 228 auf
1 gesetzt. An die zwei 1-Bit-Felder schließt sich ein "Fragmentversetzungs"-Feld 232 an,
das den Ort oder die Reihenfolge des aktuellen Fragments in dem
Datagramm anzeigt. Wie in 2 dargestellt,
besteht das "Fragmentversetzungs"-Feld 232 aus
13 Bits, und daher gibt es maximal 8192 mögliche Nachrichtenfragmente
für jedes Datagramm.
Auf das "Fragmentversetzungs"-Feld 232 folgt
ein "Lebensdauer"-Feld 236,
das ein Zähler ist,
der zur Begrenzung der Lebensdauern von Paketen verwendet wird.
Typischerweise zerstört
ein Netzwerk-Gateway Pakete mit einer Lebensdauer von mehr als 255
Sekunden.
-
Nachdem
die IP-Netzwerkschicht am Zielverarbeitungsrechner ein vollständiges Datagramm aufgebaut
hat, nutzt die IP-Netzwerkschicht ein Protokollfeld 240,
um das Transportprotokoll anzuzeigen. TCP ist ein Transportprotokoll,
aber es können auch
andere Protokolle benutzt werden, wie z. B. Transportprotokolle,
die durch den Kommunikationsstandard für Offene Systeme (OSI-Standard)
(z. B. ISO 8073) spezifiziert werden. Ein Kopfteil-Kontrollsummenfeld 244 folgt
auf das Protokollfeld 240, um die Gültigkeit des IP-Kopfes 200 zu überprüfen. Die Kopfteil-Kontrollsumme 244 ist
nützlich,
da sich der IP-Kopf 200 an einem Gateway (Verbindungsrechner) ändern kann,
z. B. infolge Fragmentierung zu einer Vielzahl von Fragmenten. Auf
die Kopfteil-Kontrollsumme 244 folgt ein "Ursprungsadressen"-Feld 248,
um die Ursprungsnetzwerknummer und die Verarbeitungsrechnernummer
des Datenabschnitts des Datagramms anzuzeigen. Schließlich folgt
auf das Ursprungsadressenfeld 244 ein Zieladressenfeld 252,
um die Nummer des Zielnetzwerks und die Nummer des Verarbeitungsrechners
des Datenabschnitts anzuzeigen.
-
3 zeigt
ein Blockschaltbild eines Netzwerks mit einer beispielhaften peripheren
Ausrüstung.
Wie in 3 dargestellt, kann ein Computeranwender 302 unter
Verwendung einer von verschiedenen Recheneinrichtungen einen Anschluß zu einem Netzwerkmedium 350 herstellen.
Eine mögliche Schnittstelleneinrichtung
kann ein Computer 304 sein, der über eine Netzwerkverbindung
mit dem Netzwerkmedium 350 verbunden ist. Typischerweise wird
die Netzwerkverbindung 305 durch einen Netz werk-Diensteanbieter
für den
Nutzer 302 bereitgestellt. Im Fall des öffentlichen Internets kann
der Diensteanbieter zum Beispiel ein nationaler Diensteanbieter
sein, wie z. B. America On-Line (AOL), Microsoft Network (MSN),
eine Bildungs- oder Regierungsinstitution oder ein lokaler Diensteanbieter.
Der Computer 304 kann beispielsweise irgendeine Maschine
nach Industriestandard sein, wie z. B. ein IBM-PC (oder ein kompatibler
PC) oder ein Apple Macintosh. Der Computer 304 kann auch
eine patentrechtlich geschützte
Maschine sein. Der Computer 304 kann eine Tastatur 306,
eine Maus 308, einen Monitor 310 und eine Videokamera 312 umfassen. Außerdem kann
der Nutzer 302 eine Netzwerk-Schnittstellensoftware 314 (z.
B. Microsoft Internet Explorer oder Netscape Navigator/Communicator)
zur Kommunikation über
das Netzwerkmedium 350 nutzen. Alternativ kann der Nutzer 302 einen tragbaren
Personalcomputer (PC) 316 oder ein Telefongerät 318 nutzen,
das mit geeigneter Netzwerk-Schnittstellensoftware
für den
Anschluß an
das Netzwerkmedium 350 ausgestattet ist. Der Nutzer 302 kann
alternativ einen Monitor 320 verwenden, der an einen Kabelkasten 322 angeschlossen
wird, der mit einer geeigneten Netzwerk-Schnittstellensoftware ausgestattet
ist, um den Anschluß zum
Netzwerkmedium 350 herzustellen. Ferner kann der Nutzer
unter Verwendung eines Satelliten (nicht dargestellt) ein normales
Fernsehgerät 324 verwenden, das
an einen Satellitenempfänger 326 angeschlossen
ist, um über
eine Satellitenantenne 328 mit dem Netzwerkmedium zu kommunizieren.
Schließlich kann
der Nutzer 302 eine Netzwerk-Schnittstellensoftware in
einem dedizierten (ausschließlich
zum Netzbetrieb vorgesehenen) Server 332 verwenden, um über das
Netzwerkmedium 350 zu kommunizieren. Dementsprechend können bei
der Anwendung der vorliegenden Erfindung zahlreiche Varianten des Schnittstelleneinrichtungstyps
angepaßt
werden.
-
Unter
Anwendung der obigen Schnittstelleneinrichtung gibt der Nutzer 302 Client-Befehlsanforderungen
aus, um eine Kommunikationssitzung mit einem Zielserver durchzuführen. Ein
Zielserver kann einer der Server 334, 336, 338, 340 oder 342 sein. Diese
Server sind Recheneinrichtungen mit großen nichtflüchtigen bzw. Dauerspeichern,
wie z. B. Festplattenlaufwer ken mit mehreren Gigabytes. Die Laufwerke
enthalten Dateiressourcen, die für
Clients zugänglich
sind. Wie in 3 dargestellt, können die Server
Teil eines lokalen Netzes (LAN) oder eines Weitverkehrsnetzes (WAN)
sein, das über
geeignete Schnittstellenverbindungen (z. B. Ethernet) angeschlossen
ist. Beispielsweise stellt der Nutzer 302 unter Anwendung
der TCP/IP-Protokolle einen Anschluß zu dem Netzwerkmedium 350 her,
um eine elektronische Mail-(E-mail-)Nachricht an einen entfernten
Nutzer (nicht dargestellt) zu senden, dessen Email-Konto sich im Zielserver 342 befindet.
Der Typ der Befehlsanforderungen ist von der Netzwerk-Schnittstellensoftware
abhängig,
die von dem Nutzer 302 verwendet wird. Wenn beispielsweise
Eudora genutzt wird, kann der Nutzer 302 eine Befehlsanforderung
zum Senden einer Email-Nachricht übertragen, indem er das Icon
bzw. Symbol "Senden" anklickt, das innerhalb
eines graphischen Fensters auf einem Bildschirm erscheint. Als Reaktion
auf den Befehl "Senden" wird die Email-Nachricht
entsprechend den TCP/IP-Protokollen über das Netzwerk 350 zu
ihrem Zielserver 342 übertragen.
-
4 zeigt
ein Blockschaltbild eines Client-Server-Netzwerks, das die Erfindung anwendet. Wie
in 4 dargestellt, kommunizieren ein oder mehrere
Clients 410 (zwei Clients 410a und 410b sind
dargestellt, aber die Erfindung arbeitet mit Clients im Bereich
von 1 bis n, wobei n eine positive ganze Zahl ist) mit einem Vermittlerserver 420 (dem "Vermittler") über verschiedene
Netzwerke, die ein oder mehrere Kommunikationsprotokolle nutzen,
wie z. B. die TCP/IC-Protokolle.
Außerdem
können
in dem Netzwerk viele Vermittler 420 und Server 430 vorhanden
sein, um aber die Erläuterung
zu erleichtern, wird jeweils nur einer in 4 dargestellt.
Die Clients 410, der Vermittler 420 und der Server 430 können irgendeine
Art von Recheneinrichtung sein, wie in 3 dargestellt.
-
In
einer typischen TCP/IP-Sitzung initiiert der Client 410 eine
Kommunikationsanforderung bei dem Vermittler 420, indem
er das Betriebssystem (O. S.) der Netzwerkeinrichtungen (in dieser
Figur nicht dargestellt) über
seine Absicht informiert, eine Verbindung zu einem bestimmten Server
(d. h. dem Vermitt ler 420) herzustellen. Das Betriebssystem
(O. S.) kann irgendein System nach Industriestandard sein, wie z.
B. das O. S. von Berkeley Software Development, Inc., (BSDI) (auf
UNIX-Basis), das Microsoft Disk Operating System (DOS), das Apple
Macintosh O. S., Novell Netware, AT & T UNIX, DEC VMS oder Microsoft Windows
3.1/95/98/NT. Gemäß dieser
Anforderung kann das Betriebssystem (O. S.) direkt oder indirekt
die TCP/IP-Protokolle unterstützen,
um durch Durchführen
eines Quittungsaustauschs ("Handshake") eine Verbindung
mit dem jeweiligen Server herzustellen. Die Transportschicht-Software führt den
Quittungsaustausch durch, indem sie ein Paket, das unter Umständen keine
Daten enthält,
in dem ein SYN-Bit 140 auf 1 gesetzt ist (1),
vom Client 410 zum Vermittler 420 überträgt. Bei
Empfang des Pakets wird der Vermittler 420 darüber verständigt, daß eine Verbindung
vom Client 410 angefordert wird. Der Vermittler 420 reagiert,
indem er ein Paket, in dem das ACK-Bit 128 auf 1 gesetzt
ist (1) zum Client 410 überträgt. Typischerweise quittiert
der Client 410 seinerseits die Quittung des Vermittlers 420, indem
er ein Paket mit einem auf 1 gesetzten ACK-Bit 128 an die
Anwendungssoftware im Vermittler 420 sendet. Wie oben festgestellt,
lenken die TCP/IP-Schichten übertragene
Pakete auf der Basis von Informationen, die im Zieladressenfeld 252 enthalten
sind (2), zum richtigen Zielserver. Sobald der Quittungsaustausch
abgeschlossen ist, stellen der Client 410 und der Vermittler 420 eine
virtuelle Verbindung ("Verknüpfung") her, um eine Kommunikationssitzung
zu unterstützen.
Die Verknüpfung
ist notwendig, damit ein Client über
das Netzwerk kommunizieren kann.
-
In
Abhängigkeit
von der Verfügbarkeit
von Ressourcen des Vermittlers 420 legt der Vermittler 420 fest,
ob ankommende Client-Befehlsanforderungen auszuführen sind oder Client-Befehlsanforderungen
für die
Ausführung
zu einem Fremdserver umzuschalten sind, z. B. zum Server 430. "Verfügbarkeit von
Ressourcen" bezieht
sich auf die Fähigkeit
des Vermittlers 420, mit der durch den Client 410 verwendeten
Anwendungssoftware zu kommunizieren. Der Vermittler 420 ist
in der Lage, mit der Anwendungssoftware des Clients zu kommunizieren,
wenn der Vermittler 420 mit einer Anwendungssoftware ausgestattet
ist, die mit der vom Client 410 benutzten kompatibel ist.
Der Client 410 kann ein Anwender sein, der über einen
Internetanschluß,
der von einem örtlichen
Diensteanbieter bereitgestellt wird, auf das World Wide Web zugreift.
Der Anwender kann z. B. den Netscape Navigator als Client-Anwendungssoftware
benutzen, um eine Befehlsanforderung zu senden. Die Befehlsanforderung
kann eine Anforderung zum Herunterladen einer bestimmten Datei sein
(z. B. einer Textdatei, einer Bilddatei oder einer Anwendungssoftware).
Die Methode zur Ausgabe einer solchen Befehlsanforderung ist von
dem Web-Browser abhängig,
der von dem Client 410 betrieben wird. Bei Verwendung des
Netscape Navigators kann ein Anwender eine Befehlsanforderung "Herunterladen" senden, indem er
einen markierten Abschnitt eines Text anklickt, der in dem interessierenden
Fenster auf dem Bildschirm erscheint. Der Befehl "Herunterladen" kann ein Markierungsetikett
sein, das auf einer Hypertextmarkierungssprache (HTML) basiert.
Die Anwendungssoftware kann irgendeine IP-basierte Anwendungssoftware
sein, die dem Fachmann bekannt ist, einschließlich Anwendungen, die das
Dateiübertragungsprotokoll
(FTP), das einfache Mailübertragungsprotokoll
(SMTP), das Domänen-Namensystem
(DNS) und das Hypertextübertragungsprotokoll
(HTTP) unterstützen.
Wenn der Vermittler 420 feststellt, daß er mit der Anwendungssoftware ausgestattet
ist, die mit Netscape Navigator betriebsfähig ist, dann sendet der Vermittler 420 Antwortpakete
an den Client 410 mit den gewünschten Daten. Wenn der Vermittler 420 andererseits
nicht mit der erforderlichen Anwendungssoftware ausgestattet ist, dann
schaltet der Vermittler 420 Client-Befehle zum Server 430 um.
-
Wie
oben festgestellt, gibt es mehrere Fremdserver, die in einem Netz
eingesetzt werden können,
aber in 4 ist nur der Server 430 dargestellt.
Bevor Client-Anforderungen zu einem Server umgeschaltet werden,
stellt der Vermittler 420 fest, welcher Server für die Weiterschaltung
genutzt werden kann. Um diese Feststellung zu treffen, programmiert
ein Systembetreiber den Vermittler 420 mit einer Liste
von Servern, aus welcher der Vermittler 420 einen Fremdserver
auswählt.
Um einen Server mit der angeforderten Ressource auszuwählen, kann der Vermittler 420 irgendein
gewünschtes
Auswahlverfahren anwenden, wie z. B. die Wahl eines Servers nach
Reihenfolge, zufällig,
oder unter Anwendung anderer gewünschter
Kriterien. Das Ziel des Weiterschaltens ist der Belastungsausgleich
der Anforderungsantworten durch die Server. Sobald der Vermittler 420 den
Server 430 auswählt,
stellt der Server 430 eine Verbindung mit dem Client 410 unter
Verwaltung des Vermittlers 420 her, um die angeforderten
Daten für
den Client 410 bereitzustellen.
-
5 zeigt
ein Ablaufdiagramm, das den Steuerungsablauf beschreibt, der durch
den Vermittler 420 ausgeführt wird (4).
In einer Ausführungsform
kann die Erfindung mit dem BSDI-Betriebssystem implementiert werden.
Das BSDI-Betriebssystem umfasst eine TCP/IP-Netzwerkfähigkeit,
indem es die Netscape FastTrack- und Apache Web-Server, Post.Office-
und BSD sendmail-Email-Server, FTP, Netnews- und BSDI MaxIM Internet-Graphikmanager
einbezieht. Als Alternative unterstützt der BSDI-Server, der als
sein eigener Router wirkt, das Punkt-zu-Punkt-Protokoll (PPP) und das Serial
Line Internet Protocol (SLIP) über
ein Modem für
Einwahlverbindungen. In einer Ausführungsform verwendet die Erfindung
die Berkeley Socket-Anwendungsprogrammierschnittstelle
(API), um mit entfernten Verarbeitungsrechnern auf einem Netz zu
kommunizieren. Die Berkeley Socket-API wird auf C-Funktionsaufrufe
gesetzt, um die Netzwerkkommunikation zu unterstützen. Die Sockets-API ist nicht auf
die Anwendung mit dem TCP/IP-Protokoll beschränkt und kann auch mit anderen
Netzwerkprotokollen eingesetzt werden. In Client-Computern (z. B. dem
Client 410), die ein TCP/IP-Protokoll nutzen, schließen die
Funktionsaufrufe ein:
socket( ), bind( ), connect( ), send(
), recv( ) und close( ). In Servercomputern (z. B. dem Vermittler 420) schließen die
Funktionsaufrufe ein: socket( ), bind( ), listen( ), accept( ),
send( ), recv( ) und close( ). Diese Funktionsaufrufe sind dem Fachmann
bekannt.
-
Beginnend
bei Block 502, führt
der Vermittler 420 die Verwaltung der Client-Befehlsanforderungsfunktion
durch. In Block 504 führen
der Client 410 und der Vermittler 420 unter Anwendung
eines Transport- und Netzwerkschicht-Kommunikations protokolls, wie
z. B. TCP/IP, den oben beschriebenen Quittungsaustausch durch und
stellen dadurch eine Verbindung zwischen sich her. In einer Implementierung
führt die
Anwendungssoftware einen accept( )-Funktionsaufruf durch, um den
Vermittler 420 in einen Ruhezustand zu versetzen. Der Ruhezustand bleibt
wirksam, bis eine weitere Verbindung mit dem Vermittler 420 hergestellt
wird. Im Block 508 stellt der Vermittler 420 fest,
ob ankommende Client-Befehlsanforderungen auszuführen sind oder Client-Befehlsanforderungen
an einen Fremdserver zur Ausführung
weiterzuschalten sind, z. B. an den Server 430. Wie oben
beschrieben, trifft der Vermittler 420 diese Entscheidung
auf der Basis der Verfügbarkeit geeigneter
Ressourcen. Wenn der Vermittler 420 entscheidet, Client-Befehlsanforderungen
zu erfüllen, dann
nimmt im Block 512 der Vermittler 420 ankommende
Client-Befehlsanforderungen zur Ausführung an und antwortet dem
Client 410 entsprechend. In einer Implementierung reagiert
der Vermittler 420 auf den Client 410 unter Verwendung
von Berkeley Socket-Anwendungsprogrammierschnittstellen (API), z. B.
read( )- und write( )-Funktionsaufrufen zum Lesen bzw. Schreiben
von Daten. Wenn die Übertragung von
Daten abgeschlossen ist (d. h. wenn die Sitzung beendet ist), führt die
Anwendungssoftware einen close( )-Funktionsaufruf durch, um die
Verbindung zwischen dem Vermittler 420 und dem Client 410 zu beenden.
Dementsprechend überträgt im Block 514 der
Vermittler 420 ein Paket, in dem ein FIN-Bit 144 (1)
auf 1 gesetzt ist, an den Client 410. Die Funktion der
Verwaltung von Client-Befehlsanforderungen endet am Block 550.
-
Wenn
andererseits der Vermittler 420 entscheidet, die Anforderung
an den Server 430 weiterzuleiten (4), dann
führt die
Anwendungssoftware einen Umschaltungs-Systemaufruf durch, um das Betriebssystem
anzuweisen, die aktuelle Client-Vermittler-Sitzung
zum Server 430 umzuschalten. Dementsprechend modifiziert
der Vermittler 420 im Block 516 seine Zieladresse 252 des
IP-Kopfes 200 (2), indem er die Zieladresse
des Servers 430 in das Zieladressenfeld 252 einschreibt.
Zum Beispiel kann die Zieladresse des Vermittlers 420 im
Zieladressenfeld 252 durch 11001100110011001100110011001100
dargestellt werden. Wenn die Zieladresse des Servers 430 als 10101010101010101010101010101010
dargestellt wird, dann ersetzt der Vermittler 420 seine
Zieladresse durch 10101010101010101010101010101010 im Zieladressenfeld 252.
Wie oben beschrieben, kann der Vermittler 420 für diesen
Zweck über
mehrere Fremdserver verfügen.
Im Block 520 initiiert der Vermittler 420 einen
Quittungstausch mit dem Server 430, um eine TCP/IP-Sitzung
zwischen dem Vermittler 420 und dem Server 430 auszuhandeln
und einzurichten. Tatsächlich
stellt die Vermittler-Server-Verbindung eine indirekte Client-Server-Verbindung her.
-
Im
Block 524 überträgt der Vermittler 420 zum
Server 430 ein Paket, das in dieser Ausführungsform,
mit Ausnahme des Zieladressenfelds 252, im wesentlichem
mit dem vom Client 410 empfangenen Paket identisch ist,
in dem das SYN-Bit 140 auf 1 gesetzt ist. Das Paket kann
unter Umständen mit
dem Client-Paket
nicht genau identisch sein, da andere Felder (z. B. das Folgenummernfeld 112,
das Huckepack-Quittierfeld 116) durch den Vermittler 420 modifiziert
werden können.
Zum Beispiel kann die Modifikation des Folgenummernfelds 112 notwenig sein,
da der Vermittler 420 eine Folgenummer für die Pakete
generieren kann, die sich von der durch den Client 410 generierten
Folgenummer unterscheidet. Ein Paket mit einer Zieladresse des Servers 430 aktiviert
den Server 430, auf den Vermittler 420 mit einem
Bestätigungs-Antwortpaket
zu antworten, in dem ein ACK-Bit 128 auf 1 gesetzt ist.
Wenn der Server 430 bereit ist, die Quittungsaustauschanforderung
vom Vermittler 420 anzunehmen, überträgt der Server 430 ein
Paket, in dem das ACK-Bit 128 auf 1 gesetzt ist, zum Vermittler 420.
Typischerweise reagiert der Vermittler 420 bei Empfang
des Pakets mit dem auf 1 gesetzten ACK-Bit 128 auf den
Server 430, indem er ein Paket mit auf 1 gesetztem ACK-Bit 128 zum
Server 430 sendet, um die Quittung zu quittieren. Daher
können
der Vermittler 420 und der Server 430 mehrere
Pakete austauschen, bis der Server 430 und der Vermittler 420 im
Block 528 im gleichen Anwendungszustand sind. Der Anwendungszustand des
Vermittlers 420 ist der gleiche wie der des Servers 430,
wenn der Vermittler 420 sendebereit ist und der Server 430 bereit
ist, Nachrichteninformationen zu empfangen. Da der Client 410 bereits
eine Verbin dung mit dem Vermittler 420 hergestellt hat,
braucht zwischen dem Client 410 und dem Server 430 keine Verbindung
hergestellt zu werden. Der Client 410 überträgt Pakete zum Server 430 über den
Vermittler 420. Im Block 532 generiert der Vermittler 420 ein Pseudo-Quittungspaket
an den Client 410. Die Pseudo-Quittung wird generiert, nachdem der
Vermittler 420 das Quittungspaket vom Server 430 empfangen hat.
Außerdem
ist das Pseudo-Quittungspaket transparent für den Client 410 und
trennt daher nicht die bereits zwischen dem Client 410 und
dem Vermittler 420 hergestellte Verbindung.
-
Im
Block 534 modifiziert der Vermittler 420 für alle vom
Client 410 empfangenen Datenpakete seine Zieladresse (2),
indem er die Zieladresse des Servers 430 in das Zieladressenfeld 252 einschreibt.
Für den
Zweck dieses Abschnitts bezeichnet ein Datenpaket ein Paket, das
die durch den Client ausgegebenen Anwendungsbefehle enthält (z. B. Befehle
zum Herunterladen einer Datei, zum Senden einer Email-Nachricht
usw.). In Block 536 überträgt der Vermittler 420 an
den Server 430 alle vom Client 410 empfangenen
Datenpakete. Typischerweise sind alle Server in dem Netzwerk, einschließlich des
Vermittlers 420, mit einem oder mehreren entsprechenden
Paketvermittlungsknoten (PSN) verbunden. Der gesamte Paketverkehr
nach oder von dem Server fließt
durch seine PSN. Pakete werden sowohl am Sende-PSN als auch am Empfangs-PSN
gepuffert. Die verfügbare
Puffergröße an jedem
PSN ist von der durch die Server verwendeten Datenverbindungsschicht
abhängig.
Dementsprechend wirkt der PSN des Vermittlers 420 mit dem
Vermittler 420 zusammen, um alle Datenpakete zum Server 430 weiterzuleiten.
Außerdem
modifiziert der Vermittler 420, wenn nötig, Informationen, die im
Folgenummernfeld 112 und im Huckepack-Quittierfeld 116 enthalten
sind. Wie oben festgestellt, kann die Modifikation des Folgenummernfelds 112 notwendig
sein, da der Vermittler 420 unter Umständen eine Folgenummer für die Pakete
generiert, die sich von der durch den Client 410 generierten
Folgenummer unterscheidet. Der Vermittler 420 fährt damit
fort, Pakete vom Client 410 zum Server 430 weiterzuleiten,
bis alle Datenpakete den Server 430 erreicht haben. Der
Prozeß endet nach Übergabe
aller Datenpakete an den Server 430 im Block 550.
-
6 zeigt
ein Ablaufdiagramm, das die Entscheidungsschritte beschreibt, die
durch den in 4 dargestellten Server ausgeführt werden.
Beginnend im Block 602, wirkt der Server 430 mit
dem Vermittler 420 zusammen, um auf Client-Befehlsanforderungen
zu reagieren. Im Block 624 empfängt der Server 430 vom
Vermittler 420 das Paket mit dem auf 1 gesetzten SYN-Bit 140,
in dem der Abschluß eines Quittungsaustauschs
zwischen ihnen angefordert wird. Der Vermittler 420 initiiert
den Quittungsaustausch als Reaktion auf einen Verbindungsumschaltungs-Systemaufruf,
der das Betriebssystem anweist, die Client-Vermittler-Sitzung zum
Server 430 weiterzuschalten. Wenn der Server 430 bereit
ist, die Quittungsaustauschanforderung vom Vermittler 420 anzunehmen, überträgt der Server 430 ein
Paket mit dem auf 1 gesetzten ACK-Bit 128 zum Vermittler 420. Bei
Empfang des Pakets mit dem auf 1 gesetzten ACK-Bit 128 reagiert
der Vermittler 420 typischerweise auf den Server 430,
indem er ein Paket mit dem auf 1 gesetzten ACK-Bit 128 überträgt, um die
Quittung zu quittieren. Daher können
der Vermittler 420 und der Server 430 mehrere
Pakete austauschen, bis sich der Server 430 und der Vermittler 420 im
Block 628 im gleichen Anwendungszustand befinden. Wie oben
festgestellt, ist der Anwendungszustand des Vermittlers 420 der
gleiche wie der des Servers 430, wenn der Vermittler 420 sendebereit
und der Server 430 bereit ist, Nachrichteninformationen
zu empfangen.
-
Im
Block 640 empfängt
der Server 430 Datenpakete vom Vermittler 420,
um Befehlsanforderungen des Clients 410 auszuführen. Der
Server 430 kann einen peripheren Treiber verwenden, um
unter Anwendung des Nutzerdatagramm-Protokolls (UDP) Datenpakete
zu empfangen. UDP ermöglicht
Nutzern, Nachrichten zu senden, ohne eine bestimmte Verbindung herzustellen.
UDP wird oft als eine Anwenderschnittstelle zum IP (Internet-Protokoll) bezeichnet.
Wie dem Fachmann bekannt, weist ein UDP-Paket ein Ursprungsanschlußfeld, ein
Zielanschlußfeld,
ein Längenfeld,
ein Kontrollsummenfeld und ein Datenfeld auf. Der Ursprungsanschluß zeigt die
Adresse des Ursprungsservers an (z. B. des Vermittlers 420).
Der Zielanschluß zeigt
die Adresse des Zielservers an (z. B. des Servers 430).
Das Längenfeld
stellt die Größe des UDP-Pakets
dar. Ebenso wie in TCP/IP enthält
das Kontrollsummenfeld die Ergebnisse eines Kontrollsummenalgorithmus,
um für
eine zuverlässige
Datenübertragung
zu sorgen. Das Datenfeld ist ein Feld von variabler Länge, welches
die in dem UDP-Paket übertragenen
Daten enthält.
Die Befehlsanforderungen sind typischerweise in das Datenfeld 260 (2)
von Datenpaketen eingebettet. Im Block 644 generiert und
erzeugt der Server 430 abgehende Pakete für die Übertragung
zum Client 410 als Reaktion auf die Befehlsanforderungen. Das
Betriebssystem (O. S.) weist die Anwendungssoftware im Server 430 an,
Informationen, die in dem Ursprungsadressenfeld 248 (2)
enthalten sind, durch Einschreiben der Ursprungsadresse des Vermittlers 420 in
das Ursprungsadressenfeld 248 für alle abgehenden Pakete zu
modifizieren. Durch Einschreiben der Ursprungsadresse des Vermittlers 420 anstelle
seiner Ursprungsadresse bewirkt der Server 430, daß der Client 410 glaubt,
daß die
Information gerade durch den Vermittler 420 gesendet wird.
Außerdem
modifiziert der Server 430 nötigenfalls Informationen, die
im Folgenummernfeld 112 enthalten sind, um die durch den
Client 410 verwendete Folgenummer anzuzeigen. Wie oben
festgestellt, kann eine Modifikation von Informationen im Folgenummernfeld 112 notwendig
sein, da der Vermittler 420 unter Umständen eine Folgenummer für die Pakete generiert,
die sich von der durch den Client 410 generierten Folgenummer
unterscheidet. Schließlich überträgt im Block 648 der
Server 420 Pakete mit der Zieladresse des Clients 410 zum
Netzwerk für
die Übergabe
an den Client 410. Der Prozeß endet nach Übergabe
aller erforderlichen Pakete im Block 650.
-
Angesichts
des Vorstehenden wird man erkennen, daß die Erfindung den seit langem
bestehenden Bedarf für
ein System und ein Verfahren zur Verwaltung von Client-Befehlsanforderungen
in Client-Server-basierten Netzwerken erfüllt, indem sie Server-Ressourcen
wirksam nutzt. Die Erfindung kann in anderen konkreten Formen ausgeführt werden,
ohne von ihrem Grundgedanken oder von wesentlichen Eigenschaften
abzuweichen. Die beschriebene Ausführungsform ist in jeder Hinsicht
nur als erläuternd
und nicht als einschränkend
anzusehen. Der Umfang der Erfindung wird daher durch die beigefügten Patentansprüche und
nicht durch die vorstehende Beschreibung angegeben. Alle Änderungen,
die innerhalb der Bedeutung und des Äquivalenzbereichs der Ansprüche liegen,
sind in ihren Umfang einzuschließen.