DE60002202T2

DE60002202T2 - Kommunikation zwischen softwarekomponenten

Info

Publication number: DE60002202T2
Application number: DE60002202T
Authority: DE
Inventors: Julian Simon Ipswich POWERS; Reuben Michael Felixstowe HINDS
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1999-06-11
Filing date: 2000-06-09
Publication date: 2004-02-05
Anticipated expiration: 2020-06-10
Also published as: AU5238300A; DE60002202D1; EP1192539B1; JP2003502729A; ATE237839T1; US7290264B1; WO2000077630A1; JP4546009B2; EP1192539A1

Description

Die vorliegende Erfindung bezieht sich auf die Schaffung eines Verfährens und einer Vorrichtung zur Schaffung einer Kommunikation zwischen zwei oder mehr Software-Elementen. Die hier offenbarte Erfindung kann insbesondere, jedoch nicht ausschließlich, auf dynamische verteilte Echtzeitsysteme mit hochmobilen Software-Elementen angewendet werden.
Anhand der 1 und 2 werden wohlbekannte Beispiele heutiger Architekturen diskutiert, die von derartigen Anwendungen verwendet werden, um die Wechselwirkung einer Anzahl von Clients zu ermöglichen.
1(a) zeigt eine sehr einfache Verbindung jedes Clients mit allen anderen Clients. Es ist klar, daß ein derartiger Zugang sehr schnell unpraktisch wird, während die Anzahl der Clients steigt. Es könnte leicht gewünscht werden, daß beispielsweise einhundert Clients in Wechselwirkung treten sollen.
1(b) zeigt einen anspruchsvolleren Zugang, bei dem jeder Client mit einem einzelnen zentralen Server verbunden ist. Das Konzept einer Client/Server-Anordnung und die zugeordnete Terminologie sind wohlbekannt. Allerdings wird dieser Zugang ebenfalls unpraktisch, wenn die Anzahl der Clients zu steigen beginnt. Wenn beispielsweise einhundert Clients auf irgendeine nichttriviale Weise in Wechselwirkung treten sollten, würde ein einzelner heutiger Server einfach sowohl von der Rechenlast als auch von dem Netzverkehr überwältigt werden.
2 zeigt einen anspruchsvolleren Zugang, bei dem jeder aus einer Anzahl von Clients nun über eine Schnittstelle nicht mit einem einzelnen zentralen Server, sondern mit einem Server-Cluster, der mehrere Server umfaßt, verbunden ist. Während dieser Zugang die Fähigkeit erhält, das Management der Anwendung auf zentrale Weise in dem Server-Cluster auszuführen, ermöglicht er außerdem, sowohl die Rechenlast als auch den Netzverkehr unter den mehreren Servern des Server-Clusters zu verteilen.
Es ist wohlbekannt, daß ein sogenannter objektorientierter Zugang zur Computerprogrammierung während der vergangenen Jahre weitverbreitet geworden ist, wobei Anwendungen wie etwa große Mehrspielerspiele keine Ausnahme sind. Das Konzept eines Objekts und die zugeordnete Terminologie sind wohlbekannt. Zur Bezugnahme auf ein Spielobjekt, d. h. auf irgendeine selbständige Gruppierung von Code und Daten, welche einen Aspekt einer Spielimplementierung darstellt, wird hier der Begriff 'Spielkomponente' verwendet.
Typischerweise führt jeder der Server des Server-Clusters mehrere Prozesse aus, wobei jeder Prozeß mehrere Spielkomponenten hostet. Selbstverständlich gibt es bei diesem Zugang einige Komponenten, beispielsweise einen sogenannten 'Anmeldemanager', die lediglich einmal an einem festen Ort zu instanziieren sind. Andere Komponenten, beispielsweise eine Desintegratorpistole, könnten mehrmals, an verschiedenen Orten instanziiert werden. Tatsächlich könnte es sehr gut der Fall sein, daß eine derartige Komponente von einem ersten Spieler, der an einem ersten Client spielt, an einen zweiten Spielspieler, der an einem zweiten Client spielt, übergeben wird. Auf diese Weise müßte die Komponente von dem ersten Client nach oben zu dem Server-Cluster und daraufhin nach unten zu dem zweiten Client bewegt werden.
Diese Architektur muß außerdem auf verschiedene Weise dynamisch sein.
Während die Größe oder die Komplexität derartiger Mehrspielerspiele wächst oder während die Anzahl der verbundenen Clients wächst, kann erwünscht sein, die Anzahl der Server in dem Server-Cluster zu erhöhen. Wie oben erwähnt wurde, können auf diese Weise die Rechenlast im Zusammenhang mit dem Hosten des Spiels und der während des Spielens des Spiels erzeugte Netzverkehr über eine Anzahl einzelner Server verteilt oder ausgeglichen werden. Außerdem kann erwünscht sein, neue Server mit einer besonderen Funktionalität, beispielsweise eine anspruchsvolle Maschine für künstliche Intelligenz (AI-Maschine), mit dem Server-Cluster zu verbinden.
Ferner kann es sehr gut der Fall sein, daß sich die Rechenaufgaben, die unterhalten werden müssen, ändern, während sich die Spielumgebung entwickelt. Möglicherweise müssen bei Bedarf neue Prozesse erzeugt und alte Prozesse vernichtet werden.
Der Entwickler von Anwendungen wie etwa großen Mehrspielerspielen sieht sich somit einer beträchtlichen Herausforderung gegenüber, mit einer derartigen hochdynamischen und verteilten Architektur zu arbeiten. Es ist klar, daß insbesondere das Problem gestellt wird, eine derartige Echtzeitkommunikation mit niedriger Latenzzeit zwischen den verteilten Spielkomponenten zu erlauben, die es erlaubt, ein hochdynamisches und verteiltes Mehrspielerspiel zu spielen.
Ausgehend von dem wie obenerwähnten breiten Interesse an der objektorientierten Computerprogrammierung ist wohlbekannt, daß es gegenwärtig eine Anzahl von Zugängen gibt, um zu erlauben, daß Objekte miteinander kommunizieren. Von besonderem Interesse hinsichtlich des obenerwähnten Problems sind die verschiedenen Zugänge, die erlauben, daß sogenannte verteilte Objekte, d. h. über ein Client/Server-System verteilte Objekte, miteinander kommunizieren.
Eine gute Einführung ist zu finden in 'The Essential Distributed Objects Survival Guide' von Robert Orfali, Dan Harkey und Jeri Edwards, veröffentlicht von John Wiley & Sons, Inc., 1996.
Als ein erstes Beispiel könnte eine Client/Server-Implementierung einfach unter Verwendung der Standard-Übertragungssteuerprotokoll/Internetprotokoll-Berkeley-Socket-API (TCP/IP-Berkeley-Socket-API) implementiert werden. Allerdings würden sofort viele Probleme einschließlich der folgenden entstehen:

(a) Jeder Client müßte ständig Verbindungen mit allen relevanten Server-Prozessen erzeugen und vernichten (wobei sich die Definition von 'relevant' regelmäßig ändert), was Latenzzeit- und Verarbeitungsorganisationsaufwands-Probleme einbringt.
(b) Spielkomponenten, die ihren Ort ändern (d. h. sich zwischen Prozessen bewegen), erzeugen Probleme der Ortsverfolgung und der Datensequentialisierung. Während eine TCP/IP-Verbindung die Datenordnung zwischen jedem Ende sicherstellt, umfassen Kommunikationen zwischen mobilen Spielkomponenten mehrere TCP/IP-Verbindungen, bei denen keine relativen Sequenzinformationen unterhalten werden.
(c) Die Zwangssequentialisierung von TCP/IP-Übertragungsstrecken kann die wahrgenommene Latenzzeit zwischen Clients in der Umgebung drastisch erhöhen. Wenn beispielsweise in der Sequenz 'Der Spieler A sagt hallo, der Spieler B schießt auf dich das erste Element beim Übergang verloren geht, wird das zweite Element verzögert, während ein Zeitablauf/Wiederübertragungs-Mechanismus aufgerufen wird.

