DE60019640T2 - Digitales Rechnersystem und Verfahren zur Beantwortung von über ein externes Netzwerk empfangenen Anfragen - Google Patents

Digitales Rechnersystem und Verfahren zur Beantwortung von über ein externes Netzwerk empfangenen Anfragen Download PDF

Info

Publication number
DE60019640T2
DE60019640T2 DE60019640T DE60019640T DE60019640T2 DE 60019640 T2 DE60019640 T2 DE 60019640T2 DE 60019640 T DE60019640 T DE 60019640T DE 60019640 T DE60019640 T DE 60019640T DE 60019640 T2 DE60019640 T2 DE 60019640T2
Authority
DE
Germany
Prior art keywords
operating system
server
external network
responder
internal network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60019640T
Other languages
English (en)
Other versions
DE60019640D1 (de
Inventor
K. Bradley HANKINSON
D. Brian SUGGS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KAWAI HACHIRO
Kawai Hachiro Kawasaki
Original Assignee
KAWAI HACHIRO
Kawai Hachiro Kawasaki
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KAWAI HACHIRO, Kawai Hachiro Kawasaki filed Critical KAWAI HACHIRO
Application granted granted Critical
Publication of DE60019640D1 publication Critical patent/DE60019640D1/de
Publication of DE60019640T2 publication Critical patent/DE60019640T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Communication Control (AREA)
  • Curing Cements, Concrete, And Artificial Stone (AREA)
  • Polymers With Sulfur, Phosphorus Or Metals In The Main Chain (AREA)
  • Glass Compositions (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft ein digitales Computersystem gemäß Anspruch 1 und ein Verfahren zum Antworten auf eine über ein externes Netzwerk empfangene Anfrage gemäß Anspruch 18 und nimmt starken Bezug auf ein verteiltes Betriebssystem für ein digitales Computersystem. Die Erfindung ist insbesondere relevant für einen Hochgeschwindigkeitsserver, in dem unterschiedliche Funktionen der Zustandsmaschine des Servers über eine Vielzahl von Prozessoren verteilt sind, auf denen eine Vielzahl von Betriebssystemen läuft.
  • 2. Beschreibung des Standes der Technik
  • Die Explosion in der Verwendung des World Wide Web über das globale Internet hat einen entsprechenden Bedarf an Servern erzeugt, die die Fähigkeit besitzen, große Webseiten mit erhöhter Geschwindigkeit und Zuverlässigkeit unterzubriNgen. Das Internet verwendet Glasfaserkabel und Hochgeschwindigkeitsschaltungen und -router, um alle Formen digitalen Inhalts wie z. B. Sprache, Daten und Video mit Gigabit-Datenübertragungsraten (bald Terabit-Datenübertragungsraten) über den Erdball zu tragen. Im Internet ist die maximale Anzahl von Benutzern, die ein Server unterstützen muss, nicht vorhersagbar und variabel und kann von einer Handvoll Benutzern zu potentiell Millionen von Benutzern reichen, im Gegensatz zu den lokalen Netzwerken (LANS), bei denen die maximale Anzahl von Benutzern relativ klein ist. Demzufolge besteht ein Bedarf an Servern zur Verwendung im Internet, die eine große Anzahl von Benutzern unterstützen können und die mit Terabit-Datenübertragungsraten arbeiten.
  • Eine allgemeine Lösung zum Betreiben einer großen Webseite besteht im Aufbau einer Server-Farm. Der Aufbau einer Server-Farm bedingt die Verbindung einer Vielzahl von Servern (vielleicht Hunderte) mit verschiedenen Netzwerkschemen, um sich einem einzelnen leistungsfähigeren System anzunähern. Der Aufbau und der Betrieb einer Server-Farm ist typischerweise ein kostspieliges Unterfangen, da Server-Farmen eine große Menge von Platz benötigen, der mit spezialisierten Kühl- und Energieeinrichtungen ausgerüstet sein muss. Zusätzlich benötigen Server-Farmen normalerweise Personal von Wartungstechnikern. Server-Farmen sind im Allgemeinen komplex und auf Grund eines übermäßigen Betrags von Ausfallzeit unzuverlässig. Ein weiterer Nachteil von Server-Farmen besteht darin, dass sie nicht die Leistung und Skalierbarkeit bereitstellen können, die oft von großen und wachsenden Webseiten benötigt werden.
  • Lastverteilung ist ein gut bekanntes Verfahren, um die Unzuverlässigkeit und Nicht-Ansprechempfindlichkeit von Server-Farmen zu verringern. Ein Lastverteiler ist eine Computer- oder Netzwerkeinrichtung, die eintreffende Anfragen an die Server-Farm empfängt und dann unter Verwendung einer Vielzahl von Verfahren auswählt, welche/r Server innerhalb der Server-Farm am Besten zum Antworten auf diese Anfrage geeignet ist. Der Lastverteiler reicht die Anfrage (mit der Netzwerkverbindung) an den ausgewählten Server weiter. Dies erlaubt es, dass ein Computer (der Server) auf Client-Anfragen für einen anderen Computer (der Lastverteiler) antwortet. Im Stand der Technik befasst sich die US-A-5 774 600 mit einer Server-Farm und beschreibt einen Multiknoten-Server, der Seiten des World Wide Web an netzwerkbasierte Browser-Clients überträgt. Ein Lastverteiler empfängt alle Anfragen von Clients, da diese für die gesamte Seite eine virtuelle Adresse verwenden. Der Lastverteiler stellt eine Verbindung mit dem Client her und wartet auf die Internetadresse von dem Client. Die Internetadresse gibt die angefragte Quelle an. Der Lastverteiler wartet mit der Durchführung der Lastverteilung, bis nachdem der Ort der angefragten Ressource bekannt ist.
  • Die Verbindungs- und Internetadressenanfrage werden von dem Lastverteiler zu einem zweiten Knoten übergeben, der die angefragte Ressource aufweist. Der Lastverteiler gibt die ursprüngliche Verbindungspaketfolge zu dem zweiten Knoten ab, modifiziert aber die Adresse zu der für den zweiten Knoten. Die Netzwerksoftware ist modifiziert, um die physische Netzwerkadresse des zweiten Knotens zu erzeugen, ändert aber dann die Zieladresse zu der virtuellen Adresse zurück. Der zweite Knoten überträgt die angefragte Ressource direkt an den Client, mit der virtuellen Adresse als seine Ressource. Da alle Anfragen zuerst von dem Lastverteiler empfangen werden, der den physischen Ort der angefragten Ressource bestimmt, können Knoten unterschiedliche Ressourcen enthalten. Der gesamte Inhalt der Webseite wird nicht auf alle Knoten gespiegelt. Netzwerkflaschenhälse werden vermieden, da die Knoten große Dateien direkt zurück an den Client spielen, wobei sie den Lastverteiler umgehen. Client-Browser können die virtuelle Adresse cachen, obwohl verschiedene Knoten mit unterschiedlichen physischen Adressen Anfragen bedienen.
  • Somit offenbart die US-A-5 774 660 ein digitales Computersystem, umfassend: eine erste CPU, eine erste interne Netzwerkschnittstelle, die mit der ersten CPU gekoppelt ist, eine zweite CPU und eine zweite interne Netzwerkschnittstelle, die mit der zweiten CPU gekoppelt ist, wobei die zweite Netzwerkschnittstelle ausgebildet ist, um mit dem internen Netzwerk zu koppeln. Die US-A-5 774 660 offenbart jedoch nicht, dass die ersten und zweiten Betriebssysteme unterschiedliche Eigenschaften in Bezug auf die jeweiligen Funktionen und gemeinsame Eigenschaften, die die zur Kommunikation über ein internes Netzwerk notwendige Funktionalität bereitstellen, aufweisen. Überdies bilden das erste und das zweite Betriebssys tem vereint kein Verbund-Betriebssystem und sind somit nicht Teilnehmer in einer verteilten Zustandsmaschine.
  • Lastverteilung ist eine inhärente Fähigkeit des hier offen gelegten Verbund-Betriebssystems, wie später in dem Abschnitt mit dem Titel „Lastverteilung" erläutert.
  • Symmetrische Multiprocessing (SMP)-Server sind als Alternativen zu Server-Farmen bekannt. Die begrenzte Skalierbarkeit von SMP-Servern macht sie jedoch im Allgemeinen für die Bedürfnisse von groß angelegten Webseiten schlecht geeignet. SMP-Server und Server-Farmen sind oft nicht in der Lage, diese hoch beanspruchte schnell wachsende Umgebung des Netzes zu verarbeiten. Zum Beispiel ist bekannt, dass sichere Transaktionen, die für den e-Commerce erforderlich sind, SMP-Server und Server-Farmen oft festfahren.
  • Computer, die nicht über lange Distanzen z. B. über das Internet vernetzt sind, haben wegen der geographischen Distanz zwischen dem Client und dem Server oft hinausgezögerte Ansprechzeiten. Um die Zeit zu verringern, die erforderlich ist, bis ein Server auf Anfragen von Clients antwortet, werden Webserver manchmal an einem oder mehreren Ort/en, der/die sich näher an Clients befindet/en, repliziert. Zum Beispiel kann ein Client in Japan, der eine Verbindung mit einem Server, der eine e-Commerce-Webseite in Seattle, Washington, hostet, mit einem Duplikat-Server in Tokio anstatt mit dem Hauptserver in Seattle, Washington, gekoppelt sein. Dies bringt die Daten näher zu dem Benutzer. Es ist jedoch schwierig, eine Konsistenz zwischen den Daten zu halten, die von Duplikat-Servern bedient werden, speziell wenn der Inhalt dynamisch generiert wird. Wenn z. B. ein Kunde die Online-Bestellfähigkeit eines Webservers nutzt und später versucht, den Status einer Bestellung auf einem Duplikat-Server zu kontrollieren, kann der Kunde keine genaue Information erhalten. Wenn Duplikat-Server verwendet werden, ist es auch schwierig, Hits auf einer Webseite für Werbezwecke genau nachzuverfolgen.
  • In Internetservern nach dem Stand der Technik führt oft eine Maschine das gesamte TCP/IP-Zustandsdiagramm durch (aus), was oft in Trägheit resultiert. In Systemen, in denen Funktionen mit Bündelungs-Software verteilt werden, sind die verteilten Funktionen typischerweise oben auf den Betriebssystemen wie z. B. Linux oder Windows NT, die im Allgemeinen identische Dienste durchführen, geschichtet. Demzufolge ist die Datenverarbeitung auf dem Anwendungsniveau verteilt, was oft in Latenzen und anderen Schwierigkeiten resultiert.
  • Demgemäß besteht ein Bedarf an einem Server, der eine erhöhte Geschwindigkeit, Sicherheit, Zuverlässigkeit, Kapazität und Wirtschaftlichkeit aufweist, und der auch reduzierte Raum-, Energie- und Kühl-Anforderungen sowie auch reduzierte Wartungs- und Betriebskosten aufweist.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Wie oben stehend erwähnt, stellt die vorliegende Erfindung ein digitales Computersystem in Übereinstimmung mit Anspruch 1 und ein Verfahren zum Antworten auf eine Anfrage, die über ein externes Netzwerk empfangen wird, in Übereinstimmung mit Anspruch 18 bereit. Die Erfindung ist besonders geeignet zur Implementierung eines verteilten Hochgeschwindigkeitsbetriebssystems mit hoher Kapazität, das als Verbund-Betriebssystem Federated Operating SystemTM (Federated OSTM) bezeichnet wird („Federated Operating SystemTM" und „Federated OSTM" sind Handelsnamen von Thunder River Technologies Inc.).
  • Eine Ausführungsform der Erfindung betrifft einen Webserver, der mit einer Vielzahl von Elementen implementiert ist, die in Elementklassen klassifiziert sind. Jede Elementklasse weist ein ausgeprägtes spezialisiertes Betriebssystem auf, das für seine Funktion optimiert ist. Obwohl jede Klasse von Betriebssystem einzigartig ist, weisen die meisten Elementklassen oder alle Elementklassen gemeinsame Eigenschaften auf, die von einer gemeinsamen Elternklasse vererbt sind. Zusammen bilden die Betriebssysteme der Elemente das Verbund-Betriebssystem. Eine illustrative Ausführungsform umfasst zumindest ein Empfängerelement, zumindest ein Verteilerelement, und zumindest ein Antwortsenderelement. Jedes Element besitzt eine interne Netwerkschnittstelle zum Koppeln mit einem internen Netzwerk, das zur Kommunikation zwischen den Elementen verwendet wird. Das interne Netzwerk kann z. B. mit einer Backplane, einem Kreuzschienenschalter, einem LAN, einem WAN oder einer drahtlosen Verbindung (die eine Satellitenverbindung umfassen könnte) implementiert sein. Die Empfängerelemente und Antwortsenderelemente weisen auch eine externe Netzwerkschnittstelle zur Kopplung mit einem externen Netzwerk wie z. B. dem Internet auf. Das externe Netzwerk kann ebenfalls z. B. ein LAN, ein WAN oder ein drahtloses Netzwerk (das Satellitenverbindungen umfassen könnte) sein.
  • Die Empfängerelemente empfangen Anfragen von Clients über das externe Netzwerk und reichen die Daten von den Anfragen über das interne Netzwerk an Verteilerelemente weiter. Das Verteilerelement, das für eine bestimmte Verbindung verwendet wird, verwendet das interne Netzwerk, um Information an ein Antwortsenderelement zu senden, und weist das Antwortsenderelement an, von dem Client angefragte Daten über das externe Netzwerk an den Client zu senden.
  • Die Elemente sind vorzugsweise mit Element-Hardwareeinheiten ausgeführt, die zumindest eine/n CPU, RAM, ROM, eine interne Netzwerkschnittstelle und eine externe Netzwerkschnittstelle umfassen. (Alternativ können Elemente als separate Prozesse oder Threads in einem Uniprozessor oder SMP (symmetrischen Multiprocessing)-System implementiert sein. Die Element-Hardwareeinheiten können vorzugsweise neu konfiguriert werden, um als jede beliebige Elementklasse zu arbeiten, was erlaubt, die Element-Hardwareeinheiten während des Betriebs des Servers zur Lastverteilung oder zum Austausch von defekten Element-Hardwareeinheiten neu zu konfigurieren.
  • Bevorzugte Ausführungsformen der Erfindung verwenden Adressen-, Port- und Host-Nachschlagealgorithmen, die in einer festgelegten Zeitspanne ablaufen, selbst wenn Datenbanken mit einer großen Anzahl von Einträgen durchsucht werden. Zum Beispiel können in einer HTTP (Hyper Text Transfer Protocol)-Ausführungsform große Datenbanken, die IP (Internet Protocol)-Adressen und TCP (Transmission Control Protocol)-Portnummern enthalten, und große Datenbanken, die Hostnamen enthalten, in einer festgelegten Zeitspanne durchsucht werden. Dies ermöglicht es dem Server, in Echtzeit zu arbeiten, selbst während er eine große Anzahl von gleichzeitigen Verbindungen bearbeitet.
  • Es ist möglich, unterschiedliche Elemente in derselben Hülle anzuordnen oder Elemente über kleine oder große Distanzen zu trennen. Zum Beispiel könnte sich ein Empfänger und Verteiler in Seattle, Washington, befinden, während ein Antwortsender des selben Servers sich in Tokio, Japan, befinden könnte, um schnelle Antworten an Clients in Japan zu liefern.
  • Die Erfindung stellt für ihre Benutzer eine Anzahl von Vorteilen bereit wie z. B. eine/n erhöhte/n Geschwindigkeit, Durchsatz, Zuverlässigkeit, Ska lierbarkeit, Leistung, Sicherheit und Verwaltbarkeit. Ein Server, der das Verbund-Betriebssystem implementiert, kann vergrößert werden, um ein extrem großes Volumen von Webverkehr ohne eine Leistungsverschlechterung zu bearbeiten, einschließlich Verschlüsselung/Entschlüsselung (z. B. Secure Sockets Layer (SSL)-Transaktionen, die für den e-Commerce verwendet werden). Zusätzlich kann ein Server, der das Verbund-Betriebssystem enthält, ohne spezielle Anforderungen an Energie und Kühlung in einer kompakten Hülle implementiert sein und kann durch einen einzelnen Techniker mit minimalem Training von einer Konsole aus verwaltet und konfiguriert werden. Die Erfindung stellt auch andere Vorteile und Nutzeffekte bereit, die aus der folgenden Beschreibung ersichtlich sind.
  • Bevorzugte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen dargelegt.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1A ist ein Blockdiagramm eines Element-Hardwaremoduls in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 1B ist eine perspektivische Ansicht von Element-Hardwaremodulen und Backplanes in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 1C ist eine Draufsicht von ICs und einer Leiterplatte in Übereinstimmung mit illustrativen Ausführungsformen der Erfindung.
  • 2 ist ein Blockdiagramm eines Servers, der das Verbund-Betriebssystem in seiner Betriebsumgebung implementiert, in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 3 ist ein Blockdiagramm eines Servers, der das Verbund-Betriebssystem in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung implementiert.
  • 4A ist ein Diagramm, das die Beziehungen zwischen einigen Elementen des Verbund-Betriebssystems in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 4B ist ein Blockdiagramm von Komponenten eines Servers, der ein Verbund-Betriebssystem in seiner Betriebsumgebung implementiert, in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 5 ist ein Blockdiagramm eines Servers in seiner Betriebsumgebung, in der Elemente geographisch verteilt sind, in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 6 ist ein Blockdiagramm eines Servers in seiner Betriebsumgebung, in der einige Elemente direkt mit dem Internet-Backbone gekoppelt sind, in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 7 ist ein Blockdiagramm eines Servers mit einem entfernten Datenspeicher in seiner Betriebsumgebung, in dem einige Elemente direkt mit dem Internet-Backbone gekoppelt sind, in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 8 ist ein Diagramm von Komponenten des Verbund-Betriebssystems mit einem Thunder-OS (Thunder-Betriebssystem = Thunder-BS) in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 9A ist ein Blockdiagramm, das die Beziehungen zwischen Elementen eines Thunder-BS in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 9B ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem bootfähigen Element in einem Thunder-BS in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 9C ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem Empfängerelement in einem Thunder-BS in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 9D ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem Verteilerelement in einem Thunder-BS in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 9E ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem statischen Antwortsenderelement in einem Thunder-BS in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 9F ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem dynamischen Antwortsenderelement in einem Thunder-BS in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 10 ist ein Blockdiagramm, das die Verteilung von Funktionen zwischen Empfänger-, Verteiler- und Antwortsenderelementen in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 11 ist ein Diagramm einer Empfänger-TCP-Verbindungszustandsmaschine in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 12 ist Diagramm einer Verteiler-TCP-Verbindungszustandsmaschine in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • 13 ist ein Blockdiagramm, das ein verteiltes TCP/IP-Datenverarbeitungssystem in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 14A ist ein Flussdiagramm, das ein Verfahren zum Initialisieren eines Servers in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 14B ist ein Flussdiagramm, das ein Verfahren zum Initialisieren eines Servers in Übereinstimmung mit einer weiteren illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 15 ist ein Diagramm, das den Datenfluss zwischen einem Client, Empfänger, Verteiler und Antwortsender zur Bedienung einer Client-Anfrage in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 16A ist ein Flussdiagramm, das ein Verfahren zum Antworten auf eine Anfrage, die über ein externes Netzwerk empfangen wird, in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 16B ist ein Flussdiagramm, das ein Verfahren zum Antworten auf eine Anfrage, die über ein externes Netzwerk empfangen wird, in Übereinstimmung mit einer weiteren illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 16C ist ein Flussdiagramm, das ein Verfahren zum Antworten auf eine Anfrage, die über ein externes Netzwerk empfangen wird, in Übereinstimmung mit einer weiteren illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 16D ist ein Flussdiagramm, das ein Verfahren zum Antworten auf eine Anfrage, die über ein externes Netzwerk empfangen wird, in Übereinstimmung mit einer weiteren illustrativen Ausführungsform der Erfindung veranschaulicht.
  • 17 ist eine Draufsicht einer signaltragenden optischen Disk in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung.
  • DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Definitionen:
  • Verteilt: eine Eigenschaft eines Systems, dessen Funktionalität unter mehreren Untersystemen aufgeteilt ist, von denen jedes einen Teil der Funktionalität ausführt und die idealerweise gleichzeitig arbeiten können, was in einer schnelleren vollständigen Fertigstellung einer gegebenen Aufgabe resultiert.
  • Echtzeit: eine Eigenschaft eines Systems, die nicht mehr als eine festgelegte Zeitspanne benötigt, um eine gegebene Aufgabe fertig zu stellen.
  • Server: ein Computersystem, das Daten serviert und/oder Daten empfängt und/oder Daten verarbeitet.
  • Client: eine Vorrichtung, die Anfragen und Daten an Server sendet und Daten in Ansprechen auf diese Anfragen empfängt. Ein Client kann auch von einem Server übertragene Daten empfangen, die nicht in Ansprechen auf eine Anfrage durch den Client gesendet wurden.
  • VME: bezieht sich auf die „VERSAmodule Eurocard"-Computerarchitektur, die von Motorola entwickelt wurde und in der ursprünglichen VMEBus-Spezifikation (IEEE-1014-1987) und späteren Revisionen wie z. B. VME64 (ANSI/VITA 1-1994), VME64x und VME320 definiert ist.
  • Hierin bezieht sich das Wort „vorzugsweise" auf ein/e Element, Handlung, Struktur, Material oder Eigenschaft, das/die nicht erforderlich ist, es aber wünschenswert ist, dass sie/es enthalten ist.
  • Hierin bedeutet der Ausdruck „zum Beispiel", dass die/das beispielhafte/n Elemente, Handlungen, Struktur, Material oder Eigenschaften, die/das explizit angegeben sind/ist, nicht erforderlich sind/ist, und dass ein/e andere/s Elemente, Handlungen, Struktur, Material oder Eigenschaften verwendet, durchgeführt oder enthalten sein kann/können.
  • Übersicht über einige unterschiedliche Aspekte der Erfindung
  • Die Erfindung umfasst, ist jedoch nicht beschränkt auf die folgenden Aspekte. Ein Aspekt der Erfindung umfasst Ausführungsformen eines digitalen Computersystems, die ein Verbund-Betriebssystem (Federated Operating SystemTM) implementieren. Weitere Aspekte der Erfindung umfassen Ausführungsformen eines Servers, die ein Verbund-Betriebssystem (Federated Operating SystemTM) implementieren. Weitere Aspekte der Erfindung umfassen Ausführungsformen eines Servers, die eine verteilte TCP/IP-Zustandsmaschine implementieren. Weitere Aspekte der Erfindung sind Verfahren zum Antworten auf eine Anfrage, die über ein externes Netzwerk empfangen wurde. Weitere Aspekte der Erfindung sind Verfahren zum Antworten auf eine Anfrage (die nicht über ein externes Netzwerk empfangen werden muss). Weitere Aspekte der Erfindung sind Verfahren zum Initialisieren eines Servers (oder eines digitalen Computersystems). Weitere Aspekte der Erfindung umfassen Ausführungsformen eines signaltragenden Mediums, das konkret einen maschinenlesbaren Code beinhaltet, der von einer digitalen Verarbeitungsvorrichtung zum Implementieren eines verteilten Servers ausgeführt werden kann. Weitere Aspekte der Erfindung umfassen Ausführungsformen eines signaltragenden Mediums, das konkret ein Programm von maschinenlesbaren Anweisungen beinhaltet, die von einer digitalen Verarbeitungsvorrichtung zur Durchführung eines Verfahrens zum Antworten auf eine Anfrage ausgeführt werden können. Weitere Aspekte der Erfindung sind hierin ebenfalls beschrieben.
  • Übersicht über das Verbund-Betriebssystem
  • Das Verbund-Betriebssystem (BS) (Federated Operating System (OS)) ist die allgemeine Architektur der Erfindung. Das Verbund-BS ist ein verteiltes Betriebssystem, das mit einer Vielzahl von Elementen ausgeführt ist, die in Elementklassen klassifiziert sind. Jedes Element ist eine Instanz einer Elementklasse und kann als Knoten bezeichnet werden. Jede Elementklasse weist ein ausgeprägtes spezialisiertes Betriebssystem (das auch als ein Betriebssystemkern bezeichnet werden kann) auf, das für seine Funktion optimiert ist. Zusammen bilden die Betriebssysteme der Elemente das Verbund-BS. Die Elemente des Verbund-BS wirken konzertiert zusammen, um die Funktionen eines Servers durchzuführen. Somit ist das System eine Integration von mehreren Betriebssystemen und wird daher als ein Verbund von Elementen bezeichnet. Jedes Element könnte allein arbeiten, um seine Funktion durchzuführen, vorzugsweise wirken die Elemente des Verbund-BS aber zusammen, um einen Server zu implementieren.
  • Die Eigenschaften des von jedem Element implementierten spezifischen Betriebssystems sind durch die spezifische Hardware-, Firmware- und/oder Softwarekombination, die verwendet wird, um dieses bestimmte Element zu implementieren, definiert. Somit ist die Einzigartigkeit der Elemente durch die Hardware-, Firmware- und/oder Software-Unterschiede begründet. Obwohl es nicht erforderlich ist, weisen vorzugsweise alle Elemente (mit Ausnahme des Konfigurationselements) gemeinsame Eigen schaften auf, die von einem gemeinsamen Elternelement vererbt sind (mit Hilfe einer objektorientierten Vererbung). Die Eltern(Basis)-Elementklasse, von der weitere Elementklassen vorzugsweise abgeleitet werden, enthält (unter anderem) die Funktionalität, die für synchrone Element-zu-Element-Kommunikationen über ein internes Netzwerk erforderlich sind, und umfasst vorzugsweise eine ereignisgesteuerte Verarbeitungsschleife.
  • Die Elementklassen umfassen z. B. die folgenden Klassen: Empfänger-, Verteiler-, Antwortsender-, Konfigurations-, Wächter-, dauerhafte Speicherungs-, Systemadministratorbenachrichtigungs-, Decoder-, Routing-Manager- und bootfähige plus Proto- und externe Netzwerk-Elementklassen, die abstrakte Klassen sind (der Ausdruck „Antwortsender" umfasst sowohl statische Antwortsender- als auch dynamische Antwortsenderklassen). Auch andere Klassen könnten verwendet werden. Elemente unterschiedlicher Klassen führen unterschiedliche Funktionen durch. Ein Server, der ein Verbund-BS implementiert, umfasst zumindest ein Empfängerelement, zumindest ein Verteilerelement und zumindest ein Antwortsenderelement (und umfasst vorzugsweise auch ein oder mehrere zusätzliche/s Element/e in weiteren Elementklassen). In einer alternativen Ausführungsform ist ein Verteilerelement nicht enthalten und die Funktionalität eines Verteilerelementes ist in einem Empfängerelement und/oder Antwortsenderelement implementiert (oder könnte in einem anderen Element aus einer anderen Elementklasse implementiert sein). Ausführungsformen, die mit einem externen Netzwerk gekoppelt sind, umfassen zumindest ein Element, das mit dem externen Netzwerk gekoppelt ist (und umfassen zumindest einen Empfänger und zumindest einen Antwortsender, die mit dem externen Netzwerk gekoppelt sind). In Ausführungsformen, die nicht mit einem externen Netzwerk gekoppelt sind, muss ein Empfängerelement und/oder ein Antwortsenderelement nicht enthalten sein. Die Anzahl von Elementen in einem Server und die Klassen der Ele mente in einem Server sind durch die Dienste, die der Server bereitstellen soll, die Belastung auf dem System, Eingriffe durch Menschen und weitere Faktoren bestimmt.
  • Jedes Element umfasst eine Hardware- und/oder Softwarekombination, die ein Betriebssystem implementiert, das sich von den Betriebssystemen von Elementen in unterschiedlichen Klassen unterscheidet. Zum Beispiel implementieren Empfängerelemente das gleiche Empfängerbetriebssystem, aber Verteilerelemente implementieren ein Verteilerbetriebssystem, das sich von dem Empfängerbetriebssystem unterscheidet. In dem Verbund-BS sind einzigartige Eigenschaften einer jeden Elementklasse auf dem Betriebssystemsniveau implementiert. Somit sind die Betriebssysteme für die Empfänger-, Verteiler-, Antwortsender- und weitere Klassen alle unterschiedlich (obwohl sie vorzugsweise gemeinsam vererbte Eigenschaften aufweisen können). Dies ist anders als im Stand der Technik, worin eine verteilte Datenverarbeitung oft eine Bündelungs-Software bedingt, die über Betriebssystemen arbeitet, welche im Wesentlichen identische Dienste bereitstellen. Es ist möglich, von bestehenden Elementklassen neue Elementklassen unterzuklassifizieren. Eine neue Elementklasse würde die gesamte Funktionalität der Elternelementklasse plus eine bestimmte neue Funktionalität enthalten. Zum Beispiel kann ein dynamischer Antwortsender von einem statischen Antwortsender unterklassifiziert werden. Wie in der illustrativen Ausführungsform von 9A veranschaulicht, erbt der dynamische Antwortsender die gesamte Funktionalität des statischen Eltern-Antwortsenders und fügt zusätzliche Funktionalität in Bezug auf das Generieren dynamischer Daten zu. Obwohl nicht erforderlich, ist das Verbund-BS in der C++-Programmiersprache ausgeführt, was die Implementierung der Vererbungshierarchie der Betriebssysteme der Elemente erleichtert.
  • Das Verbund-BS ist nicht auf TCP/IP (Transmission Control Protocol/Internet Protocol)-Implementierungen beschränkt, sondern kann jedes beliebige Netzwerkkommunikationsprotokoll wie z. B. Netware, VINES, AppleTalk, DECNET, SNA, OSI, ATM, netBios und IP-over-SONET implemtieren. Auch andere Kommunikationsprotokolle könnten verwendet werden. Das Verbund-BS kann auch sowohl mit paketbasierten Kommunikationssystemen als auch mit schaltungsbasierten Kommunikationssystemen, in denen eine zugeordnete Schaltung für die Kommunikation verwendet wird, verwendet werden. Das Verbund-BS kann auch in Systemen implementiert sein, die kein externes Netzwerk aufweisen, z. B. Systeme, die Daten verarbeiten, welche von entfernbaren Medien empfangen werden. Zur Einfachheit der Beschreibung, ohne aber dadurch eine Einschränkung zu beabsichtigen, werden hierin oft TCP/IP-Ausführungsformen des Verbund-BS beschrieben.
  • Anders als im Stand der Technik, in dem eine Maschine das gesamte Zustandsdiagramm für die verwendete Kommunikationsprotokollfolge durchführt, sind in dem Verbund-BS Aufgaben zwischen den Prozessoren in einer Vielzahl von Elementen verteilt. Somit ist in einer TCP/IP-Ausführungsform des Verbund-BS die TCP/IP-Zustandsmaschine über eine Vielzahl von Elementen verteilt. Mit anderen Worten, die TCP/IP-Aufgaben werden aufgeteilt und Zustände in TCP/IP-Zustandsdiagrammen werden auf unterschiedliche Elemente abgebildet. Demzufolge ist die Bedienung einer einzelnen IP-Adresse über die Netzwerkschnittstellen einer Vielzahl von Elementen (die entweder in der gleichen Hülle oder in getrennten Hüllen angeordnet sein können) verteilt. In Ausführungsformen, die andere als TCP/IP-Kommunikationsprotokolle verwenden, ist die Zustandsmaschine für diese anderen Protokolle ebenfalls über die Elemente verteilt. Somit werden Antwortgenerierung und Datenbereitstellung an einen oder mehrere Client/s durch mehrere Elemente parallel verarbeitet. In einer TCP/IP-Ausführungsform ist das Leistungsvermögen für eine Unterstützung von mehreren IP-Adressen im Allgemeinen nur durch die verfügbare Speichermenge begrenzt, was eine Skalierung zur Unterstützung von Millionen oder mehr IP-Adressen zulässt. In einer TCP/IP-Ausführungsform ist die Anzahl gleichzeitiger TCP/IP-Verbindungen, die unterstützt werden können, im Allgemeinen ebenfalls nur durch die verfügbare Speichermenge begrenzt, was eine Skalierung zur Unterstützung von Millionen oder mehr gleichzeitiger TCP/IP-Verbindungen zulässt. Somit kann eine TCP/IP-Ausführungsform hohe Datenvolumen z. B. bis zu Hunderttausende oder mehr von gleichzeitig verbundenen Internetnutzern liefern.
  • Bei dem Verbund-BS sind verteilte Multithread-Systeme mit mehreren (vorzugsweise) Singlethreadelementen implementiert. Die Elemente eines Verbund-BS erfüllen typischerweise nicht mehrere Arbeitsgänge gleichzeitig (ein gleichzeitiges Durchführen mehrerer Arbeitsgänge – Multitasking – durch Elemente ist jedoch möglich). Das Verbund-BS als Gesamtes bewerkstelligt eine parallele Verarbeitung, da jedes Element parallel mit weiteren Elementen arbeitet. Zum Beispiel führt das Verbund-BS in einer TCP/IP-Ausführungsform eine parallele Verarbeitung von Internetprotokollen aus, da jedes Element spezifische Aspekte des TCP/IP-Protokolls parallel mit weiteren Elementen ausführt. Demzufolge ist die Verarbeitung von Internetkernfunktionen beschleunigt. In ähnlicher Weise führt das Verbund-BS in einer OSI(Open System Interconnection, Kommunikation offener Systeme)-Ausführungsform eine parallele Bearbeitung unterschiedlicher Schichten des siebenschichtigen Stapels der Kommunikation offener Systeme (OSI) aus.
  • Mit dem Verbund-BS ausgeführte Server sind gut geeignet für viele Hochleistungsanwendungen z. B. Nutzen von umfangreichen Internet/Intra netanwendungen wie z. B. e-Commerce, Hosting, Multimediabereitstellung (Video und Audio auf Wunsch), spezialisierte Militärprojekte, drahtlose Infrastruktur und Internetspiele. Zusätzlich zur Verwendung mit dem Internet könnte das Verbund-BS mit anderen öffentlichen paketbasierten Breitbandnetzwerken verwendet werden.
  • Hardware für das Verbund-Betriebssystem
  • Wie oben stehend erwähnt, sind die durch jedes Element ausgeführten Eigenschaften des spezifischen Betriebssystems durch die spezifische Hardware-, Firmware- (z. B. ROM) und/oder Softwarekombination, die verwendet wird, um dieses bestimmte Element zu implementieren, definiert. Elemente des Verbund-BS sind in jeweiligen Element-Hardwareeinheiten (die als Knoten bezeichnet werden können) ausgeführt, die auf vielerlei Art und Weise ausgeführt sein können. In einigen Ausführungsformen des Verbund-BS ist jedes) Element (Instanz) mit einem separaten Hardwaremodul ausgeführt. Somit ist in diesen Ausführungsformen jede Element-Hardwareeinheit als ein Element-Hardwaremodul ausgeführt. 1 ist ein Blockdiagramm einer illustrativen Ausführungsform eines Element-Hardwaremoduls 105. Das Element-Hardwaremodul 105 umfasst zumindest eine CPU 110a (Zentralprozessoreinheit), eine interne Netzwerkschnittstelle 115, eine externe Netzwerkschnittstelle 120, einen Arbeitsspeicher (RAM) 125 und eine kleine Menge von dauerhaftem Speicher (ROM) 130, um das anfängliche Programmbild, das verwendet wird, um nachfolgende Instanzen eines Verbund-BS-Kerns zu laden, zu speichern. Die Element-Hardwareeinheiten können mit den gleichen oder unterschiedlichen CPUs, den gleichen oder unterschiedlichen Speichermengen und mit den gleichen oder unterschiedlichen Typen von Netzwerkschnittstellen ausgeführt sein. Die interne Netzwerkschnittstelle und die externe Netzwerkschnittstelle in Element-Hardwareeinheiten sind beide vorzugsweise für bidirektionale Kommunikation (Eingeben und Ausgeben von Daten und anderen Signalen) konfiguriert. Es ist nicht notwendig, eine externe Netzwerkschnittstelle 120 für Elemente vorzusehen, die nicht verwendet werden, um mit dem externen Netzwerk zu kommunizieren, obwohl vorzugsweise alle Element-Hardwareeinheiten eine interne Netzwerkschnittstelle umfassen, so dass jedes Modul die Fähigkeit besitzt, falls notwendig, als ein Empfänger oder Antwortsender zu arbeiten. Die interne Netzwerkschnittstelle wird zur Kommunikation zwischen Element-Hardwareeinheiten über das interne Netzwerk verwendet und die externe Netzwerkschnittstelle wird zur Kommunikation mit Clients über das externe Netzwerk verwendet. Optional kann die externe Netzwerkschnittstelle auch zur internen Kommunikation zwischen Element-Hardwareeinheiten verwendet werden, indem ein Kommunikationspfad für den Fall von Hardwarefehlern oder anderen Ausfällen bereitgestellt wird. Obwohl nicht erforderlich, um die Leistung zu erhöhen, hält jedes Element vorzugsweise interne Netzwerk-Nachrichteninformation, so dass jedes Element die erforderliche Netzwerk-Routinginformation kennt, die verwendet wird, um Nachrichten zu anderen Elementen zu senden, mit denen das Element kommuniziert.
  • Wenn eine Element-Hardwareeinheit mehr als eine CPU umfasst, sind die CPUs der Element-Hardwareeinheit vorzugsweise miteinander verbunden. Obwohl nicht erforderlich, ist jede CPU vorzugsweise mit jeder Netzwerkschnittstelle der Element-Hardwareeinheit gekoppelt, und der RAM und ROM sind mit jeder CPU gekoppelt. Jede beliebige Anzahl von CPUs, die in der Praxis gekoppelt werden können, kann in einem Element verwendet werden. Zum Beispiel weist jede Element-Hardware zwei CPUs 110a und 110b auf.
  • Vorzugsweise ist das Verbund-BS mit einem portablen Sourcecode ausgeführt, der die Unterstützung heterogener CPU-Hardware zulässt, was die Freiheit der Auswahl aus unterschiedlichen Prozessoren und unterschiedlichen Lieferanten zulässt. Diese Portabilität erleichtert ein Optimieren von Elementen für eine spezifische Funktionalität. Zum Beispiel kann eine Implementierung eines Elementes optimiert sein, um DSP (Digital Signal Processor)-basierte Verschlüsselungs-/Entschlüsselungsmaschinen zur Unterstützung von SSL (Secure Sockets Layer)- oder anderen sicheren Protokollen zu verwenden. Vorzugsweise sind Abhängigkeiten von einer natürlichen Byte-Anordnung, Wortgröße etc. eines Prozessors in einem Minimalcode-Modul für jeden Typ von Prozessor eingekapselt. Jede CPU kann ein beliebiger Typ von digitaler Verarbeitungsvorrichtung sein und vorzugsweise ist jede CPU eine digitale Hochgeschwindigkeits-Verarbeitungsvorrichtung. Wenn ein Modul mehr als eine CPU aufweist, ist es nicht notwendig, dass die CPUs in einem Modul das gleiche Fabrikat oder Modell sind. Vorzugsweise ist die CPU 110a ein Power-PC und die CPU 110b ein weiterer Power-PC, der der gleiche ist wie der Power-PC, der für die CPU 110a verwendet wird. Alternativ könnten die CPUs x86-Prozessoren, Digitalsignal-Hochgeschwindigkeitsprozessoren (High Speed Digital Signal Processors DSPs) hergestellt von Texas Instruments oder ein beliebiger anderer Prozessor (der auch als digitale Verarbeitungsvorrichtung bezeichnet werden kann) sein.
  • Die Prozessoren in dem Verbund-BS wirken als ein integriertes Datenverarbeitungssystem, das aus einer Vielzahl von Prozessoren besteht. Die Anzahl von Prozessoren kann von wenigen Prozessoren bis zu Hunderten (oder mehr) Prozessoren reichen, wobei die Anzahl von Prozessoren abhängig ist von der Anzahl der Elemente und der Anzahl der Prozessoren, die verwendet wird, um die Elemente zu implementieren. Prozessorleistung kann einem Server, der das Verbund-BS implementiert, einfach zugefügt werden, indem Element-Hardwareeinheiten dem System zugefügt werden, ohne die extensive LAN- und Softwarekonfiguration, die in UNIX- oder NT-Server-Farmen im Stand der Technik typischerweise erforderlich ist.
  • Ein beispielhafter Stand-Alone-Server, der das Verbund-BS in einer einzelnen Hülle implementiert, enthält eine Anzahl von Reihen von Element-Hardwaremodulen und ihr zugeordnetes Backplane, einen Netzwerk-Kreuzschienenschalter zum Verbinden der Reihen von Element-Hardwaremodulen, eine Netzwerkschaltung, die mit den externen Netzwerkschnittstellen gekoppelt ist, Verbindungen für die Netzwerkschaltungen, eine Energie aufbereitende Gleichstromversorgung, (optional) eine Batteriesicherung mit einer zugeordneten Ladeschaltung und einen Massendatenspeicher. In Ausführungsformen, in denen die Elemente physisch getrennt sind, sind die Hüllen, welche getrennte Elemente beherbergen, über lokale oder Fernnetzwerkverbindungen miteinander verbunden, was die Implementierung von geographisch verteilten Systemen erlaubt.
  • Vorzugsweise sind das physische Packaging der Element-Hardwareeinheiten und die interne Netzwerktopologie entworfen, um eine Skalierbarkeit im Hinblick auf die Anzahl von unterstützten Element-Hardwareeinheiten (und CPUs) zuzulassen. Zum Beispiel weisen in einer in 1B veranschaulichten illustrativen Ausführungsform Element-Hardwaremodule 105a, 105b eine geringe Energieverlustleistung auf und sind derart geformt (weisen einen Formfaktor auf), dass eine Anzahl von Element-Hardwaremodulen Seite an Seite in einer Reihe von typischerweise 10 bis 50 Modulen installiert werden kann und dass mehrere Reihen vertikal in einer bücherregalähnlichen Anordnung gestapelt werden können. In dieser Ausführungsform stecken die Module in einer gegebenen Reihe in einem Backplane (z. B. Backplanes 155 und 160), das alle Verbindungen für die Energie- und Netzwerkschnittstellen eines jeden Moduls bereit stellt. Das Backplane enthält auch die Verbindungen, die für das Netzwerk unter den Modulen in einer gegebenen Reihe notwendig sind, und stellt auch eine oder mehrere Netzwerkverbindung/en 165a, 165b bereit, die verwendet wird/werden, um eine Verbindung mit einer oder mehreren zusätzlichen Reihe/n herzustellen. Die Verbindung, die in jedem Backplane verwendet wird, ist vorzugsweise eine Kreuzschaltung („Switched Fabric") mit hoher Bandbreite und niedriger Latenz, was zulässt, dass mehrere Paare von Modulen gleichzeitig kommunizieren. In Implementierungen, die mehrere Backplanes verwenden, ist die Schnittstelle zwischen Backplanes vorzugsweise eine Switched Fabric ähnlich jener, die verwendet wird, um Module zu verbinden.
  • Die Element-Hardwareeinheiten (und Backplanes) können physisch nahe aneinander angeordnet sein oder können über lange Distanzen gekoppelt sein. Zum Beispiel können Element-Hardwareeinheiten in der selben Hülle oder in unterschiedlichen Hüllen in dem selben Gebäude angeordnet sein, oder können durch größere Distanzen z. B. einen oder mehrere Kilometer oder sogar Tausende von Kilometern getrennt sein. Die Verbindung, die ein Backplane mit anderen Modulen oder Backplanes von internen Netzwerken koppelt, kann z. B. ein Glasfaserkabel mit einer Länge von etwa 1 cm bis zu vielen Kilometern sein, und könnte sich sogar bis zu gegenüberliegenden Enden des Erdballs erstrecken. Ein Beispiel einer Implementierung, in der einige Element-Hardwareeinheiten entfernt in Bezug auf weitere Element-Hardwareeinheiten angeordnet sind, ist eine Ausführungsform, bei der Elemente, die für eine Verschlüsselung und Entschlüsselung von sicherer Nachrichtenübermittlung verantwortlich sind, in einer sicheren physischen Umgebung angeordnet sind, die sich entfernt von anderen Modulen des Verbund-BS befindet. Vorzugsweise ist das Verbund-BS mit einer großen Anzahl (Hunderten) von CPUs in einer kompakten Hülle implementiert.
  • In einer weiteren Ausführungsform, die als „System on a Chip"-Ausführungsform bezeichnet wird und in 1C veranschaulicht ist, sind die CPU(s), Netzwerkschnittstellen, RAM und ROM einer Element-Hardwareeinheit zu einer einzelnen integrierten Schaltung (IC) integriert. In dieser Ausführungsform ist/sind ein oder mehrere IC/s 175a, 175b, die diese Elemente enthält/enthalten, sowie interne Netzwerk-Verbindungshardware an einer einzelnen Leiterplatte 180 montiert. In dieser Ausführungsform ist die Leiterplatte vorzugsweise in der gleichen physischen Form gebildet wie die oben erläuterten Element-Hardwaremodule und kann in dasselbe Backplane eingesteckt werden. In dem System auf einer Chip-Ausführungsform verbindet das interne Netzwerk 183 alle CPUs auf der Platte. Eine interne Netzwerkschnittstelle 185 der Leiterplatte und eine externe Netzwerkschnittstelle 187 der Leiterplatte sind vorgesehen, um die Verbindung der Platte zu trennen. In einer Variation dieser Ausführungsform enthält/enthalten eine oder mehrere der IC/s jeweils mehrere Element-Hardwareeinheiten (CPU-/Netzwerkschnittstellen, RAM-/ROM-Kombinationen), die innerhalb jeder IC verbunden sind und die auch den Chip von dem internen Netzwerk auf der Platte und von dem externen Netzwerk trennen. Somit sind mehrere Element-Hardwareeinheiten in einem einzigen IC implementiert. Auch Untersysteme können auf einen einzelnen Chip implementiert sein, der mehrere Prozessormodule und einen Netzwerkschalter umfasst.
  • Internes Netzwerk und externes Netzwerk
  • Wie oben stehend erläutert, umfasst das Verbund-BS eine Vielzahl von Elementen. Wie in 2 veranschaulicht, kommunizieren die Elemente des Verbund-BS 205 miteinander über ein internes Netzwerk 210, das z. B. ein Backplane, ein Kreuzschienenschalter-Netzwerk, ein Local Area-Netzwerk (LAN), ein Wide Area-Netzwerk (WAN) oder ein beliebiger geeigne ter Typ von drahtgebundenem oder drahtlosem Netzwerk sein kann. Vorzugsweise weist das interne Netzwerk eine hohe Bandbreite und eine niedrige Latenz auf. Optional kann das interne Netzwerk aus einer Vielzahl von Netzwerken bestehen, die z. B. in einem Backplane integriert sind. Beispiele von Implementierungen des internen Netzwerks umfassen: ein Backplane wie z. B. VME64 oder CompactPCI, Kreuzschienenschalter-Netzwerke wie z. B. Race++, SCI (Scalable Coherent Interface) sowie Myrinet, anwendereigene spezifische Netzwerkschnittstellen, LANs wie z. B. Ethernet und WANs wie z. B. SONET oder ATM. Das WAN kann einen beliebigen Typ von Hochgeschwindigkeitsübertragungssystem verwenden. Vorzugsweise ist das interne Netzwerk mit einer SCI implementiert, welche eine Hochleistungs-, Paketkommunikations- und Schalttechnologie ist. Weitere Möglichkeiten sind Fibre Channel und Sky Channel oder eine beliebige andere Art zur Herstellung einer Kommunikation zwischen den Elementen. Das interne Netzwerk könnte auch für eine Verwendung mit aufkommenden Verbindungsstandards wie z. B. InfiniBand ausgebildet sein. Die interne Netzwerkschnittstelle 115 (1) eines jeden Elementes ist mit dem internen Netzwerk gekoppelt. Demzufolge sind alle Elemente mit dem internen Netzwerk gekoppelt und können miteinander über das interne Netzwerk kommunizieren.
  • In bestimmten alternativen Ausführungsformen eines Servers, der das Verbund-BS implementiert, besteht keine Verbindung mit einem externen Netzwerk. Zum Beispiel muss ein Computational-Engine-Server, der Daten von einem entfernbaren Medium oder über physikalische Sensoren, chemische Sensoren, optische Sensoren und/oder Audiosensoren empfängt, nicht mit einem externen Netzwerk gekoppelt sein. Vorzugsweise sind zumindest ein Empfänger 225 und ein Antwortsender 220 mit einem externen Netzwerk 215 verbunden. Die interne Netzwerkschnittstelle 115 eines jeden Element-Hardwaremoduls 105 dient zum Koppeln mit dem internen Netzwerk 210 und die externe Netzwerkschnittstelle 120 eines jeden Element-Hardwaremoduls 105 dient zum Koppeln mit dem externen Netzwerk 215. Wie oben stehend erwähnt ist es nicht notwendig, dass Elemente, welche nicht mit dem externen Netzwerk gekoppelt sind, eine externe Netzwerkschnittstelle aufweisen, obwohl vorzugsweise alle Elemente sehr wohl eine externe Netzwerkschnittstelle aufweisen. Die Elemente, die mit dem externen Netzwerk gekoppelt sind, können z. B. mit Ethernet-Verbindungen oder ATM gekoppelt sein. Das externe Netzwerk kann ein beliebiger Typ von LAN und/oder WAN sein und kann ein beliebiger Typ von drahtgebundenem oder drahtlosem Netzwerk sein. Obwohl das Verbund-BS für große externe Netzwerke wie z. B. das Internet optimiert ist, könnte es auch mit kleineren WANs oder LANs verwendet werden.
  • Obwohl in 2 alle Elemente, die mit dem externen Netzwerk gekoppelt sind, mit derselben Stelle in dem externen Netzwerk gekoppelt sind, ist dies nicht erforderlich. Mit anderen Worten, Elemente können mit dem externen Netzwerk an unterschiedlichen Orten in dem externen Netzwerk gekoppelt sein. Auch kann die externe Netzwerkschnittstelle eines oder mehrerer von den Elementen mit dem Internet durch direkte Verbindung mit dem Internet-Backbone gekoppelt sein, was durch Verbinden der entsprechenden Netzwerkschnittstelle direkt mit einem oder mehreren von den Haupt-Providern des Internet-Backbones bewerkstelligt wird.
  • Echtzeit verteilt und objektorientiert
    • – Verbund-BS-Elemente sind (vorzugsweise) Echtzeit-Elemente, da auf jedem (vorzugsweise) eine einzelne Aufgabe läuft, die nur durch eine festgelegte Anzahl von Unterbrechungen, die jeweils bekannte, gebundene Ausführungszeiten aufweisen, preemptiert werden können. Das Verbund-BS ist als Ganzes (vorzugsweise) ein Echtzeit-System, da die Dienst- und Pro tokollalgorithmen (vorzugsweise) alle in Echtzeit ausgeführt werden. Zum Beispiel empfängt in einer TCP/IP-Ausführungsform der Empfängerelement-Prozess vorzugsweise TCP/IP-Pakete in Echtzeit. Als ein weiteres Beispiel werden in einer TCP/IP-Ausführungsform IP-Adressen-Nachschlagevorgänge und Hostnamen-Nachschlagevorgänge vorzugsweise in Echtzeit bewerkstelligt.
    • – Das Verbund-BS ist verteilt, da Betriebssystemdienste (wie z. B. die TCP/IP-Protokolle in einer TCP/IP-Ausführungsform) über die Element-Betriebssysteme (die in dem internen Netzwerk gekoppelt sind) verteilt sind, und da das Verbund-BS eine Verteilungsfunktionalität unter unterschiedlichen Elementen unterstützt.
    • – Das Verbund-BS ist (vorzugsweise) objektorientiert, da (1) Elemente (vorzugsweise) von einem vererbten Verhalten von einer Elternklasse abgeleitet werden, und die Elemente das, was vererbt ist, erweitern; und (2) da das System (vorzugsweise) mit objektorientierten Werkzeugen aufgebaut wird.
  • Adressen-Nachschlagevorgang und Host-Nachschlagevorgang in Echtzeit
  • In einer TCP/IP-Ausführungsform sendet ein Client für ein HTTP (Hyper Text Transfer Protocol) ein Paket von Information, das eine IP-Adresse, eine Portnummer und einen Hostnamen enthält, an den Server, um den von dem Server bereitgestellten Dienst zu definieren, zu dem der Client einen Zugang wünscht. Es ist möglich, dass mehrere Hostnamen auf der gleichen IP-Adresse unterstützt werden, und im Gegensatz dazu ist es möglich, dass mehrere IP-Adressen vorhanden sind, die einem einzigen Hostnamen entsprechen. Die IP-Adresse bezieht sich auf das Internet Protocol (IP), der Port bezieht sich auf das Transmission Control Protocol (TCP) und der Hostname bezieht sich auf das Hyper Text Transfer Protocol (HTTP).
  • Im Allgemeinen müssen in Servern nach dem Stand der Technik Betriebssysteme und/oder Anwendungen in eingehenden Nachrichten nach Übereinstimmungen mit den IP-Adressen, TCP-Portnummern und weiteren Daten wie z. B. Hostnamen suchen. IP-Adressen und Hostnamen in eingehenden Nachrichten werden mit (möglicherweise) zahlreichen IP-Adressen und (möglicherweise) zahlreichen Hostnamen, die in entsprechenden Datenbanken, welche für den Server zugänglich sind, gespeichert sind, verglichen. Typischerweise ist der Netzwerkcode des Betriebssystems verantwortlich für die Verarbeitung der IP-Adresse und TCP-Portnummer eines eingehenden Pakets, um zu bestimmen, ob das Paket zu einer neuen oder bestehenden Verbindung gehört, und um die geeignete Anwendung zu bestimmen, zu der die Daten gesendet werden. Es kann notwendig sein, dass die Anwendung (z. B. ein HTTP-Webserver) nach weiteren Daten in der Nachricht (z. B. ein Hostname) sucht, um das eingehende Paket zu verarbeiten.
  • TCP/IP-Ausführungsformen des Verbund-BS verwenden (vorzugsweise) die „Trie"-Datenstruktur in ihren Suchalgorithmen, um schnell und deterministisch nach einer Übereinstimmung unter einer großen Anzahl von IP-Adressen und einer großen Anzahl von Hostnamen zu suchen. Ein Algorithmus, der die „Trie"-Datenstruktur verwendet, benötigt im Allgemeinen die gleiche Zeitspanne für die Suche, unabhängig von der Größe der zu durchsuchenden Datenbank. Dieser Typ von Algorithmus wird als deterministisch bezeichnet, da die Suchzeit für jeden Typ von Suche konstant ist und nicht von der Größe des zu durchsuchenden Pools abhängig ist. Im Gegensatz dazu verwenden Server nach dem Stand der Technik typischerweise Algorithmen (z. B. Hash-Tabellen), die sich einer determi nistischen Leistung nur dann annähern, wenn die Größe des zu durchsuchenden Pools klein genug ist. Dieser Ansatz wird im Stand der Technik verwendet, um die Menge an benötigtem Speicher zum Halten der Datenstrukturen, die von dem Suchalgorithmus benötigt werden, zu minimieren, und basiert auf einer Annahme, dass nur eine begrenzte Anzahl von gleichzeitigen Sitzungen unterstützt werden muss. Die für Suchverfahren nach dem Stand der Technik benötigte Suchzeit nimmt im Allgemeinen zu, wenn der Datenbank zusätzliche Adressen zugefügt werden, und demzufolge können Systeme nach dem Stand der Technik nicht in Echtzeit betrieben werden. Im Gegensatz dazu verwendet das Verbund-BS wann immer es möglich ist Algorithmen, die die Trie-Datenstruktur verwenden, welche Ausführungszeiten aufweisen, die nicht von der Anzahl von zu durchsuchenden Datenstrukturen beeinflusst werden. Als ein Ergebnis der Verwendung von deterministischen Suchalgorithmen benötigt das Verbund-BS eine konstante Zeitspanne, um jedes eingehende Paket zu verarbeiten, selbst wenn es eine große Anzahl von Sitzungen unterstützt. Die Verwendung der deterministischen Algorithmen erlaubt es, dass das Verbund-BS in Echtzeit arbeitet, da alle Suchen in der selben festgelegten kurzen Zeitspanne beendet werden und da die festgelegte Zeitspanne kurz genug ist, um zu erlauben, dass das System in Echtzeit betrieben wird. Es kann gesagt werden, dass in einer TCP/IP-Ausführungsform das Verbund-BS eine Echtzeit-TCP/IP-Zustandsmaschine aufweist. Eine Echtzeit-Zustandsmaschine könnte auch in Nicht-TCP/IP-Ausführungsformen des Verbund-BS implementiert sein. Obwohl die Verwendung von deterministischen Algorithmen die Leistung deutlich verbessert und bevorzugt ist, ist die Verwendung von deterministischen Suchalgorithmen in dem Verbund-BS nicht erforderlich.
  • In einer bevorzugten TCP/IP-Ausführungsform kann das Verbund-BS Millionen von gleichzeitigen TCP/IP-Verbindungen unterstützen, und kann ein Host für zumindest Hunderttausende von IP-Adressen und Hunderttausende von Hostnamen ohne Leistungsverlust sein. Dies ist begründet in dem Konstruktionsansatz und den verwendeten Algorithmen und ist ein Ergebnis der Fähigkeit, ein eingehendes Paket in einer bekannten Zeitspanne zu verarbeiten, unabhängig davon, wie viele weitere aktive Verbindungen gerade gehalten werden. Auf der anderen Seite erfahren TCP/IP-Server nach dem Stand der Technik oft einen deutlichen Leistungsverlust oder sogar einen Ausfall, wenn sie versuchen, eine große Anzahl von Verbindungen zu halten, oder wenn sie versuchen, eine große Anzahl von IP-Adressen zu unterstützen, selbst wenn die Mehrzahl dieser Verbindungen ungenutzt ist.
  • Ereignis-/netzwerkgesteuert
  • Obwohl es nicht erforderlich ist, ist das Verbund-BS vorzugsweise ereignisgesteuert/netzwerkgesteuert. Mit anderen Worten, die Netzprotokollfunktionalität ist nur dann aktiv und ruft den entsprechenden Dienst auf, wenn Daten vorhanden sind, auf die eingewirkt werden soll (in einer TCP/IP-Ausführungsform ist ein Beispiel eines Ereignisses ein Empfang eines TCP/IP-Pakets resultierend aus einem Benutzer-Click auf einen Hyperlink auf einer Webseite). Im Gegensatz dazu steuern in herkömmlichen Servern Anwendungen den Protokollstapel, sodass Anwendungen Daten aus dem Netzwerk lesen, und es blockieren, bis die Daten verfügbar sind.
  • Mehrere externe Netzwerke
  • Obwohl es nicht erforderlich ist, kann das Verbund-BS mit mehr als einem externen Netzwerk gekoppelt sein. Zum Beispiel können ein Empfänger und ein Antwortsender eines Servers, der das Verbund-BS implementiert, mit einem ersten externen Netzwerk gekoppelt sein und ein weiterer Empfänger und ein weiterer Antwortsender des Servers können mit einem weiteren externen Netzwerk gekoppelt sein. Ein das Verbund-BS implementierender Server, der mit mehr als einem externen Netzwerk gekoppelt ist, kann konfiguriert sein, um einen Datentransfer zwischen unterschiedlichen externen Netzwerken zu verhindern, oder kann konfiguriert sein, um eine Routing-Funktion zum Übergeben jeglicher Daten zwischen beliebigen zwei externen Netzwerken zu implementieren, oder kann konfiguriert sein, um durch selektives Übergeben von Daten zwischen zwei externen Netzwerken eine Firewall zu implementieren. Das Routing kann mit einem Routing-Managerelement (z. B. dem in 9A gezeigten Routing-Managerelement 920) implementiert sein. In ähnlicher Weise kann ein Firewall-Managerelement (z. B. das in 9A gezeigte Firewall-Managerelement 928) verwendet werden, um zugelassene Daten selektiv von einem externen Netzwerk zu einem weiteren Netzwerk zu übergeben.
  • Sicherheitsmerkmale
  • Das Verbund-BS besitzt eine Anzahl von Merkmalen, die die Sicherheit erhöhen. Zum Beispiel sind Clients mit dem externen Netzwerk verbunden, sind aber nicht mit dem internen Netzwerk verbunden und das externe Netzwerk wird nur verwendet, um Daten zu und von Clients zu übertragen. „Denial of Service"-Attacken werden durch die Fähigkeiten der Elemente, eingehende Pakete mit Netzwerkgeschwindigkeit zu verarbeiten, gemildert (in bevorzugten Ausführungsformen). Vorzugsweise werden die gesamten Client-Daten über sichere Container-Objekte übergeben und das Bounds-Checking wird verstärkt, wodurch Pufferüberlauf-Attacken gemildert werden. Auch kann eine Verschlüsselung/Entschlüsselung an geographisch getrennte Elemente an physisch sichere Orte delegiert werden. Ein Firewallschutz kann einfach realisiert werden, z. B. um für Si cherheit in Systemen zu sorgen, die mit mehreren externen Netzwerken verbunden sind.
  • Elementklassen
  • Wie oben stehend erwähnt, weist jede Elementklasse ein ausgeprägtes spezialisiertes Betriebssystem auf, das für seine spezifische Funktion optimiert ist. Zum Beispiel weist jedes Empfängerelement ein Empfängerbetriebssystem auf, weist jedes Verteilerelement ein Verteilerbetriebssystem auf und weist ein jedes Antwortsenderelement ein Antwortsenderbetriebssystem auf.
  • Unterschiedliche Elementklassen sind unterschiedliche einzigartige Unterklassen der Elternklasse, was als die Protoklasse bezeichnet wird. Eine Ausnahme ist die Konfigurationsklasse, die eine Unterklasse der Protoklasse sein kann oder nicht. Beispiele von Elementklassen sind Empfänger- 225, Verteiler- 230, Antwortsender- 220, Konfigurations- 235, Wächter- 240, dauerhafte Speicher- 245, Systemadministrator-Benachrichtigungs- 250, Decoder- 255 und Routing-Manager- 260 -Klassen (veranschaulicht in 2) zusätzlich zu der bootfähigen Klasse. Zusätzlich gibt es Protoelement- und externe Netzwerk-Elementklassen, die abstrakte Klassen sind, welche nicht als Elemente implementiert sind, die aber Elternklassen für Elemente sind. Eine illustrative Ausführungsform eines Servers, der das Verbund-BS implementiert, umfasst ein Empfängerelement, ein Verteilerelement und acht Antwortsenderelemente (und umfasst vorzugsweise auch ein Wächterelement). Das Verbund-BS ist skalierbar in dem Sinn, dass Elemente je nach Wunsch zugefügt oder entfernt werden können. Es ist möglich, eine große Anzahl von Antwortsendern einzuschließen, z. B. 400 Antwortsender und sogar größere Anzahlen von Antwortsendern könnten verwendet werden. Wenn jeder Antwortsender Daten mit z. B. 2,5 Gigabit pro Sekunde überträgt, und wenn z. B. 400 Antwortsender vorhanden sind, dann würde das Verbund-BS ein Leistungsvermögen zur Lieferung von einem Terabit (240 Bits/Sekunde) an Daten aufweisen. Jeder Antwortsender könnte z. B. mit einer OC-48-Verbindung zum Übertragen von Daten mit 2,5 Gigabit pro Sekunde gekoppelt sein.
  • Obwohl es nicht notwendig ist, besitzt vorzugsweise jede Element-Hardwareeinheit die Fähigkeit, während des Betriebs („on the fly") dynamisch neu konfiguriert zu werden, um die Funktion eines beliebigen nicht abstrakten Elementes durchzuführen. Mit anderen Worten, die CPU(s) eines Elementes kann/können vorzugsweise einer beliebigen der Elementfunktionen zugewiesen sein. Wenn z. B. ein Verteiler aussteigt, könnte z. B. ein Antwortsender oder Empfänger während des Betriebs eines Servers dynamisch neu konfiguriert werden, um als ein Verteiler zu wirken. Diese Fähigkeit erlaubt auch eine dynamische Lastverteilung. Eine dynamische Neukonfigurierung von Element-Hardwareeinheiten erlaubt eine Fehlerbeseitigung ohne Dienstunterbrechung. Somit ist ein Server, der das Verbund-BS implementiert, ein fehlertolerantes, verteiltes System, das Dienste von ausgefallenen Element-Hardwareeinheiten (oder ausgefallenen Element-ICs) entfernt neu zuweisen kann.
  • Vorzugsweise werden alle Elemente von einem bootfähigen Element abgeleitet, das vorzugsweise von einem Protoelement abgeleitet ist. Alternativ können Elemente implementiert werden, ohne dass sie von einem anderen Element abgeleitet sind, wobei in diesem Fall solche Elemente eine Zwischenelement-Kommunikationsfunktionalität implementieren müssen. Elementklassen sind wie folgt beschrieben:
  • – Empfängerelement:
  • Vorzugsweise ist/sind ein oder mehrere Empfänger in dem Verbund-BS enthalten.
  • Obwohl in diesem Abschnitt als „der Empfänger" beschrieben, können es auch mehr als ein Empfänger sein.
  • Vorzugsweise ist der Empfänger von einem externen Netzwerkelement abgeleitet.
  • In Ausführungsformen, die einen Empfänger umfassen, ist der Empfänger mit einem externen Netzwerk gekoppelt.
  • Der Empfänger bearbeitet die Client-Verbindungsverwaltung. Zum Beispiel stellt der Empfänger in Ansprechen auf Verbindungsanfragen von Clients Verbindungen zwischen Clients und dem Server her. Zum Beispiel in TCP/IP-Ausführungsformen stellt der Empfänger TCP-Verbindungen mit Clients her. Das Herstellen einer Verbindung beinhaltet üblicherweise nicht eine Übertragung von Client-Daten.
  • Der Empfänger ist vorzugsweise die einzige Netzwerkschnittstelle eines bestimmten Servers, zu der ein entfernter Client übertragen kann.
  • Der Empfänger kann Daten über das externe Netzwerk empfangen oder übertragen, aber in TCP/IP-Ausführungsformen überträgt der Empfänger im Allgemeinen nur Headerdaten, z. B. ein Handshake, um eine Verbindung herzustellen.
  • In Ausführungsformen, die einen Empfänger und einen Verteiler umfassen, übergibt der Empfänger die Daten an einen Verteiler, sobald eine Verbindung zwischen einem Client und dem Server hergestellt ist und Daten empfangen werden. Zum Beispiel könnten in einer TCP/IP-Ausführungsform die Daten eine HTTP-Anfrage sein.
  • In TCP/IP-Ausführungsformen verarbeitet der Empfänger IP und TCP und verarbeitet vorzugsweise auch ARP (Address Resolution Protocol) und ICMP (Internet Control Message Protocol).
  • Obwohl es nicht notwendig ist, weist der Empfänger in einer TCP/IP-Ausführungsform vorzugsweise nur eine Teil-TCP/IP-Zustandsmaschine auf.
  • In TCP/IP-Ausführungsformen verwaltet der Empfänger vorzugsweise das IP-Fragment-Reassembly.
  • In TCP/IP-Ausführungsformen hält der Empfänger vorzugsweise bestimmte TCP-Zustandsinformation.
  • – Verteilerelement:
  • Vorzugsweise ist/sind ein oder mehrere Verteiler in dem Verbund-BS enthalten.
  • Obwohl in diesem Abschnitt als „der Verteiler" beschrieben, können auch mehr als ein Verteiler vorhanden sein.
  • Verteiler müssen nicht mit dem externen Netzwerk gekoppelt sein, was die Sicherheit erhöht.
  • Der Verteiler verwaltet vorzugsweise die Ressourcenzuweisung, zum Beispiel bestimmt er, welche/r Antwortsender zugeordnet werden soll/en, um auf jede Client-Anfrage zu antworten. Die Daten, die erforderlich sind, um auf eine Anfrage zu antworten, können über mehr als einen Antwortsender verteilt sein.
  • In einer TCP/IP-Ausführungsform führt der Verteiler vorzugsweise eine aktive Verbindungs- und Dienst-Verwaltung durch, umfassend z. B. eine HTTP-Sitzungsverwaltung, Mail-Sitzungsverwaltung und FTP.
  • In einer TCP/IP-Ausführungsform verarbeitet der Verteiler Verbindungen, die in Zuständen vorliegen, welche zulassen, dass eine Datenübertragung erfolgt. Der Verteiler hält vorzugsweise eine Aufzeichnung des Zustandes einer jeden Verbindung, die der Verteiler verarbeitet. Die Zustandsinformation umfasst Elemente, die von der TCP-Spezifikation benötigt werden (z. B. Folgenummern) wie auch Information, die von dem Verbund-BS benötigt wird (z. B. welche/r Antwortsender und Antwortidentifizierung einer gegebenen Verbindung zugeordnet ist). Zum Beispiel ist eine Verbindung einem bestimmten Dienst zugeordnet und der Dienstcode ordnet der Verbindung ein Antwortobjekt zu. Die Antwortidentifzierung ist eine in dem Verteiler gespeicherte Zustandsinformation, die das Antwortobjekt identifiziert, und ist z. B. eine ganze Zahl, die als ein Index dient, den der Verteiler zu einem Antwortsender übergibt, was es dem Antwortsender ermöglicht, die korrekte Antwortinformation zu identifizieren. Andere Zustandsinformation in Bezug auf Verbindungen wird vorzugsweise von anderen Elementen gehalten.
  • – Antwortsenderelement:
  • Vorzugsweise ist/sind ein oder mehrere Antwortsender in dem Verbund-BS enthalten.
  • Obwohl in diesem Abschnitt manchmal als „der Antwortsender" beschrieben, können auch mehr als ein Antwortsender vorhanden sein und vorzugsweise sind in einem Server viele Antwortsender vorhanden.
  • Vorzugsweise wird der Antwortsender von einem externen Netzwerkelement abgeleitet.
  • In Ausführungsformen, die einen Antwortsender umfassen, ist der Antwortsender mit einem externen Netzwerk gekoppelt.
  • Der Antwortsender überträgt Daten.
  • Der Antwortsender kann vorzugsweise statische Daten verwalten und übertragen und/oder dynamische Daten erzeugen, verwalten und übertragen.
  • Der Antwortsender erfüllt die Funktion des Sendens angefragter Daten zu einem spezifischen Client.
  • In einer TCP/IP-Ausführungsform überträgt der Antwortsender HTTP-Daten, Maildaten und/oder Daten für andere Dienste.
  • Obwohl es nicht erforderlich ist, umfasst zumindest ein Element des Verbund-BS eine Nicht-Echtzeit-Schicht. Zum Beispiel kann ein Anrufsender eine Nicht-Echtzeit-Schicht umfassen, auf der Nicht-Echtzeitprogramme (z. B. Java) laufen. Vorzugsweise ist die Nicht-Echtzeit-Schicht Linux. Alternativ könnte die Nicht-Echtzeit-Schicht eine Open-Source-Nicht-Echtzeit-Schicht wie z. B. FreeBSD, oder OpenBSD oder eine Nicht-Open-Source-Nicht-Echtzeit-Schicht, wie z. B. AIX oder Solaris, oder eine beliebige Open Source- oder Nicht-Open-Source-Nicht-Echtzeit-Schicht sein. Das Verbund-BS kann verwendet werden, um einen Betriebsserver zu implementieren, selbst wenn es keine Schnittstelle zu einer Nicht-Echtzeit-Schicht gibt, aber in diesem Fall können auf dem Server keine Nicht-Echtzeitprogramme laufen. Auf der Nicht-Echtzeit-Schicht, z. B. Linux, läuft eine Aufgabe auf einem Element des Verbund-BS.
  • Vorzugsweise gibt es zwei Hauptverhaltensweisen eines Antwortsenders:
    (1) Übertragen von in dem Antwortsender gecachten statischen Daten und/oder Laden statischer Daten auf den Antwortsender; (2) Bedienen dynamischer Datenanfragen, z. B. durch Generieren von (einer) Antwort/en bei einer Anwendung, die auf einer virtuellen Java-Maschine läuft, die in der Nicht-Echtzeit-Schicht des Antwortsenders läuft.
  • In einer TCP/IP-Ausführungsform sind die Antwortsender vorzugsweise in zwei Gruppen unterteilt, die (1) statische Antwortsenderelemente und (2) dynamische Antwortsenderelemente umfassen. Statische Antwortsenderelemente verwalten und übertragen z. B. statische Daten für HTTP-, FTP-, Mail- und andere Dienste.
  • Dynamische Daten können von jedem beliebigen Element des Verbund-BS entweder in der Echtzeit-Schicht oder der Nicht-Echtzeit-Schicht erzeugt werden. Zum Beispiel kann ein dynamisches Antwortsenderelement Daten von einem dauerhaften Speicherungselement (z. B. das dauerhafte Speicherungselement 475 in 4B) abfragen, und optional diese Daten mit anderen Daten (z. B. einem HTTP-Header) kombinieren und die kombi nierten Daten zu dem Client übertragen. In einem anderen Beispiel kann ein dynamisches Antwortsenderelement Daten von einem externen Datenbankserver (z. B. der externe Datenbankserver 485 in 4B) anfragen und optional diese Daten mit anderen Daten kombinieren und die kombinierten Daten zu dem Client übertragen. Es ist nicht notwendig, dass ein dynamischer Antwortsender eine Nicht-Echtzeit-Schicht aufweist. Wenn ein dynamischer Antwortsender eine Nicht-Echtzeit-Schicht aufweist, dann implementiert der dynamische Antwortsender eine Nicht-Echtzeit-Schicht-Laufzeitzuweisung und eine Nicht-Echtzeit-Schicht-Nachrichtenschnittstelle (z. B. zu Linux oder Solaris). Dynamische Antwortsenderelemente übertragen dynamische Daten zu dem Client. Vorzugsweise sind dynamische Antwortsenderelemente von einem statischen Antwortsenderelement abgeleitet.
  • – Konfigurationselement:
  • Ein Konfigurator ist in Ausführungsformen des Verbund-BS, die vorkonfiguriert sind, nicht erforderlich.
  • Obwohl in diesem Abschnitt als „der Konfigurator" beschrieben, können auch mehr als ein Konfigurator vorhanden sein. Vorzugsweise ist in einem Server jedoch nur ein Konfigurator vorhanden.
  • Der Konfigurator weist eine Benutzerschnittstelle zum Laden, Modifizieren und Speichern der gesamten Systemkonfiguration auf. Vorzugsweise erlaubt der Konfigurator auch dem Benutzer, das System in Bezug auf seine aktuelle Konfiguration abzufragen und dessen Betrieb zu überwachen.
  • Vorzugsweise ist der Konfigurator sprachcodierend neutral und zahlreiche Sprachen (z. B. englisch, japanisch, deutsch etc.) werden in der Benutzer schnittstelle voll unterstützt. Vorzugsweise ist die Benutzerschnittstelle eine graphische Benutzeroberfläche, die in Verbindung mit einem Monitor, einer Maus und einer Tastatur verwendet wird.
  • Wie in 3 gezeigt, umfasst eine illustrative Ausführungsform eines Servers 300, der das Verbund-BS implementiert, ein Server-Gehäuse 305, das die Element-Hardwareeinheiten und das interne Netzwerk (z. B. die/das in 2 gezeigte/n Element-Hardwaremodule und interne Netzwerk) umfasst. Der Server ist mit dem externen Netzwerk an einem oder mehreren Orten gekoppelt. Die illustrative Ausführungsform des Servers umfasst vorzugsweise auch einen Monitor 310, eine Maus 315 und eine Tastatur 320, die mit einem Konfigurationselement gekoppelt sind.
  • In dem HTTP-Dienst einer TCP/IP-Ausführungsform umfasst die Systemkonfiguration Elemente wie z. B. IP-Adressen und TCP-Ports, af die zu hören ist. Der Konfigurator sorgt für eine zentralisierte Konfiguration des gesamten Systems, das in einer TCP/IP-Ausführungsform vorzugsweise alle Internet-Kerndienste wie z. B. einen HTTP-Dienst, einen FTP-Dienst, einen IMAP-E-Mail-Dienst und einen POP3-E-Mail-Dienst umfasst.
  • Wenn er das System konfiguriert, überträgt der Konfigurator einen Code an andere Elemente oder informiert andere Elemente von dem Ort des Codes, auf dem die anderen Elemente laufen, um Instanzen spezifischer Klassen von Elementen zu werden, die für eine gegebene Konfiguration erforderlich sind. Der Code kann in einem ROM, einem dauerhaften Speicherungselement oder in einer anderen Speicherungsvorrichtung gespeichert werden.
  • Das Konfigurationselement muss keine Unterklasse des Protoelementes sein, da es nicht notwendig ist, dass das Konfigurationselement an dem Echtzeitbetrieb des Servers teilnimmt. Vorzugsweise ist der Konfigurator keine Unterklasse des Protoelementes und kein Echtzeit-Element. Wenn der Konfigurator nicht als eine Unterklasse des Protoelementes ausgeführt ist, muss der Konfigurator noch immer das gleiche Nachrichtenprotokoll implementieren wie das Protoelement, so dass das Konfigurationselement in der Lage sein wird, mit den Echtzeit-Elementen zu kommunizieren. Der Konfigurator kann z. B. als ein Standardverfahren in einem Nicht-Echtzeit-Betriebssystem (z. B. MacOS oder Linux) zusammen mit den Vorrichtungstreibern, die benötigt werden, um mit dem internen Netzwerk des Servers zu kommunizieren, implementiert sein.
  • – Wächterelement:
  • Ein Wächterelement kann optional in dem Verbund-BS implementiert sein.
  • Obwohl in diesem Abschnitt als „der Wächter" beschrieben, können mehr als ein Wächter vorhanden sein.
  • Das Wächterelement überwacht die Gesundheit des Systems durch Empfangen periodischer Zustandnachrichten von den anderen Elementen sowie durch Initiieren periodischer Abfragen an die anderen Elemente. Demgemäß empfängt der Wächter regelmäßig Daten, z. B. einmal pro Sekunde, (oder eine beliebige andere Zeitspanne) von Elementen über dem gesamten internen Netzwerk. Vorzugsweise überwacht der Wächter sowohl die Hardware als auch die Software.
  • Das System kann derart konfiguriert sein, dass ein oder mehrere Wächter einen oder mehrere weitere Wächter überwacht/en.
  • Durch den/die Wächter ist der Server in der Lage, (ein) funktionsgestörtes Element/e zu detektieren und das System on the fly dynamisch neu zu konfigurieren, indem eine andere Element-Hardwareeinheit zugewiesen wird, die die Funktion eines jeden entsprechenden funktionsgestörten Elementes durchführt. Der Wächter kann dies bewerkstelligen, indem er die Daten, für die das ausgefallene Element verantwortlich war, auf die Hardwareeinheit eines anderen Elementes derselben Klasse wie das ausgefallene Element lädt und dann die Elemente von der Änderung informiert.
  • Zum Beispiel werden die Antwortdaten eines ausgefallenen Antwortsenders auf einen anderen Antwortsender geladen und (der) betroffene Verteiler wird/werden von dem neuen Ort der betroffenen Antworten informiert. Wenn es keine anderen Elemente der selben Klasse wie ein ausgefallenes Element gibt oder wenn die bestehenden Elemente nicht in der Lage sind, die neu angeordnete Funktionalität anzunehmen, kann die Klasse eines bestehenden Elementes zu der Klasse des ausgefallenen Elementes geändert werden, indem die bestehende Element-Hardwareeinheit neu gestartet wird (was erfordern kann, dass die Elementfunktionalität zu der/den Hardwareeinheit/en von (einem) noch anderen Element/en neu angeordnet wird). Somit ist die Architektur selbstüberwachend und selbstheilend.
  • Wenn eine CPU ausfällt, wird der Ausfall von einem Wächter detektiert, und die Aufgaben des ausgefallenen Elementes werden transparent einem anderen Prozessor in einem anderen Element neu zugewiesen und ein Alarm für andere Elemente wird in dem internen Netzwerk abgeschickt. Wenn eine CPU in einem Element nicht ausgefallen ist, wenn aber ein interner Kommunikationskanal in dem Element auf Grund einer Hardware- oder Softwarestörung nicht verfügbar ist, routet das gestörte Element vorzugsweise Nachrichten neu, ohne einen Ausfall des Dienstes. Wenn dies nicht möglich ist, wird der Ausfall von dem Wächter detektiert, und die Wiederherstellung schreitet wie für den Fall eines CPU-Ausfalls voran.
  • Lastverteilung: Die Architektur des Verbund-BS führt inhärent eine Lastverteilung aus, da die Last inhärent über die Elemente verteilt wird. Zum Beispiel wird in einer TCP/IP-Ausführungsform die TCP/IP-Zustandsmaschine über eine Vielzahl von Elementen verteilt. Vorzugsweise umfasst das Verbund-BS auch eine intelligente Lastverteilung, um dynamisch Ressourcen zuzuweisen, die mit einem sich ändernden Benutzerbedarf übereinstimmen. Eine dynamische Lastverteilung kann z. B. bewerkstelligt werden, indem ein Verteiler dem Antwortsender Aufgaben zuweist, den der Verteiler als am wenigsten belastet bestimmt. Alternativ oder zusätzlich zu der durch Verteiler gesteuerten dynamischen Lastverteilung kann die dynamische Lastverteilung dadurch bewerkstelligt werden, dass Antwortsender bestimmen, wenn sie zu wenig genutzt werden. Wenn ein Verteiler und/oder (ein) Antwortsender bestimmt/en, dass ein oder mehrere Antwortsender wenig belastet ist/sind, kann die Funktionalität von zwei oder mehr Antwortsendern auf eine kleinere Anzahl von Antwortsendern zusammengelegt werden (auf eine Weise ähnlich der zum Wiederherstellen von einem ausgefallenen Element). Die Klasse des/der resultierenden nicht verwendeten Elemente/s kann geändert werden, indem das/die nicht verwendete/n Element/e als Elemente von Elementklassen neu gestartet werden, die eine größere Last erfahren, z. B. Empfänger. Eine statische Lastverteilung kann einfach durch Aufteilen der Daten unter den Antwortsendern ausgeführt werden. Ein weitere Ansatz für eine Lastverteilung ist ein geographischer Algorithmus, in der der Antwortsender, der sich geographisch am Nächsten zu dem anfragenden Client befindet, ausgewählt wird. Ein noch weiterer Ansatz für eine Lastverteilung ist ein Netzwerk-Topologiealgorithmus, in dem der Antwortsender, der dem Client im Hinblick auf die Netzwerktopologie am Nächsten ist, ausgewählt wird. Die Lasten des Antwortsenders können auch auf Basis der Fähigkeiten eines jeden Antwortsenders verteilt werden. Zum Bei spiel werden Antworten, die Verschlüsselungsfähigkeiten erfordern, Antwortsendern zugewiesen werden, die Verschlüsselungsfähigkeiten besitzen. Eine Lastverteilung kann automatisiert sein oder kann einen menschlichen Eingriff erfordern.
  • – Dauerhaftes Speicherungselement:
  • Ein oder mehrere dauerhafte/s Speicherungselement/e kann/können in dem Verbund-BS enthalten sein. Dauerhafte Speicherungselemente sind insofern einzigartig in Bezug auf die anderen Elementklassen, als sie eine direkte Schnittstelle zu einer oder mehreren Datenspeicherungsvorrichtung/en aufweisen. Demzufolge muss eine Hardware, die verwendet wird, um ein dauerhaftes Speicherungselement zu implementieren, eine Schnittstelle zum Koppeln mit einer oder mehreren Datenspeicherungsvorrichtung/en aufweisen. Dauerhafte Speicherungselemente sind dafür verantwortlich, Rohdaten zu und von den anderen Elementen zu servieren. Dies erlaubt, dass sich die Prozessoren der Elemente eine große Speichermenge, vorzugsweise Terabytes von redundantem Fiber Channel RAID (Redundant Array of Independent Disks)-Hochgeschwindigkeits(Gigabit/Sek)-Speicher teilen. Es könnte auch ein beliebige/r anderer Typ und Größe von Speicher verwendet werden, z. B. herkömmliche Festplatten, optische Disks, ROM etc. Optional kann ein dauerhaftes Speicherungselement eine große Menge von Hochgeschwindigkeits-RAM umfassen, die verwendet wird, um Daten in einer speicherresidenten Datenbank zu cachen. Optional kann das dauerhafte Speicherungselement ein Dateisystem emulieren.
  • – Systemadministratorbenachrichtigungselement
  • Ein oder mehrere Systemadministratorbenachrichtigungselement/e kann /können optional in dem Verbund-BS enthalten sein. In dem Fall einer Unterbrechung wie z. B. eines Strom- oder Telefonserviceausfalls benachrichtigen ereignisbasierte Fernalarmierungen z. B. durch einen Pager oder ein Mobiltelefon das Systemadministratorpersonal. Die Systemadministratorbenachrichtigungseinrichtung detektiert entweder die Unterbrechung selbst oder wird von der Unterbrechung durch ein anderes Element informiert, und dann versucht die Systemadministratorbenachrichtigungseinrichtung, das Systemadministratorpersonal zu kontaktieren und von der Unterbrechung zu benachrichtigen. Optional kann die Funktionalität eines Systemadministratorbenachrichtigungselementes in einem Wächterelement enthalten sein.
  • – Decoderelement:
  • Ein oder mehrere Decoder kann/können optional in dem Verbund-BS enthalten sein. Ein Decoder ist ein Element, das speziell optimiert ist, um Verschlüsselungs-/Entschlüsselungs- oder Authentifizierungsfunktionen zu erledigen, z. B. in TCP/IP-Ausführungsformen eine SSL(Secure Sockets Layer)-Sitzungsverwaltung. Eine illustrative Ausführungsform eines Decoderelementes umfasst eine große Anzahl von spezialisierten CPUs (z. B. RISC-Prozessoren oder Digitalsignal-Prozessoren), wobei jede CPU die gleichzeitig datenverarbeitungsintensiven Aspekte einer Verschlüsselung/Entschlüsselung für eine gegebene Verbindung erledigt.
  • – Routing-Managerelement
  • Ein oder mehrere Routing-Manager kann/können optional in dem Verbund-BS enthalten sein. Ein Routing-Manager hält Adressen-Routingtabellen. Zum Beispiel hält in einer TCP/IP-Ausführungsform ein Routing-Managerelement IP-Routingtabellen.
  • – Firewall-Managerelement:
  • Ein oder mehrere Firewall-Managerelement/e kann/können optional in dem Verbund-BS enthalten sein. Ein Firewall-Managerelement bestimmt, welche Daten von einem externen Netzwerk zu einem anderen übergeben werden sollen.
  • – Protoelement:
  • Das Protoelement ist die Elternklasse der anderen Echtzeit-Elementklassen. Vorzugsweise erben alle Echtzeit-Elementklassen die Eigenschaften des Protoelementes. (Wie oben stehend erwähnt, muss das Konfigurationselement nicht eine Unterklasse des Protoelementes sein.) Die Protoelementklasse ist eine abstrakte Klasse, was bedeutet, dass keine Elementinstanz erzeugt wird, die nur ein Protoelement ist, sondern stattdessen jedes Echtzeit-Element vorzugsweise eine Instanz von einer der Unterklassen ist, die von der Protoelementklasse abgeleitet sind.
  • Die Protoelement-Funktionalität umfasst z. B. die Speicherverwaltung, die Selbstheilungsüberwachung, die Element-zu-Element-Kommunikation und Dienstprogrammfunktionen. Selbstheilungsüberwachung bedeutet, dass das Element die Fähigkeit besitzt, sein Leistungsvermögen und seine Belastung zu messen und seine „Gesundheit" zu bestimmen, indem es den Zustand der Hardware-, Firmware- und Softwarekomponenten, die das Element umfassen, bestimmt. Das Protoelement kann eine Fähigkeit umfassen, zu bestimmen, wenn ein Problem mit einem Element vorliegt und dann Hilfe anzufordern und/oder kann die Fähigkeit umfassen, Da ten mit (einem) anderen Element/en zu teilen, das/die die Daten analysiert/analysieren und bestimmt/bestimmen, ob ein Problem vorliegt. Die Element-zu-Element-Kommunikationsfunktionalität ist eine Funktionalität zum Senden von und Antworten auf Nachrichten von anderen Elementen. Zum Beispiel umfasst ein Protoelement die Funktionalität, auf eine Nachricht von einem Konfigurator zu antworten, der das Element darüber informiert, welche Klasse von Element es sein wird, z. B. ein Empfänger. Das Protoelement umfasst vorzugsweise auch die Funktionalität, einen Code zu empfangen und zu laden, der die einem Element zugewiesene bestimmte Elementklasse implementiert. Mit anderen Worten besitzt vorzugsweise jedes Element (mit Ausnahme vielleicht des Konfigurationselementes) die Fähigkeit, eine Nachricht zu empfangen, die selbst eine neue Instanz des Betriebssystems ist. Zum Beispiel könnte der Inhalt der Nachricht der Betriebssystemcode sein, um ein bootfähiges Element z. B. in einen Empfänger umzuwandeln. Wie oben stehend erläutert, kann danach ein Element zu einer anderen Elementklasse z B. einem Verteiler umgewandelt werden.
  • – Externes Netzwerkelement:
  • Das externe Netzwerkelement ist vorzugsweise eine Unterklasse eines bootfähigen Elementes und ist vorzugsweise die Elternklasse von Empfänger- und Antwortsenderelementen. Ein Beispiel für ein externes Netzwerkelement 916 ist in 9A gezeigt. Empfänger- und Antwortsenderelemente erben vorzugsweise Eigenschaften von dem externen Netzwerkelement, wie z. B. die Fähigkeit einer Schnittstelle für das externe Netzwerk und Rohprotokollunterstützung. Ein Beispiel für eine Rohprotokollunterstützung in einer TCP/IP-Ausführungsform ist das Parsing und die Generierung von IP- und TCP-Paketen. Die externe Netzwerk-Elementklasse ist vorzugsweise eine abstrakte Klasse, was bedeutet, dass keine Elementin stanz erzeugt wird, die nur ein externes Netzwerkelement ist, sondern stattdessen ist vorzugsweise jedes Empfänger- und Antwortsenderelement eine Instanz einer Unterklasse, die von der externen Netzwerk-Elementklasse abgeleitet ist. Möglicherweise wird ein unterschiedliches externes Netzwerkelement für jede externe Netzwerkschnittstelle verwendet, z. B. Myrinet, Ethernet und ATM. Alternativ ist ein einzelnes externes Netzwerkelement vorhanden, das eine Vielzahl von externen Netzwerkschnittstellen unterstützt.
  • – Bootfähiges Element:
  • Bootfähige Elemente sind eine Unterklasse des Protoelementes. Somit erben bootfähige Elemente die Funktionalität des Protoelementes. Bootfähige Elemente müssen jedoch einen CPU-spezifischen Code definieren, der notwendig ist, um diese Funktionalität zu implementieren. Ein bootfähiges Element ist eine Bare-Bones-Instanz eines Verbund-BS-Echtzeit-Elementes. Da bootfähige Elemente einen CPU-spezifischen Code aufweisen, müssen bootfähige Elemente nicht notwendigerweise identisch sein. Somit sind bootfähige Elemente für X86-, PowerPC-, und DSP-Prozessoren voneinander unterschiedlich. Ein CPU-spezifischer Code kann z. B. eine spezifische Byteanordnung und Wortgröße umfassen. Typischerweise ist der ausführbare Code für ein bootfähiges Element ein Teil der Firmware (dauerhafter Speicher) eines Elementes (Knoten), so dass, wenn das Element mit Energie versorgt wird, das Element eine Instanz eines bootfähigen Elementes wird.
  • Jede Elementklasse (mit Ausnahme vielleicht der Konfigurationsklasse und der Protoklasse) ist vorzugsweise eine Tochterklasse eines bootfähigen Elementes. Bootfähige Elemente besitzen die Fähigkeit, den ausführbaren Code zu empfangen und zu laden, um eine einem Element zugewiesene bestimmte Elementklasse zu implementieren. Mit anderen Worten, jede/s bootfähige Element oder Unterklasse eines bootfähigen Elementes besitzt die Fähigkeit, eine Nachricht zu empfangen, die eine neue Instanz eines Betriebssystems enthält. Zum Beispiel könnte die Nachricht den Betriebssystemcode enthalten, um ein bootfähiges Element z. B. in einen Empfänger umzuwandeln. Wie oben stehend erwähnt, kann danach ein Element in eine andere Elementklasse umgewandelt werden.
  • 4A veranschaulicht die hierarchische Beziehung zwischen einem Protoelement 405, einem bootfähigen Element 410, einem Empfängerelement 415, einem Verteilerelement 420 und einem Antwortsenderelement 425 in einer illustrativen Ausführungsform des Verbund-BS. 4A veranschaulicht, dass bootfähige Elemente vorzugsweise Instanzen des Protoelementes sind, und dass Elementklassen, die als Knoten des Verbund-BS arbeiten, vorzugsweise Instanzen eines bootfähigen Elementes sind (obwohl die bootfähigen Elemente nicht identisch sein müssen). 4B ist ein Blockdiagramm eines Servers 440 in seiner Betriebsumgebung, der eine illustrative Ausführungsform eines Verbund-BS implementiert. 4B veranschaulicht Empfänger 445, Verteiler 450, Antwortsender 455, einen Konfigurator 460, einen Wächter 465, Decoder 470, dauerhafte Speicherungselemente (Datenserver) 475, einen Wächter 480, einen externen Datenbankserver 485, ein internes Netzwerk 490, ein externes Netzwerk 492 und Clients 495. Die in 4B gezeigten externen Datenbankserver sind herkömmliche Server, die optional mit dem internen Netzwerk eines Servers, der das Verbund-BS implementiert, gekoppelt sein können.
  • Internes Netzwerkmodul
  • Vorzugsweise umfassen das Protoelement und das Konfigurationselement ein internes Netzwerkmodul (z. B. das in 9A gezeigte interne Netz werkmodul 902). Das interne Netzwerkmodul umfasst z. B. eine interne Netzwerkschnittstelle, Nachrichtendatenstrukturen und ein Nachrichtenprotokoll, die verwendet werden, um die Kommunikation über das interne Netzwerk zu erleichtern. Interne Netzwerkmodule sind spezifisch für ein bestimmtes internes Netzwerkprotokoll. Zum Beispiel wird in Abhängigkeit von dem in dem internen Netzwerk verwendeten Protokoll eines der folgenden internen Netzwerkmodule verwendet: eine durchgeschaltete Switched Fabric, z. B. Myrinet, ein Bus-Backplane, z. B. VME, oder ein WAN, z. B. SONET. Das interne Netzwerkmodul ist keine Elementklasse.
  • Ausführungsform mit einer geographischen Verteilung von Elementen:
  • In einer Ausführungsform des Verbund-BS ist zumindest ein Element an einem anderen Ort angeordnet als andere Elemente. Dies ist möglich, da es bei dem Verbund-BS nicht notwendig ist, dass die Elemente (oder Prozessoren) physisch nahe oder benachbart sind. Elemente müssen nicht in derselben Hülle, in demselben Raum oder nicht einmal auf demselben Kontinent angeordnet sein. Mit anderen Worten, die Elemente könnten getrennt und irgendwo angeordnet sein, solange sie miteinander über ein internes Netzwerk kommunizieren können. Zum Beispiel kann das interne Netzwerk anstatt mit einem VMEbus-Backplane mit einem WAN ausgeführt sein, das ein SONET-Übertragungssystem verwendet. (Andere Übertragungssysteme als SONET könnten ebenfalls verwendet werden.) Dies könnte z. B. nützlich sein, um einen oder mehrere Antwortsender an einem anderen Ort anzuordnen als den Rest des Verbund-BS. Z. B. könnte ein Antwortsender in Tokio angeordnet sein, um Daten nahe bei Clients in Japan anzuordnen und ein schnelles Bedienen von in Japan befindlichen Clients zu ermöglichen, während der Empfänger und der Verteiler an einem Hauptort in Seattle, Washington, beherbergt bleiben. Selbst obwohl die Daten entfernt von anderen Elementen des Verbund-BS angeordnet sein können, ist für diese Ausführungsform wie in weiteren Ausführungsformen nur eine Sitzung pro Client notwendig. Somit kann in dieser Ausführungsform ein Antwortsender nahe bei Clients angeordnet sein, ohne die Notwendigkeit, ganze Server zu replizieren, und ohne die unerwünschten Folgen der Replizierung von Servern wie z. B. eine Erzeugung von exzessivem Verkehr und die Schwierigkeit beim Nachverfolgen der Anzahl von Hits auf einer Seite.
  • In einer weiteren Implementierung dieser Ausführungsform mit geographisch verteilten Elementen können zahlreiche Antwortsender desselben Verbund-BS an verschiedenen Orten auf der ganzen Welt angeordnet sein. Zum Beispiel könnten ein oder mehrere Empfänger und Verteiler und vorzugsweise weitere Elemente in einer Haupteinrichtung z. B. in Seattle, Washington, beherbergt sein, während ein oder mehrere Antwortsender z. B. in New York, London, Berlin, Hongkong und Tokio angeordnet ist/sind. Es wäre möglich, eine große Anzahl von Antwortsendern, z. B. Hunderte (oder mehr), die alle Elemente eines einzigen Verbund-BS sind, an verschiedenen Orten auf der ganzen Welt anzuordnen. Antwortsender könnten auch an Satelliten angeordnet sein.
  • 5 veranschaulicht einen Server, der eine Ausführungsform mit geographisch verteilten Elementen implementiert, und ein SONET-Übertragungssystem für das interne Netzwerk 510 verwendet, in dem ein Antwortsender 515 in New York angeordnet ist, zwei Antwortsender 520, 525 in Tokio angeordnet sind und in dem ein Antwortsender 530 und der Rest der Elemente 535 in Seattle angeordnet sind. Das Anordnen eines Antwortsenders in Seattle ist nicht erforderlich.
  • In den Ausführungsformen, in denen Elemente geographisch verteilt sind, kann jedes der Elemente entfernt von jedem der anderen Elemente ange ordnet sein, solange die Elemente in der Lage sind, miteinander über ein internes Netzwerk zu kommunizieren. Somit ist diese Ausführungsform nicht darauf begrenzt, nur Antwortsender von anderen Elementen entfernt anzuordnen. Z. B. könnte/n ein Empfänger oder ein Empfänger und ein Antwortsender von dem Rest der Elemente eines Verbund-BS entfernt angeordnet sein. Die Ausführungsform mit einer geographischen Verteilung ist besonders interessant für Internetanwendungen, die vorzugsweise mit einer Thunder-BS-Ausführungsform des Verbund-BS ausgeführt sind.
  • – Ausführungsform mit einer direkten Internet-Backboneverbindung:
  • Ein Server 605 gemäß einer weiteren Ausführungsform der Erfindung ist in 6 veranschaulicht. In dieser Ausführungsform sind ein oder mehrere Empfänger 610 und Antwortsender 615 direkt mit dem Internet-Backbone 620 (dem externen Netzwerk) gekoppelt. Dies reduziert die Anzahl von Hops und erhöht dadurch die Geschwindigkeit.
  • – Ausführungsform mit einer direkten Internet-Backboneverbindung und einem entfernten Datenspeicher:
  • In einer weiteren in 7 veranschaulichten Ausführungsform sind ein oder mehrere Empfänger und Antwortsender direkt mit dem Internet-Backbone 710 (externes Netzwerk) gekoppelt, wie in der vorhergehenden Ausführungsform. In dieser Ausführungsform ist ein Verteiler 720 mit einem Verteiler 725 über eine sichere Privatverbindung 730 gekoppelt. Der Verteiler 725 ist mit einem oder mehreren Decoder/n 735 (der/die sowohl verschlüsselt/verschlüsseln und decodiert/decodieren), der/die eine SSL (Secure Sockets Layer) implementiert/implementieren, und mit einem oder mehreren Antwortsender/n 740 gekoppelt. Die Antwortsender 740 sind mit dem externen Netzwerk gekoppelt. Die Antwortsender 740 sind auch mit den Decodern 735 gekoppelt. Der Verteiler 725, die Decoder 735 und die Antwortsender 740 sind an einem sicheren Ort (der typischerweise geographisch entfernt von dem Empfänger 745, dem Verteiler 720 und den Antwortsendern 750 ist) angeordnet, z. B. in einer Bank oder einem Unternehmen, die/das die Kontrolle der Daten auf den Antwortsendern 740 bewahren möchte. Diese Ausführungsform könnte z. B. von einem/einer Unternehmen oder Bank verwendet werden, das/die wünscht, Daten über das Internet verfügbar zu machen und dabei den Datenspeicher unter der Kontrolle des Unternehmens oder der Bank zu belassen und dabei eine extrem hohe Geschwindigkeit für den Empfänger und die Antwortsender zu halten, der/die direkt mit dem Backbone gekoppelt ist/sind. In dieser Ausführungsform sendet ein Client eine verschlüsselte Nachricht an den Empfänger 745, die von dem Empfänger zu dem Verteiler 720 übertragen wird, und die dann von dem Verteiler 720 über die Privatverbindung 730 zu dem Verteiler 725 gesendet wird. Der Verteiler 725 sendet dann die Nachricht an einen der Decoder 735, der die Nachricht decodiert und die decodierte Nachricht an den Verteiler 725 zurückleitet. Der Verteiler 725 sendet dann eine Nachricht, die den Ort der angefragten Daten identifiziert, an einen der Antwortsender 740, der die Daten zu einem der Decoder 735 sendet, wo die Daten verschlüsselt und dann zu einem der Antwortsender 740 zurückgeleitet werden, der dann die verschlüsselten Daten über das Internet an einen Client sendet.
  • – Asymmetrische und symmetrische Ausführungsformen:
  • Einige Ausführungsformen der Erfindung können als asymmetrisch bezeichnet werden. Eine Webserverimplementierung der Erfindung ist ein Beispiel einer Ausführungsform, die typischerweise asymmetrisch sein wird. Diese Ausführungsformen werden als asymmetrisch bezeichnet, da die Menge von Daten, die von dem Server empfangen wird, üblicherweise viel kleiner ist als die Menge von Daten, die von dem Server ausgegeben wird. (Es ist jedoch möglich, dass der Datenfluss in der anderen Richtung asymmetrisch sein könnte, wobei die Menge von Daten, die von dem Server empfangen wird, größer ist als die Menge von Daten, die von dem Server ausgegeben wird, z. B. in einem Mailserver, der eine Menge von Mails empfängt, die nicht abgerufen werden.) Andere Ausführungsformen der Erfindung können als symmetrisch bezeichnet werden. Ein Mailserver (von dem die Mail regelmäßig abgerufen wird) ist ein Beispiel einer Ausführungsform, die typischerweise symmetrisch sein wird. Ein weiteres Beispiel einer Ausführungsform, die typischerweise symmetrisch ist, ist eine Telefonausführungsform, worin IP-Pakete Sprachdaten tragen. Diese Ausführungsformen werden als symmetrisch bezeichnet, da die Menge von Daten, die von dem Server empfangen wird, grob ähnlich der Menge von Daten ist, die von dem Server ausgegeben wird. Es ist möglich, dass eine Implementierung der Erfindung sowohl asymmetrische als auch symmetrische Eigenschaften aufweist. Zum Beispiel könnte ein Server als typischer Internet-Datenserver funktionieren und könnte auch als ein Mailserver und/oder Sprachdatenserver funktionieren.
  • – Thunder Operating SystemTM (ThunderOSTM = Thunder-Betriebssystem)
  • (Thunder Operating SystemTM und ThunderOSTM sind Handelsmarken von Thunder River Technologies Inc.)
  • Das Thunder-BS, das eine von vielen möglichen Ausführungsformen des Verbund-BS ist, ist eine spezifische Instanz des Verbund-BS, die für Internetserver optimiert ist und die die bevorzugte Ausführungsform des Verbund-BS ist. Thunder-OS ist eine verteilte skalierbare TCP/IP-Implementierung des Verbund-BS. In der Thunder-BS-Ausführungsform der Verbund-BS (das verschiedene Ausführungsformen von Thunder-BS umfassen kann), laufen auf den Elementen Betriebssysteme, die zusam men Thunder-BS bilden. Wie in dem Verbund-BS allgemein, läuft auf dem Thunder-BS jede Elementklasse auf einem einzigartigen Betriebssystem. Thunder-BS umfasst eine verteilte TCP/IP-Zustandsmaschine. Das Thunder-BS enthält eine TCP/IP- und Internetserversoftware, die hoch optimiert für das Internet ist. Vorzugsweise wird das Thunder-OS in der C++-Programmiersprache ausgeführt, was die Implementierung der Vererbungshierarchie des Betriebssystems der Elemente erleichtert.
  • Für eine erhöhte Geschwindigkeit ist das Thunder-OS derart ausgeführt, dass die Schlüssel-Internetdienste und Protokolle direkt als Teil des verteilten Betriebssystems implementiert sind. Diese Schlüssel-Internetsoftwaredienste und -protokolle umfassen:
    • – HTTP (Hyper Text Transfer Protocol);
    • – FTP (File Transfer Protocol);
    • – IMAP (Internet Messaging Access Protocol); und
    • – POP3 (Post Office Protocol 3).
  • Zusätzlich zu diesen Schlüssel-Internetsoftwarediensten und -protokollen sind vorzugsweise auch andere Netzwerkprotokolle auf niedrigerem Niveau, die typischerweise in Betriebssystemen zu finden sind, wie z. B. TCP/IP, DNS (Domain Name Server), ARP (Address Resolution Protocol), UDP (User Datagram Protocol) und ICMP (Internet Control Message Protocol) in dem Thunder-BS enthalten. Das Thunder-OS umfasst vorzugsweise auch WAP (Wireless Application Protocol), SSL (Secure Sockets Layer) und andere Dienste und Protokolle. Die Dienste und Protokolle sind auf eine verteilte Weise ausgeführt, unter Verwendung mehrerer Elementklassen, um die involvierte Verarbeitung zu verteilen. In Thunder-BS-Implementierungen laufen diese Dienste und Protokolle in Echtzeit in Bezug auf eingehende Netzwerkpakete ab. Das bedeutet, dass eingehende Pakete jeweils in einer begrenzten Zeitspanne verarbeitet werden, unabhängig von der Anzahl aktiver Verbindungen, die ein Server hält. Eine synchrone Nachrichtenübermittlung wird verwendet, um Echtzeit-Deadlines zu verstärken, und eine Echtzeit-TCP/IP-Zustandsmaschine ist mit Konstantzeitalgorithmen ausgeführt.
  • Eine illustrative Ausführungsform eines Thunder-BS 805, die in 8 veranschaulicht ist, umfasst: TCP/IP (Transmission Control Protocol/Internet Protocol), HTTP (Hyper Text Transfer Protocol), FTP (File Transfer Protocol), IMAP (Internet Messaging Access Protocol), DNS (Domain Name Service) etc.
  • Wie in 8 veranschaulicht, läuft in der Thunder-BS-Ausführungsform des Verbund-BS das Verbund-BS vorzugsweise auf einer Nicht-Echtzeit-Schicht auf bestimmten Prozessoren oder Elementen, um Werkzeuge zum Generieren eines dynamischen Inhalts wie z. B. Java, Python, PERL, FastCGI, CGI, Smalltalk, PHP, Erlang, C++ und andere zu unterstützen. Demzufolge können optionale Endbenutzeranwendungen, die für diese Sprachen oder Umgebungen geschrieben sind, auf der Nicht-Echtzeit-Schicht laufen. Thunder-BS-Elemente sind als singlethreaded Echtzeit-Prozesse ausgeführt, mit einer optionalen Unterstützung zum Verbinden mit dem Nicht-Echtzeit-System, das laufen darf, wenn der Echtzeit-Prozess inaktiv ist. Die Nicht-Echtzeit-Schicht kann ein Multitasking unterstützen, wobei mehrere Prozesse oder Threads ausgeführt werden. Vorzugsweise ist die Nicht-Echtzeit-Schicht ein Linux-Kern, obwohl andere als Nicht-Echtzeit-Systeme unterstützt werden könnten. Ein Betreiben der Linux-Schicht über dem Thunder-BS stellt sicher, dass bestehende Linux-Anwendungen laufen können „wie sie sind". Mit Thunder-BS-Verwaltungs-Internetdiensten in Echtzeit und Linux zur Bereitstellung standardbasierter offener Schnittstellen, stellt ein in dieser Ausführungs form des Verbund-BS implementierter Server eine starke Plattform für das Hosting großer dynamischer Webseiten bereit.
  • Ein dynamischer Inhalt kann in der Echtzeit-Schicht generiert werden, oder durch Anwendungen, die auf der Nicht-Echtzeit-Schicht laufen. Zum Beispiel ist für eine Nicht-Echtzeit-Schicht eine Java-Virtuell-Maschine für Java-Anwendungen vorgesehen, und ein Perl-Interpreter ist vorgesehen, um Anwendungen laufen zu lassen, die in Perl geschrieben sind. Diese Anwendungen erzeugen dynamische Daten in Ansprechen auf eine Anfrage, benötigen aber keine Einsicht dahingehend, wie diese Daten zurück an den anfragenden Client übermittelt werden.
  • 9A ist ein Blockdiagramm, das die Beziehungen zwischen den Elementen des Thunder-BS veranschaulicht. 9A umfasst interne Netzwerkmodule 902, ein Konfigurationselement 904, ein Protoelement 906, ein bootfähiges Element 908, ein dauerhaftes Speicherungselement 910, ein Wächterelement 912, ein Verteilerelement 914, ein externes Netzwerkelement 916, ein Codierer-/Decoderelement 918 (auch als ein Decoderelement bezeichnet), einen Routing-Manager 920, ein Empfängerelement 922, ein statisches Antwortsenderelement 924, ein dynamisches Antwortsenderelement 926 und ein Firewall-Managerelement 928. Das Thunder-BS ist implementiert, um sprachcodierend neutral zu sein, wie in den Konfigurationselement- 904 und Protoelement- 906 -kästchen in 9A angezeigt, was bedeutet, dass eine breite Vielfalt von Sprachen zusätzlich zu Englisch unterstützt wird. 9B ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem bootfähigen Element 908 im Thunder-BS veranschaulicht. 9C ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem Empfängerelement 922 im Thunder-BS veranschaulicht. 9D ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem Verteilerelement 914 im Thunder-BS veran schaulicht. 9E ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem statischen Antwortsenderelement 924 im Thunder-BS veranschaulicht. 9F ist ein Blockdiagramm, das Funktionen und Wechselwirkungen in einem dynamischen Antwortsenderelement 926 im einem Thunder-BS veranschaulicht. Im Thunder-BS sind die Antwortsenderelemente entweder statische Antwortsenderelemente oder dynamische Antwortsenderelemente.
  • TCP wie im Thunder-BS implementiert (als ThunderTCP bezeichnet) nutzt die verteilte Natur des Verbund-BS, um die Bedienung von TCP-Verbindungen zu verbessern. Die TCP-Spezifikation (Internet Requests for Comments (RFC) 793, hiermit durch Verweis aufgenommen) beschreibt eine Zustandsmaschine mit elf Zuständen. Jedoch sind nur wenige dieser Zustände in der tatsächlichen Datenübertragung involviert. Die Natur dieser Zustände bewirkt, dass das TCP sich selbst an eine verteilte Implementierung wie z. B. im Thunder-BS verleiht. Ein mit einem Thunder-BS implementierter Server ist als eine verteilte Zustandsmaschine ausgeführt, die Verbindungsobjekte verwendet, um die erforderliche Zustandinformation zu halten.
  • Die Verteilung der Implementierung von TCP im Thunder-BS ist unter Bezugnahme auf 10 wie folgt beschrieben. Die Herstellung einer Verbindung („Drei-Wege-Handshake" des TCP) besitzt eine minimale Abhängigkeit von dem Dienst und erfordert nur die Kenntnis darüber, welche Dienste gegebenen Portnummern zuzuordnen sind. Dieser Teil der TCP-Zustandsmaschine wird effizient zu einem separaten Element verteilt, welches das Empfängerelement 1005 ist. Dieses Empfängerelement ist in der Lage, eine große Anzahl von Verbindungen zu verwalten, und wird im Allgemeinen nicht mit einer dienstspezifischen Verarbeitung belastet.
  • Sobald eine Verbindung hergestellt ist, wird ein Verbindungsobjekt in einem Verteilerelement 1010 erzeugt und dieses Objekt wird dem aktuellen TCP-Port zugeordnet. Der Verteiler (1) verwaltet verschiedene Aspekte des Datenübertragungsabschnittes der TCP-Spezifikation wie z. B. Anmerkungen und erneute Übertragungen und (2) ruft den geeigneten Dienst auf. Die Dienstfunktionalität kann in dem Verteilerelement und/oder in einem unterschiedlichen Element (oder Elementen) vorhanden sein und wird typischerweise sowohl auf das Verteilerelement als auch zumindest eine andere Elementklasse verteilt. Typischerweise werden Datengenerierungs- und -übertragungsaspekte des Dienstes in einem Antwortsenderelement ausgeführt, wodurch das Verteilerelement von einem Großteil der Verarbeitung befreit wird.
  • Das Ende der Kette ist das Antwortsenderelement 1015. Der Antwortsender benötigt nur eine minimale Kommunikation mit dem Verteiler. Diese Kommunikation erfolgt, damit der Antwortsender weiß, welche Daten zu übertragen sind, wann die Daten zu übertragen sind und wie viele der Daten zu übertragen sind (oder im Fall von Zeitüberschreitungen neu zu übertragen sind). Der Antwortsender muss keine dauerhafte Zustandsinformation zwischen Aufrufen halten, da der Verteiler bei jedem Aufruf die notwendige Verbindungszustandsinformation zu dem Antwortsender liefert. Mehrere Antwortsenderelemente können einem gegebenen Verteiler zugeordnet sein, wodurch zugelassen wird, dass mehrere Verbindungen parallel bedient werden. Zusätzlich können mehrere Verteiler einem gegebenen Empfängerelement zugeordnet sein.
  • Beim Thunder-BS können die Datenstrukturen, die Client- und Server-IP-Adressen und TCP-Ports einem Verbindungsobjekt und einem gegebenen Dienst zuordnen, in einer konstanten Zeitspanne durchsucht werden. Das heißt, die Zeit, um das Nachschlagen durchzuführen, ist unabhängig von der Anzahl gerade aktiver Verbindungen oder der Anzahl der Dienste. Das Nachschlagen wird durchgeführt, um die Aufzeichnung zu suchen, die die aktuelle Verbindungszustandsinformation enthält, die der durch die Client- und Server-IP-Adressen und TCP-Portnummern identifizierten Verbindung zugeordnet ist. Auch Host-Nachschlagevorgänge werden in einer konstanten Zeitspanne bewerkstelligt. Dieser Ansatz beseitigt viele der Einschränkungen herkömmlicher TCP-Implementierungen. Wo immer es möglich ist, ist der verfügbare Speicher die einzige Einschränkung für die Anzahl der unterstützten aktiven Verbindungen.
  • Serversoftware nach dem Stand der Technik bearbeitet oft mehrere Clients gleichzeitig, indem sie eine separate Instanz des Serverprozesses aufruft, um jede Verbindung zu bearbeiten. Demzufolge kann eine große Anzahl von Clients, die relativ langsame Netzwerkschnittstellen verwenden, einen großen Teil von Systemressourcen benötigen, selbst wenn die tatsächliche Bedienung der Clients auf Grund der niedrigen Bandbreite von deren Verbindung trivial ist. Andererseits verwendet das Thunder-BS zum Bearbeiten eingehender Pakete einen singlethreaded ereignisgesteuerten Ansatz, in Kombination mit einer verteilten parallelen Ausführung, um ausgehende Daten zu generieren und zu übertragen. Dieser Ansatz erlaubt, dass das System schnell genug arbeitet, um auf Ereignisse (eingehende Netzwerkpakete) in Echtzeit zu antworten. Des Weiteren erlaubt das Verteilen der Datengenerierung und -übertragung über mehrere Elemente eine Skalierung des Systems. Dieser Ansatz erlaubt, dass ein einzelner Server eine viel größere Anzahl von Clients verwaltet, als es sonst möglich wäre.
  • Zustandsinformation
  • Um Anfragen von Clients zu bedienen, muss eine Zustandsinformation für jede Verbindung gehalten werden. Im Thunder-BS wird diese Zustandsin formation von dem Empfänger und/oder Verteiler gehalten. Unterschiedliche Elemente können Teile der Zustandsinformation zu unterschiedlichen Zeiten halten. Jedes Element hält nur einen Teil der gesamten Zustandsinformation, und der gesamte Zustand ist über eine Vielzahl von Elementen gespeichert. TCP-Ports können dadurch gekennzeichnet sein, dass sie entweder (1) nach einer Kommunikation von einem Client horchen oder (2) eine hergestellte Verbindung aufweisen. Das nicht Vorhandensein einer Verbindung wird als geschlossener Zustand (nicht wirklich ein Zustand) bezeichnet, der der Eintrittspunkt in die Zustandmaschine ist. 11 veranschaulicht eine Empfänger-TCP-Verbindungszustandsmaschine 1105 und 12 veranschaulicht eine Verteiler-TCP-Verbindungszustandsmaschine 1205 für das Thunder-BS. Diese Zustandsmaschinen sind in den folgenden Abschnitten beschrieben.
  • Empfänger-TCP-Verbindungszustandsmaschine
  • Die Zustandsmaschine 1105 des Empfängers in der Thunder-BS-Ausführungsform ist in 11 veranschaulicht. Wenn von einem Client eine neue Verbindung initiiert wird, sendet der Client ein TCP-Paket (Paket 1) mit dem SYN-Flag-Satz in dem TCP-Header. Wenn der Empfänger solch ein Paket mit einer Ziel-IP-Adresse und einem TCP-Port, auf das zu hören der Empfänger konfiguriert wurde, empfängt und der Empfänger für diese Verbindung (wie durch die Source- und Ziel-IP-Adresse wie auch durch die TCP-Portnummern identifiziert) noch keine Datenstruktur zugewiesen hat, erzeugt der Empfänger eine Verbindung, indem er einer neuen Datenstruktur zuweist, die Zustandsinformation für die Verbindung zu halten. Die Verbindungs-Trie-Datenstruktur wird dann aktualisiert, um diese neu zugewiesene Struktur zu referenzieren, so dass, wenn ein zukünftiges Paket mit den selben IP-Adressen und TCP-Ports empfangen wird, die bestehende Datenstruktur gefunden wird. Die neu zugewie sene Datenstruktur wird initialisiert, um die Verbindung in dem SYN_RCVD-Zustand anzuzeigen. Der Empfänger sendet dann ein Paket (Paket 2) zurück an den Client, das das empfangene Paket bestätigt. Dieses Paket besitzt auch sowohl den SYN-Flag-Satz als auch das ACK-Flag. Wenn der Empfänger danach ein Paket (Paket 3) empfängt, welches das Paket 2 bestätigt, geht er zu dem DISPATCHER_RELAY(Weitergabe-an-Verteiler)-Zustand über und sendet eine Nachricht an den Verteiler mit der Information, die für den Verteiler notwendig ist, um eine neue Verbindungszustandsaufzeichnung zu erzeugen. Dies beendet den als „Drei-Wege-Handshake" des TCP bekannten Austausch.
  • Während eine Verbindung in dem DISPATCHER_RELAY-Zustand ist, werden die relevanten Daten von jeglichen von dem Empfänger empfangenen Paketen einfach an den Verteiler weitergeleitet. Der Verteiler informiert den Empfänger darüber, ob die Verbindung in dem DISPATCHER_RELAY-Zustand verbleiben soll, ob sie zu dem FIN_WAIT2-Zustand übergehen soll, oder ob sie geschlossen werden soll. Der Verteiler informiert den Empfänger auch darüber, ob irgendwelche Endbestätigungen oder Resets an den Client zurückgesendet werden sollen und ob der TCP-Port als in dem TIME_WAIT-Zustand befindlich gekennzeichnet werden soll. Für Verbindungen in dem FIN_WAIT2-Zustand wird, wenn das FIN-Flag in dem eingehenden Paket gesetzt ist, die Verbindung geschlossen, und der Port wird als in dem TIME_WAIT-Zustand befindlich gekennzeichnet. Es ist zu beachten, dass in herkömmlichen TCP-Implmentierungen der TIME_WAIT-Zustand ein tatsächlicher Zustand der Zustandsmaschine ist. In der ThunderTCP-Implementierung wird TIME_WAIT in einer Datenstruktur angezeigt, die sich außerhalb des Umfangs der Zustandsmaschine befindet und die überprüft wird, bevor die Zustandsmaschine aufgerufen wird. Wenn eine Verbindung in dem Empfänger geschlossen wird, wird die Datenstruktur, die für die Verbindungszustandsinformation zugewie sen wurde, freigegeben. Die Zustände SYN_RCVD und FIN_WAIT2 entsprechen den entsprechenden Zuständen des in der TCP-Spezifikation (RFC 793) enthaltenen Zustandsdiagrammes. Der Zustand DISPATCHER_RELAY zeigt an, dass die Verbindung sich in einem der Zustände befindet, die von dem Verteiler bearbeitet werden. Es ist zu beachten, dass die gesamte Datenübertragung in diesem Zustand abläuft, und auch, dass der Empfänger in diesem Zustand nur sehr wenig Verarbeitung für Verbindungen leisten muss. Für Serverdienste wie z. B. HTTP, die keine Verbindungen zu dem Client initiieren, wird der zusätzliche Zustand SYN_SENT nicht verwendet.
  • Verteiler-TCP-Verbindungszustandsmaschine
  • Die Zustandsmaschine 1205 des Verteilers in der Thunder-BS-Ausführungsform ist in 12 veranschaulicht. Wenn der Verteiler eine neue Verbindung von dem Empfänger empfängt, weist er einer neuen Datenstruktur zu, die Verbindungszustandsinformation zu halten, und sendet eine Identifizierung für die zugewiesene Struktur an den Empfänger zurück. Diese Identifizierung wird von dem Empfänger genutzt, um zukünftige Nachrichten dieser Verbindung zuzuordnen. Der Zustand der Verbindung wird auf ESTABLISHED gesetzt und die Verarbeitung fährt fort, wie für Verbindungen, die sich zu Beginn in dem ESTABLISHED-Zustand befinden.
  • Für Verbindungen in dem ESTABLISHED- oder CLOSE_WAIT-Zustand bestimmt der dienstspezifische Code, welcher Antwortsender benutzt wird, um von dem Client empfangene Daten zu bestätigen und Daten zu dem Client zu senden. Der dienstspezifische Code ist dafür verantwortlich, einen Antwortsender anzuweisen, die Antwortdaten zusammen mit der notwendigen TCP-Bestätigungsinformation zurück zu dem Client zu senden.
  • Wenn die Antwortdaten nicht sofort verfügbar sind, wird, falls erforderlich, nur die Bestätigung gesendet. Die Menge von Daten, die zu dem Client gesendet werden kann, ist auch durch die TCP-Bestätigungs-Folgenummer und die Fenstergröße, die von dem Client in jedem TCP-Paket gesendet werden, begrenzt.
  • Für Verbindungen in dem ESTABLISHED-, FIN_WAIT_1- oder FIN_WAIT_2-Zustand werden jegliche von dem Client empfangene Daten zu dem der Verbindung zugeordneten Dienst übergeben. (Die dienstspezifische Verarbeitung kann in dem Verteiler selbst erfolgen oder kann über andere Elemente verteilt werden.)
  • Für Verbindungen in dem ESTABLISHED-Zustand wird, wenn der Client sein Ende der Verbindung geschlossen hat, der Verbindungszustand auf CLOSE_WAIT gesetzt. Wenn der Dienst das Ende der Verbindung des Servers geschlossen hat, der Zustand auf FIN_WAIT_1 gesetzt.
  • Für Verbindungen in dem CLOSE_WAIT-Zustand wird, wenn der Dienst das Ende der Verbindung des Servers geschlossen hat, wird der Zustand auf LAST_ACK gesetzt.
  • Für Verbindungen in dem LAST_ACK-Zustand wird, wenn der Client alle Daten des Servers bestätigt hat, die Zuordnung der Verbindungszustandsdatenstruktur aufgehoben und der Empfänger wird angewiesen, die Verbindung zu schließen.
  • Für Verbindungen in dem FIN_WAIT_1-Zustand wird, wenn der Client sein Ende der Verbindung geschlossen hat, aber nicht alle Daten des Servers bestätigt hat, der Zustand auf CLOSING gesetzt. Wenn der Client sein Ende der Verbindung geschlossen hat und alle Daten des Servers bestätigt hat, wird die Zuweisung der Verbindungszustandsdatenstruktur aufgehoben und der Empfänger wird angewiesen, eine Endbestätigung zu senden, und die Verbindung als in TIME_WAIT befindlich zu kennzeichnen. Wenn der Client sein Ende der Verbindung nicht geschlossen hat und alle Daten des Servers bestätigt hat, und der Dienst nach dem Schließen des Endes der Verbindung des Servers weitere Clientdaten annehmen wird, wird der Zustand auf FIN_WAIT_2 gesetzt. Wenn der Client sein Ende der Verbindung nicht geschlossen hat und alle Daten des Servers bestätigt hat und der Dienst nach dem Schließen des Endes der Verbindung des Servers keine weiteren Client-Daten annehmen wird, wird die Zuweisung der Verbindungszustandsdatenstruktur aufgehoben und der Empfänger wird angewiesen, seinen Verbindungszustand auf FIN_WAIT_2 zu setzen.
  • Für Verbindungen in dem FIN_WAIT_2-Zustand wird, wenn der Client sein Ende der Verbindung geschlossen hat, die Zuweisung der Verbindungszustandsdatenstruktur aufgehoben und der Empfänger wird angewiesen, eine Endbestätigung zu senden und die Verbindung als in TIME_WAIT befindlich zu kennzeichnen.
  • Für Verbindungen in dem CLOSING-Zustand wird, wenn er Client alle Daten des Servers bestätigt hat, die Zuweisung der Verbindungszustandsdatenstruktur aufgehoben und der Empfänger wird angewiesen, die Verbindung in TIME_WAIT befindlich zu kennzeichnen.
  • In Übereinstimmung mit der TCP-Spezifikation wird, wenn Daten übertragen werden, ein Zeitmesser gestartet. Wenn der Zeitmesser abläuft, bevor die Daten durch den Client bestätigt werden, wird der entsprechende Antwortsender benachrichtigt, die notwendigen Daten zu übertragen. Bestätigungsauszeiten und TCP-Reset-Nachrichten können auch bewirken, dass eine Verbindung geschlossen wird.
  • Verteilte TCP/IP-Implementierung im Thunder-BS
  • Die Thunder-BS-Ausführungsform einer verteilten TCP/IP-Implementierung erlaubt, dass mehrere Elemente und ihre zugeordneten externen Netzwerkschnittstellen kollektiv eine einzelne IP-Adresse bedienen. Im Speziellen ist die TCP/IP-Zustandsmaschine über einen Empfänger und einen oder mehrere Antwortsender (und vorzugsweise einen oder mehrere Verteiler) verteilt, so dass eine IP-Adresse von einem Empfänger und einem oder mehreren Antwortsender/n (und vorzugsweise einem oder mehreren Verteiler/n) bedient wird. Das Vorhandensein mehrerer Antwortsender mit ihren zugeordneten externen Netzwerkschnittstellen erlaubt, dass die Thunder-BS-Ausführungsform einer verteilten TCP/IP-Implementierung Daten mit Geschwindigkeiten überträgt, die das Leistungsvermögen einer einzelnen externen Netzwerkschnittstelle übersteigen würden. Ein Hinzufügen zusätzlicher Antwortsender zu einem Server erhöht die Kapazität des Servers, Daten für den/die einer spezifischen IP-Adresse zugeordneten Dienst/e zu übertragen.
  • Alternative Ausführungsform einer verteilten TCP/IP-Implementierung Eine weitere Ausführungsform einer verteilten TCP/IP-Implementierung, veranschaulicht in 13, benötigt das Verbund-BS nicht, kann jedoch in einem einzelnen Computer 1302 mit einer oder mehreren CPU/s 1305 implementiert sein, mit einer Vielzahl von externen Netzwerkschnittstellen 1310a bis 1310e und mit oder ohne einem Betriebssystem. In dieser Ausführungsform sind ein oder mehrere Empfänger 1315, ein oder mehrere Verteiler 1320 und ein oder mehrere Antwortsender 1325 als Prozesse oder Threads, die auf dem Computer ablaufen, implementiert. Da diese Prozesse oder Threads auf einem einzelnen Computer ablaufen, können sie untereinander kommunizieren, ohne ein internes Netzwerk zu benötigen. Diese Kommunikation wird erreicht durch einen geteilten Speicher, Nachrichten-Warteschlangen oder ein anderes Interprozess- oder Interthread-Kommunikationsverfahren. Die Empfänger-, Verteiler- und Antwortsenderprozesse oder -threads in dieser Ausführungsform arbeiten ähnlich den in der Thunder-BS-Ausführungsform einer verteilten TCP/IP-Implementierung beschriebenen Empfänger-, Verteiler- und Anwortsenderelementen. Somit sind Verfahren zum Initialisieren eines Servers und Verfahren zum Antworten auf Anfragen in dieser alternativen Ausführungsform analog den Verfahren in der Thunder-BS-Ausführungsform implementiert. Im Speziellen wird die Bedienung einer einzelnen IP-Adresse über einen Empfängerprozess oder -thread, einen oder mehrere Verteiler oder -threads und einen oder mehrere Antwortsenderprozesse oder -threads verteilt. Eine dedizierte Netzwerkschnittstelle ist mit dem Empfängerprozess oder -thread gekoppelt und eine oder mehrere dedizierte externe Netzwerkschnittstelle/n ist/sind mit jedem Antwortsender gekoppelt. Kollektiv stellen diese Prozesse oder Threads mit ihren dedizierten externen Netzwerkschnittstellen Dienste für eine oder mehrere IP-Adresse/n bereit. Die Bedienung einer einzelnen IP-Adresse wird nicht von einer einzelnen externen Netzwerkschnittstelle verarbeitet, sondern ist auf mehrere externe Netzwerkschnittstellen verteilt. Ein einzelner Empfänger kann eine oder mehrere IP-Adresse/n bedienen. Vorzugsweise ist ein Empfänger mit einer einzelnen externen Netzwerkschnittstelle gekoppelt, obwohl mehrere externe Netzwerkschnittstellen mit einem einzelnen Empfänger gekoppelt sein können.
  • Eine Variation der vorhergehenden Ausführungsform einer verteilten TCP/IP-Implementierung benötigt ebenfalls nicht das Verbund-BS, kann aber auf mehreren Computern implementiert werden. Jeder Computer weist eine oder mehrere CPU/s, eine oder mehrere interne Netzwerk schnittstelle/n und eine oder mehrere externe Netzwerkschnittstelle/n auf. Jeder Computer kann mit oder ohne ein/em Betriebssystem betrieben werden. In jedem Computer sind die interne Netzwerkschnittstelle und die externe Netzwerkschnittstelle vorzugsweise nicht eine geteilte einzelne Schnittstelle, sondern sind vorzugsweise separate unterschiedliche Schnittstellen. In dieser Ausführungsform sind ein oder mehrere Empfänger, ein oder mehrere Verteiler und ein oder mehrere Antwortsender als Prozesse oder Threads, die auf jedem Computer ablaufen, implementiert. Vorzugsweise läuft jeder dieser Prozesse oder Threads auf einem dedizierten Computer ab. Vorzugsweise kommunizieren diese Prozesse oder Threads untereinander mit Hilfe eines internen Netzwerkes. Das interne Netzwerk kann ein beliebiges drahtgebundes, drahtloses, optisches oder anderes Netzwerksystem sein, das Computer miteinander verbinden kann, z. B. Ethernet, Gigabit Ethernet, Token-Ring, Fibre Channel oder Infini-Band. Die Empfänger- Verteiler- und Antwortsenderprozesse oder -threads in dieser Ausführungsform arbeiten ähnlich den in der hierin erläuterten Thunder-BS-Ausführungsform einer verteilten TCP/IP-Implementierung beschriebenen Empfänger-, Verteiler- und Antwortsenderelementen. Somit sind Verfahren zum Initialisieren eines Servers und Verfahren zum Antworten auf Anfragen in dieser alternativen Ausführungsform analog den Verfahren in der Thunder-BS-Ausführungsform implementiert. Im Speziellen wird die Bedienung einer einzelnen IP-Adresse über einen Empfängerprozess- oder -thread, einen oder mehrere Verteilerprozesse oder -threads und einen oder mehrere Antwortsenderprozesse oder -threads verteilt. Vorzugsweise ist eine dedizierte Netzwerkschnittstelle mit dem Empfängerprozess oder -thread gekoppelt und eine oder mehrere dedizierte externe Netzwerkschnittstelle/n ist/sind mit jedem Antwortsender gekoppelt. Kollektiv stellen diese Prozesse oder Threads mit ihren (vorzugsweise) dedizierten externen Netzwerkschnittstellen Dienste für eine oder mehrere IP-Adresse/n bereit. Die Bedienung einer einzelnen IP-Adresse wird nicht von einem einzelnen Computer oder einer einzelnen externen Netzwerkschnittstelle verarbeitet, sondern ist auf mehrere Computer und mehrere externe Netzwerkschnittstellen verteilt. Ein einzelner Empfänger kann eine oder mehrere IP-Adresse/n bedienen. Vorzugsweise ist ein Empfänger mit einer einzigen externen Netzwerkschnittstelle gekoppelt, obwohl mehrere externe Netzwerkschnittstellen mit einem einzelnen Empfänger gekoppelt sein können.
  • Alternative verteilte TCP/IP-Ausführungsformen müssen keinen Verteilerprozess oder -thread umfassen, sondern können die Verteilerfunktionalität in den Empfänger- und/oder Antwortsenderprozessen oder -threads beinhalten.
  • Verfahren der Konfiguration und des Betriebes
  • Vor Verarbeitungsanfragen von Clients wird der Server durch den Konfigurator konfiguriert. Obwohl eine Konfiguration durch den Konfigurator automatisch sein könnte, wird ein Konfiguration typischerweise durch den Konfigurator in Ansprechen auf eine Bedienereingabe bewerkstelligt. Der Bediener kann die Konfigurationsdaten entweder manuell eingeben oder eine zuvor gespeicherte Konfiguration laden. Dann initiiert der Bediener das Laden der Konfiguration auf den Server. Die ausgewählte Konfiguration identifiziert, welche BS-Element-BS-Instanz auf jede teilnehmende Element-Hardwareeinheit geladen wird.
  • Ein typisches Beispiel für ein Konfigurieren eines Servers ist das folgende:
    ein Empfänger, ein Verteiler und eine Anzahl von Antwortsendern werden vorbestimmt. In einigen alternativen Ausführungsformen werden keine Verteiler vorbestimmt, und die Verteilerfunktionalität ist in einem Empfänger und/oder einem Antwortsender implementiert. In diesen alterna tiven Ausführungsformen werden Aktivitäten, die von einem Verteiler durchgeführt worden wären, von einem oder mehreren Empfänger/n und/oder einem oder mehreren Antwortsender/n durchgeführt. Nachdem die Elemente vorbestimmt sind, wird der geeignete ausführbare Code sodann auf diese Element-Hardwareeinheiten heruntergeladen und wird ausgeführt. Der Empfänger wird dann angewiesen, welche IP-Adressen und TCP-Portnummern Verbindungen daran annehmen sollen und welche Verteiler diesen Verbindungen zugeordnet werden sollen. Der Verteiler wird dann angewiesen, welche Dienste er jedem dieser IP-Adressen-/TCP-Port-Paare zuordnen soll. Für den HTTP-Dienst wird der Verteiler auch angewiesen, welche Hostnamen Anfragen annehmen sollen. Die Antwortdaten werden dann auf die Antwortsender geladen. Dies können statische Rohdaten und/oder ein ausführbarer Code sein, der laufen gelassen werden soll, um dynamische Daten zu generieren. Während jede Antwort geladen wird, wird der Verteiler über ihren Ort informiert. Sobald der Verteiler über den Ort der Antwort informiert ist, aktualisiert er seine Datenstruktur, die zum Nachschlagen von Antworten verwendet wird, so dass der Server bereit ist, diese Antwort das nächste Mal zu bedienen, wenn ein Client darum anfragt. 14A ist ein Flussdiagramm zur Veranschaulichung eines Verfahrens zum Initialisieren eines Servers gemäß einer illustrativen Ausführungsform der Erfindung. 14B ist ein Flussdiagramm zur Veranschaulichung eines Verfahrens zum Initialisieren eines Servers gemäß einer weiteren illustrativen Ausführungsform der Erfindung.
  • 15 veranschaulicht einen Datenfluss zwischen dem Client 1505, dem Empfänger 1510, dem Verteiler 1515 und dem Antwortsender 1520 zur Bedienung einer Anfrage von dem Client in der Thunder-BS-Ausführungsform. Eine typische Transaktion zwischen einem Client und einem Server geht wie folgt vor sich: Ein Client initiiert eine Anfrage, was darin resultiert, dass eine Verbindung hergestellt wird, indem eine Anzahl von TCP-Paketen zwischen dem Client und einem Empfängerelement des Servers ausgetauscht wird. Während jedes Paket empfangen wird, muss der Empfänger die in dem Paket enthaltenen IP-Adressen und TCP-Ports nachschlagen und bestimmen, ob sie einer bestehenden Verbindung entsprechen. Vorzugsweise wird dieses Nachschlagen unter Verwendung der „Trie"-Datenstruktur ausgeführt, um für eine deterministische Ausführungszeit zu sorgen, unabhängig davon, wie viele aktive Verbindungen der Empfänger hält.
  • Wenn die Verbindung erfolgreich den „hergestellten"(established)-Zustand erreicht hat, so kann der Client dann Daten senden, die die tatsächliche Anfrageinformation enthalten. Der Empfänger zieht Header aus den empfangenen Daten und zieht auch die Nutzinformation heraus und übergibt die Nutzinformation „wie sie ist" an den Verteiler. Für eine HTTP-Anfrage umfassen die Daten (Nutzinformation) den HTTP-Header (der z. B. einen Befehl umfasst, Daten an eine spezifizierte Internetadresse zu bekommen) und falls vorhanden, die HTTP-Nutzinformationsdaten. Wenn der Empfänger das Paket mit diesen Daten empfängt, sendet er die Daten an den Verteiler. Wenn der Verteiler die Anfragedaten für eine neue Verbindung empfängt, weist er eine Datenstruktur zu, die den Zustand der Verbindung hält, und sendet eine Identifizierung an den Empfänger zurück, die es dem Empfänger erlaubt, zukünftige Daten dieser Verbindung an den Verteiler zuzuordnen. Der Empfänger speichert diese Identifizierung in seiner Datenstruktur, die dieser Verbindung zugeordnet ist.
  • Der Verteiler verarbeitet dann die Anfragedaten, um zu bestimmen, welche Antwort gesendet werden soll. Vorzugsweise verwendet ein Teil dieser Verarbeitung die „Trie"-Datenstruktur, um die richtige Antwort wirksam anzuordnen. Auf Basis der Datenaufzeichnung, die aus dieser Suche resul tiert, sendet der Verteiler eine Nachricht an den entsprechenden Antwortsender, die ihn anweist, bestimmte von den Daten zurück an den Client zu senden. (Die Menge von Daten, die zu empfangen der Client bereit ist, sowie Bestätigungen darüber, welche Daten der Client bereits empfangen hat, sind ein Teil der in jedem von dem Client gesendeten TCP-Paket enthaltenen Information.) Der Antwortsender gibt eine Rückmeldung an den Verteiler mit einer Identifizierung, um die einzigartige Instanz der dieser Verbindung zugeordneten Antwort zu identifizieren. Dies ist notwendig für dynamische Daten, wo jede Verbindung möglicherweise darin resultieren würde, dass unterschiedliche Daten in Ansprechen auf identische Anfragen zurückgesendet werden. Der Antwortsender teilt dem Verteiler auch die Größe der Antwortdaten mit, falls sie bekannt sind, sodass der Verteiler bestimmen kann, wann die vollständige Antwort gesendet wurde. Der Verteiler verwendet die Größe der Antwortdaten, wenn er die nächste Folgenummer berechnet. Der Antwortsender sendet die Antwortdaten an den Client.
  • Wenn der Client die Antwortdatenpakete empfängt, sendet er Bestätigungspakete zurück an den Empfänger, die anzeigen, welche Daten der Client erfolgreich empfangen hat und wie viele weitere Daten er nun aufzunehmen gewillt ist. Der Empfänger empfängt dieses Paket und führt wiederum den IP-Adressen- und TCP-Port-Nachschlagevorgang durch und bestimmt, dass dieses Paket zu einer hergestellten Verbindung gehört. Der Empfänger sendet dann die notwendige Information von dem Paket zusammen mit der zuvor für diese Verbindung gespeicherten Identifizierung an den Verteiler. Der Verteiler empfängt diese Nachricht und verwendet die Identifizierung, um die entsprechende Zustandsinformation anzuordnen. Dann verwendet der Verteiler die Bestätigungsinformation zusammen mit der gespeicherten Zustandsinformation, um zu bestimmen, welcher Abschnitt der Daten nun gesendet werden kann. Die Folgenummern in dem Verteiler werden um die Anzahl übertragener Bytes inkrementiert. Der Verteiler sendet dann eine Nachricht an den entsprechenden Antwortsender. Diese Nachricht enthält die zuvor gespeicherte Antwortidentifizierung zusammen mit der Information, die anzeigt, welcher Abschnitt der Daten zu senden ist. Der Verteiler hält auch Zeitmesser, die bewirken, dass er die Antwortsender anweist, Daten neu zu senden, die nicht innerhalb der entsprechenden Zeitspanne bestätigt wurden. Der Client empfängt neuerlich diese Daten und sendet die nächste Bestätigung.
  • Dieser Zyklus setzt sich fort, bis alle Antwortdaten von dem Antwortsender gesendet und von dem Client bestätigt wurden, zu welcher Zeit der Verteiler den Empfänger darüber informiert, dass die Verbindung geschlossen werden soll. Der Verteiler informiert den Antwortsender auch darüber, dass die einzigartige Instanz der Antwort für diese Verbindung nicht mehr gebraucht wird. Und zuletzt hebt der Verteiler die Zuweisung der Datenstruktur auf, die die Zustandsinformation für diese Verbindung enthält. Das letzte Schließen der Verbindung beinhaltet, dass einige zusätzliche Pakete zwischen dem Client und dem Empfänger ausgetauscht werden, wonach der Empfänger die Zuweisung seiner Datenstruktur aufhebt, die die Zustandsinformation für die Verbindung enthält. Fehlerzustände, abgebrochene Anfragen etc. resultieren in einer Verarbeitung zusätzlich zu der oben beschriebenen. 16A ist ein Flussdiagramm, das ein Verfahren zum Antworten auf eine über ein externes Netzwerk empfangene Anfrage in Übereinstimmung mit einer illustrativen Ausführungsform der Erfindung veranschaulicht. 16B ist ein Flussdiagramm, das ein Verfahren zum Antworten auf eine über ein externes Netzwerk empfangene Anfrage in Übereinstimmung mit einer weiteren illustrativen Ausführungsform der Erfindung veranschaulicht. 16C ist ein Flussdiagramm, das ein Verfahren zum Antworten auf eine über ein externes Netzwerk empfangene Anfrage in Übereinstimmung mit einer weiteren il lustrativen Ausführungsform der Erfindung veranschaulicht. 16D ist ein Flussdiagramm, das ein Verfahren zum Antworten auf eine über ein externes Netzwerk empfangene Anfrage in Übereinstimmung mit einer weiteren illustrativen Ausführungsform der Erfindung veranschaulicht.
  • Signaltragendes Medium
  • Ein weiterer Aspekt der Erfindung ist ein signaltragendes Medium, das konkret einen maschinenlesbaren Code beinhaltet, der von einer digitalen Verarbeitungsvorrichtung zur Implementierung einer beliebigen der hierin beschriebenen Ausführungen eines Servers oder digitalen Computersystems ausführbar ist. Ein weiterer Aspekt der Erfindung ist ein signaltragendes Medium, das konkret ein Programm von maschinenlesbaren Anweisungen beinhaltet, die von einer digitalen Verarbeitungsvorrichtung zur Durchführung eines jeden beliebigen hierin beschriebenen Verfahrens umfassend z. B. Verfahren zum Antworten auf eine über ein externes Netzwerk empfangene Anfrage, Verfahren zum Antworten auf eine Anfrage (die nicht über ein externes Netzwerk empfangen werden muss) oder Verfahren zum Initialisieren eines Servers, ausgeführt werden können. In einer bevorzugten Ausführungsform der Erfindung umfasst der maschinenlesbare Code einen Software-Maschinenprogrammcode.
  • Der Code kann sich in einem oder mehreren von verschiedenen Typen signaltragender Medien befinden. Zum Beispiel kann der Code in einem signaltragenden Medium wie z. B. einer optischen Disk 1705, in 17 gezeigt, enthalten sein. Die optische Disk kann ein beliebiger Typ von signaltragender Disk sein, z. B. eine CD-ROM, CD-R (eine beschreibbare CD-ROM, die auf einem CD-ROM-Laufwerk gelesen werden kann), CD-RW (mehrfach beschreibbare CD), CD-E (beschreibbare und löschbare CD), oder DVD (Digital Video Disk) und wird typischerweise eine CD-ROM sein.
  • Alternativ kann anstelle oder zusätzlich zu einer optischen Disk das signaltragende Medium eines oder mehrere der folgenden umfassen: eine magnetische Datenspeicherdiskette (Floppy Disk), eine Zip-Disk, einen DASD-Speicher (z. B. eine herkömmliche „Festplatte" oder ein RAID-Array), ein Magnetband, ein RAM, ein elektronischer Nur-Lese-Speicher (z. B. ROM, EPROM oder EEPROM), Lochkarten oder Übertragungsmedien wie z. B. digitale und/oder analoge Nachrichtenverbindungen.
  • Pseudocode
  • Der folgende Pseudocode beschreibt die Implementierung einer illustrativen TCP/IP-Ausführungsform des Verbund-BS, das Thunder-BS und illustrative Elementklassen umfasst:
  • Figure 00760001
  • Figure 00770001
  • Figure 00780001
  • Figure 00790001
  • Figure 00800001
  • Figure 00810001
  • Figure 00820001
  • Figure 00830001
  • Figure 00840001
  • Figure 00850001
  • Es wird für den Fachmann einzusehen sein, dass verschiedene Änderungen und Abwandlungen an den illustrativen Ausführungsformen der hierin beschriebenen Erfindung vorgenommen werden können, ohne von dem Umfang der Erfindung wie durch die Ansprüche definiert abzuweichen.

Claims (27)

  1. Digitales Computersystem, umfassend: eine erste CPU (110a, 1305), auf der eine erste ausgeprägte spezialisierte einzigartige Klasse von Betriebssystem läuft, die für ihre spezifische Funktion optimiert ist; eine erste interne Netzwerkschnittstelle (115), die mit der ersten CPU gekoppelt ist, wobei die erste Netzwerkschnittstelle zur Kopplung mit einem internen Netzwerk (183, 205, 210, 490, 902) vorgesehen ist; eine zweite CPU (110b, 1305), auf der eine zweite ausgeprägte spezialisierte einzigartige Klasse von Betriebssystem läuft, die für ihre spezifische Funktion optimiert ist; eine zweite interne Netzwerkschnittstelle (115), die mit der zweiten CPU gekoppelt ist, wobei die zweite Netzwerkschnittstelle zur Kopplung mit dem internen Netzwerk (183, 205, 210, 490, 902) vorgesehen ist; und wobei das erste und das zweite Betriebssystem unterschiedliche Eigenschaften in Bezug auf die jeweiligen Funktionen und gemeinsame Eigenschaften, die die zur Kommunikation über ein internes Netzwerk notwendige Funktionalität bereitstellen, aufweisen, wobei das erste und das zweite Betriebssystem vereint ein Verbund-Betriebssystem bilden.
  2. Digitales Computersystem nach Anspruch 1, wobei eine erste externe Netzschnittstelle (120) mit der ersten CPU (110a, 1305) gekoppelt ist, und eine zweite externe Netzwerkschnittstelle (120) mit der zweiten CPU (110b, 1305) gekoppelt ist, und wobei bestimmte Zustandsinformation, die eine TCP-Verbindung betrifft, von dem ersten Betriebssystem gehalten wird, und bestimmte Zustandsinformation, die die TCP-Verbindung betrifft, von dem zweiten Betriebssystem gehalten wird.
  3. Digitales Computersystem nach Anspruch 2, wobei das erste Betriebssystem und das zweite Betriebssystem gemeinschaftlich zumindest eine gemeinsame IP-Adresse bedienen.
  4. Digitales Computersystem nach Anspruch 1, ferner umfassend: eine dritte CPU, auf der ein drittes Betriebssystem läuft; eine dritte interne Netzwerkschnittstelle, die mit der dritten CPU gekoppelt ist, wobei die dritte Netzwerkschnittstelle zur Kopplung mit dem internen Netzwerk (183, 205, 210, 490, 902) vorgesehen ist; und wobei das erste, das zweite und das dritte Betriebssystem unterschiedliche Eigenschaften und gemeinsame Eigenschaften aufweisen, wobei das erste Betriebssystem vorzugsweise ein Empfängerbetriebssystem ist; das zweite Betriebssystem vorzugsweise ein Antwortsenderbetriebssystem ist; das dritte Betriebssystem vorzugsweise ein Verteilerbetriebssystem ist; und das erste, das zweite und das dritte Betriebssystem vorzugsweise gemeinsame Eigenschaften aufweisen, die von einem gemeinsamen Elternteil vererbt sind, und/oder in welchem eine erste externe Netzwerkschnittstelle (120) mit der ersten CPU (110a, 1305) gekoppelt ist, und eine zweite externe Netzwerkschnittstelle (120) mit der zweiten CPU (110b, 1305) gekoppelt ist, wobei das erste Betriebssystem und das zweite Betriebssystem vorzugsweise gemeinschaftlich zumindest eine gemeinsame IP-Adresse bedienen, und/oder in welchem das digitale Computersystem ferner das interne Netzwerk (183, 205, 210, 490, 902) umfasst, und das interne Netzwerk mit der ersten, der zweiten und der dritten internen Netzwerkschnittstelle (115) gekoppelt ist, und/oder in welchem bestimmte Zustandsinformation, die eine TCP-Verbindung betrifft, von dem ersten Betriebssystem gehalten wird und bestimmte Zustandsinformation, die die TCP-Verbindung betrifft, von dem dritten Betriebssystem gehalten wird, wobei das erste Betriebssystem dann vorzugsweise konfiguriert ist, um zumindest IP-Adressen und TCP-Ports nachzuschlagen, und um TCP-Verbindungen herzustellen; wobei das zweite Betriebssystem vorzugsweise konfiguriert ist, um zumindest Antwortdaten zu senden; und das dritte Betriebssystem vorzugsweise konfiguriert ist, um zumindest Verbindungszustandsinformation zu halten, und um zu bestimmen, was für eine Antwort zu senden ist.
  5. Digitales Computersystem nach Anspruch 1, das als Server (300, 440, 505, 605) implementiert ist, umfassend: eine erste Element-Hardwareeinheit (105a), die die erste CPU (110a) umfasst und einen ersten Element-Hardwareeinheitsspeicher-RAM (125) aufweist, der das erste Betriebssystem enthält, eine zweite Element-Hardwareeinheit (105b), die die zweite CPU (110b) umfasst und einen zweiten Element-Hardwareeinheitsspeicher-RAM (125) aufweist, der ein zweites Betriebssystem enthält, wobei die zweite Element-Hardwareeinheit eine interne Netzwerkschnittstelle (115) zur Kopplung mit dem internen Netzwerk (183, 205, 210, 490, 902) aufweist; und wobei das erste und das zweite Betriebssystem bestimmte unterschiedliche Eigenschaften aufweist, wobei bestimmte Zustandsinformation, die eine TCP-Verbindung betrifft, vorzugsweise in der ersten Element-Hardwareeinheit (105a) gehalten wird und bestimmte Zustandsinformation, die die TCP-Verbindung betrifft, vorzugsweise in der zweiten Hardwareeinheit (105b) gehalten wird; und wobei das erste Betriebssystem und das zweite Betriebssystem vorzugsweise gemeinschaftlich zumindest eine gemeinsame IP-Adresse bedienen, wobei der Server vorzugsweise das interne Netzwerk (183, 205, 210, 490, 902) umfasst, und wobei das interne Netzwerk (183, 205, 210, 490, 902) mit den internen Netzwerkschnittstellen (115) der ersten und zweiten Element-Hardwareeinheiten (105a, 105b) gekoppelt ist.
  6. Server (300, 440, 505, 605) nach Anspruch 5, wobei: das erste Betriebssystem Eigenschaften zumindest eines Empfängerbetriebssystems aufweist; das zweite Betriebssystem Eigenschaften zumindest eines Antwortsenderbetriebssystems aufweist; die erste Element-Hardwareeinheit (105) eine externe Netzwerkschnittstelle (120) zur Kopplung mit einem externen Netzwerk (215, 492, 620, 710, 916) aufweist; und die zweite Element-Hardwareeinheit (105b) eine externe Netzwerkschnittstelle (120) zur Kopplung mit dem externen Netzwerk (215, 492, 620, 710, 916) aufweist.
  7. Server (300, 440, 505, 606) nach Anspruch 5, ferner umfassend: eine dritte Element-Hardwareeinheit, die eine dritte CPU umfasst und einen dritten Element-Hardwareeinheitsspeicher-RAM aufweist, der ein drittes Betriebssystem enthält, wobei die dritte Element-Hardwareeinheit eine interne Netzwerkschnittstelle (115) zur Kopplung mit dem internen Netzwerk (183, 205, 210, 490, 902) aufweist; wobei das erste, das zweite und das dritte Betriebssystem bestimmte unterschiedliche Eigenschaften aufweisen; wobei bestimmte Zustandsinformation, die eine TCP-Verbindung betrifft, vorzugsweise in der ersten Element-Hardwareeinheit (105a) gehalten wird und bestimmte Zustandsinformation, die die TCP-Verbindung betrifft, vorzugsweise in der dritten Hardwareeinheit gehalten wird, und wobei eine Echtzeit-TCP/IP-Zustandsmaschine vorzugsweise gemeinschaftlich in einer Vielzahl von Element-Hardwareeinheiten (105a, 105b) implementiert ist.
  8. Server (300, 440, 505, 605) nach Anspruch 7, wobei Zustandsinformation, die eine TCP-Verbindung betrifft, in der ersten Element-Hardwareeinheit (105a) und der dritten Element-Hardwareeinheit gehalten wird, und wobei zumindest bestimmte Zustandsinformation, die in der ersten Element-Hardwareeinheit (105a) gehalten wird, verschieden ist von der Zustandsinformation, die in der dritten Element-Hardwareeinheit gehalten wird, wobei das erste Betriebssystem vorzugsweise konfiguriert ist, um zumindest IP-Adressen und TCP-Ports nachzuschlagen, und um TCP-Verbindungen herzustellen; das zweite Betriebssystem vorzugsweise konfiguriert ist, um zumindest Antwortdaten zu senden; und das dritte Betriebssystem vorzugsweise konfiguriert ist, um zumindest Verbindungszustandsinformation zu halten, und um zu bestimmen, was für eine Antwort zu senden ist, wobei das erste Betriebssystem und das zweite Betriebssystem vorzugsweise gemeinschaftlich zumindest eine gemeinsame IP-Adresse bedienen, wobei das erste Betriebsystem vorzugsweise ein Empfängerbetriebssystem ist; das zweite Betriebssystem vorzugsweise ein Antwortsenderbetriebssystem ist; das dritte Betriebssystem vorzugsweise ein Verteilerbetriebssystem ist; die erste Element-Hardwareeinheit (105a) vorzugsweise eine externe Netzwerkschnittstelle (120) zur Kopplung mit einem externen Netzwerk (215, 492, 620, 710, 916) aufweist; und die zweite Element-Hardwareeinheit (105b) vorzugsweise eine externe Netzwerkschnittstelle (120) zur Kopplung mit dem externen Netzwerk (215, 492, 620, 710, 916) aufweist.
  9. Server (300, 440, 505, 605) nach Anspruch 7, wobei das erste, das zweite und das dritte Betriebssystem gemeinsame Eigenschaften aufweisen, die von einem gemeinsamen Elternteil vererbt sind.
  10. Server (300, 440, 505, 605) nach Anspruch 8, wobei: das erste Betriebssystem einen Abschnitt eines HTTP-Servers umfasst; das zweite Betriebssystem einen Abschnitt eines HTTP-Servers umfasst; und das dritte Betriebssystem einen Abschnitt eines HTTP-Servers umfasst, wobei die Abschnitte des HTTP-Servers in dem ersten, dem zweiten und dem dritten Betriebssystem zusammen einen HTTP-Server bilden.
  11. Server (300, 440, 505, 605) nach Anspruch 8, wobei: das erste Betriebssystem vorzugsweise einen Abschnitt eines FTP-Servers umfasst; das zweite Betriebssystem vorzugsweise einen Abschnitt eines FTP-Servers umfasst; das dritte Betriebssystem vorzugsweise einen Abschnitt eines FTP-Servers umfasst; und die Abschnitte des FTP-Servers in dem ersten, dem zweiten und dem dritten Betriebssystem zusammen einen FTP-Server bilden.
  12. Server (300, 440, 505, 605) nach Anspruch 7, wobei: der erste Element-Hardwareeinheitsspeicher einen ersten Element-Hardwareeinheitsspeicher-ROM umfasst, der ein bootfähiges Element enthält; der zweite Element-Hardwareeinheitshardwarespeicher einen zweiten Element-Hardwareeinheitsspeicher-ROM umfasst, der ein bootfähiges Element enthält; und der dritte Element-Hardwareeinheitshardwarespeicher einen dritten Element-Hardwareeinheitsspeicher-ROM umfasst, der ein bootfähiges Element enthält.
  13. Server (300, 440, 505, 605) nach Anspruch 7, wobei die erste Element-Hardwareeinheit (105a) IP-Adressen-Nachschlagevorgänge in Echtzeit bewerkstelligt, wobei die erste Element-Hardwareeinheit (105a) vorzugsweise einen IP-Adressennachschlagesuchalgorithmus benutzt, der eine Trie-Datenstruktur verwendet, wobei die dritte Element-Hardwareeinheit (105a, 105b) vorzugsweise Host-Namen-Nachschlagevorgänge in Echtzeit bewerkstelligt, wobei die Element-Hardwareeinheiten vorzugsweise Anfragen von Clients in Echtzeit verarbeiten.
  14. Server (300, 440, 505, 605) nach Anspruch 7, wobei auf zumindest einer Element-Hardwareeinheit eine Nicht-Echtzeit-Schicht und eine Echtzeit-Schicht läuft.
  15. Server (300, 440, 505, 605) nach Anspruch 7, wobei zumindest eine Element-Hardwareeinheit (105a) in einer anderen Hülle angeordnet ist als zumindest eine andere Element-Hardwareeinheit (105b), und/oder wobei zumindest eine Element-Hardwareeinheit (105a) zumindest 1 Kilometer von zumindest einer weiteren Element-Hardwareeinheit (105b) entfernt angeordnet ist.
  16. Digitales Computersystem nach Anspruch 2, wobei es mehrere CPUs (110a, 110b, 1305) gibt, auf denen jeweils ein jeweiliges Betriebssystem läuft, wobei eine TCP/IP-Zustandsmaschine gemeinschaftlich auf der Vielzahl von CPUs (110a, 110b, 1305) implementiert ist.
  17. Server (300, 440, 505, 605) nach Anspruch 6, wobei zumindest ein Antwortsenderelement (220, 425, 455, 515, 520, 525, 530, 535, 615, 740, 924, 926, 1015, 1325, 1520) in einer anderen Hülle angeordnet ist als zumindest ein Empfängerelement (225, 415, 445, 610, 745, 1005, 1315, 1510), und/oder wobei zumindest ein Antwortsenderelement (220, 425, 455, 515, 520, 525, 530, 535, 615, 740, 924, 926, 1015, 1325, 1520) zumindest einen Kilometer von zumindest einem Empfängerelement (225, 415, 445, 610, 745, 1005, 1315, 1510) entfernt angeordnet ist, und/oder wobei die externen Netzwerkschnittstellen (120) von zumindest einem Antwortsenderelement (220, 425, 455, 515, 520, 525, 530, 535, 615, 740, 924, 926, 1015, 1325, 1520) und zumindest einem Empfängerelement (225, 415, 445, 610, 745, 1005, 1315, 1510) mit dem externen Netzwerk (215, 492, 620, 710, 916) an unterschiedlichen Orten in dem externen Netzwerk (215, 492, 620, 710, 916) gekoppelt sind, die zumindest einen Kilometer getrennt sind, und/oder wobei die externen Netzwerkschnittstellen (120) von zumindest zwei Antwortsenderelementen (220, 425, 455, 515, 520, 525, 530, 535, 615, 740, 924, 926, 1015, 1325, 1520) mit dem externen Netzwerk (215, 492, 620, 710, 916) an unterschiedlichen Orten in dem externen Netzwerk (215, 492, 620, 710, 916) (215, 492, 620, 710, 916) gekoppelt sind, und/oder wobei die externe Netzwerkschnittstelle (120) von zumindest einem Element direkt mit dem Internet-Backbone (620,720) gekoppelt ist, und/oder wobei unterschiedliche Abschnitte eines HTTP-Servers in einer Vielzahl von unterschiedlichen Element-Betriebssystemen implementiert sind, und/oder wobei unterschiedliche Abschnitte eines FTP-Servers in einer Vielzahl unterschiedlicher Element-Betriebssysteme implementiert sind, und/oder wobei der Server (300, 440, 505, 605) ferner zumindest ein Konfigurationselement (235) umfasst, das eine interne Netzwerkschnittstelle (115) zur Kopplung mit dem internen Netzwerk (138, 205, 210, 490, 902) aufweist, und/oder wobei der Server (300, 440, 505, 605) ferner zumindest ein Wächterelement (240) umfasst, das eine interne Netzwerkschnittstelle (115) zur Kopplung mit dem internen Netzwerk (183, 205, 210, 490, 902) aufweist, und/oder wobei der Server (300, 440, 505, 605) ferner zumindest ein dauerhaftes Speicherungselement (245) umfasst, das eine interne Netzwerkschnittstelle (115) zur Kopplung mit dem internen Netzwerk (183, 205, 210, 490, 902) aufweist, und/oder wobei der Server (300, 440, 505, 605) ferner zumindest ein Decoderelement (255) umfasst, das eine interne Netzwerkschnittstelle (115) zur Kopplung mit dem internen Netzwerk (183, 205, 210, 490, 902) aufweist, und/oder wobei der Server (300, 440, 505, 605) ferner zumindest ein Systemadministratorbenachrichtigungselement (250) umfasst, das eine interne Netzwerkschnittstelle (115) zur Kopplung mit dem internen Netzwerk (183, 205, 210, 490, 902) aufweist.
  18. Verfahren zum Antworten auf eine Anfrage, die über ein externes Netzwerk (215, 492, 620, 720, 916) empfangen wird, das umfasst, dass: zumindest ein Empfängerbetriebssystem auf einer ersten CPU laufen gelassen wird; zumindest ein Antwortsenderbetriebssystem auf einer zweiten CPU laufen gelassen wird; mit der ersten CPU (110b, 1305) eine Anfrage empfangen wird, die über das externe Netzwerk übertragen wird; über das interne Netzwerk (183, 205, 210, 490, 902) eine Nachricht von der ersten CPU (110a) an die zweite CPU (110b) gesendet wird; und Antwortdaten über das externe Netzwerk (215, 492, 620, 710, 916) von der zweiten CPU (110b) übertragen werden, wobei das Verfahren ferner umfasst, dass die richtige Antwort auf die Anfrage identifiziert wird, und wobei das Verfahren dann ferner umfasst, dass unterschiedliche Abschnitte eines Servers auf dem Empfängerbetriebssystem und dem Antwortsenderbetriebssystem laufen gelassen werden, wodurch ein Server als eine verteilte Zustandsmaschine implementiert wird.
  19. Verfahren nach Anspruch 18 zum Antworten auf eine Anfrage, die über ein externes Netzwerk (215, 492, 620, 710, 916) empfangen wird, das umfasst, dass: das Empfängerbetriebssystem verwendet wird, um eine IP-Adresse und einen TCP- oder UDP-Port nachzuschlagen, die über das externe Netzwerk (215, 492, 620, 710, 916) empfangen werden; eine CPU mit einem Verteilerbetriebssystem identifiziert wird, die der IP-Adresse und dem TCP- oder UDP-Port, die in der Nachschlagetabelle gefunden werden, zugeordnet ist; Anfragedaten von dem Empfängerbetriebssystem an das Verteilerbetriebssystem übergeben werden; die Empfänger- und Verteilerbetriebssysteme verwendet werden, um Zustandsinformation zu halten, das Verteilerbetriebssystem verwendet wird, um Antwortdaten und zumindest ein entsprechendes Antwortsenderbetriebssystem auf einer dritten CPU zu identifizieren; das Verteilerbetriebssystem verwendet wird, um eine Nachricht zu senden, die die Antwortdaten identifiziert und ein Antwortsenderbetriebssystem anweist, die Antwortdaten zu übertragen; das Antwortsenderbetriebssystem verwendet wird, um die Antwortdaten über das externe Netzwerk (215, 492, 620, 710, 916) zu übertragen; und die Empfänger-, Verteiler- und Antwortsenderbetriebssysteme unterschiedliche Betriebssysteme sind, wobei das Verfahren ferner umfasst, dass das Empfängerbetriebssystem verwendet wird, um eine TCP-Verbindung herzustellen, wenn eine TCP-Anfrage empfangen wird.
  20. Verfahren nach Anspruch 18 oder 19, das ferner umfasst, dass: das erste Betriebssystem verwendet wird, um einen HTTP-Header aus einer Nachricht zu extrahieren, die über das externe Netzwerk (215, 492, 620, 710, 916) empfangen wird, und eine Nachricht, die den HTTP-Header umfasst, zu senden.
  21. Digitales Computersystem nach einem der Ansprüche 1 bis 4, wobei eine Vielzahl von zweiten CPUs (110b) vorgesehen ist, auf denen jeweils eine zweite ausgeprägte spezialisierte einzigartige Klasse von Betriebssystem läuft, die für ihre Funktion optimiert ist.
  22. Digitales Computersystem nach einem der Ansprüche 1 bis 4, wobei weitere CPUs (1305) vorgesehen sind, auf denen jeweils eine jeweilige ausgeprägte spezialisierte Klasse von Betriebssystem läuft, die für ihre Funktion optimiert ist.
  23. Digitales Computersystem nach Anspruch 22, wobei eine der weiteren CPUs eine Firewall-Funktion (928) ausführt.
  24. Digitales Computersystem nach Anspruch 22, wobei eine der weiteren CPUs eine Wächterfunktion (902) ausführt.
  25. Digitales Computersystem nach Anspruch 22, wobei eine der weiteren CPUs eine Video- und/oder Audioübertragungsfunktion ausführt.
  26. Digitales Computersystem nach Anspruch 1, wobei eine der CPUs zumindest eines von einem paketbasierten Kommunikationsprotokoll und einem schaltungsbasierten Kommunikationsprotokoll betreibt.
  27. Digitales Computersystem nach Anspruch 1, wobei die erste und die zweite CPU (110a, 110b) als ein System auf einem Chip (105) ausgeführt sind.
DE60019640T 1999-12-16 2000-12-08 Digitales Rechnersystem und Verfahren zur Beantwortung von über ein externes Netzwerk empfangenen Anfragen Expired - Lifetime DE60019640T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/464,945 US6799202B1 (en) 1999-12-16 1999-12-16 Federated operating system for a server
US464945 1999-12-16
PCT/US2000/033323 WO2001044938A2 (en) 1999-12-16 2000-12-08 Federated operating system for a server

Publications (2)

Publication Number Publication Date
DE60019640D1 DE60019640D1 (de) 2005-05-25
DE60019640T2 true DE60019640T2 (de) 2006-03-02

Family

ID=23845897

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60019640T Expired - Lifetime DE60019640T2 (de) 1999-12-16 2000-12-08 Digitales Rechnersystem und Verfahren zur Beantwortung von über ein externes Netzwerk empfangenen Anfragen

Country Status (7)

Country Link
US (1) US6799202B1 (de)
EP (1) EP1242882B1 (de)
JP (1) JP4245296B2 (de)
AT (1) ATE293809T1 (de)
AU (1) AU1955301A (de)
DE (1) DE60019640T2 (de)
WO (1) WO2001044938A2 (de)

Families Citing this family (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU6262701A (en) * 2000-05-24 2001-12-03 Voltaire Advanced Data Security Ltd. Filtered application-to-application communication
CA2415888C (en) * 2000-08-04 2008-10-21 Avaya Technology Corporation Intelligent demand driven recognition of url objects in connection oriented transactions
US20020116605A1 (en) * 2000-12-21 2002-08-22 Berg Mitchell T. Method and system for initiating execution of software in response to a state
US20020116532A1 (en) * 2000-12-21 2002-08-22 Berg Mitchell T. Method and system for communicating an information packet and identifying a data structure
US7546369B2 (en) * 2000-12-21 2009-06-09 Berg Mitchell T Method and system for communicating a request packet in response to a state
US20020116397A1 (en) 2000-12-21 2002-08-22 Berg Mitchell T. Method and system for communicating an information packet through multiple router devices
US7418522B2 (en) * 2000-12-21 2008-08-26 Noatak Software Llc Method and system for communicating an information packet through multiple networks
US7287090B1 (en) * 2000-12-21 2007-10-23 Noatak Software, Llc Method and system for identifying a computing device in response to a request packet
US7421505B2 (en) * 2000-12-21 2008-09-02 Noatak Software Llc Method and system for executing protocol stack instructions to form a packet for causing a computing device to perform an operation
US7512686B2 (en) * 2000-12-21 2009-03-31 Berg Mitchell T Method and system for establishing a data structure of a connection with a client
DE10109196B4 (de) * 2001-02-26 2005-04-28 Viessmann Werke Kg Vorrichtung und Verfahren zur Fernüberwachung und Parametrierung von Einrichtungen, insbesondere von Heizungsanlagen
US6971044B2 (en) * 2001-04-20 2005-11-29 Egenera, Inc. Service clusters and method in a processing system with failover capability
US7231430B2 (en) * 2001-04-20 2007-06-12 Egenera, Inc. Reconfigurable, virtual processing system, cluster, network and method
US20020188700A1 (en) * 2001-06-08 2002-12-12 Todd Steitle System and method of interactive network system design
US7228412B2 (en) * 2001-07-06 2007-06-05 Juniper Networks, Inc. Bufferless secure sockets layer architecture
US7149892B2 (en) * 2001-07-06 2006-12-12 Juniper Networks, Inc. Secure sockets layer proxy architecture
US7908472B2 (en) * 2001-07-06 2011-03-15 Juniper Networks, Inc. Secure sockets layer cut through architecture
US7853781B2 (en) * 2001-07-06 2010-12-14 Juniper Networks, Inc. Load balancing secure sockets layer accelerator
US7207061B2 (en) * 2001-08-31 2007-04-17 International Business Machines Corporation State machine for accessing a stealth firewall
GB0211286D0 (en) * 2002-05-16 2002-06-26 Nokia Corp Routing data packets through a wireless network
US7424741B1 (en) * 2002-05-20 2008-09-09 Cisco Technology, Inc. Method and system for prevention of network denial-of-service attacks
US7539183B2 (en) * 2002-06-24 2009-05-26 Emerson Network Power - Embedded Computing, Inc. Multi-service platform system and method
US7441114B2 (en) * 2002-09-10 2008-10-21 Ge Fanuc Automation North America, Inc. Methods and systems for management and control of an automation control module
US20040177129A1 (en) * 2003-03-06 2004-09-09 International Business Machines Corporation, Armonk, New York Method and apparatus for distributing logical units in a grid
US9003048B2 (en) * 2003-04-01 2015-04-07 Microsoft Technology Licensing, Llc Network zones
US20040210663A1 (en) * 2003-04-15 2004-10-21 Paul Phillips Object-aware transport-layer network processing engine
GB2412755A (en) * 2004-03-30 2005-10-05 Hewlett Packard Development Co Coordination of lifecycle state changes in software components
US8150837B2 (en) * 2004-06-25 2012-04-03 Apple Inc. Methods and systems for managing data
US8131674B2 (en) 2004-06-25 2012-03-06 Apple Inc. Methods and systems for managing data
US8161184B2 (en) * 2004-06-25 2012-04-17 Apple Inc. Method and apparatus for facilitating long-lived DNS queries
US20050289107A1 (en) * 2004-06-25 2005-12-29 Yan Arrouye Methods and systems for managing data
US7600217B2 (en) 2004-12-14 2009-10-06 Sap Ag Socket-like communication API for Java
US7580915B2 (en) * 2004-12-14 2009-08-25 Sap Ag Socket-like communication API for C
US7593930B2 (en) * 2004-12-14 2009-09-22 Sap Ag Fast channel architecture
US7672949B2 (en) * 2004-12-28 2010-03-02 Sap Ag Connection manager having a common dispatcher for heterogeneous software suites
US7933947B2 (en) * 2004-12-28 2011-04-26 Sap Ag Connection manager that supports failover protection
US7694065B2 (en) 2004-12-28 2010-04-06 Sap Ag Distributed cache architecture
US7971001B2 (en) 2004-12-28 2011-06-28 Sap Ag Least recently used eviction implementation
US7539821B2 (en) 2004-12-28 2009-05-26 Sap Ag First in first out eviction implementation
US20060143256A1 (en) 2004-12-28 2006-06-29 Galin Galchev Cache region concept
US8204931B2 (en) 2004-12-28 2012-06-19 Sap Ag Session management within a multi-tiered enterprise network
KR100645537B1 (ko) * 2005-02-07 2006-11-14 삼성전자주식회사 안정적인 패킷 포워딩을 위한 동적인 큐 관리방법 및 이를위한 네트워크 프로세서의 구성요소
US8589562B2 (en) 2005-04-29 2013-11-19 Sap Ag Flexible failover configuration
US7716377B2 (en) * 2005-05-25 2010-05-11 Harris Steven T Clustering server providing virtual machine data sharing
US7689660B2 (en) * 2005-06-09 2010-03-30 Sap Ag Application server architecture
KR101290413B1 (ko) * 2005-07-17 2013-07-26 오브시디안 리서치 코포레이션 인피니밴드 네트워크의 물리적 범위를 확장하기 위한 방법
US7693138B2 (en) * 2005-07-18 2010-04-06 Broadcom Corporation Method and system for transparent TCP offload with best effort direct placement of incoming traffic
US7966412B2 (en) 2005-07-19 2011-06-21 Sap Ag System and method for a pluggable protocol handler
US20070118664A1 (en) * 2005-10-24 2007-05-24 International Business Machines Corporation Mail dispatch system
US8707323B2 (en) 2005-12-30 2014-04-22 Sap Ag Load balancing algorithm for servicing client requests
US20070156907A1 (en) * 2005-12-30 2007-07-05 Galin Galchev Session handling based on shared session information
US7877381B2 (en) * 2006-03-24 2011-01-25 International Business Machines Corporation Progressive refinement of a federated query plan during query execution
US7490110B2 (en) * 2006-03-24 2009-02-10 International Business Machines Corporation Predictable query execution through early materialization
US8250134B2 (en) * 2006-12-27 2012-08-21 International Business Machines Corporation Processing multiple requests by a statically identified user server prior to user server termination
US8103628B2 (en) * 2008-04-09 2012-01-24 Harmonic Inc. Directed placement of data in a redundant data storage system
US9021071B2 (en) * 2008-06-09 2015-04-28 International Business Machines Corporation Methods of federating applications providing modular data
US8271659B2 (en) * 2008-09-04 2012-09-18 Oracle International Corporation Methods and systems for automatic removal and replacement of connections in a pool rendered stale by a firewall
US9384042B2 (en) * 2008-12-16 2016-07-05 International Business Machines Corporation Techniques for dynamically assigning jobs to processors in a cluster based on inter-thread communications
US9396021B2 (en) * 2008-12-16 2016-07-19 International Business Machines Corporation Techniques for dynamically assigning jobs to processors in a cluster using local job tables
US8239524B2 (en) 2008-12-16 2012-08-07 International Business Machines Corporation Techniques for dynamically assigning jobs to processors in a cluster based on processor workload
US8122132B2 (en) * 2008-12-16 2012-02-21 International Business Machines Corporation Techniques for dynamically assigning jobs to processors in a cluster based on broadcast information
US9923995B1 (en) 2010-02-27 2018-03-20 Sitting Man, Llc Methods, systems, and computer program products for sharing information for detecting an idle TCP connection
US20140082258A1 (en) * 2012-09-19 2014-03-20 Lsi Corporation Multi-server aggregated flash storage appliance
TWI544337B (zh) * 2012-10-25 2016-08-01 緯創資通股份有限公司 共用通用串列匯流排（ｕｓｂ）裝置之雙作業系統架構，以及雙作業系統架構共用通用串列匯流排（ｕｓｂ）裝置之方法
WO2016075836A1 (ja) * 2014-11-14 2016-05-19 富士通株式会社 データ検証プログラム、データ検証方法及びデータ検証装置
US11240334B2 (en) 2015-10-01 2022-02-01 TidalScale, Inc. Network attached memory using selective resource migration
US11023135B2 (en) 2017-06-27 2021-06-01 TidalScale, Inc. Handling frequently accessed pages
US10817347B2 (en) 2017-08-31 2020-10-27 TidalScale, Inc. Entanglement of pages and guest threads
US11175927B2 (en) 2017-11-14 2021-11-16 TidalScale, Inc. Fast boot
CN110971680B (zh) * 2019-11-22 2022-01-28 拉扎斯网络科技（上海）有限公司 通信方法、装置、系统、电子设备及可读存储介质
US11425224B2 (en) * 2020-02-25 2022-08-23 Level 3 Communications, Llc Disaggregated and distributed composable infrastructure

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185619B1 (en) 1996-12-09 2001-02-06 Genuity Inc. Method and apparatus for balancing the process load on network servers according to network and serve based policies
US5634053A (en) 1995-08-29 1997-05-27 Hughes Aircraft Company Federated information management (FIM) system and method for providing data site filtering and translation for heterogeneous databases
US5940074A (en) 1996-06-03 1999-08-17 Webtv Networks, Inc. Remote upgrade of software over a network
US5818448A (en) 1996-07-02 1998-10-06 Sun Microsystems, Inc. Apparatus and method for identifying server computer aggregation topologies
US6182139B1 (en) * 1996-08-05 2001-01-30 Resonate Inc. Client-side resource-based load-balancing with delayed-resource-binding using TCP state migration to WWW server farm
US5774660A (en) 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US6003079A (en) * 1997-02-27 1999-12-14 Hewlett Packard Company System and method for continuously measuring quality of service in a federated application environment
US6393483B1 (en) * 1997-06-30 2002-05-21 Adaptec, Inc. Method and apparatus for network interface card load balancing and port aggregation
SE511972C2 (sv) 1997-09-09 2000-01-10 Sics Swedish Inst Of Computers Uppslagningsanordning och förfarande för att klassificera och vidarebefordra datapaket
US6141759A (en) * 1997-12-10 2000-10-31 Bmc Software, Inc. System and architecture for distributing, monitoring, and managing information requests on a computer network
US6195680B1 (en) * 1998-07-23 2001-02-27 International Business Machines Corporation Client-based dynamic switching of streaming servers for fault-tolerance and load balancing
US6438652B1 (en) * 1998-10-09 2002-08-20 International Business Machines Corporation Load balancing cooperating cache servers by shifting forwarded request
US6564251B2 (en) * 1998-12-03 2003-05-13 Microsoft Corporation Scalable computing system for presenting customized aggregation of information
US6502103B1 (en) * 1999-06-14 2002-12-31 International Business Machines Corporation Providing composed containers and data objects to support multiple resources

Also Published As

Publication number Publication date
EP1242882B1 (de) 2005-04-20
WO2001044938A2 (en) 2001-06-21
JP4245296B2 (ja) 2009-03-25
EP1242882A2 (de) 2002-09-25
ATE293809T1 (de) 2005-05-15
AU1955301A (en) 2001-06-25
US6799202B1 (en) 2004-09-28
WO2001044938A3 (en) 2002-01-03
JP2003528371A (ja) 2003-09-24
DE60019640D1 (de) 2005-05-25

Similar Documents

Publication Publication Date Title
DE60019640T2 (de) Digitales Rechnersystem und Verfahren zur Beantwortung von über ein externes Netzwerk empfangenen Anfragen
DE60301783T2 (de) Verfahren und system zur gleichrangigen kommunikation in einer netzwerkumgebung
DE60211524T2 (de) Verfahren und vorrichtung zur verteilten lieferung von inhalten innerhalb eines computernetzwerkes
US8843605B2 (en) Method and system for filtering and suppression of telemetry data
DE69328666T2 (de) Verfahren und Gerät um eine Anzahl Rechner als einen einzigen Host auf dem Netz erscheinen zu lassen
DE69814900T2 (de) Verfahren und system zur unterstützung verteilter software- entwicklung ohne bewusstsein der verteilten charakteristik der software
US7788403B2 (en) Network publish/subscribe incorporating web services network routing architecture
US7529805B2 (en) Distributed web services network architecture
DE68920057T2 (de) Verfahren und Vorrichtung zur Verbindung eines SNA-Hostrechners mit einem entfernten SNA-Hostrechner über ein paketvermitteltes Nachrichtennetz.
DE69128952T2 (de) Gerät und Verfahren zur Entkupplung von Datenaustauschdetails zur Beschaffung einer Hochleistungskommunikation zwischen Softwareprozessen
DE69837938T2 (de) Übergreifende bildung von server clustern mittels einer netzwerkflussvermittlung
DE69935920T2 (de) Lastausgleich in einer netzwerkumgebung
CN101371237B (zh) 在网络元件中代表应用执行消息有效载荷处理功能
DE19882235B4 (de) Verwendung von Web-Technologie für Teilnehmerverwaltungsaktivitäten
DE60024763T2 (de) Verfahren und Vorrichtung zur Packetfragmentenweiterleitung
DE69812777T2 (de) Verbindung von Ethernetkompatiblen Netzwerken
DE69929268T2 (de) Verfahren und System zur Überwachung und Steuerung der Netzzugriffe
CN103403707B (zh) 用于数据库代理请求交换的系统和方法
EP1859597B1 (de) Verfahren für die kommunikation zwischen einer anwendung und einem client
US6370583B1 (en) Method and apparatus for portraying a cluster of computer systems as having a single internet protocol image
DE602004011638T2 (de) Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem
DE69927285T2 (de) Netzverwaltungssystem
US20030154279A1 (en) Symbolic definition of a computer system
DE10296675T5 (de) Virtuelles Vernetzungssystem und -verfahren in einem Verarbeitungssystem
DE202015009244U1 (de) Routing von Datenverkehr innerhalb von und zwischen autonomen Systemen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition