-
Technischer Bereich
-
Die
vorliegende Erfindung bezieht sich auf Betriebssystemfunktionen
und die Hardware-Implementierung
oder Beschleunigung derartiger Funktionen.
-
Hintergrund des Standes der
Technik
-
Betriebssysteme
in Computern befähigen die
Computer, mit externen Quellen zu kommunizieren. Das Betriebssystem
behandelt typischerweise die direkte Steuerung von Gegenständen, welche zum
Computergebrauch gehören,
wobei ein Keyboard, ein Display bzw. eine Anzeigeeinrichtung, das Disk-
bzw. Scheibenspeichern, Netzwerkeinrichtungen, Drucker, Modems,
etc. beinhaltet sind. Das Betriebssystem in einem Computer ist typischerweise so
gestaltet, dass die Zentraleinheit (CPU) veranlasst wird, Aufgaben
durchzuführen,
wobei das Steuern lokaler und Netzwerk-File-Systeme, eines Speichers, peripherer
Einrichtungstreiber und von Prozessen beinhaltet ist, welche Anwendungsprozesse
beinhalten. Das Platzieren all dieser Verantwortlichkeit für alle diese
Funktionen auf der CPU bringt merkliche Verarbeitungsbelastungen
für diese
mit sich, speziell wenn das Betriebssystem sehr kompliziert ist,
wie z. B. im Falle von Windows NT (erhältlich von Microsoft Corporation,
Redmond, Washington), Unix (erhältlich von
vielen Quellen, wobei SCO-Software, Santa Cruz, Kalifornien, und
in einer Version, welche "Linux" genannt wird, von
Red Hat Software, Cambridge, Massachusetts) und NetWare (erhältlich von Novell,
Provo, Utah). Je mehr Belastung auf der CPU platziert wird, um Prozesse
laufen zu lassen, andere als diejenigen, welche zu Anwendungen gehören, umso
weniger CPU-Zeit ist verfügbar,
um Anwendungen laufen zu lassen, mit dem Ergebnis, dass die Leistungsfähigkeit
von Anwendungen herabgesetzt werden kann. Zusätzlich unterliegt die Leistung
von Geräten
extern zur CPU Begrenzungen, welche durch die CPU eingebracht werden,
wenn das Betriebssystem die Verantwortlichkeit zum Steuern dieser
Geräte
auf der CPU platziert. Außerdem
wird die Zuverlässigkeit
des gesamten Software-Hardware-Systems, wobei die CPU beinhaltet
ist, welche das Betriebssystem laufen lässt, in Verbindung mit den
Geräten,
neben anderen Dingen, von dem Betriebssystem abhängen. Entsprechend der einhergehenden
Komplexität
des Betriebssystems können unvorhergesehene
Zustände
auftreten, welche die Stabilität
des gesamten Software-Hardware-Systems untergraben.
-
Im
US-Patent 5,355,453 , ausgestellt
für Row et
al., wird ein Netzwerk-File-Server veröffentlicht, welcher viele Netzwerksteuer-Leiterplatten,
eine oder mehrere File-Steuer-Leiterplatinen, eine oder mehrere
Speicherprozessor-Leiterplatinen und einen oder mehrere Host-Prozessoren beinhaltet.
Jede der Leiterplatinen beinhaltet einen Mikroprozessor zum Ausführen von
Aufgaben unter der Steuerung eines Software-Programms. Die Netzwerksteuerungs-Leiterplatten, File-Steuerungs-Leiterplatten,
Speicherprozessor-Leiterplatten und Host-Prozessoren sind alle über einen
gemeinsam genutzten VME-Bus verbunden.
-
In ähnlicher
Weise beschreiben Jovanov et al. ("Hardware implementation of some DMBS
functions using SPR",
System Sciences, 1992, S. 328–337)
einen dedizierten Sortierprozessor, welcher über einen Systembus an einer
CPU angebracht ist, welche die Datenbanksteuerungs-Systemsoftware laufen
lässt.
Der Sortierprozessor dient dazu, einige der am häufigsten benutzten Funktionen
eines vorhandenen Datenbanksteuerungssystems zu beschleunigen.
-
Corominas
et al. ("A VLSI
Implementation of a SMDS Attachment Unit over an ICI interface", Melecon '96, 13. Mai 1996,
S. 373–376)
beschreiben ein Metropolitan-Area-Network- bzw. Stadtnetz-("MAN"-)Protokollsteuerglied
(welches eine integrierte Schaltung beinhaltet), welches in einer MAN-Netz-Adaptiereinheit
platziert ist, welche die Schnittstellen mit einem Vermittlungs-Vielfach-Megabit-Datendienstnetz über einen
VME-Bus bildet.
-
Als
Referenz kann auch die folgende aufgeführt werden: Ponomarev, D. V.,
und Ghose, K., "A comparative
study of some network subsystems organizations", High Performance Computing, 1998, 436–443;
US-A-5,802,288 ,
welche sich auf die integrierte Kommunikation für Computer in Pipeline-Anordnung
bezieht; und Vuillemin, J. E., et al., "Programmable active memories: Reconfigurable
systems come of age",
IEEE Transactions an VLSI Systems, 4, 56–69, 1996.
-
Zusammenfassung der Erfindung
-
Entsprechend
der Erfindung wird eine Vorrichtung zum Behandeln von Dienstanforderungen über ein
Netzwerk bzw. Netz geliefert, wie es im Weiteren in Anspruch 1 definiert
ist. Detaillierte Ausführungsformen
der Erfindung sind in den angehängten Ansprüchen definiert.
-
Kurze Beschreibung der Zeichnungen
-
Die
vorausgegangenen Merkmale der Erfindung werden schließlich besser
mit Bezug auf die folgende detaillierte Beschreibung verstanden,
welche mit Bezug auf die beigefügten
Zeichnungen gegeben wird, in welchen:
-
1 eine
schematische Darstellung einer Ausführungsform der vorliegenden
Erfindung ist, welche aufgebaut ist, um Netzwerkdienste zu liefern,
wie z. B. als ein File-Server oder als ein Web-Server;
-
2 ein
Blockschaltbild der Ausführungsform
ist, welche in 1 dargestellt wird;
-
3 ein
Blockschaltbild der Ausführungsform
ist, welche als ein File-Server ausgeführt ist;
-
4 ein
Blockdiagramm der Ausführungsform
ist, welche als ein Web-Server ausgeführt ist;
-
5 das
Netzwerkteilsystem der Ausführungsformen
der 2–4 ist;
-
6 ein
Blockschaltbild des Netzteilsystems der 5 ist;
-
7 ein
Blockschaltbild des Empfangsmoduls des Netzteil- bzw. -subsystems
der 6 ist;
-
8 ein
Blockschaltbild des Sendemoduls des Netzwerksubsystems der 6 ist;
-
9 ein
Blockschaltbild ist, welches das Gebrauchen des Netzwerksubsystems
der 5 als ein Netzwerkschnittstellen-Adaptierglied
für den
Gebrauch mit einem Netzknoten, wie z. B. einer Workstation bzw.
Arbeitsstation oder einem Server, darstellt;
-
10 ein
Blockschaltbild einer Hardware-implantierten Kombination des SMB-Service-Moduls 33 und
des File-System-Moduls 34 der 3 für den Gebrauch
in einer Ausführungsform
ist, wie sie beispielsweise in 3 dargestellt
ist.
-
11 ein
Blockschaltbild einer durch Hardware beschleunigten Kombination
des SMB-Dienstmoduls 33 und
des File-System-Moduls 34 der 3 für den Gebrauch
in einer Ausführungsform
ist, wie sie beispielsweise in 3 dargestellt
ist;
-
12A ein Blockschaltbild eines Hardware-implementierten
Dienstmoduls, wie beispielsweise der Gegenstand 33 oder 43 jeweils
in 3 oder 4 ist;
-
12B ein Blockschaltbild eines Hardware-implementierten
File-Moduls, wie z. B. der Gegenstand 34 oder 44 jeweils
in 3 oder 4 ist;
-
12C ein detailliertes Blockschaltbild des Hardware-implementierten
Dienstsubsystems der 10 ist, welches einen kombinierten
Dienstmodul und einen File-Modul liefert;
-
13 ein
detailliertes Blockschaltbild des Hardware-beschleunigten Dienstsubsytems
der 11 ist;
-
14 ein
Ablaufdiagramm ist, welches eine typische Vorgehensweise entsprechend
dem Stand der Technik darstellt, welche in Software implementiert
ist, um viele Dienstanforderungen als viele Threads bzw. Pfade zu
behandeln;
-
15 ein
Ablaufdiagramm ist, welches das Behandeln von vielen Dienstanforderungen
zeigt, für den
Gebrauch in Verbindung mit dem Dienstsubsystem der 2 und
beispielsweise den Ausführungsformen
der 12 und 13;
-
16 ein
Blockschaltbild ist, welches das Gebrauchen eines File-System-Moduls,
wie beispielsweise in 3 dargestellt, in Verbindung
mit einem Computersystem darstellt, welches eine File-Speicherung
besitzt;
-
17A ein Blockschaltbild des Datenflusses in dem
Speichermodul der 3 ist;
-
17B ein Blockschaltbild eines Steuerflusses in
dem Speichermodul der 3 ist;
-
18 ein
Blockschaltbild ist, welches das Gebrauchen eines Speichermoduls,
wie beispielsweise in 3 dargestellt, in Verbindung
mit einem Computersystem darstellt, welches eine File-Speicherung
besitzt; und
-
19 ein
Blockschaltbild ist, welches die Skalierbarkeit von Ausführungsformen
der vorliegenden Erfindung darstellt, und speziell einer Ausführungsform,
bei welcher eine Vielzahl von Netzwerksubsystemen und Dienstsubsystemen
angewendet werden, wobei Expansionsschalter für die Kommunikation zwischen
Anschlüssen
aufeinanderfolgender Subsyteme und/oder Module benutzt werden.
-
Detaillierte Beschreibung
spezieller Ausführungsformen
-
Zum
Zwecke der vorliegenden Beschreibung und der angehängten Ansprüche sollen
die folgenden Terme die angezeigten Bedeutungen besitzen, wenn dies
nicht in anderer Weise vom Kontext her erforderlich ist:
Ein "Hardware-implementiertes" Subsystem bedeutet
ein Subsystem, bei welchem größere Subsystem-Funktionen
in dedizierter Hardware durchgeführt werden,
welche außerhalb
der sofortigen Steuerung eines Software-Programms arbeitet. Man
beachte, dass ein derartiges Subsystem mit einem Prozessor zusammenarbeiten
kann, welcher unter einer Software-Steuerung läuft, jedoch das Subsystem selbst wird
nicht sofort durch Software gesteuert. "Haupt-"Funktionen sind derartige, welche am
häufigsten
benutzt werden.
-
Ein
durch "Hardware
beschleunigtes" Subsystem
bedeutet eines, bei welchem Haupt-Subsystem-Funktionen unter Nutzung eines
dedizierten Prozessors und dedizierten Speichers und zusätzlich (oder
alternativ) von Hardware für
einen speziellen Zweck ausgeführt
werden; d. h. der dedizierte Prozessor und der Speicher sind getrennt
von jeder zentralen Prozessoreinheit (CPU) und einem Speicher, welcher
zu der CPU gehört.
-
Als "TCP/IP" sind neben anderen
Plätzen diejenigen
Protokolle auf der Web-Site der Internet Engineering Task Force
bzw. Internet-Ingenieur-Arbeitsgruppe unter www.ietf.org definiert,
welche hier als Referenz aufgeführt
wird. "IP" ist das Internet-Protokoll,
welches an der gleichen Stelle definiert ist.
-
Ein "File" ist eine logische
Zuordnung von Daten.
-
Ein
Protokoll-"Header" bzw. -"Nachrichtenkopf" ist eine Information
in einem Format, welches durch das Protokoll zum Übertragen
von Daten spezifiziert ist, welche zum Benutzer des Protokolls gehören.
-
Ein "SCSI-bezogenes" Protokoll beinhaltet ein
SCSL-, SCSI-2-, SCSI-3-, Wide-SCSI-, Fast-SCSI-, Fast-Wide-SCSI-, Ultra-SCSI-,
Ultra2-SCSI-, Wide-Ultra2-SCSI- oder jegliches ähnliche oder Nachfolgeprotokoll.
SCSI bezieht sich auf "Small
Computer System Interface bzw. Kleine Computersystem-Schnittstelle", welche ein Standard
für eine
parallele Verbindung von Computerperipherie entsprechend dem American
National Standards Institute bzw. Amerikanischen Nationalstandard-Institut
(ANSI) ist, welche eine Web-URL-Adresse unter www.ansi.org besitzt.
-
In
Bezug auf "Schichten 3 und 4" bedeuten die Schichten 3 und 4 in
dem Open System Interconnection bzw. Offenen Systemverbindungs-("OSI"-)Sieben-Schicht-Modell,
welches ein ISO-Standard ist. Die ISO (Internationale Organisation
zur Standardisierung) besitzt eine Web-URL-Adresse unter www.iso.ch.
-
1 ist
eine schematische Darstellung einer Ausführungsform der vorliegenden
Erfindung, welche so konfiguriert ist, dass sie Dienstanforderungen über ein
Netz behandelt. Demnach beinhaltet diese Ausführungsform Konfigurationen,
bei welchen ein File-Server oder ein Web-Server vorgesehen ist. Die
Ausführungsform 11 der
vorliegenden Erfindung ist an das Netz 10 über die
Netzschnittstelle 13 gekoppelt. Das Netz 10 kann
beispielsweise Kommunikationsverbindungen einer Vielzahl von Arbeitsstationen
beinhalten. Die Ausführungsform 11 ist
hier auch mit einer Vielzahl von Speichereinrichtungen 12 über eine
Speicherzwischenverbindung 14 gekoppelt. Die Ausführungsform 11 kann
Hardware-implementiert oder Hardware-beschleunigt sein (oder eine
Kombination aus Hardware-Implementierung und Hardware-Beschleunigung
benutzen).
-
2 ist
ein Blockschaltbild der Ausführungsform,
welche in 1 dargestellt ist. Das Netzsubsystem 21 empfängt und
sendet Netzdienstanforderungen und Rückantworten. Das Netz subsystem 21 ist
an das Dienstsubsystem 22 gekoppelt, welches den Netzdienstanforderungen
genügt.
Das Netzsubsystem 21, das Dienstsubsystem 22 oder
beide Subsysteme können
entweder Hardware-implementiert oder Hardware-beschleunigt sein.
-
3 ist
ein Blockschaltbild der Ausführungsform
von 1, spezieller ausgedrückt als ein File-Server konfiguriert.
Das Netzsubsystem 31 empfängt und sendet Netzdienstanforderungen
und -rückantworten.
Das Netzsubsystem 31 ist an das Dienstsubsystem 32 gekoppelt.
Das Dienstsubsystem beinhaltet drei Module: das Dienstmodul 33,
das File-System-Modul 34 und das Speichermodul 35. Das
Dienstmodul 33 analysiert die Netzdienstanforderungen,
welche zu dem Dienstsubsystem 32 geführt wurden und gibt, wenn angemessen,
eine entsprechende Speicherzugriffsanforderung aus. Die Netzdienstanforderung
kann in einer Vielzahl von Protokollen, wie z. B. als CIFS, SMB,
NFS oder FCP versendet werden. Das Dienstmodul 33 ist an
das File-System-Modul 34 gekoppelt. Falls die Netzdienstanforderung
eine Speicherzugriffsanforderung beinhaltet, wandelt das File-System-Modul 34 die Anforderungen
auf Zugriff zum Speicher durch Wandeln der Anforderung in ein Format
um, welches folgerichtig zu dem File-Speicher-Protokoll (z. B. HTFS, NTFS,
FAT, FAT16 oder FAT32) ist, welches von dem Speichermedium benutzt
wird. Das Speichermodul 35 wandelt das Ausgangssignal des
File-System-Moduls 34 in ein Format (wie z. B. SCSI) folgerichtig
zu den Busanforderungen für
direktes Zugreifen auf das Speichermedium um, an welches das Dienstsubsystem 32 angeschlossen
sein kann.
-
4 ist ähnlich zu 3 und
ist ein Blockschaltbild der Ausführungsform
der 1, konfiguriert als ein Web-Server. Das Netzsubsystem 41 empfängt und
sendet Netzdienstanforderungen und Rückantworten. Das Netzsubsystem 41 ist
an das Dienstsubsystem 42 gekoppelt. Das Dienstsubsystem
beinhaltet drei Module: das Service-Modul 43, das File-System-Modul 44 und
das Speichermodul 45. Das Dienstmodul 43 analysiert
die Netzdienstanforderungen, welche zu dem Dienstsubsystem 32 geführt wurden,
und gibt, wenn passend, eine entsprechende Speicherzugriffsanforderung
aus. Hier sind die Netzdienstanforderungen typischerweise im HTTP-Protokoll.
Das Dienstprotokoll 43 ist an das File-System-Modul 44 gekoppelt,
welches an das Speichermodul 45 gekoppelt ist; das File-System-Modul 44 und
das Speichermodul 45 arbeiten in einer Weise ähnlich zu
den entsprechenden Modulen 34 und 35, welche oben
in Verbindung mit 3 beschrieben wurden.
-
5 ist
das Netzsubsystem und das Dienstsubsystem der Ausführungsformen
der 2–4.
Das Netzsubsystem 51 empfängt verkapselte Daten von der
Netzempfangsschnittstelle 54 und entkapselt die Daten entsprechend
dem TCP/IP oder anderen Protokollbussen 53. Das Netzsubsystem 51 ist
auch an den peripheren Komponenten-Interconnect- bzw. Zwischenverbindungs-("PCI"-)Bus gekoppelt,
um einen lokalen Prozessor (welcher auch an den PCI-Bus gekoppelt
ist) zu liefern, um auf Daten über
das Netzwerk zuzugreifen. Das Netzsubsystem 51 sendet auch
die Daten zu dem Dienstsubsystem 52, und die Daten, welche zu
senden sind, können
von der Netzempfangsschnittstelle 54 oder dem lokalen Prozessor über den PCI-Bus 53 kommen.
Das Dienstsubsystem 52 arbeitet umgekehrt in einer Weise, ähnlich zu
den Dienstsubsystemen 22, 32 und 42 der
jeweiligen 2, 3 und 4.
-
6 ist
ein detailliertes Blockschaltbild des Netzsubsystems 51 der 5.
Das Netzsubsystem der 6 beinhaltet ein Empfangsmodul 614 (welches
einen Empfänger 601,
einen Empfangspufferspeicher 603 und einen Empfangssteuerspeicher 604 beinhaltet)
und ein Sendemodul 613 (welches einen Sender 602,
einen Sendepufferspeicher 605 und einen Sendesteuerspeicher 606 beinhaltet).
Der Prozessor 611 wird sowohl von dem Empfangsmodul 614 als
auch dem Sendemodul 613 benutzt. Der Empfänger 601 empfängt und
interpretiert die verkapselten Daten von der Netzempfangsschnittstelle 607.
Der Empfänger 601 entkapselt
die Daten, wobei die Steuerinformation benutzt wird, welche in dem Empfangssteuermodul 604 und
dem Sendesteuerspeicher 606 enthalten ist, und speichert
die entkapselten Daten in dem Empfangspufferspeicher 603, von
wo aus sie entweder durch den Prozessor 611 über den
PCI-Bus 613 wiedergewonnen werden oder an die Schnellpfad-Empfangsschnittstelle 606 ausgegeben
werden. Der Speicher 612 wird von dem Prozessor 611 zum
Speichern der Daten und Anweisungen benutzt.
-
Der
Sender 602 nimmt die Sendeanforderungen von der Schnellpfad-Sendeschnittstelle 610 oder
von dem Prozessor 611 über
den PCI-Bus 613 an. Der Sender 602 speichert die
Daten in dem Sendepufferspeicher 605. Der Sender 602 verkapselt
die Sendedaten, wobei die Steuerinformation benutzt wird, welche
in dem Sendesteuerspeicher 606 enthalten ist, und sendet
die verkapselten Daten über das
Netz über
die Netzsendeschnittstelle 609.
-
7 ist
ein Blockschaltbild des Empfangsmoduls 614 des Netzsubsystems
der 6. Pakete werden von der Empfangsmaschine 701 von
der Netzempfangsschnittstelle 607 empfangen.
-
Die
Empfangsmaschine 701 analysiert die Pakete und bestimmt,
ob das Paket einen Fehler beinhaltet, ein TCP/IP-Paket ist oder
kein TCP/IP-Paket ist. Für
ein Paket wird festgelegt, ob es ein TCP/IP-Paket ist oder nicht,
indem die Netzwerkprotokoll-Nachrichtenköpfe untersucht werden, welche in
dem Paket enthalten sind. Falls das Paket einen Fehler beinhaltet,
dann wird es fallen gelassen bzw. verworfen.
-
Falls
das Paket kein TCP/IP-Paket ist, dann wird das Paket in dem Empfangspufferspeicher 603 über den
Empfangspufferspeicherzuteiler 709 gespeichert. Eine Anzeige
dafür,
dass ein Paket empfangen wurde, wird in die Prozessor-Ereignis-Warteschlange 702 geschrieben.
Der Prozessor 713 kann dann das Paket von dem Empfangspufferspeicher 603 rückgewinnen,
wobei der PCI-Bus 704 und der Empfangs-PCI-Schnittstellenblock 703 benutzt
werden.
-
Falls
das Paket ein TCP/IP-Paket ist, dann benutzt die Empfangsmaschine 701 eine
Hash-Tabelle, welche
in dem Empfangssteuerspeicher 604 enthalten ist, um zu
versuchen, die Netzadressen und Anschlussnummern, welche innerhalb
der Protokollnachrichtenköpfe
in dem Paket enthalten sind, in einer Nummer aufzulösen, welche
die Verbindung einzigartig identifiziert, zu welcher dieses Paket
gehört,
d. h. die Verbindungsidentifikation. Falls dies eine neue Verbindungsidentifikation
ist, wird das Paket in dem Empfangspufferspeicher 603 über den Empfangspufferspeicher-Zuteiler 708 gespeichert. Eine
Anzeige dafür,
dass ein Paket empfangen wurde, wird in die Prozessor-Ereignis-Warteschlange 702 geschrieben.
Der Prozessor 713 kann dann das Paket aus dem Empfangspufferspeicher 603 wiedergewinnen,
wobei der PCI-Bus 704 und der PCI-Schnittstellenblock 703 benutzt
werden. Der Prozessor kann dann eine neue Verbindung, falls erforderlich,
erstellen, wie in dem TCP/IP-Protokoll spezifiziert, oder er kann
eine andere geeignete Aktion ergreifen.
-
Falls
die Verbindungsidentifikation bereits besteht, dann benutzt die
Empfangsmaschine 701 diese Verbindungsidentifikation als
einen Index in einer Tabelle von Daten, welche Informationen über den
Zustand jeder Verbindung enthält.
Diese Informationen werden als "TCP-Steuerblock" ("TCB") bezeichnet. Der
TCB für
jede Verbindung wird in dem Sendesteuerspeicher 606 gespeichert.
Die Empfangsmaschine 701 greift auf den TCB für diese
Verbindung über
die Empfänger-TCB-Zugriffsschnittstelle 710 zu.
Sie bearbeitet dann dieses Paket entsprechend dem TCP/IP-Protokoll
und fügt
die sich ergebenden Bytes an den empfangenen Byte-Strom für diese
Verbindung in dem Empfangspufferspeicher 603 hinzu. Falls
die Daten auf dieser Verbindung für den Prozessor 713 bestimmt
sind, dann wird eine Anzeige, dass einige Bytes empfangen wurden,
in die Prozessor-Ereignis-Warteschlange 702 geschrieben. Der
Prozessor kann dann die Bytes von dem Empfangspufferspeicher 603 wiedergewinnen,
wobei der PCI-Bus 704 und der Empfangsschnittstellenblock 703 benutzt
werden. Falls die Daten auf dieser Verbindung für die schnelle Pfadschnittstelle 608 bestimmt
sind, wird eine Anzeige, dass einige Bytes empfangen wurden, in
die Schnelle-Pfad-Ereignis-Warteschlange 705 geschrieben.
Die Empfangs-DMA-Maschine 706 wird dann die Bytes von dem
Empfangspufferspeicher 603 rückgewinnen und sie an die Schnelle-Pfad-Schnittstelle 608 ausgeben.
-
Einige
Pakete, welche durch die Empfangsmaschine 701 empfangen
werden, können
Fragmente von IP-Paketen sein. Falls dies der Fall ist, dann werden
die Fragmente als Erstes in dem Empfangspufferspeicher 603 wiederangeordnet.
Wenn ein vollständiges
IP-Paket wiederangeordnet wurde, dann wird das normale Paketverarbeiten
angewendet, wie oben beschrieben.
-
Entsprechend
dem TCP-Protokoll kann eine Verbindung in einer Anzahl von unterschiedlichen Zuständen existieren,
wobei SYN_SENT, SYN_RECEIVED und ESTABLISHED bzw. SYN_GESENDET,
SYN_EMPFANGEN und ERSTELLT beinhaltet sind. Wenn ein Netzknoten
eine neue Verbindung des Netzsubsystems zu erstellen wünscht, sendet
er zuerst ein TCP/IP-Paket mit der gesetzten SYN-Kennung. Dieses
Paket wird durch den Prozessor 713 wiedergewonnen, da es
eine neue Verbindungsidentifikation besitzen wird. Der Prozessor 713 wird
dann die gesamte erforderliche Initialisierung durchführen, wobei
das Einstellen des Verbindungszustands in der TCP für diese
Verbindung auf SYN_RECEIVED beinhaltet ist. Der Übergang von SYN_RECEIVED auf
ESTABLISHED wird durch die Empfangsmaschine 701 entsprechend dem
TCP/IP-Protokoll durchgeführt.
Wenn der Prozessor 713 umschaltet, um eine Verbindung zu
einem Netzwerkknoten über
das Netzsubsystem zu erstellen, führt er zuerst die gesamte erforderliche
Initialisierung durch, wobei das Einstellen des Verbindungszustandes
in der TCP für
diese Verbindung auf SYN_SENT beinhaltet ist. Er sendet dann ein TCP/IP-Paket
mit der eingestellten SYN-Kennung. Der Übergang von SYN_SENT auf ESTABLISHED wird
durch die Empfangsmaschine 701 entsprechend dem TCP/IP-Protokoll
durchgeführt.
-
Wenn
ein Paket empfangen wird, welches eine SYN-Kennung oder eine FIN-Kennung
oder eine RST-Kennung besitzt, welche in dem Protokollnachrichtenkopf
eingestellt ist, und wenn diese eine Aktion durch den Prozessor 713 erfordert,
dann wird die Empfangsmaschine 701 den Prozessor von diesem
Ereignis über
das Schreiben eines Eintrags in die Prozessor-Ereignis-Warteschlange 702 in
Kenntnis setzen. Der Prozessor 713 kann dann die geeignete
Aktion, wie sie durch das TCP/IP-Protokoll erforderlich ist, ergreifen.
-
Als
ein Ergebnis des Anwendens des TCP/IP-Protokolls an dem empfangenen
Paket ist es möglich,
dass eines oder mehrere Pakete nun auf dieser Verbindung übertragen
werden sollen. Beispielsweise kann eine Zustimmung zu den empfangenen
Daten, welche zu senden sind, notwendig sein, oder das empfangene
Paket kann eine erhöhte bzw.
zugenommene Fenstergröße anzeigen,
so dass damit mehr Daten gestattet wird, auf dieser Verbindung übertragen
zu werden, falls derartige Daten für die Übertragung verfügbar sind.
Die Empfangsmaschine 701 erreicht dies durch entsprechendes
Modifizieren der TCB und fordert dann einen Sendeversuch an, indem
die Verbindungsidentifikation in die Sendewarteschlange 802 in 8 über die
Anforderungsschnittstelle 711 der Empfangssende-Warteschlange
geschrieben wird.
-
Die
empfangenen Daten werden in diskreten Einheiten (Puffer) innerhalb
des Empfangspufferspeichers 603 gespeichert. Sobald alle
Daten innerhalb eines Puffers entweder durch den Prozessor 713 wiedergewonnen
wurden oder an die Schnelle-Pfad-Schnittstelle 608 ausgegeben
wurden, kann der Puffer entleert werden, d. h. er kann dann wiederbenutzt
werden, um neue Daten zu speichern. Ein ähnliches System arbeitet für den Sendepufferspeicher 605,
jedoch im Sendefall kann der Puffer nur entleert werden, wenn alle
Daten in ihm vollständig durch
den Netzknoten unter Nutzung des TCP/IP-Protokolls bestätigt wurden,
welcher die gesendeten Daten empfängt. Wenn der Protokollnachrichtenkopf
des Pakets anzeigt, dass die gesendeten Daten bestätigt wurden,
dann zeigt die Empfangsmaschine 701 dies dem freien Sendepufferblock 805 in 8 über die
empfangsfreie Sendepufferanfrage-Schnittstelle 712 an.
-
Zusätzlich ist
es für
die Empfangsmaschine 701 möglich, das obere Schichtprotokoll
("ULP") zu bearbeiten,
welches oben auf der TCP/IP läuft,
als auch die TCP/IP selbst. In diesem Fall werden die Warteschlangeneinträge in die
Prozessor-Ereignis-Warteschlange 702 und die Schnelle-Pfad-Ereignis-Warteschlange 705 nur
geschrieben, wenn eine vollständige
ULP-Protokoll-Dateneinheit
("PDU") empfangen wurde.
Nur vollständige
ULP-PDUs werden durch den Prozessor 713 empfangen und an
die Schnelle-Pfad-Schnittstelle 608 ausgegeben. Ein Beispiel
eines ULP ist NetBIOS. Das Freigeben der ULP-Verarbeitung kann auf
einer Durchverbindungsbasis geschehen; d. h., einige Verbindungen
können eine
freigegebene ULP-Verarbeitung besitzen und andere nicht.
-
8 ist
ein Blockschaltbild des Sendemoduls 613 des Netzsubsystems
der 6. Daten, welche über das Netz unter Benutzen
von TCP/IP zu senden sind, werden an die Sende-DMA-Maschine 807 eingegeben.
Diese Daten werden entweder von der Sende-Schnelle-Pfad-Schnittstelle 610 oder
von dem Prozessor 713 über
den PCI-Bus 704 und die Sende-PCI-Schnittstelle 808 eingegeben.
In jedem Fall sollte die Verbindungsidentifikation, welche bestimmt,
welche TCP/IP-Verbindung benutzt werden sollte, auch eingegeben
werden, um die Daten zu senden. Wie oben erwähnt, besitzt jede Verbindung eine
zugehörige
TCP, welche Information über
den Zustand der Verbindung enthält.
-
Die
Sende-DMA-Maschine speichert die Daten in dem Sendepufferspeicher 605,
wobei die eingegebenen Bytes zu dem gespeicherten Byte-Strom für diese
Verbindung eingegeben werden. Am Ende der Eingabe modifiziert sie
die TCP für
die Verbindung entsprechend und schreibt auch die Verbindungsidentifikation
in die Sendewarteschlange 802.
-
Die
Sendewarteschlange 802 nimmt die Sendeanforderungen in
Form der Verbindungsidentifikationen von drei Quellen an: von der
empfangenen Sendewarteschlangen-Anforderungsschnittstelle 711,
den Zeitablauffunktionsblöcken 806 und
der Sende-DMA-Maschine 807.
Wenn die Anforderungen empfangen werden, werden sie in einer Warteschlange
platziert. Wann immer die Warteschlange nicht leer ist, wird eine
Sendeanforderung für
die Verbindungsidentifikation am vorderen Ende der Warteschlange
zu der Sendemaschine 801 geführt. Wenn die Sendemaschine 801 das
Verarbeiten der Sendeanforderung vollendet hat, wird diese Verbindungsidentifikation
von der vordersten Stelle der Warteschlange entfernt, und der Prozess
wird wiederholt.
-
Die
Sendemaschine 801 akzeptiert die Sendeanforderungen von
der Sendwarteschlefe 802. Für jede Anforderung wendet die
Sendemaschine 801 das TCP/IP-Protokoll an der Verbin dung
an und sendet die Pakete wie erfordert. Um dies durchzuführen, greift
sie auf die TCP für
die Verbindung in dem Sendesteuerspeicher 606 über den
Sendesteuerspeicherzuteiler 802 zu und gewinnt den gespeicherten Byte-Strom
für die
Verbindung von dem Sendepufferspeicher 608 über den
Sendepufferspeicherzuteiler 804 wieder.
-
Der
gespeicherte Byte-Strom für
eine Verbindung wird in diskreten Einheiten (Puffern) innerhalb des
Sendepufferspeichers 605 gespeichert. Wie oben erwähnt, kann
jeder Puffer nur entleert werden, wenn die Gesamtheit der Daten
in ihm durch den Netzwerkknoten voll anerkannt wird, wobei das TCP/IP-Protokoll
benutzt wird, welcher das Senden der Daten empfängt. Wenn der Protokoll-Nachrichtenkopf
des Paketes anzeigt, dass die gesendeten Daten bestätigt wurden,
dann zeigt die Empfangsmaschine 701 dies dem freien Sendepufferblock 805 über die
empfangsfreie Sendepuffer-Anforderungsschnittstelle 712 an.
Der freie Sendepufferblock 805 wird dann alle Puffer frei
machen, welche voll bestätigt
wurden, und diese Puffer können
dann wieder benutzt werden, um neue Daten zu speichern.
-
Der
TCP/IP besitzt eine Anzahl von Zeitablauffunktionen, welche bestimmte
Operationen erfordern, welche bei regulären Intervallen durchgeführt werden
müssen,
wenn bestimmte Bedingungen zutreffen. Diese Funktionen sind durch
den Zeitablauffunktionsblock 806 implementiert. Bei regulären Intervallen
greift der Zeitablauffunktionsblock 806 auf die TCPs für jede Verbindung über den
Sendesteuerspeicher-Zuteiler 803 zu. Falls irgendeine Operation für eine spezielle
Verbindung durchgeführt
werden muss, dann wird die TCP für
diese Verbindung entsprechend modifiziert, und die Verbindungsidentifikation
wird in die Sendewarteschlange 802 geschrieben.
-
Zusätzlich ist
es für
die Sende-DMA-Maschine 807 möglich, das obere Schichtprotokoll
zu bearbeiten, welches am oberen Ende der TCP/IP läuft. In diesem
Fall werden nur vollständige
ULP-Protokolldateneinheiten an die Sende-DMA-Maschine 807 eingegeben,
entweder von dem Prozessor 713 oder von der Sende-Schnelle-Pfad-Schnittstelle 610.
Die Sende-DMA-Maschine 807 fügt dann
den ULP-Nachrichtenkopf an der vorderen Seite der PDU an und fügt den "vorher angehängten" ULP-Nachrichtenkopf
und die eingegebenen Bytes an den gespeicherten Byte-Strom für die Verbindung
an. Wie in Verbindung mit 7 oben diskutiert,
ist ein Beispiel eines ULP das NetBIOS. Das Freigeben der ULP-Verarbeitung
kann auf der Grundlage einer Durchverbindung durchgeführt werden;
d. h. einige Verbindungen können
eine ULP-Verarbeitung freigegeben haben, und andere nicht.
-
Falls
der Prozessor 713 wünscht,
ein rohes Paket zu senden, d. h. Daten zu senden, ohne die automatische Übertragung
der Hardware von Daten unter Benutzung des TCP/IP zu benutzen, dann
benutzt er, wenn der Prozessor 713 die Daten zu der Sende-DMA-Maschine 807 eingibt,
eine spezielle Verbindungsidentifikation. Diese spezielle Verbindungsidentifikation
veranlasst die Sendemaschine 801, rohe Pakete zu senden,
exakt wie sie an die Sende-DMA-Maschine 807 durch
den Prozessor 713 eingegeben wurden.
-
9 ist
ein Blockschaltbild, welches das Benutzen des Netzsubsystems der 5 als
ein Netzwerkschnittstellen-Adaptionsglied darstellt, um zusammen
mit einem Netzwerkknoten, wie z. B. einer Arbeitsstation oder einem
Server, benutzt zu werden. In dieser Ausführungsform ist das Netzsubsystem 901 in
eine Adapterkarte 900 integriert, welche in einen Computer
gesteckt ist. Die Adapterkarte 900 ist an das Netz über die
Netzschnittstelle 904 gekoppelt. Die Adapterkarte 900 ist
auch an den Mikroprozessor 910 des Computers über den
PCI-Bus 907 und die PCI-Brücke 912 gekoppelt.
Der PCI-Bus 907 kann auch durch den Computer benutzt werden,
um auf periphere Einrichtungen, wie z. B. ein Videosystem 913,
zuzugreifen. Das Empfangsmodul 902 und das Sendemodul 903 arbeiten
in einer ähnlichen
Weise wie das Empfangsmodul 614 und das Sendemodul 613 der 6.
Abwechselnd oder zusätzlich
kann die Adapterkarte 908 über eine Einzelprotokoll-Schnelle-Empfangs-Pipe
bzw. -Leitung 906 und eine Einzelprotokoll-Schnelle-Sende-Pipe
bzw. -Leitung 908 an ein Service-Modul vergleichbar zu
irgendwelchen Gegenständen 22, 32, 42 oder 52 jeweils
der 2, 3, 4 oder 5 angeschlossen
werden, um einen schnellen Zugriff auf eine Speicheranordnung durch
einen entfernten Knoten auf dem Netzwerk oder durch den Mikroprozessor 910 zu
liefern.
-
10 ist
ein Blockschaltbild einer Hardware-implementierten Kombination des
SMB-Dienstmoduls 33 und
des File-System-Moduls 34 der 3 zum Gebrauchen
in einer Ausführungsform,
wie sie beispielsweise in 3 dargestellt
ist. In der Ausführungsform
der 10 werden SMB-Anforderungen am Eingang 105 zu
dem Dienstempfangsblock 101 empfangen. Schließlich führt das
Verarbeiten durch diese Ausführungsform
zu einer Übertragung
einer entsprechenden SMB-Rückantwort über den
Ausgang 106. Ein Teil dieser Rück antwort beinhaltet einen
Nachrichtenkopf. Um den Ausgangsnachrichtenkopf herzustellen, wird
der Eingangsnachrichtenkopf in dem SMB-Rückantwort-Informationsspeicher 103 gespeichert.
Der Block 101 verarbeitet die SMB-Anforderung und erzeugt
eine Rückantwort.
Abhängig von
der Art der Anforderung kann der Block 101 auf den File-Tabellen-Cache 104 zugreifen
und eine Disk-Zugriffsanforderung ausgeben; anderenfalls wird die
Rückantwort
direkt zu dem Sendeblock 102 weitergeleitet. Der Dienstsendeblock 102 sendet
die Rückantwort,
welche durch den Block 101 erzeugt ist, über den
Ausgang 106. In dem Fall, dass eine Disk-Zugriffsanforderung
durch den Block 101 ausgegeben wurde, gibt dann, aufgrund
des Empfangs einer Disk-Rückantwort über die
Leitung 108, der Sendeblock 102 die geeignete
SMB-Antwort über
die Leitung 106. Sowohl die Empfangs- als auch die Sendemodule 101 und 102 stehen
optional in Kommunikation mit dem Host-System über den PCI-Bus 109. Wenn
eine derartige Kommunikation geliefert wird, wird dem Host-System
gestattet, direkt mit der Ausführungsform
zu kommunizieren, anstatt über
ein Netzwerk, um dem Host-System
schnelle, Hardware-implementierte File-System-Zugriffe zu geben, außerhalb
des Wirkungskreises eines herkömmlichen
Betriebssystems.
-
11 ist
ein Blockschaltbild einer Hardware-beschleunigten Kombination des
SMB-Dienstmoduls 33 und
des File-System-Moduls 34 der 3 zum Verwenden
in einer Ausführungsform,
wie sie beispielsweise in 3 dargestellt
ist. Die Arbeitsweise ist analog zu der oben in Verbindung mit 10 gegebenen,
mit Bezug auf ähnlich
nummerierte Blöcke
und Leitungen 105, 107, 108 und 106. Jedoch
steuert der dedizierte File-System-Prozessor 110 in Zusammenarbeit
mit dem dedizierten Speicher 111, welcher über den
dedizierten Bus 112 arbeitet, die Prozesse der Blöcke 101 und 102.
Zusätzlich
liefern diese Gegenstände
Flexibilität
beim Behandeln derartiger Prozesse, da sie in Software rekonfiguriert
werden können.
-
12A ist ein Blockdiagramm eines Hardware-implementierten
Dienstmoduls, wie z. B. der Gegenstand 33 oder 43 jeweils
in 3 oder 4. Das Dienstmodul 1200 empfängt Netzwerkdienstanforderungen,
erfüllt
derartige Dienstanforderungen und kann Datenspeicher-Zugriffsanforderungen
ausgeben. Das Dienstmodul 1200 beinhaltet einen Empfänger 1201,
welcher an einen Sender 1202 und eine Datenspeicher-Zugriffsschnittstelle 1203 gekoppelt ist,
welche auch an sowohl den Empfänger 1201 als auch
den Sender 1202 gekoppelt ist. Der Empfänger 1201 empfängt und
interpretiert die Netzdienstanforderungen. Beim Empfang einer Dienstanforderung leitet
der Empfänger 1201 entweder
die Anforderung an die Daten speicher-Zugriffsschnittstelle 1203 oder leitet
die Information, welche die Netzdienstanforderung erfüllt, an
den Sender 1202. Falls die Anforderung an die Datenspeicher-Zugriffsschnittstelle 1203 geführt wird,
konstruiert die Datenspeicher-Zugriffsschnittstelle 1203 die
Datenspeicher-Zugriffsanforderungen und gibt sie aus. Die Datenspeicher-Zugriffsschnittstelle 1203 empfängt auch
die Erwiderungen auf die Datenspeicher-Zugriffsanforderungen und extrahiert
Information, welche erforderlich ist, die ursprünglichen Netzdienstanforderungen
zu erfüllen. Die
Information wird dann zu dem Sender 1202 geführt. Der
Sender 1202 verarbeitet die Information, welche zu ihm
von dem Empfänger 1201 oder
der Datenspeicher-Zugriffsschnittstelle 1203 geführt wurde,
und stellt die Netzdienstantworten auf und gibt sie aus.
-
12B ist ein Blockschaltbild eines Hardware-implementierten
File-Moduls, wie Gegenstand 34 oder 44 jeweils
in 3 oder 4. Das File-System-Modul 1210 empfängt Datenspeicher-Zugriffsanforderungen,
erfüllt
derartige Datendienst-Zugriffsanforderungen und kann Ausgabespeichergerät-Zugriffsanforderungen
ausgeben. Das File-System-Modul 1210 beinhaltet einen Empfänger 1211, welcher
an einen Sender 1212 und eine Datenspeichereinrichtungs-Zugriffsschnittstelle 1213 gekoppelt ist,
welche auch sowohl an den Empfänger 1211 als auch
den Sender 1212 gekoppelt ist. Der Empfänger 1211 empfängt und
interpretiert Datenspeicher-Zugriffsanforderungen und leitet die
Anforderung zu der Datenspeichereinrichtungs-Zugriffsschnittstelle 1213 oder
leitet die Information, welche die Datenspeicher-Zugriffsanforderung erfüllt, an
den Sender 1212. Falls die Anforderung zu der Datenspeichereinrichtungs-Zugriffsschnittstelle 1213 geleitet
wird, konstruiert die Datenspeichereinrichtungs-Zugriffsschnittstelle 1213 die
Datenspeichereinrichtungs-Zugriffsanforderungen und gibt sie aus.
Die Datenspeichereinrichtungs-Zugriffsschnittstelle 1213 empfängt auch
die Erwiderungen auf die Datenspeichereinrichtungs-Zugriffsanforderungen
und extrahiert Information, welche erforderlich ist, um die ursprüngliche
Datenspeicher-Zugriffsanforderung zu erfüllen. Die Information wird
dann zu dem Sender 1212 geleitet. Der Sender 1212 bearbeitet
die Information, welche zu ihm von dem Empfänger 1211 oder dem
Datenspeichereinrichtungs-Zugriffsschnittstellenmodul 1213 geleitet
wurde, und konstruiert die Datenspeicher-Zugriffserwiderungen und gibt sie aus.
-
12C ist ein detailliertes Blockdiagramm des Hardware-implementierten
Dienstsubsystems der 10, welches ein kombiniertes
Service-Modul und ein File-Modul liefert. Die gestrichelte Linie 129 in 12C zeigt die Aufteilung zwischen den Funktionen
dieser Implementierung. Zur Linken der Linie 129 ist der
Teil des Service-Moduls; zur Rechten der Linie 129 ist
der Teil des File-System-Moduls. (Es ist jedoch davon auszugehen,
dass der Doppelpfeil oben, welcher die SMB-Empfangssteuermaschine 121 und die
SMB-Sendesteuermaschine 122 verbindet,
geeigneterweise eine Zwei-Weg-Kommunikation zwischen den Maschinen 121 und 122 für jeden
Teil des Service-Moduls und des File-System-Moduls liefert.)
-
In 12C werden SMB-Rahmen von dem Netzsubsystem über die
Netzempfangsschnittstelle 121f empfangen und werden zu
der SMB-Rahmen-Interpretationsmaschine 121b geführt. Hier
wird der Rahmen analysiert und eine Anzahl von Aufgaben durchgeführt. Der
erste Abschnitt des Nachrichtenkopfes wird für die SMB-Rückantwort-Informationssteuerung 123 kopiert,
welche die relevante Information auf einer Durchverbindungsbasis
in dem SMB-Rückantwort-Informationsspeicher 103 speichert.
Der vollständige
Rahmen wird in Puffer in dem Empfangspufferspeicher 121c geschrieben,
und der Empfangssteuerspeicher 121d wird aktualisiert.
Relevante Teile des SMB-Rahmen-Nachrichtenkopfes werden zu der SMB-Empfangssteuermaschine 121 geleitet.
-
Die
SMB-Empfangssteuermaschine 121 der 12C gliedert
die Information von dem Nachrichtenkopf und dort, wo sie passend
ist, fordert sie eine File-Zugriffserlaubnis von der Authentifizierungsmaschine 124.
Für SMB-Rahmen,
wo ein File-Zugriff angefordert wurde, extrahiert die SMB-Empfangssteuermaschine 121 entweder
die File-Pfadinformation oder die File-Identifikation von dem SMB-Rahmen-Nachrichtenkopf
und fordert von der MFT-Steuermaschine 125 den
physikalischen Ort der erforderten File-Daten.
-
Die
MFT-Steuermaschine 125 kann die Anforderungen von der SMB-Empfangssteuermaschine 121 aufreihen,
und in ähnlicher
Weise kann die SMB-Empfangssteuermaschine 121 die
Rückantworten
von der MFT-Steuermaschine 125 aufreihen. Dies gestattet
den beiden Maschinen, asynchron voneinander zu arbeiten, und gestattet
somit, dass eingehende SMB-Rahmen bearbeitet werden, während MFT-Anforderungen
unerledigt sind.
-
Die
MFT-Steuermaschine 125 verarbeitet Anforderungen von der
SMB-Empfangssteuermaschine 121.
Typischerweise für
SMB-OPEN-Befehle wird eine Anforderung einen Disk-Zugriff erfordern, um
die notwendige physikalische File-Ort-Information zu erhalten. Wo
dies notwendig ist, leitet die MFT-Steuermaschine 125 eine
Anforderung zu der komprimierten SCSI-Rahmen-Erzeugungsmaschine 121a,
welche die notwendige komprimierte SCSI-Anforderung erzeugen wird.
Das komprimierte SCSI-Protokoll ("CSP")
bezieht sich auf ein Datenformat, von welchem aus ein SCSI-Befehl
der Art erzeugt werden kann, welche in Verbindung mit 17A und anderen nachfolgenden Figuren beschrieben
wird. Da die komprimierten SCSI-Daten nicht von dem SCSI abgeleitet
werden, sondern vielmehr die Quelle sind, von welcher die SCSI-Daten abgeleitet
werden können,
bezeichnen wir manchmal die komprimierten SCSI-Daten als "Proto-SCSI"-Daten. Die relevante
Proto-SCSI-Rückantwort
wird zurück
zu der MFT-Steuermaschine 125 geleitet, wo sie verarbeitet
wird, der MFT-Cache 104 aktualisiert wird und die physikalische
File-Information zurück
zu der SMB-Empfangssteuermaschine 121 geleitet wird.
-
Typischerweise
wird für
einen SMB-READ- bzw. SMB-Lese- oder -WRITE- bzw. –Schreib-Befehl mit Bezug
auf ein neuerdings zugegriffenes kleines File die File-Information
in dem MFT-Cache 104 vorhanden sein. Dadurch wird kein
Disk-Zugriff erforderlich.
-
Wenn
die SMB-Empfangssteuermaschine 121 die Rückantwort
von einer MFT-Anforderung empfangen hat und ein Disk-Zugriff für File-Daten
erforderlich ist, wie er für
typische READ- oder WRITE-Befehle notwendig ist, werden eine oder
mehrere Proto-SCSI-Anforderungen
zu der Proto-SCSI-Rahmenerzeugungsmaschine 121a geleitet.
-
Die
Proto-SCSI-Rahmenerzeugungsmaschine 121a wird die Proto-SCSI-Nachrichtenköpfe aufbauen
und, wo notwendig, beispielsweise für WRITE-Befehle, die File-Daten-DMA-Maschine 121e programmieren,
um die File-Daten aus dem Empfangspufferspeicher 121c herauszuziehen.
Der Proto-SCSI-Rahmen wird dann zu dem Proto-SCSI-Modul über die
Proto-SCSI-Sendeschnittstelle 121g geleitet. Dort, wo kein
Disk-Zugriff erforderlich ist, wird eine SMB-Rückantwortanforderung direkt
zu der SMB-Sendesteuermaschine 122 geleitet.
-
Die
Proto-SCSI-Rahmen werden von dem Proto-SCSI-Modul empfangen und über die
Proto-SCSI-Empfangsschnittstelle 122f zu
der Proto-SCSI-Rahmeninterpretationsmaschine 122b geleitet.
Hier wird der Rahmen analysiert und eine Anzahl von Aufgaben durchgeführt. Die
MFT-Rückantworten
werden zurück
zu der MFT-Steuermaschine 125 geleitet. Alle anderen Rahmen
werden in Puffer in dem Empfangspufferspeicher 121c geschrieben, und
der Empfangssteuerspeicher 121d wird aktualisiert. Relevante
Teile des Proto-SCSI-Rahmennachrichtenkopfes
werden zu der SMB-Sendesteuermaschine 122 geleitet.
-
Jeder
SMB-Verbindung wurde zuvor eine einzigartige Identifikation zugeordnet.
Alle Proto-SCSI-Rahmen
beinhalten diese Identifikation, und die SMB-Sendesteuermaschine 122 nutzt
diese einzigartige Identifikation, um Zustandsinformation von der SMB-Empfangssteuermaschine 121 anzufordern und
diese zu aktualisieren, wo dies notwendig ist. Wenn alle notwendige
Information für
eine SMB-Rückantwort
von dem Proto-SCSI-Modul empfangen wurde, leitet die SMB-Sendesteuermaschine 122 eine
Anforderung zu der SMB-Rahmenerzeugungsmaschine 122a.
-
Die
SMB-Rahmenerzeugungsmaschine 122a konstruiert den SMB-Rückantwortrahmen
aus Daten, welche in dem SMB-Rückantwort-Informationsspeicher 103 enthalten
sind und von File-Daten, welche in dem SMB-Sendepufferspeicher 122c gespeichert
sind. Sie leitet dann den Rahmen zu der SMB-Sendeschnittstelle 106,
welche umgekehrt diese zu dem Netzsubsystem weiterleitet.
-
13 ist
ein detailliertes Blockdiagramm des Hardware-beschleunigten Dienstsubsystems
der 11. Eingehende SMB-Rahmen von dem IP-Block werden über den
Eingang 105 geliefert und werden über den SMB-Empfang „first
in", „first
out" bzw. als „Erstes
eingehend", als „Erstes
ausgehend" ("FIFO") 317 in
freie Puffer in dem SMB-Empfangspufferspeicher 121c geschrieben.
Der SMB-Empfangspufferspeicher 121c beinhaltet in einer
Ausführungsform
eine Reihe von Empfangspuffern, welche 2 Kb lang sind, und demnach
kann sich ein SMB-Rahmen über
eine Anzahl von Empfangspuffern aufspreizen bzw. aufteilen. Wenn
die Rahmen in den SMB-Empfangspufferspeicher 121c geschrieben
werden, werden die SMB-Empfangspufferbezeichnungen
in dem SMB-Empfangssteuerspeicher 121d aktualisiert.
-
Eine
32-Bit-Verbindungsidentifikation und eine 32-Bit-Rahmen-Byte-Zählung werden
zu dem SMB-Block von dem IP-Block beim Start des Rahmens geleitet.
Diese zwei Felder wer den in die ersten zwei Orte des Empfangspuffers
in dem Empfangspufferspeicher 121c geschrieben.
-
Während der
Rahmen gespeichert wird, wird der SMB-Nachrichtenkopf auch in den
SMB-Rückantwort-Informationsspeicher 103 für das spätere Gebrauchen
durch den SMB-Sendeprozess
geschrieben. Die einzigartige Verbindungsidentifikation, welche
zu dem SMB-Block
durch den IP-Block geleitet wurde, wird als ein Zeiger auf das geeignete
Informationsfeld in dem SMB-Rückantwort-Informationsspeicher 103 benutzt.
Dieser Speicher ist in Blöcken von
16 Worten angeordnet, ein Block für jede einzigartige Verbindungsidentifikation.
Mit einem 128 Mb-SDRAM ausgestattet, lässt dieser 2M-Verbindungen
zu. Gegenwärtig
werden gerade die ersten 32 Bytes des SMB-Rahmens in jedes Informationsfeld geschrieben.
-
Wenn
ein vollständiger
Rahmen in den Empfangspufferspeicher 121c geschrieben wurde,
wird ein SMB-Puffer-Lokalisierer in die SMB-Empfangsereignis-Warteschlange 1314 geschrieben,
und eine Unterbrechung für
den Host-Prozessor 1301 wird erzeugt. Der SMB-Puffer-Lokalisierer
enthält
Information, welche sich auf den SMB-Rahmen bezieht, wobei ein Pufferzeiger
und ein "letztes" Bit beinhaltet sind. Der
Pufferzeiger zeigt auf den Puffer in dem Empfangspufferspeicher 121c,
welcher den Start des SMB-Rahmens enthält. Das "letzte" Bit zeigt an, ob dieser Puffer auch
das Ende des SMB-Rahmens enthält
(d. h. ob der SMB-Rahmen
in seiner Länge
kleiner als 2 Kb ist).
-
Der
Host-Prozessor 1301 kann den SMB-Puffer-Lokalisierer in
der SMB-Empfangsereignis-Warteschlange 1314 lesen,
indem er ein geeignetes SMB-Empfangsereignisregister liest, welches
zu der Ereigniswarteschlange 1314 gehört. Von dem Pufferzeiger, welcher
von dem SMB-Puffer-Lokalisierer gelesen wurde, kann der Host-Prozessor 1301 die Adresse
des ersten Puffers des SMB-Rahmens in dem Empfangspufferspeicher 121c lesen
und kann damit den SMB-Nachrichtenkopf und den ersten Teil des Rahmens
lesen.
-
Falls
der SMB-Rahmen länger
als 2 Kb ist und wenn es notwendig ist, mehr als die ersten 2 Kb des
SMB-Rahmens zu lesen, dann sollte der Empfangspufferdeskriptor bzw.
-beschreiber, welcher zu dem Empfangspuffer gehört, aus dem Empfangssteuerspeicher 121d lesen.
Dieser Empfangspufferdeskriptor wird einen Zeiger auf den nächsten Puffer des
SMB-Rahmens beinhalten. Dieser nächste
Puffer wird in ähnlicher
Weise einen Puffer-Deskriptor besitzen, welcher zu ihm gehört, wenn
nicht der Deskriptor des vorherigen Puffers ein "letztes" Bit beinhaltet, welches anzeigt, dass
der Empfangspuffer auf das beinhaltete Ende des SMB-Rahmens gezeigt hat.
-
Nach
dem Lesen des empfangenen SMB-Rahmens, falls keine der Daten innerhalb
des Rahmens beinhaltet sind, um weiter benutzt zu werden, werden
dann die Puffer der empfangenen Rahmen für das Gebrauchen wieder verfügbar gemacht, indem
die Zeiger diesen zugeschrieben werden, für das Empfangen einer Freipuffer-Warteschlange,
welche in dem Empfangspuffersteuerspeicher 121d enthalten
ist, indem sie einem zugehörigen
empfangsrücksendefreien
Puffer-Register zugeschrieben werden.
-
Um
einen Proto-SCSI-Rahmen zu senden, erhält der Host-Prozessor 1301 zuerst
einen Zeiger auf einen freien SMB-Empfangspuffer, indem er von dem
Empfangsabruf-Freipufferregister liest. Diese Aktion wird einen
Zeiger zu einem freien Puffer aus der freien Pufferwarteschlange
ziehen, welche in dem Empfangssteuerspeicher 121d enthalten
ist. In diesem Puffer kann der Start des Proto-SCSI-Anforderungsrahmens
aufgebaut werden.
-
Um
die Proto-SCSI-Sendeentität
anzufordern, um den Proto-SCSI-Rahmen zu der Proto-SCSI-Entität zu übertragen,
schreibt der Host-Prozessor 1301 einen Puffer-Lokator und
ein Puffer-Versatzpaar zu der Proto-SCSI-Sendeereignis-Warteschlange 1315,
indem diese zu dem Empfangs-Proto-SCSI-Ereignisregister geschrieben
werden, welches zu der Proto-SCSI-Sendeereignis-Warteschlange 1315 gehört.
-
Der
Puffer-Lokator enthält
einen Zeiger auf den Puffer, welcher Daten für den Proto-SCSI-Rahmen enthält. Der
Puffer-Offset bzw. -Versatz enthält einen
Offset gegenüber
dem Start der Daten innerhalb des Puffers und ein Längenfeld.
Der Puffer-Lokator enthält
auch ein letztes Bit, um anzuzeigen, ob ein weiterer/weitere Puffer-Lokator/Puffer-Offset-Paare
zu der Proto-SCSI-Sendeereignis-Warteschlange 1315 beschrieben
werden, welche Zeiger auf mehr Daten für diesen Proto-SCSI-Rahmen
enthalten.
-
Falls
der Proto-SCSI-Rahmen dabei ist, Daten von einem anderen SMB-Empfangspuffer
zu beinhalten, wie es typisch für
einen SMB-WRITE-Befehl sein würde,
so muss dann der Host-Prozessor 1301 einen
anderen/anderes Puffer-Lokator/Puffer-Offset-Paar schreiben, wel cher/welches
diesen SMB-Empfangspuffer für
die Proto-SCSI-Sendeereignis-Warteschlange 1315 beschreibt.
Falls die Daten, welche in den Proto-SCSI-Rahmen einzubeziehen sind,
sich über
mehr als einen SMB-Empfangspuffer spreizen, dann kann die Proto-SCSI-Sendeentität die Pufferzeiger
in dem zugehörigen SMB-Empfangspuffer-Deskriptor
benutzen, welcher in dem Empfangssteuerspeicher 121d platziert
ist, um die Daten miteinander zu verbinden. Falls die Extra-Daten
von einem SMB-Empfangsrahmen sind, dann werden diese Deskriptoren
vorher durch die SMB-Empfangsentität gefüllt sein.
-
Da
die Daten von den SMB-Empfangspuffern für mehr als einen Proto-SCSI-Rahmen
benutzt werden können,
ist dann das Freimachen der SMB-Empfangspuffer, nachdem sie benutzt
wurden, kein einfacher Prozess. Die SMB-Empfangspuffer, welche Abschnitte
eines empfangenen SMB-Rahmens enthalten, welche nicht an dem Proto-SCSCI-Senden
teilgenommen haben, können
durch Zurückschreiben
zu der Warteschlange mit freien Puffer, welche in dem Empfangssteuerspeicher
enthalten ist, über
das zugehörige
empfangsrücksendefreie Pufferregister
frei gemacht werden. Die SMB-Empfangspuffer, welche Daten enthalten,
welche in den Proto-SCSI-Rahmen zu beinhalten sind, können nicht
auf die gleiche Weise frei gemacht werden, da sie nicht frei gemacht
werden können,
bis die Daten innerhalb derselben übertragen wurden.
-
So
werden, nachdem der Puffer-Lokator/die Puffer-Offset-Paare in die
verschiedenen Proto-SCSI-Rahmen,
welche die SMB-Daten enthalten werden, in die Proto-SCSI-Sendeereignis-Warteschlange 1315 geschrieben
wurden, die Zeiger auf die ursprünglichen
SMB-Empfangspuffer
werden auch in die Proto-SCSI-Sende-ereignis-Warteschlange 1315 geschrieben.
Diese Zeiger sind gekennzeichnet, um anzuzeigen, dass sie in die
freie Pufferwarteschlange zurück
frei zu machen sind, welche in dem Empfangssteuerspeicher enthalten
ist. Da die Proto-SCSI-Sendeereignis-Warteschlange 1315 in
Reihenfolge behandelt wird, werden dann die SMB-Empfangspuffer nur
frei gemacht, nachdem irgendwelche Daten in ihnen gesendet wurden.
-
Eingehende
Proto-SCSI-Rahmen von dem IP-Block werden über die Proto-SCSI-Empfangs-FIFO 1327 in
freie Puffer in dem SMB-Sendepufferspeicher 122c geschrieben.
Die SMB-Sendepuffer
sind 2 Kb lang, und demnach kann sich ein Proto-SCSI-Rahmen über eine
Anzahl von Sendepuffern aufteilen. Da die Rahmen in den SMB-Sendepufferspeicher 122c ge schrieben
werden, werden die SMB-Sendepuffer-Deskriptoren in dem SMB-Sendesteuerspeicher 122d aktualisiert.
-
Wenn
ein vollständiger
Rahmen in den SMB-Sendepufferspeicher 122c geschrieben
wurde, wird ein SMB-Puffer-Lokalisierer in die Proto-SCSI-Empfangsereignis-Warteschlange 1324 geschrieben,
und eine Unterbrechung für
den Host-Prozessor 1301 wird erzeugt. Der SMB-Puffer-Lokalisierer
enthält
Information, welche zu dem Proto-SCSI-Rahmen gehört, wobei ein Puffer-Pointer
und ein "letztes" Bit beinhaltet sind.
Der Pufferzeiger zeigt auf den Puffer in dem Sendepufferspeicher 121c,
welcher den Start des Proto-SCSI-Rahmens enthält. Das "letzte" Bit zeigt an, ob dieser Puffer auch
das Ende des Proto-SCSI-Rahmens enthält (d. h. ob der Rahmen kleiner
als 2 Kb in der Länge
ist).
-
Der
Host-Prozessor 1301 kann den Puffer-Lokalisierer in der
Proto-SCSI-Empfangsereignis-Warteschlange 1324 durch
Lesen eines geeigneten Proto-SCSI-Empfangsereignis-Registers, welches
zu der Ereigniswarteschlange 1324 gehört, lesen. Von dem Pufferzeiger,
welcher von dem Puffer-Lokalisierer gelesen wurde, kann der Host-Prozessor 1301 die
Adresse des ersten Puffers des Proto-SCSI-Rahmens in dem Sendepufferspeicher 122c bestimmen
und kann demnach den Nachrichtenkopf und den ersten Teil des Rahmens
lesen.
-
Falls
der Proto-SCSI-Rahmen länger
als 2 Kb ist und es notwendig ist, mehr als die ersten 2 Kb des
Rahmens zu lesen, dann sollte der Sende-Deskriptor, welcher zu dem
Sendepuffer gehört,
von dem Empfangssteuerspeicher 121d gelesen werden. Der Deskriptor
wird einen Zeiger auf den nächsten
Puffer des Proto-SCSI-Rahmens enthalten. Dieser nächste Puffer
wird ähnlicherweise
einen Sende-Deskriptor besitzen, welcher dazu gehört, es sei
denn, der Deskriptor des vorhergehenden Puffers enthielt ein "letztes" Bit, welches anzeigt,
dass der Puffer auf den es zeigte, das Ende des Proto-SCSI-Rahmens
enthielt.
-
Nach
dem Lesen des empfangenen Proto-SCSI-Rahmens, falls keine der Daten,
welche innerhalb des Rahmens enthalten waren, weiterhin zu benutzen
sind, dann sollten die Puffer des empfangenen Rahmens zu der Sendefreier-Puffer-Warteschlange
zurückgeschickt
werden, welche in dem Sendesteuerspeicher 122d enthalten
ist, indem diese in das Senderücksendefreie-Pufferregister
geschrieben werden, welches zu ihnen gehört.
-
Um
einen SMB-Rahmen zu senden, erhält der
Host-Prozessor als Erstes einen Zeiger auf einen freien SMB-Sendepuffer
in dem Sendepufferspeicher 122c von der Sendefreie-Puffer-Warteschlange, welche
in dem Sendesteuerspeicher 122d enthalten ist, indem von
einem zugehörigen
Register gelesen wird. In diesem Puffer kann der Start des SMB-Rückantwortrahmens aufgebaut
werden.
-
Die
32-Bit-Verbindungsidentifikation und ein 32-Bit-SMB-Sendesteuerfeld
werden vor dem SMB-Rahmen in dem Puffer platziert. Das SMB-Sende-Steuerfeld
beinhaltet einen 24-Bit-Rahmen-Byte-Zähler und
ein voraus angehängtes
Nachrichtenkopfbit. Falls das voraus angehängte Nachrichtenbit gesetzt
ist, wird dann nach der Verbindungsidentifikation und nachdem das
SMB-Sende-Steuerfeld zu dem IP-Block geführt wurde, der SMB-Nachrichtenkopf,
welcher in dem Rückantwort-Informationsspeicher 103 gespeichert
wurde, automatisch eingefügt.
-
Um
die SMB-Sendeentität
anzufordern, um den SMB-Rahmen zu der SMB-Entität zu übertragen, schreibt der Host-Prozessor 1301 einen
Puffer-Lokalisierer und ein Puffer-Offset-Paar in die SMB-Sendeereignis-Warteschlange 1325,
indem diese zu einem zugehörigen
Sende-SMB-Sendeereignisregister
geschrieben werden.
-
Der
Puffer-Lokalisierer enthält
einen Zeiger auf den Puffer, welcher Daten für den SMB-Rahmen enthält. Der Puffer-Offset enthält einen
Offset für
den Start der Daten innerhalb des Puffers und ein Längenfeld.
Der Puffer-Lokalisierer enthält
auch ein letztes Bit, um anzuzeigen, ob ein weiterer Puffer-Lokator/weitere
Puffer-Offset-Paare beschrieben werden, welche Zeiger auf mehrere
Daten für
diesen SMB-Rahmen enthalten.
-
Falls
der SMB-Rahmen dafür
ist, Daten von einem anderen SMB-Sendepuffer in dem Pufferspeicher 122c zu
beinhalten, dann muss der Host-Prozessor 1301 einen anderen
Puffer-Lokalisierer/anderes
Puffer-Offset-Paar an die SMB-Sendeereignis-Warteschlange 1325 schreiben,
welcher/welches diesen SMB-Sendepuffer beschreibt. Falls die Daten, welche
in dem SMB-Rahmen einzuschließen
sind, über
mehr als einen SMB-Sendepuffer aufgeteilt sind, dann kann die SMB-Sendeentität die Pufferzeiger
in dem zugehörigen
Sendepuffer-Deskriptor
benutzen, um die Daten miteinander zu verbinden. Falls die Extradaten
von einem Proto-SDSI-Empfangsrahmen stammen, dann werden diese Deskriptoren
im Voraus durch die Proto-SDSI-Empfangsentität gefüllt worden sein.
-
Da
die Daten von den SMB-Sendepuffern in dem Sendepufferspeicher 122c für mehr als
einen SMB-Rahmen benutzt werden können, ist das Freimachen der
SMB-Sendepuffer, nachdem sie benutzt wurden, kein einfacher Vorgang.
Die SMB-Sendepuffer, welche Abschnitte eines empfangenen Proto-SCSI-Rahmens
enthalten, welche nicht an dem SMB-Senden beteiligt sind, können durch
Rückschreiben
zu der Sende-Freie-Puffer-Warteschlange, welche in dem Sendesteuerspeicher
enthalten ist, über
das zugehörige
Rücksende-Freipufferregister freigemacht
werden. Die SMB-Sendepuffer, welche Daten enthalten, welche in die
SMB-Rahmen einzuschließen sind,
können
nicht in der gleichen Weise freigemacht werden, da sie nicht frei
gemacht werden können,
bis die Daten, welche in ihnen sind, gesendet wurden.
-
So,
nachdem der Puffer-Lokalisierer/die Puffer-Offset-Paare für die verschiedenen
SMB-Rahmen, welche
die Proto-SCSI-Daten enthalten werden, an die SMB-Sendeereignis-Warteschlange 1325 geschrieben
wurden, werden die Zeiger auf die ursprünglichen SMB-Sendepuffer auch
in die SMB-Sendeereignis-Warteschlange 135 geschrieben.
Diese Zeiger werden gekennzeichnet, um anzuzeigen, dass sie zurück zu der
Sende-Freie-Puffer-Warteschlange
freizusetzen sind. Da die SMB-Sendeereignis-Warteschlange 1325 in
Reihenfolge behandelt wird, werden dann die SMB-Sendepuffer nur
frei gemacht, nachdem jegliche Daten in ihnen gesendet wurden.
-
14 ist
ein Ablaufdiagramm, welches eine typische Vorgehensweise entsprechend
dem Stand der Technik darstellt, welche in Software implementiert
ist, für
das Behandeln vieler Dienstanfragen als viele Threads bzw. Pfade.
In einer herkömmlichen, vielverästelten
Architektur gibt es typischerweise wenigstens einen Pfad, um jeden
Client zu bedienen. Die Threads bzw. Pfade werden gestartet und
beendet, wenn sich Clients anmelden und vom Server abmelden. Jeder
Client kann einen Thread zu dem Server besitzen, um die Dienstanforderungen
zu behandeln, und einen Pfad, um die Disk-Anforderungen zu behandeln.
Der Dienstprozess 1400 beinhaltet eine Wiederholschleife,
in welcher es ein Testen für
das Vorhandensein einer Client-Verbindungsanfrage in Box 1401 gibt;
falls der Test positiv ist, initiiert der Prozess in Box 1402 den
Client-Prozess 1430. Wenn der Client-Prozess 1430 einen
Disk-Zugriff in
Box 1435 erfordert, fordert er zuerst den geeigneten Disk-Prozess
an, um auf die Disk zuzugreifen, und ruht dann in Box 1436,
bis der Disk-Zugriff vollendet ist. Der Disk-Prozess 1402 erweckt dann den
Client-Prozess 1430, um ihm zu gestatten, die Erwiderung
in Box 1437 zu dem Client zu senden, welcher die Dienstanforderung
ausgibt. Demnach gibt es wenigstens zwei Prozessvermittlungen für jede Client-Anforderung,
welche einen Disk-Zugriff
erfordert. Das Implementieren dieser Vielfachpfadprozesse in Hardware
wirft Probleme auf, da normalerweise diese durch ein Betriebssystem
mit Mehrprogrammbetrieb behandelt werden.
-
15 ist
ein Ablaufdiagramm, welches das Behandeln von vielen Dienstanforderungen
in einem einzelnen Pfad zeigt, für
den Gebrauch in Zusammenhang mit dem Dienstsubsystem der 2 und beispielsweise
für die
Ausführungsformen
der 12 und 13. In
der Einzelpfad-Architektur behandelt ein Dienstprozess 1500 die
Anfragen von vielen Clients in einem einzelnen Pfad und ein Disk-Prozess 1502 behandelt
alle Anforderungen von dem Dienstprozess 1500. Die Vorgehensweise
entsprechend dem Stand der Technik, welche einen getrennten Prozess
für jeden
Client benutzt, welcher eine Anforderung durchführt, wurde eliminiert, und
dessen Funktion wurde hier durch den Einzeldienstprozess 1500 behandelt.
Zusätzlich
können
diese beiden Prozesse, der Dienstprozess und der Disk-Prozess, innerhalb
des gleichen Pfades beinhaltet sein, wie dargestellt, oder sie können zwischen
zwei getrennten Pfaden aufgeteilt sein, um den Lastausgleich zu
erleichtern.
-
Der
Einzelpfad-Dienstprozess der 15 kann
Disk-Anforderungen, welche ausstehen, simultan besitzen. Der einzelne
Pfad beinhaltet eine Hauptschleife mit zwei Tests. Der erste Test
in Box 1501 besteht darin, ob eine Anforderung von einem Client
empfangen wurde. Der zweite Test in Box 1508 besteht darin,
ob eine vorher initiierte Disk-Zugriffsanforderung vollendet wurde.
Folglich, da ein Disk-Zugriff in Box 1508 als vollendet
zu sein bestimmt wurde, wird der Dienstprozess in Box 1507 die
geeignete Erwiderung zurück
zum Client senden. Sobald der Dienstprozess 1500 eine Disk-Zugriffsanforderung über die
Box 1501 behandelt hat und veranlasst hat, dass die Anforderung
in Box 1502 zu verarbeiten ist, und in Box 1504 das
Initiieren eines Disk-Zugriffs veranlasst hat, ist der Dienstprozess frei,
eine andere Anforderung von einem anderen Client über die
Box 1501 zu behandeln, ohne stoppen zu müssen und
auf den vorherigen Disk-Zugriff zu warten, um ihn zu vollenden.
Bei einer Festlegung in Box 1508, dass der Disk-Zugriff
vollendet wurde, wird der Disk-Prozess in Box 1507 den
Dienstprozess vom Ergebnis informieren, und der Dienstprozess wird
die Rückantwort
an den Client senden. Demnach werden die Dienst- und Disk-Prozesse
konstant laufen, solange es Anforderungen gibt, welche von Clients
gesendet werden.
-
16 ist
ein Blockdiagramm, welches das Gebrauchen eines File-System-Moduls
darstellt, wie er beispielsweise in 3 dargestellt
ist, in Verbindung mit einem Computersystem, welches einen File-Speicher
besitzt. (Eine Implementierung analog zu der der 16 kann
benutzt werden, um ein Speichermodul zu liefern, wie es in 3 dargestellt
ist, in Verbindung mit einem Computersystem, welches einen File-Speicher
besitzt.) In dieser Ausführungsform
ist das File-System-Modul 1601 in ein Computersystem integriert,
welches den Mikroprozessor 1605, den Speicher 1606 und
eine periphere Einrichtung, wie z. B. ein Video 1609, ebenso
wie ein Disk-Laufwerk 1610 beinhaltet, auf welches über ein Disk-Subsystem 1602 zugegriffen
wird, welches hier ein herkömmliches
Disk-Laufsteuerglied ist. Das File-System-Modul 1601 ist
an das Disk-Subsystem 1602 gekoppelt. Das File-System-Modul 1601 ist auch
an den Computer-Multiprozessor 1605 und den Computerspeicher 1606 über die
PCI-Brücke 1604 über den
PCI-Bus 1607 gekoppelt. Der PCI-Bus 1607 koppelt
auch den Mikroprozessor 1605 an die Computer-Periphereinrichtung 1609.
Die Empfangsmaschine 1610 des File-System-Moduls verarbeitet die Disk-Zugriffsanforderungen
von dem Mikroprozessor 1605 in einer Weise ähnlich zu
der, welche oben mit Bezug auf die 10, 11, 12B und 13 beschrieben
wurde. Auch liefert die Sendemaschine 1611 Rückantworten
auf derartige Disk-Zugriffsanforderungen
in einer Weise, ähnlich
zu der, welche oben mit Bezug auf die 10, 11, 12B und 13 beschrieben
wurde.
-
17A ist ein Blockdiagramm eines Datenflusses in
dem Speichermodul der 3. Es sollte beachtet werden,
dass, während
in den 17A und 17B ein
Tachyon-XL-Faseroptikkanal-Steuerglied,
welches von Hewlett Packard Co., Palo Alto, Kalifornien, erhältlich ist,
als E/A-Einrichtung benutzt wurde, Ausführungsformen der vorliegenden
Erfindung auch gleichermaßen
andere E/A-Einrichtungen nutzen können. Die Proto-SCSI-Anforderungen werden über den
Proto-SCSI-Eingang 1700 durch den Proto-SCSI-Anforderungsprozessor 1702 empfangen.
Die Information, welche sich auf diese Anforderung bezieht, wird
in einer SEST-Informationstabelle gespeichert, und falls dies eine
WRITE-Anforderung ist,
dann werden die WRITE-Daten, welche auch über den Proto-SCSI-Eingang 1700 geliefert
werden, in dem WRITE-Pufferspeicher 1736 gespeichert.
-
Der
Austauschanforderungs-("ERQ"-)Generator 1716 nimmt
die Information von dem WRITE-Pufferspeicher 1736. Wenn
alle Puffer, welche zu beschreiben sind, aktuell Cachegespeichert
sind, oder die Daten, welche zu schreiben sind, vollständig die
Puffer füllen,
welche zu beschreiben sind, dann kann der WRITE-Vorgang sofort ausgeführt werden. Die
Daten, welche zu schreiben sind, werden von dem WRITE-Pufferspeicher 1736 für die geeigneten Bereiche
in dem Cache-Speicher 1740 kopiert. Das Faserkanal-E/A-Steuerglied 1720 wird
dann konfiguriert, um die Daten zu dem geeigneten Bereich des Disk-Speichers
zu schreiben, welcher in Kommunikation mit dem Steuerglied 1720 ist.
Anderenfalls muss ein READ-Vorgang
von der Disk vor dem WRITE-Vorgang durchgeführt werden, um die erforderlichen
Daten von der geeigneten Disk zu erhalten.
-
Der
Proto-SCSI-Bestätigungsgenerator 1730 ist
verantwortlich für
das Erzeugen der Proto-SCSI-Rückantworten.
Es gibt drei mögliche
Quellen, welche Proto-SCSI-Rückantworten
generieren können,
von denen jede einen SEST-Index liefert: den Prozessor 1738,
das Faserkanal-E/A-Steuerglied 1720 und den Cache-Speicher 1740.
Für alle Übertragungen
wird eine Identifikation, welche es gestattet, die Proto-SCSI-Anforderung
an die Bestätigung
anzubinden, zusammen mit der Statusinformation, zurück zu der
Proto-SCSI-Bestätigungsschnittstelle 1734 geschickt.
-
17B ist ein detailliertes Blockdiagramm, welches
den Steuerfluss in dem Speichermodul der 3 zeigt.
Wenn die Proto-SCSI-Anforderungen über den Proto-SCSI-Eingang 1700 durch
den Proto-SCSI-Anforderungsprozessor 1702 empfangen werden,
wird ein einzigartiges Identifizierglied (der SEST-Index genannt)
zugeordnet. Die Information, welche sich auf diese Anforderung bezieht,
wird in einer SEST-Informationstabelle gespeichert, und falls dies
eine WRITE-Anforderung ist, dann werden die WRITE-Daten, welche
auch an den Proto-SCSI-Eingang 1700 geliefert
werden, in dem WRITE-Pufferspeicher 1736 gespeichert. Der
SEST-Index wird dann in die Proto-SCSI-Anforderungswarteschlange 1704 geschrieben.
-
Das
Cache-Steuerglied 1706 nimmt die Einträge aus der Proto-SCSI-Anforderungswarteschlange 1704 und
der benutzten Pufferwarteschlange 1708 heraus. Wenn ein
Eintrag aus der Proto-SCSI-Anforderungswarteschlange 1704 herausgenommen
worden ist, wird die Information, welche sich auf diesen SEST-Index
bezieht, aus der SEST-Informationstabelle
herausgelesen. Das Cache-Steuerglied 1706 erarbeitet dann,
welche Disk- Blöcke für diese Übertragung
erforderlich sind, und setzt diese in Cache-Pufferorte um, wobei
ein Hash-Suchlauf der Disk-Blocknummer und der Disk-Einrichtung,
auf die zuzugreifen ist, benutzt wird. Falls einer der Puffer in dem
Schreibpufferspeicher 1736, welcher für diese Übertragung erforderlich ist,
aktuell für
andere Übertragungen
benutzt wird, dann wird der SEST-Index in die ausstehende Anforderungswarteschlange 1710 gelegt,
wobei auf die Vollendung der anderen Übertragungen gewartet wird.
Anderenfalls, falls dies eine READ-Übertragung
ist und alle der erforderlichen Puffer in dem Cache sind, dann wird
der SEST-Index in
die Cache-READ-Warteschlange 1712 gelegt. Anderenfalls
wird der SEST-Index in die Speicheranforderungswarteschlange 1714 geschrieben.
Eine mögliche
Verbesserung für
diesen Algorithmus besteht darin, viele READs für den gleichen Puffer, welcher behandelt
wird, zu gestatten, vorausgesetzt, dass der Puffer aktuell in Cache-Funktion
ist.
-
Wenn
ein Eintrag aus der benutzten Pufferwarteschlange 1708 herausgenommen
wird, wird eine Überprüfung durchgeführt, ob
irgendwelche Anforderungen auf diesen Puffer warten, dass er verfügbar wird.
Dies wird durch Durchsuchen der ausstehenden Anforderungswarteschlange
durchgeführt, wobei
mit den ältesten
Anforderungen begonnen wird. Falls eine Anforderung gefunden wurde,
welche auf diesen Puffer gewartet hat, dass er verfügbar wird,
dann wird der Puffer dieser Anforderung zugeordnet. Falls die Anforderung
all die Puffer für
diese Übertragung
erfordert hat, dann wird der SEST-Index in die Speicheranforderungswarteschlange 1714 geschrieben,
und diese Anforderung wird von der Ausstehende-Anforderung-Warteschlange 1710 entfernt. Anderenfalls
bleibt die Anforderung in der Ausstehende-Anforderung-Warteschlange 1710.
-
Der
Austauschanforderungsgenerator 1716 nimmt die Einträge aus der
Speicheranforderungswarteschlange 1714 und der teilweisen
WRITE-Warteschlange 1718. Wenn ein SEST-Index aus beiden Warteschlangen gelesen
wird, dann wird die Information, welche sich auf diesen SEST-Index
bezieht, aus der SEST-Informationstabelle ausgelesen. Falls es eine
READ-Übertragung
ist, dann wird das Faserkanal-E/A-Steuerglied 1720 so konfiguriert,
um die Daten von der geeigneten Disk zu lesen. Falls es eine WRITE-Übertragung
ist und alle Puffer, welche zu beschreiben sind, aktuell in Cache-Funktion
sind, oder die Daten, welche zu schreiben sind, vollständig die
Puffer, welche zu beschreiben sind, füllen, dann kann die WRITE-Funktion
sofort durchgeführt
werden. Die Daten, welche zu schreiben sind, werden aus dem WRITE-Pufferspeicher 1736 für die geeigneten
Flächen
in den Cache-Puffern ko piert. Das Faserkanal-E/A-Steuerglied 1720 wird
dann konfiguriert, um die Daten auf die geeignete Disk zu schreiben.
Anderenfalls, wie oben mit Bezug auf 17A erwähnt, wird
es notwendig sein, eine READ-Funktion von der Disk durchzuführen, bevor
eine WRITE-Funktion
durchgeführt
wird, und eine READ-Funktion der erforderlichen Daten von der geeigneten
Disk zu initiieren.
-
Der
IMQ-Prozessor 1722 übernimmt
die Nachrichten von der eingebundenen Nachrichtenwarteschlange 1724.
Dies ist eine Warteschlange von Übertragungen,
welche das Faserkanal-E/A-Steuerglied 1720 vollendet
hat oder welche diejenigen überträgt, welche
mit einem Problem behaftet sind. Wenn es ein Problem bei der Faserkanalübertragung
gab, dann wird der IMQ-Prozessor 1722 die Nachricht zu
dem Prozessor über
die Prozessornachrichtenwarteschlange 1726 leiten, um dieser
zu gestatten, die geeignete Fehlererhebung durchzuführen. Wenn
die Übertragung
akzeptierbar war, dann wird die SEST-Information für diesen
SEST-Index ausgelesen.
Falls diese Übertragung
eine READ-Übertragung
beim Start einer WRITE-Übertragung
war, dann wird der SEST-Index in die partielle WRITE-Warteschlange 1718 geschrieben.
Anderenfalls wird er in die Speicherbestätigungswarteschlange 1728 geschrieben.
-
Wie
mit Bezug auf 17A erwähnt, ist der Proto-SCSI-Bestätigungsgenerator 1730 für das Erzeugen
der Proto-SCSI-Rückantworten
verantwortlich. Wiederum gibt es drei mögliche Quellen, welche die
Proto-SCSI-Rückantworten
erzeugen können, von
denen jede einen SEST-Index liefert.
-
Die
Prozessorbestätigungswarteschlange 1732 wird
von dem Prozessor 1738 benutzt, um die Anforderungen, welche
Fehler erzeugten und welche durch den Prozessor 1738 auszusortieren
sind, zurück
zu der Hardware zu leiten, sobald sie aussortiert wurden. Die Speicherbestätigungswartschlange 1728 wird
benutzt, um die Faserkanalanforderungen zurückzuleiten, welche normalerweise
vervollständigt
wurden. Die Cache-behandelte READ-Warteschlange 1712 wird
benutzt, um die Anforderungen zurückzuleiten, bei welchen alle
READ-Daten, welche erforderlich sind, bereits in dem Cache sind
und damit keine Faserkanalzugriffe erforderlich sind.
-
Wenn
es einen Eintrag in einer dieser Warteschleifen gibt, wird der SEST-Index
ausgelesen. Die SEST-Information für diesen Index wird dann gelesen.
Für alle Übertragungen
wird eine Identifikation, welche es gestattet, die Proto-SCSI-Anforderung
an die Bestätigung
anzubinden, zusammen mit der Statusinformation über die Proto-SCSI-Bestätigungsschnittstelle 1734 zurückgeschickt.
Für eine READ-Funktion
werden die READ-Daten auch über die
Proto-SCSI-Bestätigungsschnittstelle 1734 zurückgeschickt.
-
Sobald
die Proto-SCSI-Übertragung
vollendet wurde, werden die Adressen all der Puffer, welche zu dieser Übertragung
gehören,
in die benutzte Pufferwarteschlange 1708 geschrieben. Irgendein WRITE-Pufferspeicher,
welcher bei dieser Übertragung
benutzt wurde, wird auch zu dem Pool der freien WRITE-Pufferspeicher
zurückgeschickt.
-
18 ist
ein Blockdiagramm, welches das Benutzen eines Speichermoduls, wie
z. B. in 3 dargestellt, in Verbindung
mit einem Computersystem darstellt, welches eine File-Speicherung besitzt. Hier
agiert das Speichermodul 1801 als ein Faserkanal-Host-Bus-Anpassglied und als
Treiber für
das Computersystem, welches den Mikroprozessor 1802, den
Speicher 1803, eine periphere Einrichtung, wie z. B. ein
Videosystem 1805 und Speichereinrichtungen 1809, 1810 und 1811 besitzt.
Das Speichermodul 1801 ist an den Mikroprozessor 1802 und
den Computerspeicher 1803 über die PCI-Brücke 1804 über den
PCI-Bus 1807 gekoppelt. Das Speichermodul 1801 empfängt Anforderungen
von dem PCI-Bus und verarbeitet die Anforderungen in der Weise,
welche oben mit Bezug auf die 17A und 17B beschrieben wurde. Das Speichermodul 1801 greift
auf die Speichereinrichtungen 1809, 1810 und 1811 über die
Speichereinrichtungs-Zugriffsschnittstelle 1808 zu.
-
19 ist
ein Blockdiagramm, welches die Skalierbarkeit der Ausführungsformen
der vorliegenden Erfindung darstellt und speziell eine Ausführungsform,
wobei eine Vielzahl von Netzsubsystemen und Dienstsubsystemen angewendet
wird, wobei Erweiterungsvermittlungen bzw. -wähler für das Erstellen der Kommunikation
unter den Anschlüssen aufeinanderfolgender
Subsysteme und/oder Module benutzt werden. Um Extra-Netzverbindungen
zu gestatten, um die Bandbreitenfähigkeiten der Einheit zu erhöhen und
um eine große
Anzahl von Speicherelementen zu unterstützen, werden in dieser Ausführungsform
Erweiterungswähler 1901, 1902, 1903 benutzt,
um die Schnittstellen einer Anzahl von Modulen zusammen zu bilden.
Der Erweiterungswähler routet
jegliche Verbindung von einem Modul auf einer Seite der Er weiterungswählers zu
irgendeinem Modul auf der anderen Seite. Die Erweiterungswählerr ist
nicht blockierend und kann durch ein intelligentes Erweiterungswählersteuermodul
gesteuert werden, welches auf eine Anzahl von Eingängen zugreift
und über
die beste Route für
eine spezielle Verbindung entscheidet.
-
In
der Ausführungsform
der 19 nutzt das gezeigte Gesamtsystem eine Vielzahl
von Netzsubsystemen, welche in der Spalte 1921 gezeigt
wird, wobei das Netzsubsystem 1904 und ähnliche Subsysteme 1908 und 1912 beinhaltet
sind. Es gibt auch eine Vielzahl von Dienstsubsystemen, welche hier als
eine Kombination von File-Zugriffsmodulen (in Spalte 1922),
File-System-Modulen (in Spalte 1923) und Speichermodulen
(in Spalte 1924) realisiert ist. Zwischen jeder Spalte
von Modulen (und zwischen der Spalte der Nutzsubsysteme und der
Spalte der File-Zugriffsmodule) ist eine Vermittlungsanordnung, welche
als File-Zugriffsprotokoll-Erweiterungsvermittlung 1901,
Speicherzugriffs-Erweiterungsvermittlung 1902 und Proto-SCSI-Protokoll-Erweiterungsvermittlung 1903 implementiert
sind. Auf der File-Zugriffsprotokollebene ordnet die Erweiterungsvermittlung 1901 dynamisch
eingehende Netzverbindungen von dem Netzsubsystem 1904 speziellen
File-Zugriffsmodulen 1905 zu, abhängig von Kriterien, welche
die bestehende Arbeitsbelastung jeder der File-Zugriffsmodule 1905 beinhalten.
-
Auf
der Speicherzugriffsprotokollebene ordnet die Erweiterungsvermittlung 1902 dynamisch
eingehende File-Zugriffsverbindungen von den File-Zugriffsmodulen 1905 speziellen
File-System-Modulen 1906 zu,
abhängig
von Kriterien, welche die bestehende Belastung der File-System-Module 1906 beinhalten.
-
Auf
der Proto-SCSI-Protokollebene ordnet die Erweiterungsvermittlung 1903 dynamisch
eingehende File-Systemverbindungen speziellen Speichermodulen 1907 zu,
abhängig
von Kriterien, welche den physikalischen Ort des Speicherelements beinhalten.
-
Alternativ
können
die Gegenstände 1901, 1902 und 1903 als
Busse implementiert sein, in welchem Falle jeder Modul in einer
Spalte, welcher ein Eingangssignal akzeptiert, mit anderen Modulen
in der Spalte kommuniziert, um eine duplizierte Verarbeitung des
Signals zu verhindern, wobei dadurch die anderen Module freigehalten
werden, um andere Signale zu behandeln. Ungeachtet, ob die Gegenstände 1901, 1902 und 1903 als
Busse oder Wähler
bzw.
-
Vermittlungen
realisiert sind, ist es innerhalb des Umfangs der vorliegenden Erfindung,
den Signalverarbeitungspfad durch das System zu verfolgen, so dass,
wenn eine Rückantwort
auf eine File-Anforderung involviert ist, die geeignete Nachrichtenkopfinformation
von der entsprechenden Anforderung verfügbar ist, um ein bequemes Formatieren
des Rückantwort-Nachrichtenkopfes
zu erlauben.