Eine weitere einfache Implementierung könnte statt TCP/IP das Anwenderdatagrammprotokoll/Internetprotokoll (UDP/IP) nutzen. Während das Zwangssequentialisierungsproblem beseitigt wird, wird allerdings beispielsweise auch irgendein Konzept der Datensequentialisierung oder der zuverlässigen Lieferung beseitigt.
Die jetzt wohlbekannte sogenannte Common Object Request Broker Architecture (CORBA) und das Distributed Component Object Model (DCOM) schaffen allgemeine Mechanismen zur gemeinsamen Nutzung von Informationen zwischen verteilten Objekten über ein Netz. Allerdings besteht die Grundlage des CORBA/DCOM-Zugangs darin, die Existenz des Netzes selbst zu versuchen und zu verbergen, indem eine einheitliche Objektschnittstelle geschaffen wird. Obgleich dies leistungsfähige Techniken sind, sind sie nicht anwendbar auf stark zeitkritische und verkehrsvolumenempfindliche Anwendungen. Statt dessen ist es wesentlich, die Steuerung darüber aufrechtzuerhalten, wie der Netzverkehr verteilt und behandelt wird. Verwandte Technologien können beispielsweise auf dem asynchronen Auslesen von Nachrichten aus einer zentralen Wartschlange beruhen.
Ein typisches derartiges System des Standes der Technik ist offenbart von Birrell in "Network Objects": Software Practice & Experience, GFB, John Wiley & Sons, Bd. 25, Nr. SO4, S. 87-130.
Diese heutigen Zugänge können einfach keine Lösung zu dem oben dargestellten Problem liefern.
Gemäß einem ersten Aspekt der Erfindung wird jedoch ein Verfahren zur Schaffung einer Kommunikation zwischen zwei oder mehr Software-Elementen geschaffen, bei dem Hostcomputer-Mittel so beschaffen sind, daß sie Anwendungsprogramme für Anwendungssoftware-Elemente in einem Host-Raum hosten, wobei zwei oder mehr Anwendungssoftware-Elemente in dem Host-Raum gekostet werden; dadurch gekennzeichnet, daß das Verfahren umfaßt:
Herstellen einer Zuordnung zwischen jedem Anwendungssoftware-Element und einem Kommunikationssoftware-Element, über das Nachrichten gesendet und/oder empfangen werden sollen;
Halten des Kommunikationszustandes jedes zugeordneten Anwendungssoftware-Elements in seinem zugeordneten Kommunikationssoftware-Element;
jedem Anwendungssoftware-Element erlauben, mit anderen Anwendungssoftware-Elementen zu kommunizieren, indem Nachrichten über die jeweils zugeordneten Kommunikationssoftware-Elemente gesendet und empfangen werden; und
jedem Anwendungssoftware-Element und dem zugeordneten Kommunikationssoftware-Element erlauben, sich in dem Host-Raum zu bewegen.
Das Halten des gesamten Kommunikationszustands in dem Kommunikationssoftware-Element, das irgendeinem gegebenen Software-Element zugeordnet ist, erlaubt, daß die Verbindung von Anwendungssoftware-Element und Kommunikationssoftware-Element auf besonders dynamische Weise kommuniziert und sich bewegt. Der folglich ermöglichte Nachrichtenaustausch, der auf Einzelelementgrundlage ausgeführt wird, erlaubt die Kontinuität der Kommunikation zwischen Software-Elementen, selbst wenn sie sich auf eine so dynamische Weise bewegen.
Gemäß einem weiteren Aspekt der Erfindung wird eine Vorrichtung zum Schaffen einer Kommunikation zwischen zwei oder mehr Softwareelementen geschaffen, die umfaßt:
Hostcomputer-Mittel, die so beschaffen sind, daß sie Anwendungsprogramme für Hostanwendungssoftware-Elemente in einem Rost-Raum hosten;
zwei oder mehr Anwendungssoftware-Elemente, die in dem Host-Raum gehostet werden;
Nachrichtenaustauschmittel, die so beschaffen sind, daß sie einen Nachrichtenaustausch zwischen Kommunikationssoftware-Elementen ermöglichen; und
Bewegungsmittel, die so beschaffen sind, daß sie Softwareelementen erlauben, sich in dem Host-Raum (300) zu bewegen;
dadurch gekennzeichnet, daß zwischen jedem Anwendungssoftware-Element und einem entsprechenden Kommunikationssoftware-Element, über das Nachrichten gesendet und/oder empfangen werden, eine Zuordnung vorhanden ist; und
jedes Kommunikationssoftware-Element den Kommunikationszustand des zugeordneten Anwendungssoftware-Elements hält.
Wieder erlaubt das Halten des gesamten Kommunikationszustands in dem Kommunikationssoftware-Element, das irgendeinem gegebenen Software-Element zugeordnet ist, daß die Verbindung von Anwendungssoftware-Element und Kommunikationssoftware-Element auf besonders dynamische Weise kommuniziert und sich bewegt. Der folglich ermöglichte Nachrichtenaustausch, der auf Einzelelement grundlage ausgeführt wird, erlaubt die Kontinuität der Kommunikation zwischen Software-Elementen, selbst wenn sie sich auf eine so dynamische Weise bewegen.
Es wird nun eine Ausführungsform der Erfindung beispielhaft mit Bezug auf die beigefügte Zeichnung beschrieben, in der:
3 einen Server-Computer-Cluster zeigt, der zur Verwendung mit der Erfindung geeignet ist;
4 einen Prozeßablaufplan für die Endpunktkennungszuweisung zeigt;
5 einen Prozeßablaufplan für einen Nachrichtenaustausch von Komponente zu Komponente zeigt;
6 einen Prozeßablaufplan für die Endpunktbewegung zeigt;
7 eine Client/ Server-Anordnung zeigt, die zur Verwendung mit der Erfindung geeignet ist;
8 eine weitere geeignete Client/ Server-Anordnung zeigt; und
9 einen weiteren Prozeßablaufplan für den Nachrichtenaustausch zeigt.
SERVER-CLUSTER-ARCHITEKTUR
3 zeigt ein Beispiel eines einfachen Server-Clusters (300) und einer Netzkonfiguration, die zur Verwendung mit dieser beispielhaf ten Ausführungsform der Erfindung geeignet sind. Der geeignete Server-Computer-Cluster (300) ist in der Weise gezeigt, daß er einen ersten Server-Computer (301), einen zweiten Server-Computer (302) und einen dritten Server-Computer (303) besitzt, die über ein lokales Netz (LAN) (304) miteinander verbunden sind. Geeignete Computer, auf denen beispielsweise eine Art Unix (Irix, Linux und Solaris) oder Microsoft Windows^TM ausgeführt wird, sind wohlbekannt. Wie anhand von 7 weiter unten diskutiert wird, können mit dem Server-Computer-Cluster 300 eine Anzahl von (in 3 nicht gezeigten) Client-Computern verbunden sein.
Der erste Server-Computer (301) hostet einen ersten und einen zweiten Server-Prozeß (305, 306), während der zweite Server-Computer (302) einen dritten Server-Prozeß (307) hostet. Jeder derartige Server-Prozeß (305, 306, 307) hostet eine oder mehrere anwendungsbezogene Komponenten (308, 310, 312, 314). Wie oben diskutiert wurde, wird jede Komponente zur Beschreibung einer selbständigen Gruppierung von Code und Daten verwendet, die einen Aspekt einer Anwendungsimplementierung darstellt. Anstelle von Komponente oder Objekt kann in gleicher Weise der Begriff "Software-Element" verwendet werden.
Was einen Spielentwickler betrifft, könnten die Server-Prozesse (305, 306, 307) beispielsweise Räume in einer virtuellen Umgebung darstellen. Die in diesen Prozessen gehosteten Komponenten (308, 310, 312, 314) könnten dann Objekte in diesen Räumen sein. Häufig müssen sich diese Objekte bewegen können, wobei die Avatare der Figur in dem Spiel ein offensichtliches Beispiel sind, wobei aber beispielsweise eine Desintegratorpistole aufgenommen und von einem Raum zum anderen bewegt werden könnte.
Wie erläutert wird, ist jeder Komponente (308, 310, 312, 314) ein sogenannter 'Endpunkt' (309, 311, 313, 315) zugeordnet. Jeder derartige Endpunkt besitzt eine eindeutige systemweite Adresse. Wie deutlich wird, besteht der Zweck dessen, den Komponenten derartige Endpunkte zuzuordnen, darin, zu erlauben, daß die Komponenten über das Senden und Empfangen von Nachrichten über ihre jeweiligen Endpunkte miteinander kommunizieren.
Es sind eine erste, eine zweite, eine dritte und eine vierte Komponente (308, 310, 312, 314) gezeigt, die jeweils einen ersten, einen zweiten, einen dritten und einen vierten Endpunkt (309, 311, 313, 315) besitzen. Die erste und die zweite Komponente (308, 310) und ihre zugeordneten Endpunkte (309, 311) befinden sich in dem ersten Server-Prozeß (305), der auf dem ersten Server-Computer (301) gehostet wird. Die dritte Komponente und der zugeordnete Endpunkt (312, 313) befinden sich in dem zweiten Server-Prozeß (306), der auf dem ersten Server-Computer (301) gekostet wird. Die vierte Komponente und der zugeordnete Endpunkt (314, 315) befinden sich in dem dritten Server-Prozeß (307), der auf dem zweiten Server-Computer (302) gekostet wird.
Das Senden von Nachrichten an und von Komponenten, die sich in verschiedenen Server-Prozessen befinden, wird durch die Verwendung von Server-Nachrichtenaustausch-Schnittstellen (316, 317) erreicht. Pro Server ist eine derartige Server-Nachrichtenaustausch-Schnittstelle (SMI) vorgesehen. Somit wird der Nachrichtenaustausch zwischen den gezeigten Endpunkten durch erste und zweite Server-Nachrichtenaustausch-Schnittstellen (316, 317) behandelt, die auf dem ersten beziehungsweise auf dem zweiten Server-Computer (301, 302) gehostet werden.
Jede Server-Nachrichtenaustausch-Schnittstelle unterhält ein Leitwegtabellenpaar. Eine Tabelle abgehender Leitwege bildet eine Ziel-Endpunktadresse auf die für den Server-Prozeß verantwortliche Server-Nachrichtenaustausch-Schnittstelle ab, in der die Ziel-Endpunktadresse zu finden ist. Eine Tabelle ankommender Leitwege ordnet eine Ziel-Endpunktadresse dem auf dem Server ausgeführten Server-Prozeß zu, für den diese Server-Nachrichtenaustausch-Schnittstelle verantwortlich ist, in der die Ziel-Endpunktadresse zu finden ist. Die erste Server-Nachrichtenaustausch-Schnittstelle (316) ist in der Weise gezeigt, daß sie eine erste Tabelle (318 bzw. 319) ankommender und abgehender Leitwege besitzt. Die zweite Server-Nachrichtenaustausch-Schnittstelle (317) ist in der Weise gezeigt, daß sie eine zweite Tabelle (320 bzw. 321) ankommender und abgehender Leitwege besitzt. Wie unten diskutiert wird, werden diese Leitwegtabellen bei solchen Ereignissen wie der Erzeugung und Bewegung von Endpunkten und ihren zugeordneten Komponenten aktualisiert.
ERZEUGUNG VON KOMPONENTEN UND ENDPUNKTEN UND ZUWEISUNG VON ADRESSEN
Anhand von 3 und von 4, einem Prozeßablaufplan für die Endpunktadressenzuweisung, wird nun der Prozeß gezeigt, durch den die Zuordnung einer eindeutigen systemweiten Kennung zu einem Endpunkt stattfindet.
Der dritte Server-Computer (303), der in dem LAN (304) mit dem ersten und mit dem zweiten Server-Computer (301, 302) verbunden ist, wirkt in dieser Ausführungsform als sogenannter Endpunktlokalisierungs-Server. In einem ersten Schritt (400) weist der Endpunktlokalisierungs-Server 303 beim Start einer neuen Server-Nachrichtenaustausch-Schnittstelle einen Block von Kennungen zur Freigabe an die neu erzeugten Endpunkte zu und sendet ihn an die neue Server-Nachrichtenaustausch-Schnittstelle.
In einem zweiten Schritt (401) weist die Server-Nachrichtenaustausch-Schnittstelle beim Start eines neuen Server-Prozesses in dem Server, dem die Server-Nachrichtenaustausch-Schnittstelle zugeordnet ist, einen Unterblock von Kennungen zur Freigabe an die neu erzeugten Endpunkte zu und sendet ihn an den neuen Prozeß. Auf diese Weise ist dieser Unterblock von Kennungen für den Server-Prozeß verfügbar, um ihn, wie und wann gefordert, zuzuweisen.
Der Prozeß der Erzeugung eines Komponentenobjekts, der gemäß der Steuerung des Anwendungs-Server-Prozesses stattfindet, umfaßt die Zuweisung einer derartigen Kennung. Damit eine Komponente mit anderen Komponenten in anderen Prozessen kommunizieren kann, muß ihr ein Endpunkt zugeordnet sein. Somit erfolgt während des Prozesses der Instanziierung einer Komponente durch den fraglichen Server-Prozeß typischerweise ein Ruf, der die Erzeugung eines Endpunkts anfordert.
Daraufhin erzeugt der Server-Prozeß wie gefordert ein Endpunktobjekt, was in einem dritten Schritt (402) das Zuweisen einer der Kennungen von dem durch den Server-Prozeß gehaltenen Unterblock zu dem Endpunkt einschließt. Beispielhaft kann in der vorliegenden Ausführungsform für jeden Endpunkt eine systemweite 32-Bit-Kennung vorgesehen sein.
Wie weiter unten diskutiert wird, enthält der Endpunkt allerdings nicht nur diese Systemkennung, sondern auch den vollständigen Kommunikationszustand der zugeordneten Komponente.
Wenn ein Endpunkt erzeugt worden ist, kann der Server-Prozeß daraufhin einen Zeiger an die Komponente zurückgeben, der diesen Endpunkt an die Komponente bindet. Typischerweise kann die Komponente daraufhin eine Reihe von Funktionsadressen an den Endpunkt liefern, was erlaubt, daß der Endpunkt asynchrone Ereignisse (beispielsweise beim Empfang einer Nachricht für die Komponente) zurück an die Komponente übermittelt.
In einem vierten Schritt (403) wird die Adresse, die dem Endpunkt zugeordnet ist, der der neu instanziierten Komponente zugewiesen ist, der Server-Nachrichtenaustausch-Schnittstelle bekanntgemacht. Daraufhin aktualisiert die Server-Nachrichtenaustausch-Schnittstelle ihre Tabelle ankommender Leitwege.
In einem fünften Schritt (404) wird diese Bekanntmachung weiter an den Endpunktlokalisierungs-Server 303, den globalen Endpunktkennungsspeicher, übergeben.
Es ist klar, daß die oben angegebenen Schritte in einer anderen Reihenfolge als der gezeigten ausgeführt werden können. Beispielhaft können beispielsweise die Rückgabe des Endpunkts an die neue instanziierte Komponente und das Einhaken des Endpunkts an die relevanten Rückruffunktionen durch die Komponente nach dem obigen vierten und fünften Schritt ausgeführt werden.
Auf diese Weise können von dem für die Instanziierung verantwortlichen Server-Prozeß direkt Adressen zugewiesen werden, die dem Endpunkt eine systemweite Kennung erlauben, falls und wenn neue Komponentenobjekte instanziiert werden und somit neue Endpunkte erfordern, um über sie zu kommunizieren. Es braucht keine asynchrone Anforderung zu einem fernen Adressenzuweisungsprozeß erfolgen, die eine unzweckmäßige Verzögerung umfaßt.
Sollten einem besonderen Server-Prozeß die Adressen ausgehen, falls beispielsweise die Anzahl der für ihn verfügbaren Adressen unter einen vorgegebenen Schwellenwert fällt, kann der Server-Prozeß einen weiteren Unterblock von der Server-Nachrichtenaustausch-Schnittstelle anfordern, bevor er sie zuweisen muß. Gleichfalls kann die Server-Nachrichtenaustausch-Schnittstelle, sollten ihr die Adressen ausgehen, auf ähnliche Weise einen neuen Block von dem Endpunktlokalisierungs-Server anfordern.
Ferner könnte durch den Endpunktlokalisierungs-Server ein vordefinierter Block systemweiter Adressen von diesem Prozeß zurückgehalten werden, um für Objekte mit besonderer Wichtigkeit statische Adressen zu liefern.
Ferner kann der Endpunktlokalisierungs-Server verfolgen, welche Intensitätsblöcke er ausgegeben hat, wobei er die Anzahl der Entitäten verfolgen kann, die in jedem Block ungenutzt bleiben. Wenn ein Endpunkt freigegeben wird, wird der Endpunktlokalisierungs-Server durch die relevante Server-Nachrichtenaustausch-Schnittstelle benachrichtigt, wobei er die ungenutzte Kennungszählung in dem relevanten Block dekrementieren kann. Auf gleiche Weise werden alle noch nicht zugewiesenen Kennungen an den Endpunktlokalisie rungs-Server zurückgegeben, so daß sie von den relevanten Blöcken abgehakt werden können, falls ein Prozeß abgeschlossen wird. Wenn die Zählung ungenutzter Kennungen für irgendeinen gegebenen Block null erreicht, kann der Block daraufhin zur Neuausgabe an den Pool zurückgegeben werden.
EINFACHER NACHRICHTENAUSTAUSCH ZWISCHEN ORTSFESTEN OBJEKTEN
Die in dem gleichen Prozeß gekosteten Komponenten können direkt kommunizieren, indem sie Methodenrufe zueinander vornehmen. Komponenten, die in verschiedenen Prozessen gekostet, aber auf dem gleichen Server-Computer ausgeführt werden, während sie den Endpunktmechanismus verwenden, können den gemeinsam genutzten Speicher nutzen, so daß Nachrichten, die sich zwischen Prozessen bewegen, obgleich der Nachrichtensendemechanismus unabhängig davon, wo das Ziel ist, gleich aussieht, einfach dadurch übertragen werden, daß Zeiger herumgereicht werden.
Allerdings ist gemäß der Erfindung für die Kommunikation zwischen Komponenten, die sich auf verschiedenen Server-Computern befinden, die Verwendung von Endpunkten wie folgt erforderlich.
Es gibt eine Vielzahl von Mechanismen, damit Komponenten die Existenz anderer relevanter Komponenten entdecken. Um das obige Beispiel von Server-Prozessen zu nehmen, die Räume in einer virtuellen Umgebung darstellen, kann für jeden Raum ein RoomManager-Objekt erzeugt werden. Daraufhin können alle in jedem Raum instanziierten Komponenten eine Nachricht an das RoomManager-Objekt senden, um es über ihre Existenz zu informieren. Daraufhin kann jedes RoomManager-Objekt seinerseits durch Nachrichtenaustausch der in den jeweiligen Räumen vorhandenen Komponenten die Wechselwirkung überwachen.
Anhand von 3 und des Prozeßablaufplans für den Nachrichtenaustausch von Komponente zu Komponente aus 5 wird nun beispielhaft der Prozeß des Sendens einer Nachricht von der ersten Komponente an die vierte Komponente veranschaulicht.
In einem ersten Schritt (500) erzeugt die erste Komponente (308), die in dem ersten Server-Prozeß (305) auf dem ersten Server (301) gehostet wird, eine Nachricht, die für die vierte Komponente (314) bestimmt ist, die in dem dritten Server-Prozeß (308) auf dem zweiten Server (302) gekostet wird. In einem zweiten Schritt (501) wird diese Nachricht an den zugeordneten ersten Endpunkt (309) übergeben. In einem dritten Schritt (502) wird die Nachricht daraufhin mit der Angabe, daß sie an die vierte Komponente (314) gesendet werden soll, an die erste Server-Nachrichtenaustausch-Schnittstelle (316) gesendet, wobei dies die Server-Nachrichtenaustausch-Schnittstelle ist, die dem Server (301) zugeordnet ist, auf dem der erste Server-Prozeß (305) ausgeführt wird.
In einem vierten Schritt (503) schlägt die erste Server-Nachrichtenaustausch-Schnittstelle (316) in der zugeordneten ersten Tabelle (319) abgehender Leitwege nach, um herauszufinden, welche Server-Nachrichtenaustausch-Schnittstelle für den Server-Prozeß verantwortlich ist, in dem sich die Komponente befindet, an die die Nachricht adressiert ist. Falls eine Leitwegtabelle, wie weiter unten diskutiert wird, keine gecachede Kopie der geforderten Adresse besitzt, kann sie über das LAN eine Anforderung an den Endpunktlokalisie rungs-Server (303) senden. Der Endpunktlokalisierungs-Server (303) antwortet daraufhin mit der geforderten Adresse der Komponente, wie sie ihm am besten bekannt ist. Daraufhin kann die Server-Nachrichtenaustausch-Schnittstelle (316) diese zurückgegebene Adresse zur zukünftigen Verwendung cachen. In diesem Beispiel gibt entweder die Leitwegtabelle (319) oder der Endpunktlokalisierungs-Server (303) an, daß die Nachrichten für die vierte Komponente (314) an die zweite Server-Nachrichtenaustausch-Schnittstelle (317) gesendet werden sollen.
In einem fünften Schritt (504) sendet die erste Server-Nachrichtenaustausch-Schnittstelle (316), die auf dem ersten Server-Computer (301) gehostet wird, die Nachricht über das LAN (304) an die zweite Server-Nachrichtenaustausch-Schnittstelle (317), die auf dem zweiten Server-Computer (302) gehostet wird. In einem sechsten Schritt (505) schlägt daraufhin die zweite Server-Nachrichtenaustausch-Schnittstelle (317) in der zugeordneten zweiten Tabelle (320) ankommender Leitwege nach, um zu bestimmen, in welchem Server-Prozeß der Endpunkt gehostet wird, der der vierten Komponente (314) zugeordnet ist, an den die Nachricht zu senden ist. Die zweite Tabelle (320) ankommender Leitwege sollte die Informationen, die den Server-Prozeß identifizieren, in dem die vierte Komponente (314) gehostet wird, entweder wenn die vierte Komponente (314) in dem dritten Server-Prozeß (307) instanziiert wurde oder wenn die vierte Komponente (314) von woanders zu dem dritten Server-Prozeß (307) bewegt wurde gecached haben. Die Bewegung dieser Komponenten wird weiter unten diskutiert.
In diesem Beispiel offenbart die Tabelle (320) ankommender Leitwege, daß sich der vierte Endpunkt (315), der der vierten Komponente (314) zugeordnet ist, in dem dritten Server-Prozeß (307) befindet. In einem siebenten Schritt (506) sendet die zweite Server-Nachrichtenaustausch-Schnittstelle (317) daraufhin die Nachricht an den vierten Endpunkt (315), der in dem dritten Server-Prozeß (307) gehostet wird. In einem achten Schritt (507) übergibt der vierte Endpunkt (315) die Nachricht daraufhin an die vierte Komponente (314).
In dem Obenstehenden wird angemerkt, daß die Nachricht selbst nicht immer herumgereicht wird. Lediglich dann, wenn die Nachricht über das Netz (das LAN 304) gesendet wird, gibt es ein Konzept, daß Bytes gelesen und daraufhin geschrieben werden. Beim Bewegen zwischen einer Server-Nachrichtenaustausch-Schnittstelle und ihren zugeordneten Server-Prozessen gibt es effektiv lediglich einen Schlüssel zu der Nachricht, der herumgesendet wird (wobei er typischerweise nur wenige Bytes groß ist). Dieser Schlüssel kann schnell zurück auf einen Zeiger auf die tatsächlichen Nachrichtendaten abgebildet werden.
BEWEGTE OBJEKTE
Wie oben angegeben wurde, besteht eines der Ergebnisse dessen, daß der gesamte Kommunikationszustand in dem Endpunkt gehalten wird, der irgendeiner gegebenen Komponente zugeordnet ist, darin, daß die Verbindung von Komponente und Endpunkt geeignet wird, auf dynamische Weise zwischen Prozessen bewegt zu werden. Der Nachrichtenaustausch gemäß der Erfindung, der auf Einzelobjektgrundlage ausgeführt wird, ermöglicht die Kontinuität der Kommunikation zwischen Komponenten, selbst wenn sie sich auf eine so dynamische Weise bewegen.
Die Komponenten treten in vielen Sorten an Form und Größe auf. Eine Komponente kann durch einen Server-Prozeß angewiesen werden, sich von einem Prozeß zu einem anderen zu bewegen. Daraufhin kann die Komponente durch den ersten Prozeß serialisiert und als Nachricht an den Zielprozeß gesendet werden. Daraufhin kann diese Nachricht beim Empfang in dem Zielprozeß entbündelt und die Komponente neu aufgebaut werden. Die Art und Weise, in der die Serialisierung, Übertragung und Entbündelung erfolgt, hängt in großem Umfang von der Wahl des fraglichen Entwicklers ab.
Die Endpunkte müssen gleichfalls mit ihren zugeordneten Komponenten bewegt werden, wobei die Serialisierung, Übertragung und Entbündelung der Endpunkte ausgehend von dem wohlbekannten Wesen der Endpunkte selbst aber auf gleichförmigere Weise ausgeführt werden kann.
Es wird nun anhand von 3 und des Prozeßablaufplans für die Endpunktbewegung aus 6 beispielhaft der Prozeß des Bewegens eines Endpunkts 313 von dem zweiten Server-Prozeß 306 zu dem dritten Server-Prozeß 307 veranschaulicht.
Nach einer Anweisung für den dritten Endpunkt 313, sich zu dem dritten Server-Prozeß 307 zu bewegen, wird die erste Server-Nachrichtenaustausch-Schnittstelle 316 in einem ersten Schritt (600) angewiesen, den Austausch von Nachrichten für den dritten Endpunkt 313 abzuschließen.
In einem zweiten Schritt (601) wird das dritte Endpunktobjekt 313 einschließlich seines Zustands serialisiert. Diese Serialisierung erzeugt eine oder mehrere Paketnachrichten, wobei jeder Anfangs block eine Zielkennung und Bytestrom-Nutzinformationen enthält. (Der Zustand eines Endpunkts kann recht 'groß' sein und insbesondere über der Anzahl der in einer einzelnen Nachricht verfügbaren Bytes liegen.)
Es wird daran erinnert, daß der parallele Prozeß des Transports der zugeordneten Komponente 312, wie oben angegeben wurde, in einer Art und Weise ausgeführt wird, die durch den fraglichen Entwickler (der die vom Entwickler erzeugten Komponenten kennt, was die Ausführung eines effizienten Transfers ermöglich) angegeben wird.
In einem dritten Schritt (602) werden die Nachricht oder die Nachrichten an die erste Server-Nachrichtenaustausch-Schnittstelle 316 übergeben.
In die obenerwähnte Zielkennung sind mittels eines 16-Bit-Wertpaars beispielsweise die Ziel-Nachrichtenaustausch-Schnittstelle 317 und der Zielprozeß 307 codiert, welche entnommen werden können, um zu bestimmen, wohin die Nachrichtenserie weiterzuleiten ist. In diesem Fall ermittelt die erste Server-Nachrichtenaustausch-Schnittstelle 316, daß die Nachricht an die zweite Server-Nachrichtenaustausch-Schnittstelle 317 gesendet werden muß.
In einem vierten Schritt (603) wird die Nachricht an die zweite Server-Nachrichtenaustausch-Schnittstelle 317 gesendet, die diejenige Server-Nachrichtenaustausch-Schnittstelle ist, die für den beabsichtigten Zielprozeß 307 verantwortlich ist. Wie unten diskutiert wird, können diese Nachrichten mit einer Angabe transportiert werden, daß sie anstelle beispielsweise einer Nachricht zwischen Endpunkten höhere Steuerinformationen enthalten.
Außerdem aktualisiert die erste Server-Nachrichtenaustausch-Schnittstelle 316 ihre erste Tabelle ankommender Leitwege, was bewirkt, daß die dritte Komponente 313 nicht mehr in irgendeinem der Prozesse gehostet wird, für die die erste Server-Nachrichtenaustausch-Schnittstelle 316 Verantwortlichkeit besitzt. Sie aktualisiert die erste Tabelle 319 abgehender Leitwege, was bewirkt, daß sich die dritte Komponente 313 zu einem Server-Prozeß bewegt hat, für den die zweite Server-Nachrichtenaustausch-Schnittstelle 317 verantwortlich ist.
In einem fünften Schritt (604) wird die Nachricht daraufhin an den Ziel-Server-Prozeß, in diesem Fall an den dritten Server-Prozeß 307, übergeben.
In einem sechsten Schritt (605) wird die Nachricht daraufhin entbündelt, um, wie gefordert, den dritten Endpunkt 313 in dem dritten Server-Prozeß 307 wieder zu erzeugen. Wenn er wieder erzeugt worden ist, kann der dritte Endpunkt 313 wieder an der dritten Komponente 312 befestigt werden, nachdem sie in dem dritten Server-Prozeß 307 wieder erzeugt worden ist. Es wird angemerkt, daß der Endpunkt 313 als Teil seines Kommunikationszustands, wenn er wieder erzeugt worden ist, Nachrichten, die für seine zugeordnete Komponente 312 bestimmt sind, annehmen und in eine Warteschlange einreihen kann, selbst wenn der parallele Prozeß des Transports der zugeordneten Komponente die Komponente zu diesem Zeitpunkt noch nicht wieder erzeugt hat.
Auf diese Weise haben sich die dritte Komponente 312 und der zugeordnete Endpunkt 313 von dem zweiten Server-Prozeß 306 auf dem ersten Server-Computer 301 zu dem dritten Server-Prozeß 307 auf dem zweiten Server-Computer 302 bewegt. Es ist klar, daß, während die dritte Komponente 312 und der zugeordnete Endpunkt 313 vor der Anweisung, sich zu bewegen, am Nachrichtenaustausch teilnehmen könnten und dies nach der Wiedererzeugung weiter tun können, diese während der kurzen Zeitdauer, während der die Komponente und der zugeordnete Endpunkt im Übergang in der Nachrichtenform sind, keine Nachrichten erzeugen können.
Allerdings kann die erste Server-Nachrichtenaustausch-Schnittstelle 316 im Ergebnis der Aktualisierung der Leitwegtabellen 318, 319 der ersten Server-Nachrichtenaustausch-Schnittstelle 316, falls nach der Bewegung der dritten Komponente 313 von dem zweiten Server-Prozeß 306 durch die erste Server-Nachrichtenaustausch-Schnittstelle 316 Nachrichten für die dritte Komponente 313 empfangen werden, die Nachrichten einfach an die zweite Server-Nachrichtenaustausch-Schnittstelle 317 zur Lieferung an den wiederhergestellten Endpunkt weiterleiten. Insbesondere dann, wenn eine Nachricht für den Endpunkt bei der ersten Server-Nachrichtenaustausch-Schnittstelle 316 eintrifft, nutzt sie zunächst die erste Tabelle 318 ankommender Leitwege, um zu versuchen, sie an den relevanten Prozeß zu liefern. Da sich der Endpunkt 315 nicht mehr in einem Prozeß befindet, für den die erste Server-Nachrichtenaustausch-Schnittstelle 316 verantwortlich ist, schlägt dieser Versuch fehl. Daraufhin leitet die erste Server-Nachrichtenaustausch-Schnittstelle 316 die Nachricht unter Verwendung der ersten Tabelle 319 abgehender Leitwege, die den Ort 307 identifiziert, zu dem sich der Endpunkt 315 bewegt hat, weiter.
Eine noch anspruchsvollere Diskussion des Nachrichtenaustauschs an ungültige Ziele wird weiter unten diskutiert.
CLIENT/SERVER-CLUSTER-ARCHITEKTUR
Wie oben in der Diskussion anhand von 3 angegeben wurde, können mit dem Server-Computer-Cluster 300 eine Anzahl von Client-Computern verbunden sein. Wieder sind geeignete Computer, beispielsweise Computer, die Microsoft Windows^TM ausführen, wohlbekannt.
7 zeigt einen Server-Computer-Cluster, der einen ersten und einen zweiten Server-Computer (700, 701) enthält, wie sie beispielsweise in 3 gezeigt sind. Wieder hostet jeder Server-Computer (700, 701) wenigstens einen jeweiligen Server-Prozeß (702, 703). Erneut hostet jeder Server-Prozeß wenigstens eine jeweilige Komponente (704, 706) und einen jeweiligen zugeordneten Endpunkt (705, 707). Erneut ist jeder Server-Computer (700, 701) mit einer jeweiligen Server-Nachrichtenaustausch-Schnittstelle (708, 709) versehen.
Ferner zeigt 7 eine Anzahl von Client-Computern (710, 711). Jeder Client-Computer hostet wenigstens einen jeweiligen Client-Prozeß (712, 713). Jeder Client-Prozeß hostet wenigstens eine jeweilige Komponente (714, 716) mit einem jeweiligen zugeordneten Endpunkt (715, 717).
Die Client-Computer (710, 711) sind jeweils über einen jeweiligen ersten und zweiten Schnittstellencomputer (718, 719) sowohl mit dem ersten als auch mit dem zweiten Server-Computer (700, 701) des Server-Computer-Clusters verbunden. Jeder Server-Computer (700, 701) ist über eine Übertragungsstrecke mit hoher Bandbreite unter Verwendung eines zuverlässigen Paketverbindungsprotokolls wie etwa TCP/IP mit jedem Schnittstellencomputer (718, 719) verbunden. Jeder Client-Computer (710, 711) ist über eine Übertragungsstrecke mit niedriger Bandbreite wie etwa die, die unter Verwendung eines Modems über eine PSTN-Verbindung bereitgestellt wird, mit nur einem der Schnittstellencomputer (718 bzw. 719) verbunden. Geeignet wird ein unzuverlässiges Paketverbindungsprotokoll wie etwa UDP/IP verwendet. In Bezug auf die erste und zweite Client-Nachrichtenaustausch-Schnittstelle (720, 721) sind der erste und der zweite Schnittstellencomputer (718, 719) vorgesehen.
Es ist wünschenswert, in den Nachrichtenaustauschmechanismus eine Fähigkeit aufzunehmen, 'Hinweise' in Bezug auf das Wesen der Nachricht anzugeben. Diese könnten beispielsweise Angaben in Bezug auf die Nachrichtenpriorität und auf eine Prioritätszeitänderung, eine Lebensdauer, einen Inhaltskombinationsindikator und einen Zuverlässigkeitsmerker umfassen. Auf diese Weise können die Client-Nachrichtenaustausch-Schnittstellen (720, 721) auf die Hinweise, die jeder Nachricht zugeordnet sind, insbesondere unter Umständen, in denen auf der Übertragungsstrecke mit niedriger Bandbreite eine Stauung vorhanden ist, reagieren, um das Management des Übertragungsstreckenverkehrs zu den Clients so effektiv wie möglich auszuführen.
Ein besonders geeignetes und vorteilhaftes Schema für ein derartiges Management einer Übertragungsstrecke mit niedriger Bandbreite ist in der Patentanmeldung des Anmelders im Vereinigten Königreich, GB 9907445.2, angegeben, deren Priorität von der veröffentlichten internationalen Patentanmeldung WO00/62506 beansprucht wird.
Eine Spielkomponente (704), die in einem Server-Prozeß (702) gehostet wird, kann eine Nachricht erzeugen, die für eine Spielkomponente (714) bestimmt ist, die sich in einem Client-Prozeß (712) befindet. Diese Nachricht kann daraufhin über den Endpunkt (705) gesendet werden, der dieser Spielkomponente (704) zugeordnet ist. Daraufhin wird die Nachricht an die Server-Nachrichtenaustausch-Schnittstelle (708) übergeben, die dem Server (700) zugeordnet ist, auf dem dieser Prozeß ausgeführt wird. Die Server-Nachrichtenaustausch-Schnittstelle (708) kann in der Adressierungstabelle nachschlagen, um zu ermitteln, welche Client-Nachrichtenaustausch-Schnittstelle (720) für den Client-Prozeß (712), in dem sich die Komponente (714) befindet, an die die Nachricht adressiert ist, verantwortlich ist.
Es ist klar, daß die Server-Nachrichtenaustausch-Schnittstelle (316, 708) beim Versuch zu bestimmen, wo der Zielendpunkt 'erreicht' werden kann, die relevante Nachrichtenaustausch-Schnittstelle lokalisiert. Diese Nachrichtenaustausch-Schnittstelle könnte entweder (wie in dem oben anhand von 5 diskutierten Beispiel) eine weitere Server-Nachrichtenaustausch-Schnittstelle (317) oder (wie in diesem Fall) eine Client-Nachrichtenaustausch-Schnittstelle (720) sein.
Daraufhin sendet die Server-Nachrichtenaustausch-Schnittstelle (708) die Nachricht an die relevante Client-Nachrichtenaustausch-Schnittstelle (720), die auf dem entsprechenden Schnittstellencomputer (718) gehostet wird. Daraufhin kann die Client-Nachrichtenaustausch-Schnittstelle (720) die Nachricht über die Übertragungsstrecke mit niedriger Bandbreite zwischen dem Schnittstellencomputer (718) und dem Client-Computer (710) an den Client-Prozeß (712) senden. Daraufhin kann die Nachricht über den zugeordneten Endpunkt (715) an die Komponente (714) geliefert werden, an die die Nachricht adressiert ist.
Auf dieselbe Weise können die Komponenten (714, 716), die in den Prozessen (712, 713) gehostet werden, die auf den Client-Computern (710, 711) ausgeführt werden, Nachrichten mit Komponenten (706, 704) austauschen, die in den Server-Prozessen (702, 703) gehostet werden.
Es wird angemerkt, daß der Schnittstellencomputer (718, 719) als Alternative ebenso leicht Server-Prozesse hosten könnte, d. h. eine Maschine sowohl eine Server-Nachrichtenaustausch-Schnittstelle als auch eine Client-Nachrichtenaustausch-Schnittstelle ausführen könnte. Während beispielsweise ein Spiel verbreiteter wird, können daraufhin mit der Option, bestimmte Maschinen lediglich für die Ausführung der Client-Nachrichtenaustausch-Schnittstellen zu reservieren, zusätzliche Maschinen hinzugefügt werden.
Ferner können die Server-Nachrichtenaustausch-Schnittstellen/Client-Nachrichtenaustausch-Schnittstellen drei verschiedene Komponenten enthalten:

