-
Technisches
Gebiet
-
Die
vorliegende Erfindung bezieht sich im allgemeinen auf Computersysteme
und insbesondere auf Verfahren und Systeme für die Implementierung eines
HTTP-Stack auf der
Client-Seite in einem Computersystem.
-
Hintergrund
-
Das
schnelle Wachstum des Internets und internetbasierter Applikationen
hat eine Vielzahl von Vorteilen für Einzelpersonen, Firmen, Regierungen
und die Gesellschaft im allgemeinen geschaffen. Einige Jahre zuvor
wurde das Internet hauptsächlich
von Einzelpersonen genutzt, um im "Netz" mit
Hilfe einer Web-Browser-Softwareapplikations-Komponente "zu surfen". In diesem Zusammenhang
wird der Computer der Einzelperson häufig als Client bezeichnet.
Der Client fragt Daten, Bilder oder andere Informationen von einer
weiteren Maschine, die bisweilen als Server bezeichnet wird, über das
Internet ab. Die Client-/Server-Architektur kann
als anfragende Maschine (z.B. der Client) und als zuführende Maschine
(z.B. der Server) betrachtet werden, die eine Datenbank und eine
Datenbank-Verwaltungs-(DBMS-)Softwareapplikation enthalten können. Der
Client-Webbrowser
erlangt Zugriff auf das Internet durch ein Netzwerkkommunikationsprotokoll,
das eine oder mehrere Schichten enthält, um Informationen von der
Serverdatenbank-Software abzufragen und zu beziehen.
-
Der
Browser arbeitet normalerweise mit einer Hypertext-Transport-Protokoll-(HTTP-)Softwarekomponente
zusammen, die für
die Sendung von Anfragen und den Empfang von Antworten in einer
ersten Schicht zuständig
ist. Die HTTP- Softwarekomponente
wird bisweilen als der HTTP-Stack bezeichnet. Das HTTP-Stack-Protokoll wird
verwendet, um eine Verbindung mit einem Webserver herzustellen und
Hypertext-Markup-Language-(html-)Seiten oder andere Daten zum Client-Browser
zu senden. Zu diesem Zweck arbeitet der HTTP-Stack mit einer Transportschicht,
wie etwa einem Transmission-Control-Protokoll (TCP). Die TCP-Schicht
arbeitet mit einer Netzwerkschicht-Softwarekomponente, wie etwa
der Internet-Protokoll-(IP-)Schicht zusammen. Das TCP/IP-Kommunikationsprotokoll
ist zum Standard für
den Großteil
der Internetkommunikation geworden, wobei die TCP-Schicht oder der
TCP-Stack Transportfunktionen bereitstellt um sicherzustellen, dass
die Gesamtmenge von Bytes in einem gesendeten Datenpaket ordnungsgemäß empfangen
werden, und die IP-Schicht einen Routing-Mechanismus bereitstellt.
Im IP-Protokoll enthalten Nachrichten Adressen sowohl für die Bestimmungsstation
oder -maschine als auch das Bestimmungsnetzwerk (z.B. eine IP-Adresse),
wodurch das IP-Protokoll insbesondere für das Internet anwendbar wird.
-
Auf
der Server-Maschine empfängt
die Server-Softwareapplikation (z.B. eine Datenbankverwaltungssystem-Softwarekomponente)
Anfragen von einem oder mehreren derartigen Clients über eine
geschichtete Netzwerkarchitektur, die eine IP-Schicht auf der Serverseite, eine Server-TCP-Schicht
und einen HTTP-Stack auf der Serverseite beinhaltet. In der Vergangenheit
konzentrierte sich deutliche Aufmerksamkeit auf die Verbesserung
der Durchsatzfähigkeit
der serverseitigen Software-Implementierungen der HTTP-Schicht (z.B.
des serverseitigen HTTP-Stacks),
wie etwa durch die Verwendung von Multitask-Techniken. Der Grund
hierfür
ist, dass derartige Server im allgemeinen Hunderten und sogar Tausenden
von Client-Anfragen innerhalb eines kurzen Zeitraumes ausgesetzt
sind.
-
Somit
stellen zahlreiche serverseitige HTTP-Stack-Softwareimplementierungen
Multithreading bereit, das den gleichzeitigen Ablauf von zwei oder
mehr Ausführungsströmen (Threads)
innerhalb eines einzigen Programms (z.B. die Antwort auf mehrere
Client-Anfragen) gestattet. Multithreading kann in einer Einzelprozessormaschine
und/oder einer Mehrprozessorumgebung ausgeführt werden, in der eine Vielzahl
von Prozessoren einzelnen Threads bedienen können. Beispielsweise können individuelle
Clientanfragen durch entsprechende Threads verar beitet werden, wodurch
die Anfragen-Handhabungskapazität
des Servers erhöht
wird. Darüber
hinaus enthalten einige serverseitige HTTP-Stack-Implementierungen Verfahren und Softwarekomponenten,
die eine effektive Nutzung derartiger Threads ermöglichen,
wie etwa Completion-Ports und dergleichen.
-
Wenngleich
bislang Verbesserungen bei der serverseitigen HTTP-Stack-Implementierung vorgenommen
wurden, um die große
Zahl von Anfragen zu unterstützen,
die normalerweise von derartigen Servern empfangen werden, wurde
nur geringes Augenmerk auf die clientseitige HTTP-Stack-Implementierung
gelegt. Von der typischen Webbrowser-Applikation auf der Seite des
Clients wird normalerweise verlangt, Informationen von einem Server
in relativ kleinen Stücken
(z. B. jeweils eine html-Seite) zu beziehen. Darüber hinaus erzeugt der Webbrowser
normalerweise nur dann eine neue Anfrage, wenn der Client-Benutzer
einen Benutzerschnittstellen-Befehl, wie etwa durch Wählen einer
neuen Seite zur Ansicht, ausführt.
Beispielsweise kann ein Benutzer eine Seite von Informationen beziehen
und die Seite mehrere Sekunden oder sogar Minuten studieren, bevor
ein eine Anfrage nach einer weiteren Seite initiiert. Demzufolge
gab es bislang keinen Anreiz, die Anfrage-Durchsatzkapazität der HTTP-Stack-Implementierungen
auf der Client-Seite zu verbessern.
-
In
den vergangenen Jahren wurden jedoch verbesserte Software-Applikationen
entwickelt und installiert, die Firmen und andere Einrichtungen
mit internetbasierten Funktionen und Fähigkeiten versorgen, die verbesserte
Verarbeitungsfähigkeiten
auf der Client-Maschine erfordern. Eine Client-Maschine kann beispielsweise
eine Applikation beinhalten, die Hunderte oder sogar Tausende von
Anfragen in einem sehr kurzen Zeitraum erzeugt, die zeitgerecht
verarbeitet werden müssen.
Somit besteht Bedarf an verbesserten Verfahren und Systemen für die Implementierung
eines HTTP-Stacks auf der Client-Seite in einem Computersystem.
-
US-A-5
913 215 bezieht sich auf das Gebiet der Computer-Dokumentenverwaltung und bezieht sich insbesondere
auf ein Verfahren zum Verbessern der Effizienz der Identifizierung
eines einer Vielzahl von Dokumenten, die auf einem computerlesbaren
Medium gespeichert sind.
-
US-A-5
913 215 schlägt
die linguistische Analyse der Dokumente (z.B. der Webseiten) vor,
um einen Suchbegriff eines Benutzers dort automatisch zu identifizieren.
-
Das
Verfahren verwendet eine Arbeitsliste, um Arbeitsanweisungen entsprechend
den Suchbegriffen zu speichern. Multithreading-Techniken werden
angewandt, um Arbeitsanweisungen gleichzeitig auszuführen. Das
Verfahren verwendet einen Thread-Manager, um die Ausführung der
Arbeitsanweisungen zu steuern. Kennzeichnet die Arbeitsliste eine
Arbeitsanweisung, prüft
der Thread-Manager die Verfügbarkeit
eines freien Threads. Wird eine freier Thread erfasst, wird die
Arbeitsanweisung zu diesem freien Thread übermittelt. Gibt es keinen
freien Thread und ist die Zahl sämtlicher
Threads weiterhin geringer als ein vom Benutzer definiertes Maximum,
erzeugt der Thread-Manager einen neuen Thread, um die Arbeitsanweisung
auszuführen.
(Spalte 20, Zeile 47-54) Wenn die Zahl der Threads das vom Benutzer
definierte Maximum erreicht hat, wartet der Thread-Manager, bis
ein Thread die Ausführung
abgeschlossen hat und sich selbst als frei markiert. Dieser nun
freie Thread empfängt
anschließend
die Arbeitsanweisung. Sobald die Arbeitsliste leer ist, zerstört der Thread-Manager
jeden bestehenden Thread (Spalte 20, Zeile 35-40).
-
Insgesamt
werden gemäß US-A-5
913 215 freie Threads in Abhängigkeit
der existierenden Arbeitslast durch die Arbeitsanweisungen erzeugt
und zerstört,
wodurch die Prozessorauslastung verbessert werden soll.
-
"Control of Dynamic
Threads Pool for Concurrent Remote Procedure Calls" IBM Technical Disclosure Bulletin,
IBM Corp. New York, US, vol. 38, no. 5, vom 1. Mai 1995, Seite 199
bis 200 beschreibt ein Verfahren für eine serverseitige Applikation
zum Steuern eines dynamischen Thread-Protokolls. Das Verfahren erhält Systemressourcen
in verteilten Berechnungsumgebungen mit Hilfe von Multithreading-Techniken. Dies wird durch
die Verwendung eines Algorithmus' erreicht,
der die Erzeugung und Zerstörung
von (Ausführungs-) Threads
steuert. Das Verfahren erzeugt einen definierten Anteil von (Ausführungs-)
Threads, die von der Applikation bei der Initialisierung abgefragt
werden. Dieser Anteil wird mit Hilfe eines Algorithmus' bestimmt und ändert die
Zahl der (Ausführungs-)
Threads, wenn sich die Belastung des Servers ändert. In einer Situation von
zu vielen freien Ausführungs-Threads, zerstört das Verfahren
freie (Ausführungs-)
Threads. In einer Situation von zu wenig oder keinen freien (Ausführungs-)
Threads, erzeugt das Verfahren (Ausführungs-) Threads. Durch Variieren
der Zahl von (Ausführungs-)
Threads gemäß dem Anpassungsalgorithmus,
versucht das System offensichtlich die Serverauslastung zu verbessern.
-
US-A-5
754 771 bezieht sich auf ein interaktives Fernseh-Client-/Serversystem,
das eine Datenmenge bestimmt, die zu einem Client gesendet wird.
Ein Client sendet dem Server eine Anfrage und der Server behält den Kontext
der Anrage bei, bis der Client die Verbindung beendet.
-
Ein
Ziel der vorliegenden Erfindung besteht darin, eine HTTP-Stack-Softwarekomponente
einer Client-Seite, ein Verfahren sowie ein computerlesbares Medium
anzugeben, das über
von einem Computer ausführbare
Anweisungen zur Implementierung eines effizienteren HTTP-Stacks
auf der Client-Seite eines Computersystems verfügt.
-
Dieses
Ziel wird durch den Gegenstand der unabhängigen Ansprüche 1, 28
und 41 erreicht.
-
Bevorzugte
Ausführungsformen
sind Gegenstand der abhängigen
Ansprüche.
-
Der
Erfindung enthält
eine HTTP-Stack-Implementierung einer Client-Seite, die eine hohe
Leitungsfähigkeit
und Skalierbarkeit bereitstellt, die zuvor nicht erreicht wurden,
wobei Multithreading- und Completion-Ports in der HTTP-Schicht der
Client-Seite in Zuordnung mit Sockets und einem Thread-Pool verwendet werden.
In der Vergangenheit wurde der HTTP-Stack der Client-Seite unter
Verwendung eines Sockets und eines Threads eingerichtet. Wenngleich
dies zu einer geeigneten Verarbeitungsleistung für einen einzigen Benutzer beim
Zugriff auf das Internet mit einer Browser-Applikation führte, erzeugen
Applikationen von Firma zu Firma und jüngere Applikationen auf der
Client-Seite zahlreiche Anfragen, die eine zeitgerechte Verarbeitung erfordern.
Die Einzel-Thread-, Einzel-Socket-Architektur wird jedoch gleichzeitig
nur einer Anfrage gerecht. Somit können bei Stack-Implementierung auf
Client-Seite gemäß dem Stand
der Technik andere Anfragen vernachlässigt werden, weil der Client-Prozessor
damit beschäftigt
ist, gleichzeitig nur eine Anfrage zu verarbeiten.
-
Die
Erfindung gestattet es Applikationen der Client-Seite Completion-Ports
mit einem zugehörigen Gleichzeitigkeitswert
zu erzeugen, der die Maximalzahl von Threads kennzeichnet, die dem
Port zugeordnet sind, der zu einer beliebigen Zeit in Betrieb sein
sollte. I/O ist den clientseitigen Sockets zugeordnet, die ihrerseits
dem Completion-Port unter Verwendung eines Schlüssels zugeordnet sind. Die
Verwendung der Completion-Ports und der Gleichzeitigkeitswerte verbessert
die Prozessorauslastung, indem blockierende Threads deaktiviert
werden können,
wodurch die Ausführung
von Aufgaben ausgesetzt wird, die sich auf eine bestimmte Anfrage
beziehen, bis der Completion-Port ein zugehöriges Completion-Paket von I/O empfängt. Während des
Betriebs werden die Threads, die einen Completion-Port blockieren,
deaktiviert, wodurch es den anderen Threads erlaubt ist, aktiviert
zu werden, wenn Completion-Pakete im Completion-Port innerhalb der
Gleichzeitigkeitsgrenzen empfangen werden.
-
Darüber hinaus
stellt die Verwendung eines HTTP-Stacks der Client-Seite Zustandsmaschinen
bereit, die den Anfragen zugeordnet sind. Die Zustandsmaschinen
werden speziellen Anfragen unter Verwendung eines oder mehrerer
Schlüssel
zugeordnet. Wenn der Completion-Port der Client-Seite ein Completion-Paket vom
Server empfängt,
verarbeitet der nächste
verfügbare
Thread die Anfrage gemäß der entsprechenden
Zustandsmaschine unter Verwendung des Schlüssels. Die Zustandsmaschine
gestattet die korrekte Verarbeitung von Aufgaben, die mit einer
speziellen Anfrage in Verbindung stehen, durch einen der Threads
aus dem Thread-Pool und ermöglicht
somit verbesserte Verarbeitungsleistungen, die durch die Verwendung
eines Thread-Pools und Completion-Ports erreicht werden. Insbesondere
ermöglicht
der Schlüssel
die Fähigkeit
eines Threads, dessen zugehörige
Operationen (z.B. I/O-Operationen) ausstehen, einen Completion-Port
zu prüfen,
der dann den Thread aktiviert, wenn eine beliebige andere Operation
abgeschlossen ist. Ist die anfängliche
Operation (z.B. die I/O-Operation)
abgeschlossen, nimmt der nächste
verfügbare
Thread anschließend die
Ausführung
derselben im geeigneten Zustand unter Verwendung des Schlüssels wieder
auf. Der Thread kehrt somit zu einem Pool verfügbarer freier Threads zurück, sobald
der Thread eine Kennzeichnung (z.B. einen Zustandscode) empfängt, dass
die aktuelle Operation aussteht.
-
Die
Erfindung enthält
weiterhin einen dedizierten Scheduler-Thread, der dazu eingerichtet
ist, ein Objekt zu aktivieren, das dazu eingestellt ist, Anfragen
zu einer bestimmten Zeit zu senden, wie auch einen dedizierten DNS-Thread,
der verwendet wird, um symbolhafte Domainnamen zu IP-Adressen aufzulösen. Zusätzlich enthält die HTTP-Stack-Implementierung
der Client-Seite einen dedizierten Timeout-Thread mit einer Liste aktiver
Sockets und Timern, die jedem Socket zugeordnet sind, um eine feiner
aufgelöste
Steuerung über
Socket-Timeout-Perioden zu ermöglichen.
-
Ein
Aspekt der vorliegenden Erfindung gibt eine HTTP-Stack-Softwarekomponente
einer Client-Seite zum verarbeiten von Anfragen an. Die Software-Komponente
enthält
ein oder mehrere Completion-Port-Objekte und einen Thread-Pool mit
einer Vielzahl von Threads zur Bearbeitung von Aufgaben, die mit
Anfragen der Client-Seite verbunden sind. Wenngleich HTTP-Stack-Implementierungen
der Client-Seite des Standes der Technik einen einzigen Thread zur
Ausführung
enthalten, gibt die Erfindung eine Multitasking-Anfragenverarbeitung
auf der Client-Seite
mit Hilfe der Verwendung eines Pools von Threads an, die von einer
Vielzahl aktiver HTTP-Anfragen gemeinsam genutzt werden, was bislang
nicht möglich
war.
-
Darüber hinaus
sorgt die Verwendung von Completion-Ports für eine effektive Nutzung des Thread-Pools,
wodurch zusätzlich
der Durchsatz der Client-Seite bei der Anfragenverarbeitung verbessert wird.
Eine oder mehrere (z.B. zahlreiche) verschachtelte und aufeinander
bezogene Zustandsmaschinen können
einzelnen Anfragen zugeordnet sein. Wenn ein Thread, der die Anfrage
eines Clients verarbeitet, beginnt eine lang andauernde I/O-Operation
auszuführen
(z.B. wenn eine Anfragenachricht zu einem Server gesendet wurde
und der Thread auf eine Ant wort wartet), kann der Thread aus einem
Zustandcode ermitteln, dass die Operation aussteht und die Ausführung unterbrechen.
Der Completion-Port kann dann den Thread aktivieren, dessen Empfang
eines Completion-Paketes aussteht, das einer oder mehrerer ausstehender
Anfragen zugeordnet ist. Sobald der Thread auf diese Weise von der
ausstehenden Operation gelöst
ist, kehrt der Thread somit zum Pool verfügbarer Threads zurück, aus
dem dieser oder andere Threads durch den Completion-Port aktiviert
werden können,
um eine weitere Anfrage zu verarbeiten. Die selektive Aktivierung
von Threads stellt sicher, dass Anfragen, die zu einer bestimmten
Zeit weiter verarbeitet werden können,
mit einem Thread für eine
derartige Arbeit innerhalb des Gleichzeitigkeitswertes versehen
werden, der diesem Completion-Port zugeordnet ist.
-
Die
Zustandmaschinen und der Schlüssel,
der den Anfrageverarbeitungen zugeordnet ist, ermöglichen
die Aktivierung von Threads unter Verwendung des Completion-Ports.
Wenn beispielsweise ein erster Thread, der eine Aufgabe ausführt, die
einer speziellen Client-Anfrage zugeordnet ist (z.B. eine I/O-Operation), einen
Zustandscode empfängt,
der anzeigt, dass die Aufgabe aussteht, kann der Kontext des ersten
Threads, der den entsprechende Zustandsmaschinen-Zustand enthält, einem
Schlüssel
zugeordnet werden, und der erste Thread kehrt zum Thread-Pool zurück. Wird
die Verarbeitung der Anfrage anschließend neugestartet (z.B. über den
Completion-Port, der einen Thread aus dem Pool bei Empfang eines
Completion-Paketes aktiviert), schreitet die Ausführung an
der geeigneten Stelle (z.B. am Zustandsmaschinen-Zustand) gemäß dem Schlüssel fort,
der der Anfrage zugeordnet ist. Die Anfrage kann unter Verwendung
desselben oder eines anderen Threads aus dem Thread-Pool neugestartet
werden. Beispielsweise kann der Completion-Port den Zusammenhang
der Anfrage einem der Threads im Pool unter Verwendung des Schlüssels zuordnen,
um den Thread auf der Basis eines Ereignisses zu aktivieren, wobei
das Ereignis der Empfang eines Completion-Paketes sein kann.
-
Zusätzlich zum
Thread-Pool, den Completion-Ports, den Zustandsmaschinen und den
Schlüsseln kann
die HTTP-Stack-Komponente auf der Client-Seite einen Scheduler-Thread
beinhalten, der dazu eingerichtet ist, ein Objekt zu aktivieren,
das dazu eingestellt ist, die Sendung der Anfrage zu einer bestimmten
Zeit zu be ginnen, einen DNS-Thread, der dazu eingerichtet ist, Domainnamen
zu IP-Adressen aufzulösen, und/oder
einen Timeout-Thread mit einer Liste aktiver Sockets und Timern,
die jedem Socket zugeordnet sind, der dazu eingerichtet ist, wahlweise
einen Timeout an wenigstens einem Socket gemäß einem Timer in der Liste
auszuführen.
-
Gemäß einem
weiteren Aspekt der Erfindung wird eine Softwarekomponente zur Implementierung
eines HTTP-Stacks auf Client-Seite angegeben, die einen Thread-Pool
enthält.
Der Thread-Pool kann N Threads enthalten, die dazu eingerichtet
sind, M Anfragen von einer Client-Applikationskomponente zu verarbeiten,
wobei N und M ganze Zahlen größer als
1 sind und M größer als
N sein kann. Es können
beispielsweise zehn derartiger Threads verwendet werden, um Hunderte
oder sogar Tausende von Anfragen zu verarbeiten. Die HTTP-Stack-Komponente
kann zudem eine oder mehrere Thread-Aktivierungskomponenten beinhalten, die
selektiv wenigstens einen der N-Threads auf der Basis eines Ereignisses
(wie etwa des Empfangs eines Completion-Paketes) aktivieren. In
dieser Hinsicht kann die Thread-Aktivierungskomponente einen Completion-Port
oder eine beliebige andere Softwarekomponente beinhalten, die dazu
eingerichtet ist, derartige Threads zur Ausführung selektiv zu aktivieren.
-
Die
Threads im Thread-Pool sind dazu eingerichtet, sich selbst zu deaktivieren
oder andernfalls von der Verarbeitung eines Vorgangs zu lösen, der
mit einer Client-Anfrage in Verbindung steht, wenn der Thread eine
Kennzeichnung (wie etwa einen Zustandscode) empfängt, dass der Vorgang aussteht.
Anschließend kehrt
der Thread zum Thread-Pool zurück,
um eine Aktivierung durch den Completion-Port auf der Basis des Empfangs
eines Completion-Paketes zu erwarten. Anstelle zu warten und keine
Aufgaben einer Anfrage auszuführen
(z.B. Blockieren einer I/O-Operation), kann somit der Thread vorteilhaft
verwendet werden, um nützliche
Operationen auszuführen,
die mit einem Completion-Paket in Verbindung stehen.
-
Zustandsmaschinen
können
den M Anfragen zugeordnet sein, wobei ein oder mehrere Schlüssel den Anfragen
zugeordnet sein können.
Beispielsweise kann jede Anfrage eine Sammlung von zahlreichen ihr
zugeordneten Zustandsmaschi nen beinhalten, die verwendet werden,
wenn diese spezielle Anfrage verarbeitet wird. Ist ein erster Thread
einer ersten Anfrage zugeordnet, kann somit der Thread derart eingerichtet
sein, dass er seinen Kontext der entsprechenden Zustandsmaschine
unter Verwendung eines Schlüssels
zuordnet, bevor er zum Thread-Pool
zurückkehrt.
Darüber
hinaus ist die Thread-Aktivierungskomponente dazu eingerichtet,
den Kontext eines der N Threads der Zustandsmaschine unter Verwendung
des Schlüssels
zuzuordnen, um den Thread auf der Basis eines Ereignisses (wie etwa
des Empfangs eines Completion-Paketes) zu aktivieren.
-
Ein
weiterer Aspekt der Erfindung gibt ein Verfahren zur Implementierung
eines HTTP-Stacks einer Client-Seite an, das die Verarbeitung von
M Anfragen von einer Client-Applikationskomponente unter Verwendung
eines Thread-Pools umfasst, der N Threads beinhaltet, wobei M und
N ganze Zahlen größer als
1 sind und M größer als
N ist. Das Verfahren kann weiterhin die wahlweise Aktivierung wenigstens
einen der N Threads mit Hilfe einer oder mehrerer Thread-Aktivierungskomponenten
(z.B. eines Completion-Ports) auf der Basis eines Ereignisses (z.B.
des Empfangs eines Completion-Paketes) umfassen. Die Threads können sich wahlweise
deaktivieren und zum Thread-Pool beispielsweise dann zurückkehren,
wenn ein Thread eine Kennzeichnung empfängt, dass die momentane Operation,
der er zugeordnet ist, aussteht. Auf diese Weise blockieren die
Threads nicht die I/O-Operationen. Das Aktivieren eines Threads
auf der Basis eines Ereignisses kann den Empfang eines Completion-Paketes
unter Verwendung der Thread-Aktivierungskomponente und das Aktivieren
einer der N Threads bei Empfang des Completion-Paketes beinhalten.
-
Darüber hinaus
kann das Verfahren die Zuordnung eines Zustandsmaschine zu wenigstens
einer der M Anfragen beinhalten. Dies kann die Zuordnung wenigstens
eines Schlüssels
zu wenigstens einer der M Anfragen, die Zuordnung eines ersten der
N Threads zu wenigstens einem der M Anfragen und die Zuordnung eines
Kontextes des ersten der N Threads zu der wenigstens einen Zustandsmaschine
unter Verwendung wenigstens eines Schlüssels beinhalten, wenn der
erste der N Threads deaktiviert oder von der Anfrage getrennt wird
(z.B. wenn eine Operation, die der Anfrage zugeordnet ist, aussteht).
Darüber
hinaus kann das Verfahren die Zuordnung eines Kontextes eines der
N Threads zu der wenigstens einen Zustandsmaschine unter Verwendung
des wenigstens einen Schlüssels
beinhalten, um den Thread auf der Basis eines Ereignisses zu aktivieren.
-
Das
Verfahren kann weiterhin die Aktivierung eines Objektes, das dazu
eingestellt ist, mit der Sendung von Anfragen zu einer bestimmten
Zeit zu beginnen, unter Verwendung eines Scheduler-Threads und/oder das
Auflösen
von Domainnamen zu IP-Adressen unter Verwendung eines DNS-Threads
beinhalten. Darüber hinaus
kann das Verfahren die wahlweise Durchführung eines Timeouts bei wenigstens
einem Socket gemäß wenigstens
einem Timer, der wenigstens einem Socket zugeordnet ist, unter Verwendung
eines Timeout-Threads beinhalten, der eine Liste aktiver Sockets
und Timer beinhaltet, die jedem Socket zugeordnet sind.
-
Ein
weiterer Aspekt der vorliegenden Erfindung gibt ein computerlesbare
Medium an, das über
von einem Computer ausführbare
Anweisungen zur Verarbeitung von M Anfragen von einer Client-Applikationskomponente
unter Verwendung eines Thread-Pools mit N Threads verfügt, wobei
M und N ganze Zahlen größer 1 sind
und M größer als
N ist. Weitere von einem Computer ausführbare Anweisungen können bereitgestellt sein,
um wahlweise wenigstens einen der N Threads unter Verwendung wenigstens
einer Thread-Aktivierungskomponente auf der Basis eines Ereignisses
zu aktivieren.
-
Um
die zuvor erwähnten
und die damit in Verbindung stehenden Ziele zu erreichen, sind bestimmte beispielhafte
Aspekte der Erfindung hier in Verbindung mit der folgenden Beschreibung
und den beigefügten Zeichnungen
beschrieben. Diese Aspekte sind jedoch nur für einige wenige der unterschiedlichen
Arten kennzeichnend, in der die Prinzipien der Erfindung verwendet
werden können,
wobei mit der vorliegenden Erfindung beabsichtigt ist, dass sämtliche
derartige Aspekte und deren Äquivalente
enthalten sind. Andere Vorteile und neuartige Merkmale der Erfindung
werden aus der folgenden detaillierten Beschreibung der Erfindung
in Verbindung mit den Zeichnungen deutlich.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
eine schematische Darstellung, die eine beispielhafte HTTP-Stack-Implementierung
einer Client-Seite gemäß einem
Aspekt der vorliegenden Erfindung zeigt;
-
2 ist
eine schematische Darstellung, die Beziehungen zwischen zahlreichen
Klassen innerhalb einer beispielhaften HTTP-Stack-Implementierung
einer Client-Seite zeigt;
-
3 ist
eine schematische Darstellung, die zahlreiche beispielhafte Zustandsmaschinen
gemäß einem
weiteren Aspekt der Erfindung zeigt;
-
4 ist
eine schematische Darstellung, die weiterhin die Zustandmaschinen
aus 3 darstellt, die damit verbundene, unterschiedliche,
beispielhafte Zustandsmaschinen-Zustände enthalten;
-
5 ist
eine schematische Darstellung, die ein beispielhaftes Client-Computersystem mit
einer HTTP-Stack-Implementierung einer Client-Seite gemäß der Erfindung
darstellt;
-
6 ist
eine schematische Darstellung, die ein beispielhaftes Client-Computersystem darstellt,
das auf einen oder mehrere Server-Computer über das Internet zugreift;
-
7 ist
eine schematische Darstellung, die ein weiteres beispielhaftes Client-Computersystem
darstellt, das über
eine Firmen-zu-Firmen-Applikation verfügt, die dazu eingerichtet ist,
Daten oder Informationen von einer Vielzahl von Server-Computern über das
Internet gemäß Anfragen
von einer Vielzahl von Applikationen zu beziehen, die auf getrennten
Client-Computern laufen;
-
8 ist
eine schematische Darstellung, die ein weiteres beispielhaftes Client-Computersystem
darstellt, das dazu eingerichtet ist, Informationen zu beziehen,
die sich auf die Verfügbarkeit
von Automobilen von einer Vielzahl von Händler-Server-Computern gemäß einer
Anfrage von einer Vielzahl von Webbrowsern beziehen;
-
9 ist
ein Flussdiagramm, das ein beispielhaftes Verfahren zur Implementierung
eines HTTP-Stack einer Client-Seite gemäß einem weiteren Aspekt der
Erfindung darstellt;
-
10 ist
ein Flussdiagramm, das weiterhin das beispielhafte Verfahren von 9 zeigt;
und
-
11 ist
ein schematisches Blockschaltbild, das eine beispielhafte Betriebsumgebung
darstellt, in der ein oder mehrere Aspekte der Erfindung ausgeführt werden
können.
-
Detaillierte
Beschreibung
-
Die
vorliegende Erfindung wird nun unter Bezugnahme auf die Zeichnungen
beschrieben, wobei ähnliche
Bezugszeichen verwendet werden, um ähnliche Elemente zu kennzeichnen.
In der folgenden Beschreibung werden zu Zwecken der Erläuterung
zahlreiche spezielle Details beschrieben, um für ein umfassendes Verständnis der
vorliegenden Erfindung zu sorgen. Dem Fachmann wird jedoch verständlich sein,
dass die vorliegende Erfindung ohne diese speziellen Details in
die Praxis umgesetzt werden kann. Darüber hinaus sind hinlänglich bekannte
Konstruktionen und Vorrichtung bei einigen Beispielen in Gestalt
eines Blockschaltbildes dargestellt, um die Beschreibung der vorliegenden
Erfindung zu vereinfachen.
-
Die
Erfindung enthält
Softwarekomponenten und Verfahren zur Implementierung eines HTTP-Stack auf
einer Client-Seite, die zu einer hohen Leitungsfähigkeit und Skalierbarkeit
führen,
die mit herkömmlichen Implementierungen
nicht möglich
waren. Multithreading und Completion-Ports werden in der HTTP-Schicht der
Client-Seite in Zuordnung mit Sockets und einem Thread-Pool verwendet,
wodurch Firmen-zu-Firmen-Applikationen und andere anfrageintensive
clientseitige Applikationen unterstützt werden. Die Erfindung umfasst zudem
einen dedizierten Scheduler-Thread, der dazu eingerichtet ist, ein
Objekt zu aktivieren, das dazu eingestellt ist, mit dem Senden von
Anfragen zu einer bestimmten Zeit zu beginnen, wie auch einen dedizierten DNS-Thread,
der zum Auflösen
symbolischer Domainnamen in IP-Adressen verwendet wird. Darüber hinaus enthält die HTTP-Implementierung der
Client-Seite einen dedizierten Timeout-Thread mit einer Liste aktiver Sockets
und Timern, die jedem Socket zugeordnet sind, die eine feinere Steuerung über Socket-Timeout-Perioden
gestatten.
-
In 1 ist
eine beispielhafte HTTP-Stack-Implementierungskomponente 2 einer
Client-Seite gemäß einem
Aspekt der vorliegenden Erfindung dargestellt. Die Komponente 2 enthält einen
Thread-Pool 4 mit N Threads 6, 8 und 10,
wobei N eine ganze Zahl ist, um einen oder mehrere von M Client-Anfragen 12, 14 und 16 auszuführen, wobei
M eine ganze Zahl größer N ist.
Die Anfragen 12, 14 und 16 werden von
einer Client-Softwareapplikations-Komponente 18 erzeugt.
Beispielsweise können
die Threads 6, 8 und 10 des Thread-Pools 4 für die Ausführung einer
speziellen Anfrage (z.B. die Anfrage 12, 14 oder 16)
gemäß einem Gleichzeitigkeitswert
(nicht gezeigt) eingeteilt werden, der einem Completion-Port 20 zugeordnet
ist, wodurch die Zahl aktiver Threads gesteuert werden kann. Somit
kann, wenn der Gleichzeitigkeitswert (z.B. 10) für den Completion-Port 20 nicht
erreicht wurde und eine oder mehrere der M Anfragen 12, 14 und/oder 16 eine
Verarbeitung erfordern, ein Thread vom Thread-Pool 4 aktiviert
und einer Anfrage zur Ausführung
einer derartigen Verarbeitung zugeordnet werden. Weiterhin können gemäß der Erfindung
Threads aus dem Thread-Pool 4 wahlweise deaktiviert oder
andernfalls von einer Anfrage getrennt werden, wenn beispielsweise
ein Zustandscode (nicht gezeigt) empfangen wird, der anzeigt, dass
eine I/O-Operation, die einem der Sockets 24, 26 und/oder 28 zugeordnet
ist, aussteht.
-
Die
Verarbeitung unterschiedlicher Aufgaben, die einer speziellen Client-Anfrage
zugeordnet sind (wie etwa die Anfragen 12, 14 und/oder 16),
kann in Übereinstimmung
mit einer oder mehreren Zustandsmaschinen bewerkstelligt werden,
die zusammen mit 22 gekennzeichnet sind. Beispielsweise
können
die Zustandsmaschinen 22 für die TCP-Datensendung, die
Sicherheitsprotokoll-Implementierung
(z.B. die Implementierung von Secure Sockets Layer (SSL) oder Transport
Layer Security (TSL)), das Daten-Parsing und/oder die Daten-Authentifizierung
vorgesehen sein, wie es im folgenden detaillierter dargestellt und
beschrieben ist.
-
Die
Zustandsmaschinen 22, die der Verarbeitung der Client-Anfragen 12, 14 und/oder 16 zugeordnet sind,
können
verwendet werden, um die Aktivierung von Threads aus dem Thread-Pool 4 unter
Verwendung des Completion-Ports 20 weiter zu vereinfachen.
Wenn beispielsweise ein erster Thread 6, der eine Aufgabe verarbeitet,
die der Client-Anfrage 12 zugeordnet ist, ermittelt, dass
eine Ope ration, die der Client-Anfrage 12 zugeordnet ist,
aussteht (z.B. bei Vervollständigung
einer I/O-Operation), kann der Kontext des ersten Threads 6 der
entsprechenden Zustandsmaschine 22 unter Verwendung eines
Schlüssels
(nicht gezeigt) zugeordnet werden, worauf der erste Thread 6 dem
Pool 4 verfügbarer
Threads zurückgegeben
wird (z.B. wird der Thread 6 deaktiviert). Wird die Verarbeitung
der Anfrage 12 anschließend neugestartet, schreitet
die Ausführung
an der geeigneten Stelle oder dem geeigneten Zustand gemäß der entsprechenden
Zustandsmaschine 22 fort. Die Anfrage kann unter Verwendung
desselben Threads oder eines anderen Threads aus dem Thread-Pool (z.B.
dem Thread 6, 8 oder 10) neugestartet
werden. Beispielsweise kann der Completion-Port 20 den
Kontext von Thread 8 im Pool 4 der Zustandsmaschine 22 entsprechend
der Client-Anfrage 12 unter Verwendung des Schlüssel zuordnen,
um den Thread 8 auf der Basis eines Ereignisses zu aktivieren.
In dieser Hinsicht kann das Ereignis der Empfang eines Completion-Paketes 20 über eines
der Sockets 24, 26 oder 28 sein.
-
Zusätzlich zum
Thread-Pool 4, dem Completion-Port 20, den Zustandsmaschinen 22 und
den Schlüsseln
(nicht gezeigt) kann die HTTP-Stack-Komponente 2 der Client-Seite
einen Scheduler-Thread 30 enthalten, der dazu eingerichtet
ist, ein Objekt zu aktivieren, das dazu eingestellt ist, die Sendung
von Anfragen zu einer bestimmten Zeit zu beginnen. Beispielsweise
kann der Scheduler-Thread 30 eine zeitsortierte Warteschlange
innerhalb einer Verbindungs-Pool-Klasse (nicht gezeigt) für einige
Objekte überwachen,
die zu einer festgelegten Zeit aktiviert werden sollen. Der Thread 30 kann
anschließend
einen speziellen externen Eintrittspunkt aufrufen, um diese Objekte
zu passender Zeit zu aktivieren. Der Scheduler-Thread 30 kann sowohl dazu
verwendet werden, Objekte aus einer Client-Verbindungs-Klasse (nicht gezeigt) in
einer Warteschlange für
verzögerte
Aktivierung zu plazieren, als auch eine oder mehrere Operationen
zu unterbrechen, die in Bearbeitung sind. Beispielsweise können Operationen,
wie Senden, vom Scheduler-Thread 30 unterbrochen werden,
wenn diese zu einer festgelegten Zeit nicht abgeschlossen sind.
-
Die
Komponente
2 kann weiterhin einen Adressauflösungs-Thread
32 für DNS (Domain
Name System) enthalten, der dazu eingerichtet ist, Domainnamen zu
IP- Adressen aufzulösen. Der
DNS-Thread
32 kann eine Struktur aus einer Warteschlange
(nicht gezeigt) mit Daten über
eine DNS-Auflösung,
die zu erfolgen hat, akzeptieren und ist dazu eingerichtet die Auflösung auszuführen und
ein Ereignis in dieser Struktur über
die Vervollständigung
der Auflösung
zu signalisieren. Ein beispielhafter DNS-Thread kann durch den folgenden Muster-Code
implementiert werden:
-
Die
HTTP-Stack-Komponente 2 der Client-Seite kann zudem einen
Timeout-Thread 34 enthalten.
Der Timeout-Thread 34 kann eine Liste (nicht gezeigt) aktiver
Sockets (z.B. Sockets 24, 26 und 28)
und Timer (nicht gezeigt) enthalten, die jedem Socket zugeordnet
sind. Der Thread 34 kann dazu eingerichtet sein, wenigstens
ein Socket, wie etwa das Socket 24, 26 oder 28,
gemäß einem
Timer in der Liste zu unterbrechen.
-
Die
HTTP-Stack-Komponente 2 der Client-Seite enthält somit
eine Kommunikations-Engine, die auf eine clientseitige Kommunikation über das
HTTP-Protokoll ausgerichtet ist. Die Komponente 2 sorgt
für eine hohe
Leistungsfähigkeit,
hohe Gleichzeitigkeit (bei der Zahl paralleler Verbindungen), Skalierbarkeit
und Flexibilität
bei der Steuerung jedes Aspektes der HTTP-Kommunikation. Auf diese
Weise kann die Komponente 2 die Verarbeitung einer großen Zahl
von Client-Anfragen (z.B. Hunderte oder Tausende) unter Verwendung einer
begrenzten Anzahl von Threads (z.B. zehn) ermöglichen. Dies wird durch die
Verwendung des Thread-Pools 4 bewerkstelligt,
der eine Blockade um den Anruf bildet, um den Zustand vom Completion-Port 20 abzufragen.
Der Thread-Pool 4 kann ohne die Verwen dung einer Applikationsprogramm-Schnittstelle
(API) eines NT-Thread-Pools implementiert werden. Kommunikationen
können
mit Hilfe von Sockets (z.B. Socket 24, 26 und/oder 28)
erfolgen, wobei ein nicht blockierendes I/O am Completion-Port 20 vervollständigt wird. Auf
diese Art und Weise kann eine große Zahl von zeitgleichen Sockets
aufgenommen werden. Es können beispielsweise
10- bis 20-Tausend Sockets gleichzeitig geöffnet sein und I/O-Operationen
ausführen.
-
Die
Verbindungen oder Sockets 24, 26 und 28 können darüber hinaus
in einer C++-Klasse (nicht gezeigt) abstrahiert sein, wodurch es
einem Benutzer gestattet ist, auf einfache Weise das Verhalten zu
neu zu definieren und Daten an einer beliebigen Ebene der Kommunikation
abzufangen. Die Implementierung 2 ist darüber hinaus
dahingehend datengesteuert, dass eintreffende Daten die Verarbeitung
derselben aktivieren können.
Die selektive Aktivierung von Threads zur Verarbeitung von I/O-Operationen
erleichtert diese datengesteuerte Operation. Die HTTP-Stack-Komponente 2 kann
vorteilhaft als zahlreiche Klassen (z.B. C++-Klassen) implementiert werden. Die Komponente
kann beispielsweise als Kommunikations-Thread-Pool-Klasse, Client-Kommunikations-Klasse,
Verbindungs-Pool-Klasse
und Client-Simulator-Klasse implementiert werden, wie es im folgenden
detaillierter beschrieben wird. Darüber hinaus können kleinere
Klassen zur Abstraktion anderer Funktionalitäten, wie etwa eine SSL-Verschlüsselungs-Klasse, eine HTTP-Anfrage-Klasse
und dergleichen, vorgesehen sein.
-
Gemäß einem
Aspekt der Erfindung kann die HTTP-Stack-Implementierung der Client-Seite
zahlreiche Hauptklassen beinhalten. Es folgt eine Beschreibung einer
beispielhaften Implementierung mit Klassen, die im folgenden beschrieben
werden. Es wird jedoch darauf hingewiesen, dass andere derartige
Implementierungen als in der Geltungsbereich der vorliegenden Erfindung
fallend angesehen werden. Die Komponente 2 kann eine CCommunicationThreadPool-Klasse
beinhalten, die einen oder mehrere Thread-Pools (z.B. den Thread-Pool 4)
implementiert und eine Verbindungsobjekt-Verwaltung ausführt. Der
Thread-Pool 4 kann an Objekten aus einer CBasicClientConnection-Klasse
oder einer daraus abgeleiteten Klasse arbeiten. Darüber hinaus
können
die CBasicClientConnection-Objekte
dazu eingerichtet sein, eine oder mehrere andere Klassen, einschließlich einer
CMassiveHttpRequest-Klasse, zu verwenden. Durch Verwendung der CMassiveHttpRequest-Klasse
(oder Objekten, die aus dieser abgeleitet sind) kann ein Benutzer
das Verhalten der Komponente 2, wie etwa die Anfragenspeicherung, ändern.
-
Ein
oder mehrere Threads des Thread-Pools 4 können als
CCommunicationsThreadPool-Klassenobjekt und innerer oder interner
Code für
den Betrieb unterschiedlicher Typen von Thread-Pools implementiert werden.
Derartige Threads können
Scheduler-Threads (z.B. den Scheduler-Thread 30) beinhalten,
die dafür verantwortlich
sind, sich um die Verbindungsobjekte zu kümmern, die in einer Zeitwarteschlange
(nicht gezeigt) sortiert sind, und die damit fortfahren, Zustandsmaschinen
(z.B. die Zustandsmaschinen 22) für gewählte Verbindungsobjekte zu
einer bestimmten (z.B. zu einer geplanten) Zeit auszuführen. Darüber hinaus
können I/O-Completion-Threads
in der HTTP-Stack-Implementierungs-Komponente 2 enthalten sein,
die dazu eingerichtet sein können,
einen Completion-Zustand vom Completion-Port 20 zu verarbeiten
und die Ausführung von
Zustandsmaschinen 22 für
das geeignete Verbindungsobjekt aufzurufen, für das eine I/O-Operation abgeschlossen
ist.
-
Es
können
Verbindungs-Threads vorgesehen sein, die für die Verwaltung einer Verbindungswarteschlange
und die Simulation einer asynchronen TCP-Verbindungseinrichtung verantwortlich
sind, wie etwa durch Überwachen
mehrerer Objekte zur selben Zeit mit Hilfe einer WSAConnect()-Funktion.
Der DNS-Thread 32 kann
dazu eingerichtet sein, eine DNS-Anfrage-Warteschlange (nicht gezeigt)
zu verwalten, indem er eine DNS-Anfrage synchron verarbeitet (jedoch
ein asynchrones Verhalten simuliert) und indem er aufgelöste Adressen
in einem engine-weiten DNS-Auflösungs-Cache
(nicht gezeigt) plaziert. Der Timeout-Thread 34 ist dafür verantwortlich,
eine Timeout-Liste (nicht gezeigt) zu verwalten, die zur Effizienz
partitioniert sein kann, und ein Timeout für Verbindungsobjekte auszuführen, die
eine längere
als festgelegte I/O-Operation haben.
-
Es
können
Verbindungsobjekte in der Komponente 2 verwendet werden,
wie etwa (++-Objekte aus der CBasicClientConnection-Klasse oder
einer Klasse, die daraus abgeleitet ist. Der Thread-Pool (z.B. der Thread-Pool 4)
kann dazu eingerichtet sein, die CBasicClientConnection-Klassenobjekte
zu betätigen,
indem er sie akti viert oder sie in Listen und/oder Warteschlangen
einfügt
und/oder aus diesen entfernt. Ein Basislogik- und Zustandsmaschinen-Code
kann in den CBasicClientConnection-Objekten implementiert sein.
Es können zwei
Klassen von Verbindungsobjekten mit der beispielhaften Komponente 2 vorgesehen
sein. Die erste ist eine CBasicClientConnection-Klasse, die die
Basis-HTTP-Zustandsmaschine
mit einer SSL-Zustandsmaschine im Inneren implementiert. Die zweite
Klasse eines Verbindungsobjektes ist eine CClientConnection. Diese wird
von einer ersten abgeleitet und fügt die Implementierung von
HTTP-Authentifizierungsverfahren
und eine Rückleitungsunterstützung hinzu.
-
Benutzer
können
aus einer dieser Klassen ableiten und ihre Implementierung eines
gewünschten
Verhaltens in einem virtuellen EventCallback()-C++-Verfahren hinzufügen. Die
Verbindungsobjekte können
demzufolge Daten und Aktionen abstrahieren, die notwendig sind,
um eine TCP-Verbindung beispielsweise zu einem Webserver einzurichten,
und können
darüber
hinaus HTTP-Anfragen senden und HTTP-Anfragen verarbeiten. Gemäß der beispielhaften
Client-HTTP-Stack-Implementierungs-Komponente 2 können die
folgenden Regeln/Beziehungen auf Verbindungsobjekte angewendet werden:
es gibt eine Eins-zu-Eins-Beziehung
zwischen einem Verbindungsobjekt und einer aktiven TCP-Verbindung; ein Verbindungsobjekt
kann gleichzeitig lediglich eine HTTP-Anfrage ausführen; ein
Verbindungsobjekt kann eine beliebige Anzahl von HTTP-Anfragen nacheinander
ausführen;
ein Verbindungsobjekt kann eine beliebige Zahl von TCP-Verbindungen
nacheinander einrichten/abbauen; und jede Client-Verbindung sollte
einen Verweis zu einem zugehörigen
CMassiveHttpRequest-Objekt während
spezieller Schritte der Ausführung
haben, aus dem ein Zustandsmaschinen-Code Informationen extrahieren kann,
die erforderlich sind, um eine HTTP-Anfrage zu senden.
-
Die
Komponente 2 kann weiterhin ein oder mehrere Anfrageobjekte
beinhalten. Beispielsweise kann während der Ausführung der
Zustandsmaschine ein HTTP-Zustandsmaschinen-Code
bei der beispielhaften CBasicClientConnection-Klasse Informationen zum Einrichten
einer TCP-Verbindung oder zum Erzeugen einer HTTP-Anfrage benötigen. Dieser
Code kann erwarten, dass die Informationen in einem Objekt von der CMassiveHttpRequest-Klasse
oder einer abgeleite ten Klasse enthalten sind, und kann über nur
einen Verweis zu diesem Objekt verfügen. Den Benutzern steht es
frei, dessen Verhalten abzuleiten, zu überladen oder abzuändern, und
können
virtuelle Basisfunktionen implementieren, um erforderliche Informationen
bereitzustellen.
-
Ebenfalls
unter Bezugnahme auf 2 sind beispielhafte Beziehungen
zwischen zahlreichen Klassen der Komponente 2 dargestellt.
Ein beispielhafter CCommunicationThreadPool-Thread-Pool 50 kann
ein Beispiel des Objektes aus dieser Klasse sein, bei der fünf Typen
von Threads ablaufen, Scheduler-Threads 52, I/O-Completion-Threads 54,
Verbindungs-Threads 56, DNS-Threads 58 und Timeout-Threads 60.
Darüber
hinaus kann der Thread-Pool 50 fünf unterschiedliche Typen von
Warteschlangen/Listen haben, wie etwa eine Global-Verbindungsobjekt-Liste 62,
eine Aktiv-Verbindungsobjekt-Liste 64, eine zeitsortierte
Scheduler-Warteschlange 66,
eine DNS-Warteschlange 68 und eine partitionierte Timeout-Liste 70.
Diese Listen 62 bis 70 können verwendet werden, um Verbindungsobjekte,
an denen der Thread-Pool 50 arbeitet, in Abhängigkeit
von Aktion und Bedingungen zu registrieren. Die fünf Listen
oder Warteschlangen 62 bis 70 sind so dargestellt, dass
sie zu CBasicClientConnection-Klasseobjekten oder abgeleiteten Klasseobjekten
verweisen, die insgesamt mit 72 gekennzeichnet sind. Diese
Objekte 72 können
ihrerseits Verweise auf einzigartige oder gemeinsam genutzte CMassiveHttpRequest-Klasseobjekte
oder abgeleitete Klasseobjekte haben, die insgesamt mit 74 gekennzeichnet
sind und Informationen über
eine Client-Anfrage
haben können.
-
Die
HTTP-Stack-Implementierungs-Komponente 2 der Client-Seite
kann als C++-Klassen-Bibliothek implementiert
werden, die in einem Client-Computer verwendet werden kann, indem
sie mit einer DLL (Dynamic Link Library), wie etwa einer massive.dll,
bei exportierten Hauptklassen verknüpft wird, oder indem sie mit einer
statischen Bibliothek massives.lib verknüpft wird. Ein C++-Polymorphismus
kann für
die Erweiterbarkeit verwendet werden. Der Komponenten-Code kann
mit Hilfe der CBasicClientConnection-Klassen-Verfahren arbeiten,
und ein Benutzer kann diese Implementierung erweitern, indem er
aus dieser Klasse ableitet und deren Verhalten abändert. Beispielsweise
kann die Implementierung von speziellen Aktionen über eine
virtuelle EventCallback()-Funktion bereitgestellt werden, wobei
ein Verbindungsobjekt über Änderungen
in der Zustandsmaschine 22 unterrichtet werden kann. Darüber hinaus
kann ein ähnlicher
Ansatz im Bezug auf die HTTP-Anfragen-Speicherung verwendet werden,
wobei ein Verbindungsobjekt mit der CMassiveHttpRequest-Schnittstelle
arbeitet und ein Benutzer eine spezielle Anfragen-Speicherung hinzufügt.
-
Der
Thread-Pool kann beispielsweise unter Verwendung von reinen Win32-Threads implementiert werden.
Die Zahl der Threads kann, muss aber nicht, statisch sein, wobei Änderungen
lediglich während
des Maschinenstartes erfolgen. Die beispielhafte HTTP-Stack-Implementierung 2 kann
weiterhin dazu eingerichtet sein zu stoppen, ohne dass bestehende
Verbindungsobjekte geschlossen werden. Auf diese Weise ist es möglich, zahlreiche
Ereignisse der Komponente 2 im selben Ablauf stattfinden
zu lassen. Der Completion-Port 20 kann dazu verwendet werden,
HTTP-Sende-/Empfangsoperationen über
das TCP-Protokoll zu senden. Eine gestreute Windsock-Sendefunktion
kann zur Sendung von Anfragen verwendet werden. Darüber hinaus
kann eine Windwos-NT-LIST_ENTRY zur Implementierung von Listen von
Verbindungsobjekten in einigen Fällen implementiert
werden. Die Verbindungsobjekte können
durch Bezugnahme gezählt
werden und mehrere Einträge
an verschiedenen Stellen durch kritische Abschnitte geschützt werden.
Die Konkurrenz dieser kritischen Abschnitte kann beispielsweise
minimal sein, und kann lediglich für Wettlauf-Bedingungen in extrem
seltenen Fällen
vorgesehen sein. Die Operationen, die von der beispielhaften HTTP-Implementierung 2 ausgeführt werden,
sind im allgemeinen nicht blockierend, wobei lediglich Benutzeraktionen
im virtuellen EventCallback()-Verfahren einige Threads blockieren
können.
-
Auch
unter Bezugnahme auf 3 und 4 kann die
HTTP-Stack-Implementierungs-Komponente 2 der
Client-Seite eine oder mehrere Zustandsmaschinen (z.B. die Zustandsmaschinen 22)
enthalten. Es folgt eine Beschreibung eines beispielhaften Satzes
derartiger Zustandsmaschinen. Es wird jedoch darauf hingewiesen,
dass andere Implementierungen, die über andere Zustandsmaschinen
verfügen,
als jene, die im speziellen dargestellt und beschrieben sind, als
in den Geltungsbereich der vorliegenden Erfindung fallend angesehen
werden. In 3 ist eine beispielhafte CClientConnection-Klasse 80 dargestellt,
die vier Zustandsmaschi nen enthält,
eine HTTP-Authentifizierungs-Maschine 82, eine HTTP-Parser-Zustandsmaschine 84,
eine SSL-Zustandsmaschine 86 und eine TCP-Datensendungs-Zustandsmaschine 88.
Diese Zustandsmaschinen 82, 84, 86 und 88 können sich
gegenseitig beeinflussen, um die Verarbeitung zu steuern, wobei
die Zustandsmaschinen ihre jeweiligen Zustände innerhalb der Verbindungsobjekte
beibehalten.
-
Der
CCommunicationThreadPool-Thread-Pool
80 kann öffentlich über eine
Applikationsprogramm-Schnittstelle (API) verwendet werden. Die folgende
Tabelle beschreibt zahlreiche beispielhafte Verfahren, die für die öffentliche
Verwendung verfügbar
sein können:
-
Die
HTTP-Stack-Implementierung
2 der Clientseite kann darüber hinaus
während
des Ablaufs statistische Informationen anhäufen. Es kann ein QueryStatistics()-Verfahren in der
Komponente
2 vorgesehen sein, das dazu eingerichtet ist,
einen Verweis zum Statistikaufbau in der Komponente
2 zurückzugeben.
Der folgende beispielhafte Aufbau enthält Informationen über Daten,
die während
eines Ablaufs gesammelt werden:
-
Die
beispielhafte HTTP-Implementierungs-Komponente 2 kann weiterhin
zwei Verbindungsklassen beinhalten. Die Funktionalität kann zwischen
diesen beiden Klassen zur Vereinfachung aufgeteilt werden, indem
beispielsweise die HTTP-Authentifizierungs-Zustandsmaschine 82 in
die CClientConnection-Klasse 80 bewegt wird, während die
Basis-HTTP-Parser, die SSL- und die TCP-Sende-Zustandsmaschinen 84, 86 bzw. 88 in
der CBasicClientConnection-Klasse vorgesehen sind. Für den allgemeinsten
Fall kann die obere Klasse (z.B. die CClientConnection-Klasse 80)
verwendet werden. In diesem Fall zeigt die folgende Tabelle eine
beispielhafte Funktionalität,
die sichtbar sein kann, wenn aus der CClientConnection-Klasse 80 abgeleitet
wird.
-
-
-
-
Die
Verbindungsobjekte können
durch Übernehmen
einer C++--Klasse aus der CBasicClientConnection-Klasse oder der
CClientConnection-Klasse
80 und durch Empfangen von Aufrufen
in einem virtuellen EventCallback()-Verfahren implementiert werden.
Die folgende Tabelle zeigt beispielhafte Ereignisse, die zur EventCallback()-Funktion
während
spezieller Ereignisse in der Verbindungsobjekt-Zustandsmaschine
gesendet werden können:
-
Die
unterschiedlichen Beziehungen zwischen den beispielhaften Ereignissen
der obigen Tabelle und den beispielhaften Zustandmaschinen
82,
84,
86 und
88 der
CClientConnection-Klasse
80 sind in
4 dargestellt.
Die Zustandsmaschinen
82,
84,
86 und
88 können unterschiedliche
Zustände
zu einer gegebenen Zeit gemäß dem Fortschritt
der Aufgabenverarbeitung durch einen aktivierten Thread (z.B. aus
dem Thread-Pool
4) haben. Darüber hinaus können die
beispielhaften Zustandsmaschinen
82,
84,
86 und
88 miteinander
interagieren oder sich gegenseitig steuern, wodurch ein Übergang
beim Zustand einer Zustandsmaschine
82,
84,
86 oder
88 den
Zustand einer weiteren Zustandsmaschine beeinflussen kann. Ein Zustandsmaschinen-Zustand
kann für
jedes Verbindungsobjekt beibehalten werden. Wenn ein Thread (z.B.
aus dem Thread-Pool
4) aktiviert wird, beginnt somit die
Verarbeitung einer speziellen Client-Anfrage gemäß der entsprechenden Zustandsmaschine
dort, wo die Anfragenverarbeitung aufhörte. Ein Benutzer kann den
Zustand einer Zustandsmaschine ändern,
wenn eine Nachricht bei der EventCallback()-Funktion empfangen wird,
oder über
externe Threads durch Aufrufen einer ChangeStateToEx()-Funktion.
Die folgende Tabelle zeigt einige beispielhafte Zustandsmaschinen-Zustände und
Erläuterungen
für diese:
-
Gemäß der beispielhaften
HTTP-Stack-Implementierung
2 kann jede Verbindung statistische
Informationen während
des Ablaufs anhäufen.
Ein QuerryStatistics()-Verfahren
gibt einen Verweis an den Statistikaufbau in der Komponente
2 zurück. Der
folgende beispielhafte Aufbau stellt Informationen bereit, die sich
auf statistische Daten beziehen, die während eines derartigen Ablaufs
gesammelt werden:
-
Die
Verbindungsobjekte in der HTTP-Stack-Implementierungs-Komponente
2 der
Client-Seite können einen
Verweis zu einem zugehörigen
Anfrageobjekt aus der CMassiveHttpRequest-Klasse oder einer davon abgeleiteten
Klase enthalten und können
ein oder mehrere Verfahren draus verwenden. Die übernommene Klasse kann die
folgenden virtuellen Elementfunktionen mit einem derartigen Verhalten
implementieren:
-
Die
folgenden Beispiele zeigen einige der Merkmale, die bei der Verwendung
der beispielhaften HTTP-Stack-Implementierungs-Komponente 2 der
Client-Seite verfügbar
sind. Beim ersten Beispiel ist es erwünscht, Seiten mit Informationen
(z.B. von einem Server-Computersystem) so schnell wie möglich herunterzuladen.
-
-
-
-
Ereignisfluss während der
Ausführung
-
Die
folgende Tabelle zeigt einen beispielhaften Verlauf von Ereignissen,
die zur beispielhaften EventCallback()-Funktion während der
Ausführung
des obigen Beispiels #1 unter Verwendung einer einzigen gleichzeitigen
Verbindung zur Vereinfachung gesendet wurden:
-
Beispiel #2
-
Das
folgende Beispiel #2 zeigt fortgeschrittene Merkmale der Komponente
2,
einschließlich
der Fähigkeit,
ein Verbindungsobjekt in einem bestimmten Zustand zu stoppen, etwas
anderes zu tun und anschließend dort
fortzufahren, wo die Beendigung erfolgte:
-
Es
wird darauf hingewiesen, dass die oben beschriebene HTTP-Stack-Implementierung 2 der
Client-Seite lediglich eine einer Vielzahl möglicher Implementierungen ist,
die in den Geltungsbereich der vorliegenden Erfindung fallen. Unter
Bezugnahme auf 5 kann die HTTP-Stack-Implementierung 2 vorteilhaft
in Verbindung mit einem Client-Computersystem 100 verwendet
werden. Das System kann weiterhin eine TCP-Schicht-Implementierung 102 und
eine IP-Schicht-Implementierung 104 enthalten.
Zusammen mit den Implementierungen 102 und 104 stellt
die HTTP-Stack-Implementierung 2 eine Schnittstelle zum
Ver arbeiten einer oder mehrerer Client-Anfragen 12, 14 und/oder 16 von
einer Client-Applikationskomponente 18 bereit. Beispielsweise
können
diese Client-Anfragen 12, 14 und/oder 16 von
der Komponente 2 durch Zugriff auf das Internet oder ein
anderes Netzwerk 106 über
die TCP- bzw. die IP-Schicht 102 und 104 verarbeitet
werden.
-
Wie
es oben unter Bezugnahme auf 1 beschrieben
wurde, enthält
die beispielhafte Komponente 2 einen Thread-Pool 4 mit
N Threads 8, 8 und 10, wobei N eine ganze
Zahl ist, zum Ausführen
oder anderweitigen Verarbeiten einer oder mehrerer der M Client-Anfragen 12, 14 und 16,
wobei M eine ganze Zahl größer als
N ist. Beispielsweise können
die Threads 6, 8 und 10 des Thread-Pools 4 für die Ausführung einer
speziellen Anfrage (z.B. der Anfrage 12, 14 oder 16)
gemäß einem
Gleichzeitigkeitswert (nicht gezeigt) eingestellt werden, der einem
Completion-Port 20 zugeordnet ist. Wenn der Gleichzeitigkeitswert
(z.B. 10) für
den Completion-Port 20 nicht erreicht wurde und eine oder
mehrere der M Anfragen 12, 14 und/oder 16 eine
Verarbeitung erfordern, kann somit ein Thread aus dem Thread-Pool 4 aktiviert
und einer Anfrage zugeordnet werden, um eine derartige Verarbeitung
auszuführen.
Zudem können
gemäß der Erfindung
Threads selektiv durch den Completion-Port 20 beispielsweise
dann aktiviert werden, wenn ein Completion-Paket im Completion-Port 20 empfangen
wird.
-
Die
Verarbeitung unterschiedlicher Aufgaben, die einer speziellen Client-Anfrage
zugeordnet sind, können
gemäß einer
oder mehrerer der Zustandsmaschinen 20 bewerkstelligt werden.
Beispielsweise können die
Zustandsmaschinen 20 für
die TCP-Datensendung (z.B. die Zustandsmaschine 88 aus 3 und 4), die
Sicherheitsprotokoll-Implementierung (z.B. die Secure-Sockets-Layer-(SSL-)Implementierungs-Zustandsmaschine 86),
das Daten-Parsing (z.B. die HTTP-Parser-Zustandsmaschine 84) und/oder
für die
Authentifizierung (z.B. die HTTP-Authentifizierungs-Zustandsmaschine 82)
bereitgestellt sein. Die Zustandsmaschinen 22, die der
Verarbeitung der Client-Anfragen 12, 14 und/oder 16 zugeordnet
sind, können
somit verwendet werden, um weiter die Aktivierung von Threads aus
dem Thread-Pool 4 unter Verwendung des Completion-Ports 20 zu
vereinfachen.
-
Wenn
beispielsweise ein erster Thread 6, der eine Aufgabe bearbeitet,
die der Client-Anfrage 12 zugeordnet ist, bestimmt, dass
die Aufgabe aussteht (z.B. eine I/O-Operation), kann der Kontext
des ersten Threads 6 der entsprechenden Zustandsmaschine 22 unter
Verwendung eines Schlüssels
(nicht gezeigt) zugeordnet und der erste Thread 6 anschließend deaktiviert
werden. Anschließend
kehrt der erste Thread 6 zum Thread-Pool 4 zurück. Wenn
die Verarbeitung der Anfrage 12 anschleißend neugestartet
wird, schreitet die Verarbeitung an der geeigneten Stelle gemäß der Zustandsmaschine 22 fort.
Die Anfrage kann mit Hilfe desselben oder eines anderen Threads
aus dem Thread-Pool 4 (z.B. dem Thread 6, 8 oder 10)
neugestartet werden. Beispielsweise kann der Completion-Port 20 den
Kontext des Threads 8 im Pool 4 der Zustandsmaschine 22 mit
Hilfe des Schlüssels
zuordnen, um den Thread 8 auf der Basis eines Ereignisses
zu aktivieren. In dieser Hinsicht kann das Ereignis der Empfang
eines Completion-Paketes im Completion-Port 20 sein.
-
Unter
Bezugnahme auf 6 bis 8 kann eine
beispielhafte HTTP-Stack-Implementierung 2 einer Client-Seite
in einer Vielfalt von Situationen eingesetzt werden, wobei die verbesserten
Client-Anfrage-Verarbeitungsfähigkeiten
derselben Leistungsvorteile gegenüber vorherigen HTTP-Stack-Implementierungen
bieten. In 6 enthält das Client-Computersystem 100 die
HTTP-Stack-Implementierung 2 der
Client-Seite, die TCP-Schicht-Implementierung 102 und die
IP-Schicht-Implementierung 104. Ein Benutzer 120 kann
eine Webbrowser-Applikationskomponente 122 über eine
Benutzerschnittstellen-Komponente 124 betätigen, wodurch die
Webbrowser-Applikation 122 eine oder mehrere Client-Anfragen zum Beziehen
von Daten, Bildern oder anderen Daten von einem oder mehreren Server-Computersystemen 130, 132, 134 und/oder 136 über das
Internet 106 erzeugen kann.
-
Das
beispielhafte Server-Computersystem 130 kann eine serverseitige
IP-Schicht-Implementierung 140,
eine serverseitige TCP-Schicht-Implementierung 142 und
eine serverseitige HTTP-Stack-Implementierung 144 enthalten,
die eine Schnittstelle zwischen dem Internet 106 und einer
Internet-Informationsserver-Softwareapplikation 146 bereitstellen. Ähnliche
Netzwerkschicht-Implementierungen
und -Applikationen (nicht gezeigt) können in den Server- Computersystemen 132, 134 und 136 vorgesehen
sein. Der beispielhafte HTTP-Stack 2 der
Client-Seite sorgt für
eine schnelle Bearbeitung mehr als einer Client-Anfrage durch Verwendung von mehreren
Threads (z.B. der Threads 6, 8 und 10 des
Thread-Pools 4), die selektiv aktiviert werden können, um
die Aufgabenbearbeitung auszuführen,
und selektiv deaktiviert werden können (z.B. bei Erfassen, dass
eine Operation, die verarbeitet wird, aussteht), um einen optimalen
oder verbesserten Anfragendurchsatz im Client-Computer 100 zu
erzeugen. Wenngleich die Webbrowser-Applikation 122 des
Client-Systems 100 keine große Zahl derartiger Client-Anfragen
erzeugen kann, kann der Client-HTTP-Stack 2 in Verbindung
mit den clientseitigen Applikationen verwendet werden, die eine
Verarbeitung vieler Hunderte oder Tausende von Anfragen in einer
kurzen Zeitdauer verlangen.
-
Unter
Bezugnahme auf 7 kann ein beispielhaftes Computersystem 100 eine
Firmen-zu-Firmen-Applikationssoftware-Komponente 150 zusammen
mit dem HTTP-Client-Stack 2, der TCP-Schicht 102 und
der IP-Schicht 104 enthalten. Die Applikationskomponente 150 kann
beispielsweise Transaktions-Bearbeitungsmerkmale,
wie etwa eine Firmenguthaben-Verifizierungsfunktionalität oder dergleichen,
aufweisen. Andere Client-Computer 160, 162 und/oder 164,
die Firmen-Applikationskomponenten 161, 163 bzw. 165 haben,
können
auf das System 100 über
das Internet 106 zugreifen. Beispielsweise können die
Client-Computer 160, 162 und 164 durch
Banken oder andere Leihinstitutionen betätigt werden, wobei die Firmen-Applikationskomponenten 161, 163 und/oder 165 Anfragen
auf Guthabeninformationen erzeugen können, die sich auf potentielle
Darlehens-Clients beziehen können.
-
Eine
beliebige Zahl derartiger Client-Computer (z.B. die Computer-Systeme 160, 162 und 164)
können somit
Anfragen zur Firmen-zu-Firmen-Applikationssoftware-Komponente 150 senden,
die im System 100 läuft. Die
Applikationskomponente 150 kann ihrerseits dazu eingerichtet
sein, aktualisierte Guthabeninformationen von einem oder mehreren
Computersystemen 170, 172 und/oder 174 zu
erhalten, die über
Internet-Informationsserver-Softwarekomponenten 171, 173 bzw. 175 verfügen, die
darauf installiert sind. Somit kann es erforderlich sein, dass das
Client-Computersystem 100 eine große Zahl von Client-Anfragen
in einer kurzen Zeitdauer erzeugt, um den Anfragen, die von den
Client-Computern 160, 162 und/oder 164 gesendet
werden, zeitlich gerecht zu werden.
-
Die
Server-Computersysteme 170, 172 und/oder 174 können darüber hinaus
individuell Guthabeninformations-Datenbanken (nicht gezeigt) enthalten,
aus denen Guthabeninformationen bezogen und zum beispielhaften Client-Computersystem 100 weitergeleitet
werden können.
Bei diesem Szenario muss das System 100 eine große Anzahl
von Anfragen und Antworten von den Server-Computersystemen 170, 172 und 172 zeitlich
verarbeiten, um den Anforderungen der Firmen-zu-Firmen-Applikationssoftware-Komponente 150 gerecht
zu werden. Herkömmliche
clientseitige Stack-Implementierungen, die lediglich ein I/O-Socket
und einen einzigen Ausführungs-Thread
bereitstellen, können
nicht den notwendigen Anfragenverarbeitungs-Durchsatz erzeugen.
Die Verwendung der Multithreading-Techniken (z.B. des Thread-Pools 4)
und die Bereitstellung eines oder mehrerer Completion-Ports (z.B.
des Completion-Ports 20) in der Client-HTTP-Stack-Implementierung 2 bieten
somit deutliche Vorteile gegenüber
vorherigen Verfahren und Implementierungen.
-
Unter
Bezugnahme auf 8 ist nun ein weiteres Verfahren
dargestellt, bei dem die Vorteile der vorliegenden Erfindung angewendet
werden können.
Bei diesem Beispiel kann das beispielhafte Client-Computersystem 100 eine
Automobilortungs-Applikationssoftware-Komponente 180 enthalten,
die dazu eingerichtet ist, verfügbare
Kraftfahrzeuge in Abhängigkeit
von Anfragen von einem oder mehreren Client-Computern 182 und 184 zu
orten. Die Computer 182 und 184 können Webbrowser 183 bzw. 185 enthalten,
mit denen Benutzer 186 und 188 eine oder mehrere
Suchanfragen erzeugen können.
-
Die
Benutzer 168 und 188 können es beispielsweise wünschen,
nach Preis-, Verfügbarkeits-
und/oder Optionsinformationen, die sich auf Autos und Lastwagen
beziehen, in einer bestimmten geografischen Region zu suchen. Die
Automobilortungs-Applikation 180 kann über Anfragen von den Browsern 183 und 185 befragt werden.
Die Applikation 180 kann ihrerseits eine Anzahl von Anfragen
für derartige
Informationen über
das Internet 106 von einem oder mehreren Automobilhändler-Serversystemen 190, 192 und/oder 194 erzeugen.
Diese Systeme 190, 192 und 194 können Internet-Informationsserver-Softwarekomponenten 191, 193 bzw. 195 enthalten.
-
Die
Systeme 190, 192 und 194 können anschließend geeignete
Antworten auf die Anfragen vom Client-System 100 erzeugen,
um der Applikations-Komponente 180 aktualisierte Informationen
zuzuführen.
Da es eine große
Zahl derartiger Client-Computer
(z.B. die Computer 182 und 184) geben kann, die
Informationen von der Automobilortungs-Applikation 180 abfragen,
kann es eine große
Zahl von Anfragen, die von der Komponente 180 (z.B. für Informationen
von den Servern 190, 192 und/oder 194)
erzeugt werden, wie auch Antworten darauf geben, die vom HTTP-Stack 2 der
Client-Seite verarbeitet werden müssen. Der erhöhte Anfragenverarbeitungs-Durchsatz,
der gemäß der Erfindung
erreichbar ist, bietet somit deutliche Vorteile gegenüber vorherigen
HTTP-Stack-Implementierungs-Techniken der Client-Seite mit einem
einzigen Socket und einem einzigen Thread.
-
9 und 10 zeigen
ein beispielhaftes Verfahren 200 zur Implementierung eines
HTTP-Stack der Client-Seite. Wenngleich das Verfahren 200 hier
als eine Abfolge von Schritten dargestellt und beschrieben ist, ist
die vorliegende Erfindung nicht auf die dargestellte Reihenfolge
von Schritten beschränkt.
Somit können
gemäß der Erfindung
einige Schritte in anderen Reihenfolgen und/oder zeitgleich mit
anderen Schritten auftreten, als dies hier gezeigt und beschrieben
ist. Darüber
hinaus müssen
nicht alle dargestellten Schritte erforderlich sein, um die Methodik
gemäß der Erfindung
zu implementieren. Das Verfahren 200 kann darüber hinaus
in anderen Systemen, als sie hier dargestellt und beschrieben sind,
wie auch in anderen Systemen implementiert werden, die nicht speziell
beschrieben sind.
-
Beginnend
bei Schritt 202 umfasst das Verfahren 200 den
Empfang einer Anfrage von einer Client-Applikation bei Schritt 204.
Beispielsweise kann der beispielhafte Client-HTTP-Stack 2 des
Systems 100 eine oder mehrere derartiger Anfragen von der
Automobilortungs-Applikationssoftware-Komponente 180 empfangen.
Bei Schritt 206 wird die empfangene Anfrage einer Zustandsmaschine
zugeordnet, wobei die Verfügbarkeit
eines Threads zum Verarbeiten der Anfrage beim Entscheidungsschritt 208 bestimmt
wird. Ist kein Thread verfügbar,
wartet das Verfahren 200 auf einen verfügbaren Thread bei Schritt 210.
Sobald ein Thread in Schritt 208 verfügbar wird, wird der verfügbare Thread
einer Anfrage bei Schritt 212 zugeordnet.
-
Anschließend wird
die Anfrage unter Verwendung des Threads bei Schritt 214 verarbeitet.
Ist die Verarbeitung der Anfrage bei Schritt 216 abgeschlossen,
endet das Verfahren bei Schritt 218. Andernfalls erfolgt eine
Bestimmung bei Schritt 220, ob die Verarbeitung der Anfrage
aussteht (z.B. warten, bis eine I/O-Operation abgeschlossen ist).
Wenn nicht, schreitet das Verfahren 200 wieder zu Schritt 214 fort,
bei dem die Anfrage unter Verwendung des verfügbaren Threads weiter verarbeitet
wird.
-
Bestimmt
der Thread, das die Verarbeitung der Anfrage aussteht, schreitet
das Verfahren 200 von Schritt 220 zu Schritt 222 von 10 fort,
wo der Thread-Kontext einer Zustandsmaschine unter Verwendung eines
Schlüssels
zugeordnet wird. Anschließend
wird der Thread deaktiviert und dem Thread-Pool (z.B. dem Thread-Pool 4),
bei Schritt 224 zurückgegeben.
Anschließend
erfolgt bei Schritt 226 eine Bestimmung, ob ein Completion-Paket
(z.B. am Completion-Port 20) empfangen wurde. Wenn nicht,
wartet das Verfahren 200 auf ein derartiges Paket bei Schritt 228.
Sobald ein derartiges Completion-Paket bei Schritt 226 empfangen
wird, schreitet das Verfahren 200 zu Schritt 230 fort,
bei dem das empfangene Completion-Paket der Zustandsmaschine unter
Verwendung des Schlüssels
zugeordnet wird. Das Verfahren 200 kehrt anschließend zu
Schritt 208 von 9 zurück, bei dem die Verfügbarkeit
eines Threads (z.B. desselben Threads, der zuvor verwendet wurde,
oder eines weiteren Threads aus dem Thread-Pool 4) erneut
geprüft
wird.
-
Das
beispielhafte Verfahren 200 ermöglicht somit die selektive
Aktivierung und Deaktivierung von verarbeitenden Threads in einem
Multithreading-System, wodurch eine verbesserte Anfragenverarbeitung
erreicht wird. Das Verfahren 200 kann somit vorteilhaft
bei der Verarbeitung von clientseitigen Anfragen in einem Computersystem
(z.B. dem System) insbesondere dann verwendet werden, wenn eine
große
Zahl derartiger Anfragen in einem kurzen Zeitraum verarbeitet werden
muss.
-
Um
einen Kontext für
die unterschiedlichen Aspekte der Erfindung herzustellen, ist mit 11 und
der folgenden Erläuterung
beabsichtigt, eine kurze, allgemeine Beschreibung einer geeigneten
Berechnungsumgebung zu geben, in der die unterschiedlichen Aspekte
der vorliegenden Erfindung implementiert werden können. Obwohl
die Erfindung oben im allgemeinen Zusammenhang von Softwarewerkzeugen
und computerausführbaren
Anweisungen eines Computerprogramms beschrieben wurde, das auf einem
Computer und/oder Computern läuft,
wird der Fachmann erkennen, das die Erfindung ebenso in Kombination
mit anderen Programmmodulen implementiert werden kann. Im allgemeinen
beinhalten Programmmodule Routinen, Programme, Komponenten, Datenstrukturen
und dergleichen, die spezielle Aufgaben ausführen und/oder spezielle abstrakte
Datentypen implementieren.
-
Darüber hinaus
wird der Fachmann verstehen, das die Verfahren der Erfindung mit
anderen Konfigurationen von Computersystemen in die Praxis umgesetzt
werden können,
wie etwa Einzelprozessor- oder Multiprozessor-Computersystemen, Minicomputern, Großrechnern,
wie auch PCs, Handcomputergeräten,
mikroprozessorbasierten oder programmierbaren Verbraucherelektronikgeräten und
dergleichen. Die dargestellten Aspekte der Erfindung können auch
in verteilten Berechungsumgebungen praktiziert werden, in denen
Aufgaben von entfernten Verarbeitungsvorrichtungen ausgeführt werden
können,
die über
ein Kommunikationsnetzwerk verbunden sind. Jedoch können einige,
wenn nicht sämtliche,
Aspekte der Erfindung in Computer-Einzelgeräten ausgeführt werden. In einer verteilten
Berechungsumgebung können
sich Programmmodule sowohl in lokalen als auch in entfernten Speichervorrichtungen
befinden.
-
Unter
Bezugnahme auf 11 enthält eine beispielhafte Umgebung 310 zur
Implementierung unterschiedlicher Aspekte der Erfindung einen Computer 312,
der eine Verarbeitungseinheit 314, einen Systemspeicher 316 und
einen Systembus 318 enthält, der unterschiedliche Systemkomponenten,
einschließlich
des Systemspeichers, mit der Verarbeitungseinheit 314 verbindet.
Die Verarbeitungseinheit 314 kann ein beliebiger unterschiedlicher
im Handel verfügbarer
Prozessoren sein, die, ohne darauf beschränkt zu sein, umfassen: Intel
x86, Pentium® und
kompatible Mikroprozessoren von Intel und dergleichen, einschließlich Cyrix,
AMD und Nexgen; Alpha® von Digital; MIPS® von
MIPS Technology, NEC, IDT, Siemens und andere; sowie der PowerPC® von
IBM und Motorola. Duale Mikroprozessoren und andere Multiprozessor-Architekturen
können
ebenfalls als Verarbeitungseinheit 314 verwendet werden.
-
Das
System 318 kann ein beliebiges unterschiedlicher Typen
von Busaufbauten sein, die einen Speicherbus oder Speichercontroller,
einen Peripheriebus und einen lokalen Bus beinhalten, bei dem eine
beliebige einer Vielfalt von herkömmlichen Busarchitekturen,
wie etwa PCI, VESA, Microchannel, ISA und EISA, verwendet wird,
um nur ein paar wenige zu erwähnen.
Der Speicher des Computers 312 kann einen ROM (Read Only
Memory) 320 und einen RAM (Random Access Memory) 322 beinhalten.
Eins Basis-Eingangs-/Ausgangssystem (BIOS), das die Basisroutinen
enthält,
die dabei hilfreich sind, Informationen zwischen Elementen innerhalb
des Computers 312, wie etwa während des Startens, zu übertragen,
ist im ROM 320 gespeichert.
-
Der
Computer 312 beinhaltet zudem ein Festplattenlaufwerk 324,
ein Magnetdiskettenlaufwerk 326, um beispielsweise auf
eine entnehmbare Diskette zu schreiben, oder von dieser zu lesen,
sowie ein optisches Plattenlaufwerk 330, um beispielsweise
eine CD-ROM-Platte 332 zu lesen, oder um von einem optischen
Medium zu lesen oder auf dieses zu schreiben. Das Festplattenlaufwerk 324,
das Magnetdiskettenlaufwerk 326 und das optische Plattenlaufwerk 330 sind
mit dem Systembus 318 über
eine Festplattenlaufwerksschnittstelle 334, eine Magnetdiskettenlaufwerksschnittstelle 336 bzw.
eine Schnittstelle 338 für ein optisches Plattenlaufwerk
verbunden. Die Laufwerke und ihre zugehörigen computerlesbaren Medien
stellen einen nicht flüchtigen Speicherbereich
für Daten,
Datenstrukturen, computerausführbare
Anweisungen und dergleichen für
den Computer 312 einschließlich der Speichers für die Programmrundsendung
in einem geeigneten Digitalformat bereit.
-
Wenngleich
sich die Beschreibung eines computerlesbaren Mediums oben auf eine
Festplatte, eine entnehmbare Magnetdiskette und eine CD-ROM bezieht,
wird der Fachmann verstehen, dass andere Typen von Medien, die von
einem Computer gelesen werden können,
wie etwa ZIP-Laufwerke, Magnetkassetten, Flash- Speicherkarten, digitale Videoplatten,
Bernoulli-Kassetten und dergleichen, ebenfalls in der beispielhaften
Betriebsumgebung verwendet werden können, und dass derartige Medien
weiterhin computerausführbare Anweisungen
enthalten können,
um die Verfahren der vorliegenden Erfindung auszuführen.
-
Eine
Reihe von Programmmodulen kann auf den Laufwerken und im RAM 322 gespeichert
sein, die ein Betriebssystem 340, eines oder mehrere Applikationsprogramme 342,
andere Programmmodule 344 und Programmdaten 346 umfassen.
Das Betriebssystem 340 im dargestellten Computer ist beispielsweise
das Betriebssystem "Microsoft
Windows NT", wenngleich
darauf hingewiesen wird, dass die vorliegende Erfindung mit anderen
Betriebssystemen oder Kombinationen aus Betriebssystemen, wie etwa
UNIX, LINUX und dergleichen, verwendet werden kann.
-
Ein
Benutzer kann Befehle und Informationen in den Computer 312 durch
eine Tastatur 348 und eine Zeigevorrichtung, wie etwa eine
Maus 350, eingeben. Andere Eingabevorrichtungen (nicht
gezeigt) können
ein Mikrofon, eine IR-Fernbedienung,
einen Joystick, ein Gamepad, eine Satellitenschüssel, einen Scanner und dergleichen
umfassen. Diese und andere Eingabevorrichtung sind in vielen Fällen mit
der Verarbeitungseinheit 314 durch eine Seriellanschluss-Schnittstelle 352 verbunden,
die mit dem Systembus 318 gekoppelt ist, können jedoch
auch über
andere Schnittstellen, wie etwa einen Parallelanschluss, einen Spieleanschluss, über USB,
eine IR-Schnittstelle und dergleichen, angeschlossen sein. Ein Monitor 354 oder
ein anderer Typ einer Anzeigevorrichtung ist ebenfalls mit dem Systembus 318 über eine
Schnittstelle, wie etwa einen Videoadapter 356, verbunden.
Zusätzlich
zum Monitor enthält
ein Computer normalerweise andere Peripherie-Ausgabevorrichtungen
(nicht gezeigt), wie etwa Lautsprecher, Drucker und dergleichen.
-
Der
Computer 312 kann in einer Netzwerkumgebung mit Hilfe logischer
Verbindungen zu einem oder mehreren entfernten Computern, wie etwa
einem entfernten Computer (den entfernten Computern) 358,
arbeiten. Der entfernte Computer (die entfernten Computer) 358 kann
eine Workstation, eine Servercomputer, ein Router, ein PC, ein mikroprozessorbasiertes
Unterhaltungsgerät
(z.B. ein Web-TV- Client-System),
eine Peer-Vorrichtung oder ein anderer üblicher Netzwerkknoten sein
und enthält
normalerweise zahlreiche oder sämtliche
der Elemente, die im Bezug auf den Computer 312 beschrieben
wurden, wenngleich aus Gründen der
Kürze lediglich
eine Speichervorrichtung 360 dargestellt ist. Die dargestellten
logischen Verbindung beinhalten ein LAN (lokales Netzwerk) 362 und
ein WAN (Weitverkehrsnetz) 364. Derartige Netzwerkumgebungen sind
in Büros,
unternehmensweiten Computernetzwerken, Intranets und dem Internet
allgemein üblich.
-
Bei
Verwendung in einer LAN-Netzwerkumgebung ist der Computer 312 mit
dem lokalen Netzwerk 362 durch eine Netzwerkschnittstelle
oder eine Netzwerkadapter 366 verbunden. Bei Verwendung
in einer WAN-Netzwerkumgebung enthält der Computer 312 normalerweise
ein Modem 368, oder ist mit einem Kommunikationsserver
im LAN verbunden, oder verfügt über andere
Einrichtungen zur Einrichtung von Kommunikationen über das
WAN 364, wie etwa das Internet. Das Modem 368,
das intern oder extern sein kann, ist mit dem Systembus 318 über die
Seriellanschlussschnittstelle 352 (z.B. für Kommunikationen über POTS)
verbunden. Alternativ kann das Modem 368 mit dem Systembus 318 über die
Netzwerkschnittstelle oder den Netzwerkadapter 366 (z.B.
für Kommunikationen über DSL,
Kabel, Satellit, etc.) verbunden sein. In einer Netzwerkumgebung
können
Programmmodule, die im Bezug auf den Computer 312 dargestellt
sind, oder Teile derselben in der entfernten Speichervorrichtung 360 gespeichert
sein. Es wird darauf hingewiesen, das die dargestellten Netzwerkverbindungen
beispielhaft sind und andere Vorrichtungen zum Einrichten einer
Kommunikationsverbindung zwischen den Computern verwendet werden
können.
-
Obwohl
die Erfindung im Bezug auf bestimmte Implementierungen dargestellt
und beschrieben wurde, versteht es sich, das äquivalente Abänderungen
und Modifikationen anderen Fachleuten beim Lesen und Verstehen dieser
Beschreibung und den beiliegenden Zeichnungen in den Sinn kommen
werden. In spezieller Hinsicht auf die unterschiedlichen Funktionen,
die von den oben beschriebenen Komponenten (Anordnungen, Vorrichtungen,
Schaltungen, Systemen, etc.) ausgeführt werden, ist mit den Begriffen
(einschließlich
einer Bezugnahme auf eine "Einrichtung"), die verwendet
wurden, um derartige Komponenten zu beschreiben, beabsichtigt, dass
diese, sofern es nicht anders vermerkt ist, einer beliebigen Komponente
entsprechen, die die spezielle Funktion der beschriebenen Komponente
ausführt
(d.h. dass sie funktional äquivalent
ist), wenngleich sie von der Konstruktion her nicht zum beschriebenen
Aufbau äquivalent
ist, der die Funktion bei den hier dargestellten beispielhaften
Applikationen und Implementierungen der Erfindung ausführt.
-
Obwohl
darüber
hinaus ein spezielles Merkmal der vorliegenden Erfindung im Bezug
auf lediglich einen von zahlreichen Aspekten oder Implementierungen
der Erfindung beschrieben worden sein mag, kann ein derartiges Merkmal
mit einem oder mehreren Merkmalen der anderen Implementierungen
je nach Wunsch, und wie es für
eine beliebige oder spezielle Anwendung von Vorteil ist, kombiniert
werden. In dem Umfang, in dem die Begriffe "enthält", "enthalten", "hat", "habend" und Varianten derselben
in der detaillierten Beschreibung oder in den Ansprüchen verwendet
werden, ist mit diesen Begriffen beabsichtigt, dass sie in ähnlicher Weise
einschließend
sind, wie der Begriff "enthaltend" und dessen Varianten.