(a) Nachrichtenaustausch-Schnittstelle – liefert die Ein/Aus-Leitwegtabellen und sendet die Nachricht über das Netz
(b) Server-Nachrichtenaustausch-Schnittstelle – enthält eine Nachrichtenaustausch-Schnittstelle und eine Schnittstelle zu den Server-Prozessen.
(c) Client-Nachrichtenaustausch-Schnittstelle – enthält eine Nachrichtenaustausch-Schnittstelle und eine Schnittstelle zu den Client-Prozessen.

(Obgleich die Server-Nachrichtenaustausch-Schnittstelle und die Client-Nachrichtenaustausch-Schnittstelle zwei verschiedene Prozesse sind, besitzen sie somit einen großen Teil des Codes in Form der Nachrichtenaustausch-Schnittstelle gemeinsam).
Auf diese Weise wird ein verteiltes Client/Server-System beispielsweise zum Spielen von Spielen geschaffen, das gemäß der Erfindung die hochdynamische Verbindung und den Nachrichtenaustausch von Spielkomponenten- und zugeordneten Endpunktobjekten erlaubt.
ANSPRUCHSVOLLE NACHRICHTENAUSTAUSCHMECHANISMEN
Die obige Diskussion des Nachrichtenaustauschs beruhte auf einer verhältnismäßig einfachen Spezifikation des Kommunikationszustands für die Endpunkte, über die das Senden von Nachrichten von einer Komponente zu einer anderen stattfindet. Obgleich aus dem Vorstehenden beispielsweise klar ist, daß eine Sequenz von Nachrichten, die von einer Komponente zu einer anderen gesendet werden, alle zu der gewünschten Zielkomponente geleitet werden können, selbst wenn sich die Komponenten während der Nachrichtenaustauschsequenz bewegen, ist klar, daß dieser einfache Mechanismus nicht sicherstellt, daß die Nachrichtensequenz in der Zielkomponente in der gleichen Reihenfolge empfangen wird, in der sie gesendet wurde. Als eine vollständigere Beschreibung des Kommunikationszustands eines Endpunkts besitzt er typischerweise:

(a) Kennung. 32-Bit-Wert, der in dem System, in dem der Endpunkt erzeugt wurde, eindeutig ist.
(b) eine Liste unverarbeiteter Nachrichten. Dies ist eine Liste von Nachrichten, die an dem Endpunkt angekom men sind, aber noch nicht verarbeitet werden können. Diese wird verwendet, wenn der Endpunkt zu einem neuen Ort bewegt worden ist, aber noch nicht an seinem Objekt befestigt ist.
(c) eine Zusammenstellung abgehender Verteiler (wie diskutiert wird). Dies sind die Verteiler, die das dem Endpunkt zugeordnete Objekt zum Senden von Nachrichten erzeugt hat.
(d) eine Zusammenstellung ankommender Verteiler (wie diskutiert wird). Diese sind mit den abgehenden Verteilern an fernen Endpunkten gepaart und wirken mit ihrem abgehenden Paar, um sicherzustellen, daß die Nachrichten richtig geliefert werden. Beispielsweise geht eine Nachricht, die über einen Datenstrom (siehe unten) geliefert wurde, von einem StreamOut (der ihr eine Sequenznummer gibt) über den Draht zu einem StreamIn, das sicherstellt, daß die Nachrichten vor der Lieferung sortiert werden. Ankommende Verteiler sind unter Verwendung der Techniken gemäß der Erfindung wirksam vor dem Entwickler verborgen, da sie lediglich als Folge der Erzeugung bestimmter Typen des abgehenden Verteilers erzeugt werden.

Es werden nun drei anspruchsvollere Nachrichtenaustauschmechanismen diskutiert, die als (I) "Datenstrom", (II) "Wiederholangabe" und (III) "Quelle" bezeichnet werden.
(I) Der erste derartige Nachrichtenaustauschmechanismus wird als ein 'Datenstrom' bezeichnet. Wenn eine Nachrichtensequenz von dem Endpunkt einer Komponente zu dem Endpunkt einer weiteren Komponente ausgesendet wird, stellt der Aufruf des Datenstrommechanismus für die Sequenz sicher, daß die Sequenz bei dem Zielend punkt in der gleichen Reihenfolge eintrifft, wie sie den sendenden Endpunkt verlassen hat.
Die in einem Datenstrom gesendeten Nachrichten werden zusammen mit ihrem Quell- und Zielendpunkt mit einer Sequenznummer und mit der Kennung des Datenstroms, der verwendet wird, um sie zu senden, bezeichnet. Die Sequenznummer kann verwendet werden, um Nachrichten wieder in ihrer ursprünglichen Sequenz zu ordnen, während sie an ihrem Zielendpunkt eintreffen. Die in einem Datenstrom gesendete Anfangsdatennachricht wird als 'Datenstromstart'-Nachricht gekennzeichnet, wobei sie den empfangenden Endpunkt darüber informiert, daß er einen Verteiler für den ankommenden Datenstrom erzeugen muß, um die in diesem Datenstrom eintreffenden Nachrichten zu behandeln. Die in einem Datenstrom gesendete Endnachricht ist eine 'Datenstromschließ'-Nachricht, die den empfangenden Endpunkt darüber informiert, daß er den zugeordneten Verteiler für den ankommenden Datenstrom vernichten sollte.
Die Erzeugung eines abgehenden Datenstroms erfordert die folgenden Daten:

(a) Kennung. 16-Bit-Wert, der in dem Endpunkt, bei dem er erzeugt wurde, eindeutig ist.
(b) eine Zielendpunktkennung. Das Ziel für über den Datenstrom gesendete Nachrichten.
(c) eine Sequenznummer. Dies ist die auf die nächste Nachricht zu prägende Sequenznummer.
(d) ein gültiger Merker. Wird dazu verwendet zu bestimmen, ob der Datenstrom eine Nichtablieferung an seinem Ziel erfaßt hat.

Die Erzeugung eines ankommenden sequentialisierten Datenstroms erfordert die folgenden Daten:

(a) 16-Bit-Kennung. Dies ist die gleiche wie die Kennung der abgehenden Version des Verteilers, d. h., die Kennung ist für das Ein/Aus-Verteilerpaar gemeinsam.
(b) eine Sequenznummer. Dies ist die Sequenznummer der nächsten Nachricht, die an das dem Endpunkt zugeordnete Objekt zu liefern ist.
(c) eine Liste nicht gelieferter Nachrichten. Dies ist die Liste der Nachrichten, die aus der Sequenz angekommen sind und vor der Lieferung auf fehlende Nachrichten warten müssen.

(II) Der zweite derartige Nachrichtenaustauschmechanismus wird als 'Wiederholangabe' bezeichnet. Eine Wiederholangabe kann verwendet werden, um eine besondere Nachricht an mehrere Ziele zu senden. Falls eine Nachricht von dem Endpunkt einer Komponente ausgesendet und an die mehreren Endpunkte gerichtet ist, die mehreren Zielkomponenten zugeordnet sind, stellt der Aufruf des Wiederholangabemechanismus sicher, daß für alle Zielendpunkte lediglich die minimale Anzahl von Kopien der Nachricht erzeugt werden, um die Nachricht zu empfangen. Falls beispielsweise eine Client-Komponente eine Nachricht sendet, die für die Lieferung an mehrere Komponenten bestimmt ist, die auf dem Server-Computer-Cluster ge hostet werden, stellt der Aufruf des Wiederholangabemechanismus sicher, daß die Nachricht, anstatt eine Kopie pro Zielobjekt zu dem Server-Computer-Cluster heraufzusenden, in nur einer Kopie in den Server-Computer-Cluster heraufgesendet wird, bevor sie wie gefordert kopiert wird, um an jede der Zielkomponenten gesendet zu werden. Wie klar ist, hilft die Verwendung des Wiederholangabemechanismus, den Netzverkehr minimal zu halten.
Die Erzeugung der abgehenden unsequentialisierten Wiederholungsnachrichten erfordert:

(a) Kennung. 16-Bit-Wert, der in dem Endpunkt, bei dem er erzeugt wurde, eindeutig ist.
(b) eine Liste von Zielendpunkten. Das Ziel für Nachrichten, die über die Wiederholangabe gesendet werden.

Abgehende sequentialisierte Wiederholangabe
Eine sequentialisierte Wiederholangabe bietet die gleichen Vorteile wie eine unsequentialisierte Wiederholangabe, d. h. die effektive Verwendung des Netzes und eine Minimierung des erzeugten Verkehrs. Außerdem stellt sie auch sicher, daß alle Nachrichten in der Reihenfolge, in der sie gesendet wurden, an ihre Ziele geliefert werden. Das Management hiervon wird auf ähnliche Weise wie bei einem Datenstromverteiler ausgeführt, wobei an den abgehenden Nachrichten eine Sequenznummer angebracht wird, während es an jedem empfangenden Endpunkt einen ankommenden sequentialisierten Wiederholangabenverteiler gibt. Die einzige zusätzliche Komplikation wird in der folgenden Sequenz von Operationen festgestellt:

1. Die Wiederholangabe r1 gibt es am Endpunkt e1.
2 . Der Endpunkt e2 wird zu r1 hinzugefügt, und die Nachrichten m 1 und m2 werden über die Wiederholangabe r1 gesendet.
3. Der Endpunkt e2 wird von r1 entfernt, und die Nachrichten m3 und m4 werden über die Wiederholangabe r1 gesendet.
4. Der Endpunkt e2 wird erneut zu r1 hinzugefügt, und die Nachrichten m5 und m6 werden über die Wiederholangabe r1 gesendet.
5. Der Endpunkt e2 wird von r1 entfernt.

Es wird angenommen, daß der einfache Datenstrommechanismus (die erste Nachricht wird als 'Start' gekennzeichnet und es gibt eine abschließende Schließnachricht) verwendet wird und daß diese Operationen in schneller Folge ausgeführt werden, wobei zwei getrennte und gültige Sequenzen auf dem Weg zu e2 sind. Diese sind m1+'start flag'/m2/close und m5+'start flag'/m6/close. Falls die Nachrichten-Wiederordnung in dem Netz dazu führen würde, daß die zweite Sequenz zuerst eintreffen würde, würde diese als gültige Sequenz verarbeitet, so daß Nachrichten in der falschen Sequenz geliefert würden.
Die Lösung besteht darin, die von der sequentialisierten Wiederholangabe entfernten Ziele zusammen mit der Sequenznummer, bei der sie entfernt wurden, zu speichern, bis die obige Wettlaufsituation nicht auftreten kann. Die Speicherzeitdauer ist durch die Latenzzeit in dem Netz bestimmt – falls ein Ziel wieder hinzugefügt wird, während die Wettlaufsituation noch möglich ist, wird keine neue Sequenz erzeugt, sondern statt dessen eine Nachricht gesendet, um die Sequenznummer des Empfängers auf den Wert, bei dem die Wiedersendung stattfindet, vorzurücken ("aufzufüllen"). Um das obige Beispiel fortzusetzen, ist die richtige Nachrichtensequenz m1+'start flag'/m2/pad 2 bis 5/m5/m6.
Falls zu der Wiederholangabe in der Zeitdauer, die das Auflösen dieser Wettlaufsituation dauert, kein Ziel hinzugefügt wird, kann daraufhin die abschließende Schließnachricht gesendet werden. Falls, wieder in Fortsetzung des obigen Beispiels, nach Schritt (5) e2 nie wieder zu r1 hinzugefügt wird, ist die abschließende Nachrichtensequenz m1+'start flag'/m2/pad 2 bis 5/m5/m6/...delay.../close.
Die abschließende Schließnachricht bewirkt, daß der ankommende sequentialisierte Wiederholangabenverteiler an dem empfangenden Endpunkt vernichtet wird. Seine Erzeugung erfordert die folgenden Daten:

(a) Kennung. 16-Bit-Wert, der eindeutig in dem Endpunkt ist, bei dem er erzeugt wurde.
(b) eine Liste momentaner Zielendpunkte. Die Ziele für Nachrichten, die über die Wiederholangabe gesendet wurden.
(c) eine Sequenznummer. Dies ist die auf die nächste Nachricht zu prägende Sequenznummer.
(d) eine Liste kürzlich entfernter Zielendpunkte mit ihrer 'Entfernen'-Sequenzzählung und einem "Entfernt-bei"-Zeitpunkt. Diese wird verwendet, um zu verfolgen, welche Endpunkte kürzlich in der Zielliste der Wiederholangabe waren, so daß dann, wenn das Objekt des Endpunkts einen von Ihnen wieder hinzufügt, seine Sequenz nummer von ihrem letzten Wert vorgerückt werden kann, anstatt ihm eine "Sequenzstart"-Nachricht zu senden. Dies ist erforderlich, um Wettlaufsituationen mit schnellen Hinzufügen/Entfernen/Hinzufügen-Sequenzen zu vermeiden.

Die ankommende sequentialisierte Wiederholangabe arbeitet wie für den "Datenstrom", wobei sie aber außerdem einen "Schließ"-Merker enthält, der gesetzt wird, wenn die Sequenz wieder gestartet wird (d. h. wenn der Absender über entferne x, warte, Zeitablauf von x (= sende Schließen an x), füge x hinzu, sende Daten (= sende Startsequenz an) x ging. Falls es einen Wettlauf zwischen der Schließ- und der Startsequenz gibt, könnte sie der Empfänger in der falschen Reihenfolge erhalten, so daß es einen Schließmerker gibt, der bei einer fehlenden Schließung aufgenommen wird.
(III) Der dritte derartige Nachrichtenaustauschmechanismus wird als eine 'Quelle' bezeichnet. Eine Quelle ist dadurch ähnlich einer Wiederholangabe, daß sie das Senden besonderer Nachrichten an mehrere Ziele schafft. Er unterscheidet sich aber von der Wiederholangabe dadurch, daß statt dessen, daß die sendende Komponente wählt, an welche anderen Komponenten zu senden ist, die Komponenten wählen können, Nachrichten, die von einer 'gewählten' Quelle gesendet wurden, zu 'abonnieren'. Eine Quelle ermöglicht somit die 'Veröffentlichung' allgemein verwendeter Nachrichten durch eine Komponente, ohne daß sich die Komponente selbst darum kümmern müßte, wie die Nachrichten an alle Komponenten, die sie benötigen, zu senden sind. Statt dessen kann eine Komponente einfach Nachrichten durch die Verwendung eines Quellmechanismus abonnieren, falls sie Nachrichten von einer besonderen Quellkomponente benötigt.
Die Erzeugung abgehender Nachrichten von einer nicht sequentialisierten Quelle erfordert:

(a) Kennung. 16-Bit-Wert, der eindeutig in dem Endpunkt ist, bei dem er erzeugt wurde.
(b) eine Liste momentaner Zielendpunkte mit einer Abonnementzählung für jedes Ziel. Dies sind die Ziele für die über die Quelle gesendeten Nachrichten. Die Abonnementzählung wird verwendet, um die Anzahl der empfangenen Abonnement/Abbestellungs-Nachrichten zu verfolgen, so daß ein Durcheinanderwerfen der Nachrichtenreihenfolge nicht zu einem ungültigen Abonnementzustand führt.
Die Erzeugung abgehender Nachrichten aus einer sequentialisierten Quelle erfordert die gleichen Daten wie für eine unsequentialisierte Quelle und außerdem
(c) eine Sequenznummer. Dies ist die auf die nächste Nachricht zu prägende Sequenznummer.
(d) eine Liste der jüngsten Zielendpunkte mit ihrer 'Entfernen'-Sequenzzählung und mit einem "Entfernt-bei"-Zeitpunkt. Diese wird verwendet, um zu verfolgen, welche Endpunkte jüngst in der Zielliste der Quelle hinzugefügt wurden, so daß dann, wenn sich das Objekt eines Endpunkts entscheidet, sie wieder hinzuzufügen, seine Sequenznummer von ihrem letzten Wert vorgerückt werden kann, anstatt ihm eine "Startsequenz-"Nachricht zu senden. Dies ist erforderlich, um eine Wettlaufsituation mit schnellen Hinzufügen/Entfernen-Hinzufügen-Sequenzen zu vermeiden.

Die ankommende sequentialisierte Quelle: erfordert die gleichen Daten wie für die sequentialisierte Wiederholangabe.
Es wird angemerkt, daß unsequentialisierte Quellen und Wiederholangaben keine ankommenden Verteiler haben. Während die Nachrichten an ihren Zielen eintreffen, können sie einfach direkt übergeben werden.
Anhand von 8, die eine geeignete Architektur zeigt, sowie von 9, die einen weiteren Prozeßablaufplan zeigt, wird im folgenden beispielhaft der Prozeß des Sendens einer Nachricht von einer Komponente, die in dem Server-Cluster gekostet wird, an eine Anzahl von Komponenten, die auf den jeweiligen Client-Computern gekostet werden, veranschaulicht.
In einem ersten Server-Computer (800), auf dem ein erster Server-Prozeß (801) ausgeführt wird, erfordert eine erste Spielkomponente (802) mit einem zugeordneten Endpunkt, daß eine Zustandsaktualisierungsnachricht an eine zweite, eine dritte und eine vierte Spielkomponente (803, 804, 805) gesendet wird, die jeweils in einem ersten, einem zweiten und einem dritten Client-Prozeß (806, 807, 808) auf einem ersten, einem zweiten und einem dritten Client-Computer (809, 810, 811) gekostet werden.
In einem ersten Schritt (900) fordert die erste Spielkomponente (802) eine Nachricht an und füllt sie mit der erforderlichen Zustandsaktualisierung. Diese Informationen werden direkt in den gemeinsam genutzten Speicher geschrieben.
Daraufhin sendet die erste Spielkomponente (802) die Nachricht in einem zweiten Schritt (901) über ihren zugeordneten Endpunkt an die relevante vordefinierte Wiederholangabe, die in der Server-Nachrichtenaustausch-Schnittstelle (812) gehostet wird. In diesem Fall ist die Wiederholangabe diejenige, die die Lieferung der Nachricht an die zweite, dritte und vierte Spielkomponente (803, 804, 805) sicherstellt. Dieser Schritt erfordert einfach den Transfer eines Steuercodes und eines Zeigers in den gemeinsam genutzten Speicher von dem Server-Prozeß (801) in die Server-Nachrichtenaustausch-Schnittstelle (812).
In einem dritten Schritt (902) führt die Server-Nachrichtenaustausch-Schnittstelle (812) daraufhin ein Nachschlagen in ihrer Tabelle abgehender Leitwege aus, um zu bestimmen, an welche Client-Nachrichtenaustausch-Schnittstelle oder -Schnittstellen die Nachricht zur Lieferung an die Zielendpunkte (803, 804, 805) gesendet werden muß. In diesem Fall braucht bei allen drei Client-Computern (809, 810, 811), die mit der gleichen Client-Nachrichtenaustausch-Schnittstelle (813) verbunden sind, die auf einem Schnittstellencomputer (814) gehostet wird, lediglich eine Kopie der Nachricht über das LAN gesendet zu werden.
In einem vierten Schritt (903) sendet die Server-Nachrichtenaustausch-Schnittstelle (812) die Nachricht an die Client-Nachrichtenaustausch-Schnittstelle (813).
In einem fünften Schritt (904) sendet die Client-Nachrichtenaustausch-Schnittstelle (813) eine Kopie der Nachricht an jeden der Client-Computer (809, 810, 811), der den zweiten, dritten und vierten Endpunkt (803, 804, 805) und die zugeordneten Spielkomponenten hostet. Wie oben angegeben wurde, kann ein kundenspezifisches Übertragungsprotokoll verwendet werden, um die Latenzzeit auf ein Minimum zu verringern.
In einem sechsten Schritt (905) empfangen die Endpunkte (803, 804, 805), die in den jeweiligen Client-Computern gehostet werden, jeweils die Nachricht, wobei sie die Nachricht daraufhin an ihre zugeordneten Spielkomponenten übergeben.
Auf diese Weise konnte eine erste Spielkomponente (802), die in dem Server-Cluster gehostet wird, eine Zustandsaktualisierung an die zweite und an die dritte und an die vierte Spielkomponente senden, die auf den jeweiligen Client-Computern (809, 810, 811) gehostet werden, während der Netzverkehr minimal gehalten wird.
Wie oben angegeben wurde, wird außerdem ein weiterer Mechanismus für die Behandlung von Nachrichten bereitgestellt, die an ungültige Ziele geliefert werden. Dies ist der Mechanismus, den ein Nachrichtenabsender verwenden kann, um zu entdecken, daß ein besonderes Ziel nicht mehr gültig ist.
Wenn eine Nachricht gesendet wird, kann sie in der Weise gekennzeichnet werden, daß sie eine Quittierung für Nichtlieferung erfordert. Falls eine Nachricht nicht geliefert werden kann, weil das Ziel nicht mehr vorhanden ist, wird auf diese Kennzeichnung geprüft. Erforderlichenfalls wird die Nachricht daraufhin in eine 'Prell'-Nachricht umgesetzt und an den Absender zurückgesendet. Der Absender empfängt daraufhin eine ankommende Nachricht, die als "geprellt" gekennzeichnet ist. Daraufhin kann der Absender die Nachricht untersuchen, um zu sehen, von wo sie geprellt ist.
Diese Verfolgung auf Ausfälle gibt es in zwei Formen, die spezifiziert werden, wenn die Nachricht gesendet wird. Eine Version gibt die gesamte Nachricht zurück; wobei sie erlaubt, daß der Absender genau prüft, welche Daten nicht geliefert werden konnten. Die zweite Version gibt lediglich den Nachrichtenanfangsblock zurück. Dies ist nützlich, wenn ein Absender identifizieren muß, daß ein Ziel nicht mehr gültig ist (so daß der Absender das Senden an es einstellen kann), wobei er aber nicht genau wissen muß, welche Daten nicht durchgekommen sind.
Es wird angemerkt, daß es dieser Mechanismus ist, der ermöglicht, daß Datenströme/Wiederholangaben/Quellen erfassen, wann ein Ziel ungültig ist und ihren Zustand dementsprechend aktualisieren. Beispielsweise kennzeichnet eine Wiederholangabe alle Nachrichten in der Weise, daß sie eine Quittierung eines Ausfalls erfordern. Beim Empfangen einer Prellnachricht informiert der Endpunkt der Wiederholangabe die Wiederholangabe, wobei die Wiederholangabe das Ziel aus ihrer Liste gültiger Ziele entfernt. Falls es die Komponente gefordert hat, wird ihr auch die Art der Änderung an einem ihrer Verteiler mitgeteilt.
GEEIGNETES PAKETNACHRICHTENFORMAT
Die Nachrichten, die entweder mit einem zuverlässigen oder mit einem unzuverlässigen Mechanismus transportiert werden können, können geeignet ein Format wie folgt verwenden. Zwischen den Nachrichtenaustausch-Schnittstellen wird ein Transportprotokoll ausgeführt, das geeignet die folgende Form annehmen kann:
[4 Bytes – Anfangsblockdaten] [2 Bytes – Nutzinformationslänge]
[1 Byte – Nutzinformationstyp] [... Nutzinformationen ...]
Die Art und Weise, in der jedes dieser 'Pakete' behandelt wird, hängt von dem Nutzinformationstyp ab. Beispielhaft ist eine Menge von Optionen:

(a) INTER_EMS – Diese Nachricht ist intern gegenüber den Nachrichtenschnittstellen. Die Nutzinformationen führen Informationen wie etwa aktualisiere deinen Cache, sende mir keine Informationen für den Endpunkt x mehr, der Endpunkt x ist nun an diesem Ort usw.
(b) DP_TO_DP – Die Nachricht ist für einen Entwicklerprozeß bestimmt. Die Nutzinformationen sind in diesem Fall normalerweise Endpunktbewegungsdaten. Das Anfangsblock-Datenfeld gibt die Kennung des Zielentwicklerprozesses.
(c) EP_TO_EP – Die Nachricht enthält eine Endpunkt-Endpunkt-Nachricht. Das Anfangsblock-Datenfeld enthält in diesem Fall die Kennung des Zielendpunkts.
(d) EP_TO_EPS – Die Nachricht enthält eine Endpunkt-Mehrendpunkt-Nachricht. Das Anfangsblock-Datenfeld enthält in diesem Fall die Anzahl der Zielendpunkte, wobei die tatsächliche Liste der Endpunkte an das Ende der Nutzinformationen angehängt wird.

Das Protokoll stellt das Transportprotokoll dar, welches tatsächlich Nachrichten im System befördert, obgleich es natürlich hinsichtlich der Rohnetzbegriffe tatsächlich wesentlich stärker geschichtet ist als dieses. Beispielsweise ist das Senden einer Nachricht zwischen zwei Endpunkten an zwei Server-Nachrichtenaustausch-Schnittstellen in einem Ethernet-Netz geschichtet:
[Ethernet-Anfangsblock] [IP-Anfangsblock] [TCP-Anfangsblock] [Mari-Transportanfangsblock] [EP-Nachrichtenanfangsblock] [Daten]
Die zweite Schicht des Protokolls liegt gegenüber den Endpunkten frei, wobei ein geeigneter Anfangsblock die in der folgenden Tabelle angegebene Form annehmen kann:

Auf ähnliche Weise kann das Senden einer Nachricht an einen Endpunkt an einem Client, das über eine Einwählinternetverbindung läuft, die folgende Form annehmen:
[PPP-Anfangsblock] [IP-Anfangsblock] [UDP-Anfangsblock] [Mari-Client-Transport-Anfangsblock] [Mari-Client-Nachrichtenanfangsblock] [Daten]
VORTEILHAFTE ANWENDUNGEN
Kurzfassung. Ausführung eines Lastausgleichs unter Verwendung beweglicher Objekte.
Szenarium. Eine übliche Aufgabe in großen verteilten Umgebungen ist die Sicherstellung, daß bewegte Entitäten (z. B. die Darstellung von Spielern) über die Anwesenheit anderer beweglicher Entitäten in einem bestimmten Bereich informiert werden. Dies wird normalerweise als Aura-Kollisionserfassung bezeichnet und kann durch einen einfachen Pythagoras-Algorithmus erfolgen, ist aber ein n²-Problem.
Zugang. Unterteile die Umgebung in verschiedene Gebiete und ordne irgendeinem Bereich mit Aktivität einen 'Aura-Manager' zu. Die Entitäten können den relevanten Aura-Manager bzw. die relevanten Aura-Manager bitten, sie über irgendwelche neuen Entitäten, die sich in ihrer Nähe bewegen, in Kenntnis zu setzen. Während sich die Verteilung der Entitäten in der gesamten Welt ändert, verändert sich der Organisationsaufwand im Zusammenhang mit jedem Aura-Manager. Die Fähigkeit, Endpunkte zu bewegen, macht es sehr einfach, diese Aura-Manager zwischen Server-Hosts zu übertragen, ohne die Objekte, die mit ihnen kommunizieren, zu beeinflussen, so daß der Lastausgleich leicht erreicht werden kann.
Kurzfassung. Langsame Hinabsickern von Daten zu einem Client, während der Anwender das Spiel spielt (d. h. während der Client zahlreiche Echtzeitwechselwirkungen mit mehreren Servern ausführt).
Szenarium. Anstatt einen Anwender warten zu lassen, während ein Client die neuesten Programmänderungen und Dokumentationsänderungen abruft, wäre es besser, Aktualisierungen langsam im Hintergrund eines Spiels sickern zu lassen. Wenn das Spiel das nächste Mal gestartet wird, könnten diese neuen Daten dann automatisch integriert werden.
Zugang. Unterteile die zu sendenden Daten in eine Reihe getrennter kleiner Nachrichten. Sende die ersten wenigen zuverlässig, aber mit einer sehr niedrigen Priorität, und fordere bei der letzten Nachricht eine Empfangsbestätigung an. Während der Anwender in dem Spiel aktiv ist (und "somit Netzverkehr erzeugt), zwingt die niedrigere Priorität bei diesen Nachrichten dazu, sie in eine Warteschlange am Kopf der Client-Netz-Übertragungsstrecke einzureihen. Wenn auf dieser Übertragungsstrecke freie Schlitze auftreten, wird aber eines dieser Pakete gesendet, wobei dann, wenn alle gesendet worden sind, eine Empfangsbestätigung an den Absender gesendet wird. Nachfolgend kann der Prozeß mit der nächsten Gruppe von Nachrichten wiederholt werden.
Kurzfassung. Aufteilen der Funktionalität zwischen Servern.
Szenarium. Eine intelligente mobile Nichtspielerfigur besitzt in einem Spiel zwei verschiedene Funktionalitätsbereiche. Einer ist der komplexe und spezialisierte AI-Code zuzüglich der Datenbank, die erforderlich ist, um ihn intelligent wirken zu lassen. Der andere ist der wesentlich leichtere Code und die Daten, die das Verhalten seines physikalischen Körpers darstellen. Die Trennung der Implementierung dieser zwei Bereiche bietet eine Anzahl von Vorteilen. Beispielsweise ist es dann, wenn sich eine Figur in nächster Nähe anderer Entitäten bewegt, nützlich, sie alle in einen gemeinsamen Adressen raum zu bringen, um die Genauigkeit der physikalischen Simulation zu verbessern. Allerdings würde das Bewegen aller Daten, die dem AI-Modell zugeordnet sind, einen zu hohen Organisationsaufwand auferlegen.
Zugang. Ordne den Code und die Daten, die für die AI erforderlich sind, auf einem Server an, der für die Aufgabe vorgesehen ist, die AI für das Spiel bereitzustellen. Ordne den Code und die Daten, die für die Behandlung der physikalischen Darstellung bestimmt sind, in einem einzigen beweglichen Objekt an, das sich leicht in dem System bewegen kann. Verknüpfe die beiden daraufhin über ein Paar von Datenströmen miteinander, was es erlaubt, daß sie unabhängig davon, welche Prozeßsprünge die physikalische Darstellung zuläßt, auf zuverlässige sequentialisierte Weise kommunizieren.
Kurzfassung. Übertragung von Positionsaktualisierungen.
Szenarium 1. Senden der Position eines Spielers von einem Client zu allen anderen relevanten Clients.
Zugang. Erzeuge ein Objekt, das die Figur des Spielers darstellt, und befestige es an einem Endpunkt. Erzeuge an dem Endpunkt eine Quelle mit einem wohlbekannten für Positionsaktualisierungen benannten Namen. Alle Clients, die am Ort des Spieles interessiert sind, können diese Quelle abonnieren und die Positionsaktualisierungen, die für sie veröffentlicht werden, empfangen. Dies erzeugt eine sehr effiziente Verwendung des Netzes (die Verwendung einer Quelle ermöglicht, daß das System die Nachrichtenaustauschleitung optimiert) und sehr einfachen Code (der Client, der die Informationen veröffentlicht, braucht sich nicht darum zu kümmern, an wen er die Informationen senden muß).
Szenarium 2. Senden von Positionsaktualisierungen in der Weise, daß eine kontrollierte Leistungsverschlechterung erhalten wird, wenn die Gesamtzahl der Positionsaktualisierungen, die an einen Client gesendet werden, die Kapazität der Netzübertragungsstrecke eines Clients übersteigt.
Zugang. Definiere für jedes bewegte Objekt eine Sequenz von Nachrichtenprioritäten, die für ihre Positionsaktualisierungsnachrichten zu verwenden sind, im voraus. Beispielsweise erzeugt die Verwendung der Liste 4, 2, 3, 1 eine Reihe von Positionsnachrichten mit den Prtoritäten 4, 2, 3, 1, 4, 2, 3, 1, 4 usw. Außerdem wird jeder Positionsaktualisierungsnachricht eine Lebensdauer zugewiesen, die gleich der Zeitdauer zwischen den Positionsaktualisierungen ist. Eine schwach belastete Client-Übertragungsstrecke behandelt alle Positionsaktualisierungen, während sie eintreffen. Während das Volumen steigt, werden die Nachrichten mit niedriger Priorität verlangsamt, wobei ihr Zeitgeber abläuft. Obgleich sich die Genauigkeit des Weltmodells bei dem Client unter übermäßiger Belastung verschlechtert, verschlechtert sie sich auf diese Weise auf kontrollierte lineare Weise, die den ungünstigsten Fehler minimiert. Außerdem wird angemerkt, daß die sorgfältige Wahl der für jedes Objekt verwendeten Prioritätsliste erlauben kann, wichtigen Objekten in der Nutzung der Client-Übertragungsstrecke Priorität zu geben (z. B. könnte ein hauptsächlich zur Verzierung dienendes Objekt die Liste 4, 4, 4, 4, 4, 1 verwenden, um sicherzustellen, daß unter starker Belastung lediglich 1 von 6 seiner Aktualisierungen geliefert werden) .

Claims

Verfahren zur Schaffung einer Kommunikation zwischen zwei oder mehr Software-Elementen, bei dem Hostcomputer-Mittel (301) so beschaffen sind, daß sie Anwendungsprogramme (305, 306) für Anwendungssoftware-Elemente in einem Host-Raum (300) kosten, wobei zwei oder mehr Anwendungssoftware-Elemente (308, 310, 312) in dem Host-Raum (300) gekostet werden; dadurch gekennzeichnet, daß das Verfahren umfaßt: Herstellen einer Zuordnung zwischen jedem Anwendungssoftware-Element (308, 310, 312) und einem Kommunikationssoftware-Element (309, 311, 312), über das Nachrichten gesendet und/oder empfangen werden sollen; Halten des Kommunikationszustandes jedes zugeordneten Anwendungssoftware-Elements (308, 310, 312) in seinem zugeordneten Kommunikationssoftware-Element (309, 311, 313); jedem Anwendungssoftware-Element (308, 310, 312) erlauben, mit anderen Anwendungssoftware-Elementen zu kommunizieren, indem Nachrtchten über die jeweils zugeordneten Kommunikationssoftware-Elemente (309, 311, 313) gesendet und empfangen werden; und jedem Anwendungssoftware-Element (308, 310, 312) und dem zugeordneten Kommunikationssoftware-Element (309, 311, 313) erlauben, sich in dem Host-Raum zu bewegen.
Verfahren nach Anspruch 1, bei dem der Schritt des Haltens des Kommunikationszustandes des zugeordneten Anwendungssoftware-Elements (308, 310, 312) das Halten einer Warteschlange von Nachrichten, die noch nicht zu dem zugeordneten Anwendungssoftware-Element geliefert wurden, umfaßt.
Verfahren nach Anspruch 1 oder Anspruch 2, bei dem die Hostcomputer-Mittel (300) zwei oder mehr Hostcomputer (301, 302) umfassen und bei dem der Schritt, bei dem jedem Anwendungssoftware-Element (308, 310, 312) und dem zugeordneten Kommunikationssoftware-Element (309, 311, 313) erlaubt wird, sich in dem Host-Raum zu bewegen, umfaßt: jedem Anwendungssoftware-Element und dem zugeordneten Kommunikationssoftware-Element erlauben, sich zwischen zwei oder mehr Hostcomputern (301, 302) zu bewegen.
Verfahren nach einem vorhergehenden Anspruch, bei dem der Schritt des Haltens des Kommunikationszustandes des zugeordneten Anwendungssoftware-Elements das Halten einer eindeutigen Kommunikationskennung umfaßt.
Verfahren nach Anspruch 4, das ferner umfaßt: in Reaktion auf den Empfang der eindeutigen Kommunikationskennung eines ausgewählten Anwendungssoftware-Elements (308) Bestimmen, in welchem der Hostcomputer (301, 302) sich das ausgewählte Anwendungssoftware-Element befindet.
Vorrichtung zum Schaffen einer Kommunikation zwischen zwei oder mehr Softwareelementen (308, 310, 312, 314), die umfaßt: Hostcomputer-Mittel (301), die so beschaffen sind, daß sie Anwendungsprogramme (305, 306) für Hostanwendungssoftware- Elemente (308, 310, 312) in einem Host-Raum (300) hosten; zwei oder mehr Anwendungssoftware-Elemente (308, 310, 312), die in dem Host-Raum (300) gekostet werden; Nachrichtenaustauschmittel (318, 319), die so beschaffen sind, daß sie einen Nachrichtenaustausch zwischen Kommunikationssoftware-Elementen (309, 311, 313) ermöglichen; und Bewegungsmittel, die so beschaffen sind, daß sie Softwareelementen erlauben, sich in dem Host-Raum (300) zu bewegen; dadurch gekennzeichnet, daß zwischen jedem Anwendungssoftware-Element und einem entsprechenden Kommunikationssoftware-Element (309, 311, 313, über das Nachrichten gesendet und/oder empfangen werden, eine Zuordnung vorhanden ist; und jedes Kommunikationssoftware-Element den Kommunikationszustand des zugeordneten Anwendungssoftware-Elements (308, 310, 312) hält.
Vorrichtung nach Anspruch 6, bei der der Kommunikationszustand eine Warteschlange aus Nachrichten enthält, die noch nicht an das zugeordnete Anwendungssoftware-Element geliefert worden sind.
Vorrichtung nach Anspruch 6 oder Anspruch 7, bei der die Hostcomputer-Mittel zwei oder mehr Hostcomputer (301, 302) umfassen und die Bewegungsmittel so beschaffen sind, daß sie eine Bewegung zwischen den zwei oder mehr Hostcomputern zulassen.
Vorrichtung nach einem der Ansprüche 6 bis 8, bei der der Kommunikationszustand eine eindeutige Kommunikationskennung enthält.
Vorrichtung nach Anspruch 9, die ferner umfaßt: Lokalisierungsmittel (319, 321), die so beschaffen sind, daß sie in Reaktion auf den Empfang der eindeutigen Kommunikationskennung eines ausgewählten Anwendungssoftware-Elements (308) bestimmen, in welchem der Hostcomputer (301, 302) sich das ausgewählte Anwendungssoftware-Element befindet.