DE60305378T2

DE60305378T2 - Verfahren zum Weitergeben von einem Netzwerkstapel

Info

Publication number: DE60305378T2
Application number: DE60305378T
Authority: DE
Inventors: James NE Sammamish Pinkerton; Abolade Seattle Ghadegesin; Sanjay Redmond Kaniyar; Sammamish Srinivas N K
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2002-04-30
Filing date: 2003-04-07
Publication date: 2007-02-22
Anticipated expiration: 2023-04-08
Also published as: US7007103B2; US7590755B2; US20030204634A1; US7254637B2; JP2003333076A; JP4327496B2; DE60305378D1; EP1359724B1; EP1359724A1; US20050091412A1; ATE327626T1; US20060069792A1

Description

Gebiet der Erfindung
Diese Erfindung bezieht sich im Allgemeinen auf Verfahren zum Erhöhen der Effizienz, Geschwindigkeit und/oder des Durchsatzes eines Computersystems und bezieht sich im Spezielleren auf Verfahren zum Abladen von Computer-Funktionen, die üblicherweise durch einen Host-Prozessor ausgeführt werden, zu einer bestimmten Hardware-Komponente.
Hintergrund der Erfindung
Die Komplexität und Verfeinerung von Betriebssystemen, Anwendungssoftware, Vernetzung, vernetzten Kommunikationen und ähnlichem schreitet fort, in dramatischem Maß zuzunehmen. Ein Ergebnis der Komplexität und Verfeinerung ist die zunehmende Funktionalität der Anwendungen und Systeme. Diese zugenommene Funktionalität führt oft aufgrund der zusätzlichen Aufgaben, die durch die CPU ausgeführt werden müssen, um die zugenommenen System- und Anwendungsfunktionen auszuführen, zu einer Zunahme des CPU-Overhead.
Ein Gebiet, in dem die Zunahme des CPU-Overhead leicht sichtbar ist, ist das Gebiet der vernetzten Anwendungen, wo Netzwerkgeschwindigkeiten aufgrund der Entwicklung von Medien mit hohen Bandbreiten zunehmen. Netzwerkgeschwindigkeiten gleichen sich oft an die CPU-Prozessorgeschwindigkeit und Speicher-Bandbreiten-Kapazitäten des Host-Computers an, und übersteigen diese zunehmend. Diese vernetzten Anwendungen belasten den Host-Prozessor aufgrund der geschichteten (layered) Architektur weiter, die bei den meisten Betriebssystemen verwendet wird, wie z.B. das Sieben-Schicht-ISO-Modell oder das geschichtete Modell, das von dem Windows Betriebssystem verwendet wird. Wie es allgemein bekannt ist, wird solch ein Modell verwendet, um den Datenfluss zwischen der physikalischen Verbindung zu dem Netzwerk und der Endbenutzeranwendung zu beschreiben. Die einfachsten Funktionen, wie z.B. das Setzen von Datenbits auf das Netzwerkkabel, werden in den unteren Layern ausgeführt, während Funktionen, die die Details von Anwendungen behandeln, in den oberen Layern sind. Im Wesentlichen ist der Zweck von jedem Layer, dem nächsthöheren Layer Services bereitzustellen, und dabei den höheren Layer von den Details, wie Services tatsächlich implementiert werden, abzuschirmen. Die Layer sind in solch einer Weise abstrahiert, dass jeder Layer glaubt, er kommuniziert mit dem gleichen Layer auf dem anderen Computer.
Verschiedene Funktionen, die auf ein Datenpaket angewandt werden, während es zwischen den Layern voranschreitet, können software-intensiv sein, und benötigen oft eine erhebliche Menge der CPU-Prozessor- und Speicherressourcen. Zum Beispiel sind bestimmte Funktionen, die auf das Datenpaket bei verschiedenen Layern angewandt werden, extrem CPU intensiv, wie z.B. die Berechnung und Überprüfung der Paketprüfsumme, Verschlüsselung und Entschlüsselung von Daten (z.B. SSL-Verschlüsselung und IP-Sicherheitsverschlüsselung), die Berechnung einer Nachrichten-Kurzfassung (message digest), TCP-Segmentierung, erneute TCP-Übertragung und Bearbeitung der Quittierung (acknowledgment – ACK), Paketfilterung, um vor Denial-of-Service-Attacken zu schützen, und User-Datagram-Protocol-(UDP)-Paket-Fragmentierung. Weil jede dieser Funktionen ausgeführt wird, können die daraus resultierenden Anforderungen an die CPU den Durchsatz und die Leistung des gesamten Computersystems bedeutend beeinträchtigen.
Obwohl die Anforderungen an CPU-Ressourcen wachsen, nimmt die Fähigkeit und der Durchsatz von Computer-Hardware-Peripherie, wie z.B. Netzwerk-Schnittstellenkarten (network interface cards -NICs) und ähnliches auch zu. Diese Peripherie-Geräte sind oft mit einem zugehörigen Prozessor und Speicher ausgerüstet, die geeignet sind, viele der Aufgaben und Funktionen auszuführen, die anderenfalls durch die CPU ausgeführt werden.
Die Computer-Industrie hat diese Fähigkeiten erkannt und hat Verfahren zum Abladen CPU-intensiver Aufgaben und Funktionen, die vorher durch die CPU ausgeführt wurden, entwickelt. Zum Beispiel stellen das U.S. Patent 6,141,705 im Namen von Anand et al., und die Patent-Anmeldungen Nr. 09/657,510, „Method and Computer Program Product for Offloading Processing Tasks from Software to Hardware", eingereicht am 7. September 2000 und Nr. 09/726,082, „Method and Computer Program Product for Offloading Processing Tasks from Software to Hardware", eingereicht am 29. November 2000, Lösungen bereit, um Peripherie-Geräte abzufragen und bestimmte Prozessor-Aufgaben zu den Peripherie-Geräten abzuladen, die fähig sind, die intensiven Aufgaben und Funktionen auszuführen. Die bestimmten Aufgaben, die üblicherweise abgeladen werden, schließen Aufgaben wie z.B. TCP- (Transmission Control Protocol) und/oder IP- (Internet Protocol) Prüfsummenberechnung, TCP-Segmentierung, wie z.B. large send offload (LSO), und secure Internet-Protocol- (IPSEC) Verschlüsselung und Entschlüsselung ein.
Diese Ablademechanismen sind eingeschränkt, indem die Mechanismen ein zusätzliches Erfordernis haben, nämlich dass eine minimale Anzahl von Veränderungen an dem Netzwerkstack gemacht werden muss. Als Ergebnis dieses zusätzlichen Erfordernisses gibt es eine andere Einschränkung, dass das Abladen einen langen Code-Pfad hat, weil der gesamte Netzwerkstack durchlaufen wird, um das Peripherie-Gerät zu erreichen, wobei die abgeladenen Aufgaben und Funktionen abgeschaltet sind. Eine weitere Einschränkung ist der Integrationsmangel des Netzwerkstack. Es gibt keine gut definierte Schnittstelle für den Netzwerkstack, um Parameter auf dem Peripherie-Gerät abzufragen oder zu setzen, oder eine Schnittstelle für das Peripherie-Gerät, um den Netzwerkstack über irgendwelche Bekanntmachungen oder Veränderungen der Fähigkeiten zu informieren. Zum Beispiel, wenn sich die Route ändert, während eine LSO-Anfrage verarbeitet wird, ist der Fallback-Mechanismus für den Stack, auf Timeouts oder erneute Übermittlung der LSO-Anfrage zu warten.
Ein anderer Ansatz, den Peripherie-Geräte-Hersteller versucht haben, war das Abladen der gesamten TCP-Verbindung von einem Kernstack (core stack) zu einer Netzwerk-Schnittstellenkarte (network interface card – NIC). Bei diesem Ansatz wurde der gesamte Protokollstack durch das Verwenden einer eigenen Schnittstelle umgangen, und er erfordert es, dass das Peripherie-Gerät alle TCP-Nachrichten, IP- (Internet Protocol). Nachrichten, ICMP- (Internet Control Message protocol) Nachrichten, DNS- (Domain Name Server) Nachrichten, und RIP-Nachrichten bearbeitet, was erfordert, dass die NIC alles bearbeitet. Zusätzlich adressiert dieser Ansatz nicht Umgebungen an vielen Orten und integriert sich nicht sauber in die Host-Betriebssystem-Netzwerk-Management-Einrichtungen ein. Sobald sich ein Status verändert, kann die abgeladene Verbindung leicht fehlschlagen.
US 2001/027496 A1 bezieht sich auf das Zusammenlegen von den Layern einer verbindungsbasierten geschichteten Architektur, wie z.B. TCP/IP in einen einzelnen breiteren Layer, welcher in der Lage ist, Netzwerkdaten direkter zu und von einem gewünschten Ort oder Puffer auf einem Host zu senden. Ein Verbindungskontext fasst verschiedene Merkmale der Verbindung zusammen, wie z.B. Protokolltyp und Quell- und Zieladressen für jeden Protokoll-Layer, und wird als ein Kommunikationskontrollblock (communication control block – CCB) entweder bei einem kommunikationsverarbeitenden Gerät (communication processing device – CPD), der in den Host integriert ist, oder in dem Host-Speicher gespeichert. Wenn der CPD einen CCB hält, der eine bestimmte Verbindung definiert, können Daten, die sich auf diesen CCB beziehen, dann direkt zu dem Host-Speicher gemäß einer Fast-Path umgehenden sequentiellen Protokoll-Verarbeitung (fast-path bypassing sequential protocol processing) gesendet werden. Des Weiteren können übrige nachfolgende Datenpakete von der gleichen Verbindung unter Verwendung von Direct Memory Access (DMA) zu dem Speicher gesendet werden.
WO 99 65219 A bezieht sich auf ein Internet-bereites Modem, wobei ein Netzwerkstack mit einem Modemkern zur Verwendung sowohl in Computer- als auch Nicht-Computer-Anwendungen verknüpft ist. Die Layer des Netzwerk-Protokolls, die in einem Hardware-Gerät entsprechend dem gewünschten System implementiert werden können, können von nur dem PPP-Layer bis hinauf zu den IP, TCP und UPD-Layern reichen. Des Weiteren verwendet die Übertragungsroutine Direct Memory Access (DMA), um Daten weiterzugeben, anstatt dem langsameren I/O Port Pumping. Um eine Internet-Anwendung ihre Daten direkt zu dem Modem in einem Datenpaket-Format senden zu lassen, richtet die Anwendung zuerst die Socket-Parameter ein. Wenn der Netzwerkstack auf dem Internetbereiten Modem diese Informationen erhält, sendet es ein SYN-Paket zu dem Ziel-Socket, nachdem das Paket zu der IP-Engine, dem PPP-Steuerungsprogramm und der TCP-Engine weitergegeben wurde. Nachdem der Ziel-Socket ein Rückgabe-SYN-ACK-Faket gesendet hat, wird ein ACK-Paket von der Modem-Karte gesendet, und die Anwendungs-Software wird benachrichtigt.
WO 02 27519 A bezieht sich auf eine intelligente Netzwerk-Schnittstellenkarte (intelligent network interface card – INIC), die Hardware und Verarbeitungsmechanismen zum Beschleunigen von Daten-Transfers zwischen einem Netzwerk und einer Speichereinheit bereitstellt. Mit dem Bus der INIC ist eine Reihe von Hardware-Sequencern verbunden, die die Verarbeitung von Netzwerk-Nachrichten in einem höheren Layer bereitstellen. Des Weiteren wählt die INIC aus, ob ein Paket zu dem Host-Speicher für eine „slow path"-Verarbeitung der Headers durch den Protokoll-Stack, der auf der Host-CPU läuft, gesendet werden soll, oder ob die Paketdaten direkt entweder zu einem INIC-Datei-Cache oder Host-Datei-Cache gemäß einem „fast-path" gesendet werden soll. Um die Fähigkeit für einen fast-path bei dem Host bereitzustellen, wird ein Kommunikationskontrollblock (CCB) durch den Protokollstack während der Verbindungsinitialisierungsprozeduren erzeugt. Der CCB schließt Verbindungsinformationen ein, wie z.B. Quell- und Zieladressen und Ports, Media Access Control Adressen und IP-Adressen. Nachdem eine Verbindung eingerichtet worden ist, wird der CCB von dem Host zu dem INIC-Speicher weitergegeben. Wenn es ermittelt wird, dass ein empfangenes Paket zu einer Nachricht gehört, für die eine Fast-Path-Verbindung eingerichtet worden ist, werden die Daten des Pakets ohne Netzwerk oder Transport-Layer durch eine Direct-Memory-Access- (DMA) Einheit zu dem Ziel in einem Datei-Cache gesendet, der durch den entsprechenden CCB bezeichnet ist. Nachdem alle Daten von der Nachricht zwischengespeichert wurden, werden die Daten des Weiteren durch die DMA-Einheit unter Kontrolle des Dateisystems zu der INIC-Speichereinheit oder Host-Speichereinheit gesendet.
Kurzfassung der Erfindung
Es ist die Aufgabe der Erfindung, ein flexibles Abladen von verschiedenen Layern des Protokollstack zu haben.
Diese Aufgabe wird durch die Erfindung wie in den unabhängigen Ansprüchen beansprucht gelöst.
Bevorzugte Ausführungsformen werden durch die abhängigen Ansprüche definiert.
Die vorliegende Erfindung stellt ein Verfahren zum Abladen einer Netzwerkstack-Verbindung bereit, wie z.B. einen TCP-basierten Protokollstack. Daten, die normalerweise durch einen NDIS- (network driver interface specification)-Pfad, der mehrere Software-Layer hat, zu einem Peripherie-Gerät gesendet werden, werden zu einem Pfad von einem Switch-Layer zu dem Peripherie-Gerät abgeladen. Enge Synchronisation zwischen dem Netzwerkstack und einer Prozessor-Einheit wird beibehalten. Eine Anfrage, den Stack abzuladen, wird durch den NDIS-Pfad zu dem Peripherie-Gerät gesendet. Die Anfrage schließt eine Liste mit Ressourcen-Erfordernissen ein, so dass das Peripherie-Gerät die Informationen hat, die benötigt werden, um Ressourcen zuzuordnen. Jeder Layer in dem NDIS-Pfad fügt seine Ressourcen-Erfordernisse der Liste hinzu. Wenn das Peripherie-Gerät die Anfrage akzeptiert, weist das Peripherie-Gerät Ressourcen zu und sendet einen Ablade-Handle (offload handle) zu jedem der Software-Layer, so dass die Software-Layer mit dem Peripherie-Gerät kommunizieren können.
Der Status für jeden Software-Layer wird zu dem Peripherie-Gerät gesendet, sobald die Zustimmung des Peripherie-Gerätes zum Abladen zu dem Software-Layer kommuniziert wurde. Alternativ wird der Status mit der Abladeanfrage gesendet, und nur Veränderungen des Status werden zu dem Peripherie-Gerät gesendet. Jeder Status hat Status-Variablen und jede Status-Variable ist als eine konstante Variable, zwischengespeicherte Variable oder eine übertragene Variable klassifiziert. Die konstanten Variablen ändern sich während der Zeit, in der der Protokollstack abgeladen ist, nicht. Zwischengespeicherte Variablen werden durch die CPU bearbeitet, und übertragene Variablen werden durch das Peripherie-Gerät bearbeitet.
Die vorliegende Erfindung stellt auch ein Verfahren zum Hinaufladen einer abgeladenen Netzwerkverbindung von dem Peripherie-Gerät zu dem Host bereit. Das Hinaufladen wird entweder durch das Peripherie-Gerät oder den Switch-Layer ausgelöst. Sobald das Hinaufladen ausgelöst wurde, schließt das Peripherie-Gerät alle ausstehenden Anfragen ab und übergibt den übertragenen Status an den Switch-Layer. Nachdem der übertragene Status durch den Host akzeptiert worden ist, werden die Status-Ressourcen bei dem Peripherie-Gerät freigegeben.
Während der Ablade- oder Hinauflade-Übertragungen könnte ein Update (z.B. ARP-Update oder RIP-Update) eintreffen. Es wird eine Lauf-Nummer verwendet, um sicherzustellen, dass die neueste Update-Nachricht verwendet wird, wenn mehrere Update-Nachrichten bei dem Peripherie-Gerät empfangen werden, so dass das Peripherie-Gerät nicht abgelaufene Daten verwendet.
Zusätzliche Merkmale und Vorteile der Erfindung werden von der folgenden detaillierten Beschreibung der illustrativen Ausführungsformen ersichtlich, welche mit Bezug auf die angehängten Figuren fortfährt.
Kurze Beschreibung der Zeichnungen
Während die anhängigen Ansprüche die Merkmale der vorliegenden Erfindung im Detail darlegen, kann die Erfindung zusammen mit ihren Aufgaben und Vorteilen am bes ten durch die folgende detaillierte Beschreibung im Zusammenhang mit den beigefügten Zeichnungen verstanden werden, wobei:
1 ein Blockdiagramm ist, das allgemein ein beispielhaftes Computer-System darstellt, auf dem die vorliegende Erfindung sich befindet;
2 ist ein Blockdiagramm, das die funktionalen Layer des Netzwerkstacks und des Umgehungspfades der vorliegenden Erfindung darstellt;
3 ist ein Blockdiagramm, das die funktionalen Layer des NDIS-Pfades und des Umgehungspfades der vorliegenden Erfindung darstellt;
4 ist ein Leiterdiagramm, das den Ablademechanismus der vorliegenden Erfindung darstellt;
5a-5c sind Diagramme, die einen invertierten Baum der vorliegenden Erfindung darstellen;
6 ist ein Blockdiagramm, das die Synchronisierung zwischen dem Host-Computer und dem Peripherie-Gerät darstellt;
7 ist ein Leiterdiagramm, das den Hinauflademechanismus der vorliegenden Erfindung darstellt;
8 ist ein Leiterdiagramm, das den Ablademechanismus einer sicheren Protokollstack-Verbindung entsprechend der Lehre der vorliegenden Erfindung darstellt; und
9 ist ein Leiterdiagramm, das den Hinauflademechanismus einer sicheren abgeladenen Protokollstack-Verbindung entsprechend der Lehre der vorliegenden Erfindung darstellt.
Detaillierte Beschreibung der Erfindung
Bezugnehmend auf die Zeichnungen, worin gleiche Bezugszeichen zu gleichen Elementen referenzieren, wird die Erfindung so dargestellt, dass sie in eine geeignete Computer-Umgebung implementiert ist. Obwohl nicht erforderlich, wird die Erfindung in dem allgemeinen Kontext von computer-ausführbaren Instruktionen, wie z.B. Programm-Modulen, die durch einen Personal-Computer ausgeführt werden, beschrieben. Im Allgemeinen schließen Programm-Module Routinen, Programme, Objekte, Komponenten, Datenstrukturen, etc. ein, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Außerdem werden Fachleute es begrüßen, dass die Erfindung mit anderen Computersystem-Konfigurationen ausgeübt werden kann, einschließlich Hand-Held-Geräten, Multiprozessorsysteme, mikroprozessor-basierter oder programmierbarer Unterhaltungselektronik, Netzwerk PCs, Minicomputern, Mainframe-Computern, vernetzten Peripherie-Geräten (z.B. vernetzten Druckern) und ähnlichem. Die Erfindung kann ebenso in verteilten Computerumgebungen ausgeübt werden, wo Aufgaben durch dezentrale (remote) Verarbeitungsgeräte ausgeführt werden, die durch ein Kommunikationsnetzwerk verbunden sind. In einer dezentralen Computerumgebung können Programm-Module in beiden, lokalen und Remote-Speichergeräten, liegen.
1 stellt ein Beispiel einer geeigneten Computer-Systemumgebung 100 dar, auf der die Erfindung implementiert werden kann. Die Computer-Systemumgebung 100 ist nur ein Beispiel einer geeigneten Computerumgebung und ist nicht gedacht, irgendwelche Einschränkungen bezüglich des Umfangs der Verwendung oder Funktionalität der Erfindung vorzuschlagen. Noch sollte die Computerumgebung 100 interpretiert werden, als hätte sie irgendwelche Abhängigkeiten oder Erfordernisse bezüglich irgendeiner oder einer Kombination von Komponenten, die in der beispielhaften Arbeitsumgebung 100 dargestellt sind.
Die Erfindung ist mit vielen anderen Allzweck- oder speziellen Computer-Systemumgebungen oder Konfigurationen funktionsbereit. Beispiele für gut bekannte Computer-Systeme, Umgebungen und/oder Konfigurationen, die für die Verwendung mit der Erfindung geeignet sind, schließen ein, sind aber nicht darauf begrenzt, Personal-Computer, Server-Computer, Hand-Held oder Laptop-Geräte, Multiprozessor-Systeme, Mikroprozessor-basierte Systeme, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerk PCs, Minicomputer, Mainframe-Computer, vernetzte Peripherie-Geräte (z.B. vernetzte Drucker), dezentrale Computer-Umgebungen, die irgendeins der oben genannten Systeme oder Geräte einschließen, und ähnliches.
Die Erfindung kann im allgemeinen Kontext von computer-ausführbaren Instruktionen wie z.B. Programm-Modulen, die durch einen Computer ausführbar sind, beschrieben werden. Im Allgemeinen schließen Programm-Module Routinen, Programme, Objekte, Komponenten, Datenstrukturen etc. ein, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Erfindung kann auch in dezentralen Computer-Umgebungen ausgeübt werden, wo Aufgaben durch remote-verarbeitende Geräte ausgeführt werden, die durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Computer-Umgebung können Programm-Module in beiden, lokalen und Remote-Computerspeichermedien, einschließlich Speichergeräten, liegen.
Mit Bezug auf 1 schließt ein beispielhaftes System zum Implementieren der Erfindung ein Allzweck-Computergerät in der Form von Computer 110 ein. Komponenten des Computers 110 können einschließen, sind aber nicht darauf begrenzt, eine Prozessoreinheit 120, einen Systemspeicher 130, und einen Systembus 121, der verschiedene System-Komponenten, einschließlich dem Systemspeicher mit der Prozessoreinheit 120, koppelt. Der Systembus 121 kann irgendeiner von verschiedenen Busstrukturtypen sein, einschließlich einem Speicherbus oder Speicher-Controller, einem Peripheriebus, einem Cross-Bar, einem Switched-Bus-Fabric und einem lokalen Bus, der irgendeine Auswahl von Bus-Architekturen verwendet. Der Systembus 121 kann auch eine Hierarchie von Bussen sein. Als Beispiel, und nicht Einschränkung, schließen solche Architekturen einen Industry Standard Architecture (ISA) Bus, Micro Channel Architecture (MCA) Bus, Enhanced ISA (EISA) Bus, Video Electronics Standards Associate (VESA) Local Bus, No Cache Non-Uniform Memory Access (NC-NUMA) Architecture Bus, Cache-Coherent Non-Uniform Memory Access (CC-NUMA) Architecture Bus und Peripheral Component Interconnect (PCI) Bus, der auch als Mezzanine Bus bekannt ist, ein.
Computer 110 schließt üblicherweise eine Vielfalt von computer-lesbaren Medien ein. Computerlesbare Medien können irgendwelche verfügbare Medien sein, auf die durch den Computer 110 zugegriffen werden kann, und enthalten beide, flüchtige und nichtflüchtige Medien, entfernbare und nicht-entfernbare Medien. Als Beispiel, und Nicht-Einschränkung, können computerlesbare Medien, Computer-Speichermedien und Kommunikationsmedien umfassen. Computer-Speichermedien schließen beide, flüchtige und nichtflüchtige, entfernbare und nicht-entfernbare Medien ein, die in irgendeinem Verfahren oder Technologie zur Speicherung von Informationen implementiert sind, wie z.B. compu terlesbare Instruktionen, Datenstrukturen, Programm-Module oder andere Daten. Computer-Speichermedien schließen ein, sind aber nicht darauf begrenzt, RAM, ROM, EEPROM, Flash Memory oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Disk-Speicher, magnetische Cassetten, magnetische Bänder, magnetische Diskspeicher oder andere magnetische Speichergeräte, oder irgendein anderes Medium, welches verwendet werden kann, um die gewünschten Informationen zu speichern, und auf welches durch Computer 110 zugegriffen werden kann. Kommunikationsmedien enthalten üblicherweise computerlesbare Instruktionen, Datenstrukturen, Programm-Module oder andere Daten in einem modulierten Datensignal, wie z.B. einer Trägerwelle oder anderem Transportmechanismus und schließt irgendwelche Informations-Liefermedien ein. Der Begriff „moduliertes Datensignal" meint ein Signal, das eine oder mehrere seiner Charakteristiken in einer Weise gesetzt oder verändert hat, um Informationen in dem Signal zu codieren. Zum Beispiel und nicht Einschränkung, schließen Kommunikationsmedien Kabelmedien ein, wie z.B. ein Kabelnetzwerk oder eine direkte Kabelverbindung, und kabellose Medien, wie z.B. akustische, RF, infrarote oder andere kabellose Medien. Kombinationen von irgendwelchen der oben genannten sollten ebenso in dem Umfang der computerlesbaren Medien eingeschlossen sein.
Der Systemspeicher 130 schließt Computer-Speichermedien in der Form von flüchtigem und/oder nicht-flüchtigem Speicher ein, wie z.B. Read only Memory (ROM) 131 und Random Access Memory (RAM) 132. Ein Basic Input/Output-System 133 (BIOS), das die Basis-Routinen enthält, die helfen, Informationen zwischen Elementen innerhalb des Computers 110, wie z.B. während des Hochfahrens, zu übertragen, ist üblicherweise in dem ROM 131 gespeichert. Der RAM 132 enthält üblicherweise Daten und/oder Programm-Module, die sofort zugreifbar sind für und/oder auf denen aktuell gearbeitet wird durch die Prozessoreinheit 120. Als Beispiel, und nicht Einschränkung, stellt 1 ein Betriebssystem 134, Applikationsprogramme 135, andere Programm-Module 136 und Programm-Daten 137 dar.
Der Computer 110 kann auch andere entfernbare/nicht-entfernbare, flüchtige/nicht-flüchtige Computer-Speichermedien einschließen. Nur als Beispiel stellt 1 ein Festplatten-Laufwerk 141 dar, das von oder zu nicht-entfernbaren, nicht-flüchtigen magnetischen Medien liest oder schreibt, ein magnetisches Disk-Laufwerk 151, das von oder zu einer entfernbaren, nicht-flüchtigen magnetischen Disk 152 liest oder schreibt, und ein optisches Disk-Laufwerk 151, das von oder zu einer entfernbaren, nicht-flüchtigen opti schen Disk 156 liest oder schreibt, wie z.B. einer CD-ROM oder anderem optischen Medium. Andere entfernbare/nicht-entfernbare, flüchtige/nicht-flüchtige Computer-Speichermedien, die in der beispielhaften Arbeitsumgebung verwendet werden können, enthalten, sind aber nicht darauf begrenzt, magnetische Band-Cassetten, Flash-Memory-Karten, Digital Versatile Disks, digitale Video-Bänder, solid state RAM, solid state ROM, und ähnliches. Das Festplatten-Laufwerk 141 ist üblicherweise mit dem System-Bus 121 durch eine nicht-entfernbare Speicher-Schnittstelle, wie z.B. der Schnittstelle 140 verbunden, und das magnetische Disk-Laufwerk 151 und optische Disk-Laufwerk 155 sind üblicherweise mit dem System-Bus 121 durch eine entfernbare Speicher-Schnittstelle, wie z.B. Schnittstelle 150, verbunden.
Die Laufwerke und ihre zugehörigen Computer-Speichermedien, die oberhalb diskutiert und in 1 dargestellt sind, stellen Speicher für computer-lesbare Instruktionen, Datenstrukturen, Programm-Module und andere Daten für den Computer 110 bereit. In 1 wird z.B. das Festplatten-Laufwerk 141 so dargestellt, dass es das Betriebssystem 144, Applikationsprogramme 145, andere Programm-Module 146 und Programmdaten 147 speichert. Es ist zu beachten, dass diese Komponenten entweder dieselben wie oder verschieden von dem Betriebssystem 134, Anwendungsprogrammen 135, anderen Programm-Modulen 136 und Programmdaten 137 sein können. Dem Betriebssystem 144, den Applikationsprogrammen 145, den anderen Programm-Modulen 146 und den Programmdaten 137 sind hier mit verschiedenen Nummern gegeben, um darzustellen, dass sie mindestens verschiedene Kopien sind.
Ein Benutzer kann Befehle und Informationen in den Computer 110 über Eingabegeräte, wie z.B. ein Keyboard 162 und Zeigergerät 161, das allgemein als eine Mouse, Trackball oder Touch pad bezeichnet wird, eingeben. Andere Eingabegeräte (nicht gezeigt) können ein Mikrophon, Joystick, Game pad, Satellitenschüssel, Scanner, Videoeingang oder ähnliches einschließen. Diese und andere Eingabegeräte sind oft mit der Prozessoreinheit 120 über eine Benutzereingabe-Schnittstelle 160 verbunden, die mit dem System-Bus gekoppelt ist, aber auch über andere Schnittstellen und Bus-Strukturen verbunden sein kann, wie z.B. einem Parallelanschluss, Gameport oder einem Universal Serial Bus (USB). Ein Monitor 191 oder anderer Typ von Anzeigegerät ist auch mit dem System-Bus 121 über eine Schnittstelle, wie z.B. einer Video-Schnittstelle 190, verbinden. Zusätzlich zu dem Monitor können Computer auch andere periphere Ausgabegeräte ein schließen, wie z.B. Lautsprecher 197, Drucker 196 und einen Video-Ausgang, welcher durch eine Ausgangs-Peripherie-Schnittstelle 195 verbunden ist.
Der Computer 110 kann in einer vernetzten Umgebung unter Verwendung von logischen Verbindungen zu einem oder mehreren Remote-Computern arbeiten, wie z.B. einem Remote-Computer 180. Der Remote-Computer 180 kann ein anderer Personal-Computer, Server, Router, ein Netzwerk-Peripherie-Gerät (z.B. ein Drucker), ein Netzwerk-PC, ein Peergerät oder anderer bekannter Netzwerkknoten sein, und schließt üblicherweise viele oder alle oben mit Bezug auf Personal Computer 110 beschriebenen Elemente ein, obwohl nur ein Speichergerät 181 in 1 dargestellt worden ist. Die logischen Verbindungen, die in 1 gezeigt sind, schließen ein local area network (LAN) 171 und ein wide area network (WAN) 173 ein, können aber auch andere Netzwerke einschließen. Solche Netzwerkumgebungen sind alltäglich in Büros, unternehmensweiten Computer-Netzwerken, Intranets und dem Internet.
Wenn er in einer LAN-Netzwerkumgebung verwendet wird, ist der Personal Computer 110 mit dem LAN 171 durch eine Netzwerk-Schnittstelle oder -Adapter (z.B. eine Netzwerk-Schnittstellenkarte (network interface card – NIC) 170 verbunden. Wenn er in einer WAN-Netzwerkumgebung verwendet wird, schließt der Computer 110 üblicherweise ein Modem 172 oder andere Mittel zum Herstellen von Kommunikationen über das WAN 173 ein, wie z.B. dem Internet. Das Modem 172, welches intern oder extern sein kann, kann mit dem Systembus 121 über die Benutzereingabe-Schnittstelle 160 oder einen anderen geeigneten Mechanismus verbunden sein. In einer Netzwerkumgebung können Programm-Module, die mit Bezug auf Personal Computer 110 dargestellt sind, oder Teile davon in dem Remote-Speichergerät gespeichert sein. Zum Beispiel, und nicht als Einschränkung, stellt 1 Remote-Anwendungsprogramme 185 so dar, dass sie auf dem Speichergerät 181 liegen. Es wird begrüßt, dass die gezeigten Netzwerkverbindungen exemplarisch sind und andere Mittel zum Herstellen eines Kommunikations-Links zwischen den Computern verwendet werden kann.
In der Beschreibung, die folgt, wird die Erfindung in Bezug auf Vorgänge und symbolische Repräsentationen von Funktionen beschrieben, die durch einen oder mehrere Computer ausgeführt werden können, außer wenn dies anders angegeben ist. Als solches gilt es als verstanden, dass solche Vorgänge und Funktionen, die hin und wieder als Computer-ausgeführte bezeichnet sind, die Manipulation von elektrischen Signalen, die Daten in einer strukturierten Form darstellen, durch die Prozessor-Einheit des Computers einschließen. Die Manipulation wandelt die Daten um oder pflegt sie an Orten in dem Speichersystem des Computers, welche den Arbeitsablauf des Computers in einer Weise rekonfigurieren oder anders verändern, die durch Fachleute gut verstanden ist. Die Datenstrukturen, wo Daten gepflegt werden, sind physikalische Orte des Speichers, die bestimmte Eigenschaften haben, die durch das Format der Daten definiert werden. Während die Erfindung in dem vorangehenden Kontext beschrieben ist, ist es jedoch nicht einschränkend gemeint, wie Fachleute es begrüßen werden, dass hier später beschriebene verschiedene Vorgänge und Funktionen auch in Hardware implementiert sein können.
2 stellt den Zusammenhang von manchen der Komponenten, die ein Netzwerkmodell bilden, und den Komponenten der vorliegenden Erfindung dar. Während des normalen Betriebs werden Netzwerk-Nachrichten von der Anwendung 200 durch den Netzwerkstark 202 zu dem Peripherie-Gerät 204 gesendet, wo die Nachrichten zu anderen Geräten und Anwendungen in dem Netzwerk gesendet werden und von anderen Geräten und Anwendungen empfangen werden. Der Netzwerkstark 202 schließt einen oder mehrere zwischenliegende Software-Layer 206 ein. Daten, die von der Anwendung 200 gesendet werden, wandern durch den/die dazwischenliegenden Software-Layer 206, wo bestimmte Funktionen mit den Daten ausgeführt werden können, wie z.B. das Verpacken (packaging) der Daten, sichere Datenübertragung, Datenverschlüsselung und Berechnung eines Nachrichten-Extrakts (message digest).
Der Switch 208 wird verwendet, um das Ausführen von Netzwerkstark-Funktionen für den/die dazwischenliegenden Software-Lager 206 durch die Prozessor-Einheit 120 abzuladen. Obwohl der Switch 208 separat dargestellt wird, sollte beachtet werden, dass der Switch 208 auch in den obersten dazwischenliegenden Layer des Netzwerkstacks 202 integriert sein kann. Daten werden zu dem Peripherie-Gerät 204 über einen Chimney 210 (Kamin) für das Peripherie-Gerät 204 gesendet, um Netzwerkstark-Funktionen auszuführen. In dieser Hierarchie müssen die dazwischenliegenden Software-Layer nicht ausschließlich in dem Host oder dem Peripherie-Gerät liegen, und sie erlaubt, dass irgendeiner der dazwischenliegenden Layer entweder vollständig abgeladen ist, in dem Host bleibt oder eine Kombination dieser beiden (z.B. das Abladen einer oder mehrerer bestimmter Verbindungen). Zusätzlich können Chimneys auf Chimneys geschichtet werden (z.B. kann ein IPSEC-Chimney auf einem TCP-Chimney geschichtet sein). Eine Verbindung kann irgendeine Kombination aus zuverlässigen und unzuverlässigen Datentransfers und Uni cast- oder Multicast-Datentransfers sein. Wenn ein dazwischenliegender Layer in dem Host bleibt, aktualisiert der Host zwischengespeicherte Variablen (wie unterhalb beschrieben) in dem Peripherie-Gerät 204. Zum Beispiel kann ein Transport-Control-Block- (TCB) Statuseintrag für eine Verbindung für den Transport-Layer abgeladen werden, zusammen mit einem route cache entry (RCE) für den Netzwerk-Layer, der zu dem Peripherie-Gerät 204 abgeladen ist. Der Switch 208 fährt mit dem Senden von Datenverkehr für einen anderen TCB durch den Netzwerkstack 202 fort, der sich den gleichen RCE teilt, während der Switch 208 Datenverkehr durch den Chimney 210 für den abgeladenen TCB sendet.
Der Switch 208 beginnt das Abladen durch das Senden einer Anfrage zum Abladen an den dazwischenliegenden Layer 206. Die Anfrage zum Abladen schließt Ressourcen-Informationen ein, die dem Peripherie-Gerät 204 helfen, zu entscheiden, ob es die Verbindung erfolgreich abladen kann. Jeder dazwischenliegende Layer 206 weist die Anfrage zum Abladen entweder zurück oder fügt Ressourcen-Informationen zu der Anfrage zum Abladen hinzu und sendet die Anfrage zum Abladen zu dem anschliessenden Software-Layer in dem Netzwerkstack 202. Wenn das Peripherie-Gerät 204 die Anfrage zum Abladen empfängt, berechnet es, ob es Ressourcen zum Abladen der Verbindung zur Verfügung hat. Das Peripherie-Gerät 204 weist die Anfrage zum Abladen zurück, wenn das Abladen nicht möglich ist. Andernfalls akzeptiert das Peripherie-Gerät 204 die Anfrage zum Abladen und teilt Ressourcen für die Verbindung zu. Das Peripherie-Gerät 204 schließt die Anfrage zum Abladen durch das Senden einer Abschluss-Nachricht, die eine verknüpfte Liste mit Parametern (linked list of parameters) hat, an den/die dazwischenliegenden Software-Layer(n) 206 ab. Die verknüpfte Liste mit Parametern stellt Informationen für den/die dazwischenliegenden Software-Layer 206 und den Switch 208 bereit, um es dem/den dazwischenliegenden Software-Layer(n) 206 und dem Switch zu ermöglichen, mit dem Peripherie-Gerät zu kommunizieren. Jeder dazwischenliegende Software-Layer 206 entfernt Informationen für seinen Layer von der verknüpften Liste mit Parametern.
Wenn ein dazwischenliegender Layer 206 die Abschluss-Nachricht zum Abladen empfängt, gibt der dazwischenliegende Layer 206 seinen Status an das Peripherie-Gerät 204 weiter. Jeder Status kann drei Variablen-Typen haben: CONST, CACHED und DELEGATED (konstant, zwischengespeichert und übertragene). Ein Status kann alle drei Variablen-Typen oder eine Untergruppe der drei Variablen-Typen haben. CONST-Variablen sind Konstanten, die sich während der Lebensdauer der abgeladenen Verbindung nicht ändern. Sie werden nicht zu den Layern zurückgelesen, wenn die Verbindung hinaufgeladen wird. Die Host-Prozessor-Einheit 120 behält den Besitz der CACHED-Variablen und stellt sicher, dass irgendwelche Veränderungen an einer CACHED-Variablen in der Host-Prozessor-Einheit 120 auch in dem Peripherie-Gerät 204 aktualisiert werden. Kontroll-Nachrichten, die den CACHED-Status verändern, werden durch den Netzwerkstack 202 abgewickelt. Als Ergebnis wird der Host die CACHED-Variablen schreiben, aber muss diese nicht zurückschreiben, wenn die Verbindung hinaufgeladen wird. Die Host-Prozessor-Einheit 120 überträgt den Besitz der DELEGATED-Variablen an das Peripherie-Gerät 204. Die DELEGATED-Variablen werden einmal geschrieben, wenn das Abladen stattfindet, und werden zurückgeschrieben, wenn das Abladen beendet ist. Durch das alleinige Zurückübertragen der DELEGATED-Variablen, wird der Overhead der Zurückübertragung einer Verbindung zu dem Host minimiert. Status, der zwischen dem Netzwerkstack 202 und dem Peripherie-Gerät 204 geteilt (z.B. kontrolliert) werden muss, der für verschiedene Performance-Gründe abgeladen (d.h. übertragen) worden ist, wird klar zwischen dem Netzwerkstack 202 und dem Chimney 210 getrennt (z.B. IP ID in TCP offloads), so dass beide, der Netzwerkstack 202 und das Peripherie-Gerät 204, jeweils einen ausgewählten Teil des Status besitzen. Die Host-Prozessor-Einheit 120 frägt das Peripherie-Gerät 204 nach DELEGATED-Variablen ab, wenn diese benötigt werden (z.B. für Statistiken). Die Host-Prozessor-Einheit 120 kann auch CONST- oder CACHED-Variablen für Diagnosen abfragen. Das Aufteilen des Status in drei Kategorien befähigt den Netzwerkstack 202 klar neben dem Chimney 210 zu bestehen. Es sollte beachtet werden, dass der Status in die Abfrage zum Abladen eingeschlossen sein kann. Dies kann dadurch geschehen, wenn der Status entweder keine übertragenen Status-Variablen enthält oder übertragene Status-Variablen enthält, die sich nicht zwischen dem Beginn der Abfrage zum Abladen und dem Abschluss der Abfrage zum Abladen ändern werden.
Das Peripherie-Gerät 204 oder Host entscheiden, wenn eine abgeladen Verbindung hinaufgeladen wird. Das Hinaufladen wird entweder durch das Peripherie-Gerät 204 oder den Switch 208 ausgelöst. Sobald das Hinaufladen ausgelöst wurde, stellt das Peripherie-Gerät 204 alle ausstehenden Anfragen mit dazugehörigem Status fertig und übergibt den übertragenen Status des höchsten dazwischenliegenden Layers an den Switch 208. Der Switch 208 stellt irgendwelche weiteren Übermittlungsanfragen in eine Schlange und stoppt das Bekanntgeben (posting) von Empfangspuffern. Der Switch 208 befiehlt dem höchsten dazwischenliegenden Layer, die Kontrolle über übertragenen Status zu übernehmen. Der höchste dazwischenliegende Layer übernimmt die Kontrolle über den übertragenen Status und sendet eine Abschluss-Nachricht an den Switch 208. Nachdem der Switch 208 die Abschluss-Nachricht empfangen hat, bestätigt der Switch 208 dem Peripherie-Gerät 204 das Hinaufladen, welches das Peripherie-Gerät 204 befähigt, Ressourcen freizugeben, die nicht länger verwendet werden.
Es sollte beachtet werden, dass der höchste dazwischenliegende Layer eingehende Datenpakete für die abgeladene Verbindung an das Peripherie-Gerät 204 zum Bearbeiten weiterleitet, bis es die Kontrolle über den übertragenen Status übernimmt. Datenpakete können zwischen der Zeit, zu der das Peripherie-Gerät 204 den übertragenen Status an den Switch 208 abgibt und der Zeit, zu der der höchste dazwischenliegende Layer die Kontrolle über den übertragenen Status übernimmt, ankommen. Nachdem das Peripherie-Gerät 204 den übertragenen Status an den Switch 208 übergeben hat, kann es nicht mehr länger eingehende Datenpakete bearbeiten. Das Peripherie-Gerät 204 sendet eine Fehlermeldung an den höchsten dazwischenliegenden Layer, die angibt, dass ein Hinaufladen durchgeführt wird, wenn es eingehende Daten empfängt. Die Fehlermeldung informiert den höchsten dazwischenliegenden Layer, das Weiterleiten eingehender Daten zu stoppen und weitere Daten zwischenzuspeichern, bis der höchste dazwischenliegende Layer den übertragenen Status empfängt. Alternativ könnten die eingehenden Daten auf Kosten von zusätzlichem Pufferspeicher auf dem Peripherie-Gerät 204 an das Peripherie-Gerät 204 weitergeleitet werden, wobei die Daten durch das Peripherie-Gerät 204 zwischengespeichert werden.
Mehrere Verbindungen können durch einen dazwischenliegenden Software-Layer 206 zu dem Peripherie-Gerät 204 abgeladen werden. Ein Bezugszähler für die Anzahl von höheren Layer-Status-Objekten (d.h. Statusobjekte von Layern oberhalb des dazwischenliegenden Software-Layers 206) wird durch den dazwischenliegenden Software-Layer 206 geführt, welcher das Statusobjekt zum Abladen des dazwischenliegenden Software-Layers referenziert. Ein Statusobjekt wie es hier verwendet wird, ist eine Sammlung von Status-Variablen für einen bestimmten Layer, die als CONST, CACHED oder DELEGATED wie hier verwendet, kategorisiert sind. Wenn auf ein abgeladenes Statusobjekt eines dazwischenliegenden Layers nicht mehr durch einen Layer über ihn referenziert wird, sendet der dazwischenliegende Layer 206 eine Nachricht an das Peripherie-Gerät 204, um das Statusobjekt für den dazwischenliegenden Layer hinaufzuladen und übertragene Status-Variablen zu dem dazwischenliegenden Layer 206 zu senden. Das Peripherie- Gerät 204 löscht das Statusobjekt für den dazwischenliegenden Layer 206 und der dazwischenliegende Layer 206 sendet eine Abschluss-Nachricht an den Switch 208.
Wenden wir uns nun zur 3, nachdem nun das allgemeine Konzept beschrieben worden ist, werden die Details der Erfindung in einer Ausführungsform beschrieben, wo das Peripherie-Gerät 204 eine NIC 170 ist, der Switch 208 ein Transport-Layer-Interface-Switch (TLI) 306 ist, und der Netzwerkstack 202 einen Transport-Layer 300, einen Netzwerk-Layer 302 und einen Framing-Layer 304 umfasst. Der Netzwerk-Layer 302 ist auch bekannt als ein Pfad-Layer und der Framing-Layer 304 ist auch bekannt als ein Nachbar-Layer.
Netzwerk-Nachrichten werden durch die Anwendung 200 durch den Netzwerkstack 202 zu der NIC 170 während des Betriebs gesendet. Daten, die von der Anwendung 200 gesendet wurden, gehen durch den TLI-Switch 306, welcher kontrolliert, ob die Daten den host-basierten Netzwerkstack 202 oder den Chimney 308 hinuntergehen. Es ist zu beachten, dass der TLI-Switch 306 in den obersten Layer des Netzwerks 202 eingebaut sein kann. Die Software-Layer in dem Netzwerkstack 202 empfangen Daten von der Anwendung 200, verpacken diese in eine Paketform und senden sie zu der Peripherie-Gerät-Hardware 314 über den NDIS-Minidriver 310. Andere Aufgaben, die der Netzwerkstack 202 ausführen kann, wenn ein Datenpaket durch den Stack 202 passiert, schließen Datenverschlüsselung, zuverlässige Datenübermittlung und Berechnung eines Nachrichtenextraktes ein (z.B. eine Prüfsumme oder CRC für das Datenpaket). Viele dieser Aufgaben werden von der Prozessor-Einheit 120 ausgeführt und sind prozessor-intensiv.
Der TLI-Switch 306 wird verwendet, um die Prozessor-Einheit 120 vom Ausführen von Stack-Funktionen durch das Senden von Daten für Verbindungen an die NIC 170 über den Chimney 308 (und Chimney-Driver 312) zu entlasten. Fachleute werden erkennen, dass die obere Kante des NDIS-Minidrivers 310 und Chimney-Drivers 312 die NDIS API in Microsoft^® Betriebssystemen ist. Zum Zweck der Erläuterung wird ein transmission control protocol (TCP) basierter Protokoll-Stack verwendet, um die Erfindung zu erläutern. Es wird begrüßt, dass Fachleute erkennen werden, dass jedoch viele Peripherie-Gerätetypen verwendet werden können und andere Netzwerkstacks unter Verwendung der Lehre der vorliegenden Erfindung abgeladen werden können. Zum Beispiel können stream control transmission protocol (SCTP) oder user datagram protocol (UDP) basierte Protokollstacks abgeladen werden. Zusätzlich kann die Erfindung auch verwendet wer den, um höhere Funktionsprotokolle abzuladen, wie z.B. das internet small computer system interface (iSCSI), das network file system (NFS) oder das allgemeine Schnittstellen-File-System (common interface file system – CIFS).
Es gibt viele Gründe, warum ein Abladen passiert. Als Beispiel, und Nicht Einschränkung, werden unterhalb manche der Gründe aufgeführt. Ein Systemadministrator könnte einen bestimmten Service auswählen, der abgeladen werden soll. Eine bestimmte Verbindung kann abgeladen werden, wenn Datenverkehr (im Sinne der Anzahl von Bytes oder Paketen) auf der Verbindung eine signifikante Menge an Ressourcen verbraucht. Service-Typen können abgeladen werden. Zum Beispiel können Sicherheitsprotokolle, wie z.B. IPSEC, abgeladen werden. Das Abladen kann durch eine Policy gesteuert werden. Zum Beispiel kann ein Administrator eine Policy haben, dass alle Verbindungen von innerhalb einer Organisation zuerst abgeladen werden. System-Ressourcen (z.B. cpu Nutzung, Daten-Cache-Verwendung, Page-Table-Cache-Verwendung, Speicherbandbreite), die verwendet werden, können den Host-Prozessor dazu führen, Verbindungen abzuladen.
4 stellt die Schritte dar, die genommen werden, um eine TCP-Verbindung abzuladen. Ein dreistufiger Prozess wird verwendet. Im Allgemeinen besteht der dreistufige Prozess aus dem Zuteilen von Ressourcen, die zum Abladen der TCP-Verbindung benötigt werden, dem Bereitstellen von Handles für jeden der Layer 300, 302, 304, 306 und dem Abladen des Status für jeden der Layer 300, 302, 304, 306 zu der NIC 170. Während des Abladeübergangs speichert der TLI-Switch 306 alle Nachrichten zwischen, die von der Anwendung 200 gesendet wurden. Alternativ speichert der Transport-Layer 300 die Daten zwischen. Wenn das Abladen fertig ist, werden die zwischengespeicherten Daten zu der NIC 170 unter Verwendung desselben Mechanismus übermittelt, wie für die Vermittlung von Abladedaten (offload data transmission). Wenn eingehende Pakete während des Abladeübergangs empfangen werden, fährt die NIC 170 fort, die Daten nach oben durch die Layer 300, 302, 304, 306 zu bewegen, bis der übertragene Status des Transport-Layers an die NIC 170 übergeben wurde.
Der TLI-Switch 306 beginnt das Abladen durch das Senden einer Anfrage zum Abladen an den Transport-Layer 300 (Linie 400). Die Anfrage zum Abladen schließt einen Pointer zu dem lokalen Status des nächsten Layers ein (z.B. ein TCB-Pointer für den Transport-Layer 300, einen RCE-Pointer für den Netzwerk-Layer 302, einen ARP- Tabellen-Pointer für den Framing-Layer 304 oder einen NDIS-Miniport-Pointer für den NDIS-Minidriver 310), den Ablade-Typ (z.B. TCP für den TLI-Switch 306, IPv6 für den Netzwerk-Layer 302 etc.), und Ressourcen-Information, die der NIC 170 helfen, zu entscheiden, ob sie die TCP-Verbindung erfolgreich abladen kann. Der TLI-Switch 306 kann der NIC 170 auch Versandtabellen (dispatch tables) bereitstellen. Der Transport-Layer 300 weist die Anfrage zum Abladen entweder zurück oder sendet eine Anfrage zum Abladen an den Netzwerk-Layer 302, wobei TCP-Ressource-Informationen zu den TLI-Switch-Ressource-Informationen hinzugefügt sind (Linie 402).
Der Netzwerk-Layer 302 empfängt die Anfrage zum Abladen und verweigert entweder das Abladen der Verbindung oder sendet eine Anfrage zum Abladen an den Framing Layer 304, wobei Netzwerk-Ressource-Erfordernisse zu den TCP-Ressource-Informationen und den TLI-Switch-Ressource-Informationen hinzugefügt sind (Linie 404). Der Netzwerk-Layer 302 kann der NIC 170 auch Versandtabellen bereitstellen. Der Framing-Layer 304 verweigert entweder das Abladen der Verbindung oder sendet eine Anfrage zum Abladen an die NIC 170, wobei Framing-Ressource-Erfordernisse zu den Netzwerk-Ressource-Erfordernissen, den TCP-Ressource-Informationen und den TLI-Switch-Ressource-Informationen hinzugefügt sind (Linie 306).
Die NIC 170 empfängt die Anfrage zum Abladen und berechnet, ob sie Ressourcen zur Verfügung hat, um die TCP-Verbindung abzuladen. Wenn die NIC entscheidet, dass das Abladen nicht möglich ist, verwirft sie die Anfrage zum Abladen. Wenn die NIC entscheidet, dass das Abladen möglich ist, akzeptiert sie die Anfrage zum Abladen und teilt Ressourcen für die Verbindung zu (z.B. TCB, route cache entry (RCE), Address-Resolution-Protocol- (ARP) Tabelleneinträge (ATE). Die NIC 170 erzeugt eine verknüpfte Liste mit Parametern und Versandtabellen, um sie den Layern 300, 302, 304 und 306 zu übergeben, und vervollständigt die Anfrage zum Abladen durch das Senden einer Fertigstellungsnachricht an den Framing-Layer 304, die die verknüpfte Liste mit Parametern beinhaltet (Linie 408). Die Parameter schließen einen Ablade-Handle und eine Versandtabelle für jeden der Layer 300, 302, 304, 306 ein. Wie hier verwendet, bedeutet ein Ablade-Handle einen Mechanismus, um es einem Software-Layer zu erlauben, mit dem Peripherie-Gerät zu kommunizieren. Als Beispiel, und nicht Einschränkung, kann das Ablade-Handle ein Pointer-basiertes Handle, ein ganzzeiliger Wert, der als ein Lookup in ein Array verwendet wird, eine Hash-Tabelle (z.B. eine Hashing-Funktion), ein Kommunikationskanalzwischen dem Software-Layer (oder Netzwerkstack) und dem Peripherie-Gerät oder eine Reihe von Parametern sein, die von einem Software-Layer hinuntergereicht wurden, die das Peripherie-Gerät verwendet, um das Statusobjekt nachzuschlagen.
Die Versandtabellen werden verwendet, um Daten direkt zu der NIC 170 zu senden oder Daten direkt von der NIC 170 zu empfangen. Die Versandtabellen können auch verwendet werden, um Diagnosen bereitzustellen. Zum Beispiel könnte ein Software-Layer hinzugefügt werden, um das System zu überwachen und injiziert Fehler, um sicherzustellen, dass das System richtig funktioniert. Zusätzlich kann durch Software-Layer, die zusätzliche Funktionalität falls notwendig hinzufügen kann, etwas in die Versandtabelle eingesetzt werden. Zum Beispiel könnte ein Software-Layer hinzugefügt werden, um die Funktionalität eines Filtertreibers bereitzustellen. Das Einsetzen wird üblicherweise durch das Fassen des Pointers zu der ursprünglichen Funktion getan, wo die hinzugefügte Funktion eingefügt wurde, und durch das Umleiten (d.h. zeigen auf (pointing it)) dieser zu der hinzugefügten Funktion. Nachdem das Einsetzstück eingefügt worden ist, führt die hinzugefügte Funktion ihre Funktion aus und ruft die ursprüngliche Funktion auf, so oft die ursprüngliche Funktion aufgerufen wird.
Der Framing-Layer 304 speichert das Ablade-Handle und die Versandtabelle für den Framing-Layer in seinem ARP-Tabellen-Eintrag für einfache Aktualisierungen, wenn die Ziel-MAC-Adresse sich verändert oder der Verkapselungstyp sich ändert. Der Framing-Layer 304 aktualisiert dann den NIC- 170 Status zugehörig zu dem ATE (Linie 410). Der Framing-Layer 304 entfernt seinen Status von der verknüpften Liste und leitet die restlichen Informationen in der verknüpften Liste an den Netzwerk-Layer 302 weiter (Linie 412).
Der Netzwerk-Layer 302 speichert das Ablade-Handle und die Versandtabelle für den Netzwerk-Layer 302. Der Netzwerk-Layer 302 sendet auch seinen Status an die NIC 170 (Linie 414). Der Netzwerk-Layer 302 entfernt Netzwerk-Layer-Informationen von der verknüpften Liste und sendet eine Fertigstellungs-Nachricht, die die verknüpfte Tabelle mit Parametern und Versandtabellen beinhaltet, an den Transport-Layer 300 (Linie 416). Der Netzwerk-Layer 302 kann IP-Fragmente, die er für den abgeladenen Status empfängt, an die NIC 170 zur Bearbeitung weiterleiten oder er kann die IP-Fragmente in dem Netzwerk-Layer bearbeiten und sie zu dem Transport-Layer 300 weiterleiten.
In einer alternativen Ausführungsform wird das Statusobjekt des Layers mit der Anfrage zum Abladen versendet. Zum Beispiel wird das Statusobjekt des Framing-Layers und das Statusobjekt des Netzwerk-Layers mit der Anfrage zum Abladen gesendet, und nur wenn der zwischengespeicherte Status sich zwischen der Anfrage zum Abladen und dem Fertigstellungsereignis ändert, wird der Status aktualisiert. Das gesamte Layer-Statusobjekt kann nur mit der Anfrage zum Abladen gesendet werden, wenn der übertragene Status entweder nicht vorhanden ist oder sich nicht zwischen der Anfrage zum Abladen und der Fertigstellung der Anfrage zum Abladen ändern kann. Status-Variablen, die als CONST klassifiziert sind, können jedoch mit der Anfrage zum Abladen gesendet werden, selbst wenn der übertragene Status vorhanden ist und sich zwischen der Anfrage zum Abladen und der Fertigstellung der Anfrage zum Abladen ändern kann.
Der Transport-Layer 300 speichert den Ablade-Handle für den Transport-Layer und sendet seinen Status an die NIC 170 (Linie 418). Wenn irgendwelche ausstehenden Sende- oder Empfangspuffer anstehen, gibt der Transport-Layer 300 die Puffer an den TLI-Switch 306 zurück. Sobald der Transport-Layer 300 beginnt, die Puffer zurück zu dem TLI-Switch 306 zu übergeben, wird der TLI-Switch 306 aufhören, Puffer zu dem Transport-Layer 300 zu senden und wird diese in einer Schlange einreihen und wartet auf den Transport-Layer 300, dass dieser eine Vervollständigungsnachricht an den TLI-Switch 204 sendet, die die verknüpfte Liste mit Parametern und die Versandtabelle enthält. Der Transport-Layer 300 gibt alle Puffer zurück und sendet dann die Fertigstellungsnachricht (Linie 420). Sobald der TLI-Switch 306 die Fertigstellungsnachricht empfängt, übergibt der TLI-Switch 306 die Sende- und Empfangspuffer an die NIC 170 (Linie 422). Der TLI-Switch 306 verwendet die Versandtabelle, um alle ausstehenden und künftigen Empfangspuffer bekannt zu geben (posting), und sendet zum Verarbeiten an die NIC 170. Während der Zeit, die die Ablade-Anfrage braucht, um fertig zu werden, weist jeder Layer 300, 302, 304 entweder neue Anfragen zum Abladen für das abgeladene Statusobjekt zurück (d.h. das Statusobjekt zugehörig zu einem Layer) oder stellt diese in eine Schlange, bis das Abladen fertiggestellt ist.
Transport-Layer 300 hat immer noch die Möglichkeit, eingehende TCB-Daten zu verarbeiten und die Daten an den TLI-Switch 306 zu übergeben, wenn der Transport-Status nicht zu der NIC 170 abgeladen worden ist. Wenn TCB-Daten in der Mitte eines Abladens ankommen, kann der Transport-Layer 300 entweder an den Daten festhalten, oder die Daten bearbeiten und sie an den TLI-Switch 306 weitergeben. Zwischen der Zeit, zu der der Transport-Layer 300 seinen Status an die NIC 170 sendet (Linie 418) und der Zeit, zu der der TLI-Switch Puffer an die NIC 170 übergibt (Linie 422), werden eingehende TCB-Daten, die durch den Netzwerkstack 202 nach oben kommen, zu der NIC 170 gesendet.
Auf nachfolgende Anfragen zum Abladen hin geben der Netzwerk-Layer 302 und der Framing-Layer 304 die Ablade-Handles, die sie von der NIC 170 von dem früheren Abladen empfangen haben, an die NIC 170 weiter. Dies signalisiert der NIC 170, dass Ressourcen für den Netzwerk-Layer 302 und den Framing-Layer 304 bereits zugewiesen worden sind, was der NIC Ressourcen bewahrt und das Abladen beschleunigt.
Wie vorher gezeigt, geben die Layer 300, 302, 304 ihren Status an die NIC 170 weiter. Jeder Status hat drei Variablen-Typen: CONST, CACHED und DELEGATED. CONST-Variablen sind Konstanten, die sich nie während der Lebensdauer der abgeladenen Verbindung verändern. Sie werden nicht zu den Layern zurückgelesen, wenn die Verbindung beendet wird. Die Host-Prozessor-Einheit 120 behält den Besitz der CACHED-Variablen bei und stellt sicher, dass irgendwelche Änderungen an einer CACHED-Variablen in der Host-Prozessor-Einheit 120 auch in der NIC 170 aktualisiert werden. Als Ergebnis wird der Host die CACHED-Variablen schreiben, aber nie zurücklesen (außer wenn Systemdiagnosen diese anfragen). Die Host-Prozessor-Einheit 120 übergibt den Besitz der DELEGATED-Variablen an die NIC 170. Die DELEGATED-Variablen werden einmal geschrieben, wenn das Abladen stattfindet, und werden zurückgelesen, wenn das Abladen beendet wird. Dadurch, dass nur die DELEGATED-Variablen zurück übertragen werden, wird der Overhead des Zurückübertragens der Verbindung zu dem Host minimiert. Falls notwendig (z.B. für Statistiken), fragt die Host-Prozessor-Einheit 120 die NIC 170 nach den DELEGATED-Variablen.
Die CONST-Variablen für den Transport-Layer 300 enthalten den Zielport, den Quellport, einen Bit-Schalter (flag), um anzuzeigen, dass es sich in diesem Fall um Mobile-IP handelt, wo sich die „care-of" Adresse ändern kann, SEND und RECV-Fenster Skalierungsfaktoren und den NIC-Handle für den Netzwerk-Layer 302. Die CACHED-Variablen für den Transport-Layer 300 sind TCP-Variablen und IP-Variablen. Die TCP-Variablen enthalten den effektiven MSS, die Anzahl der Bytes, die durch die NIC 170 in dem Empfangshinweis kopiert werden müssen, einen Bit-Schalter, um Nagling abzuschalten, einen Bit-Schalter, um anzuzeigen, dass Keep-Alive notwendig ist, und Keep-Alive- Einstellungen (d.h. Intervall, Anzahl von Proben und Delta). Die IP-Variablen schließen TOS und TTL ein. Die DELEGATED-Variablen enthalten den aktuellen TCP-Status, eine Lauf-Nummer für den nächsten RECV (d.h. RCV.NEXT), eine Empfangsfenstergröße (RCV.WND), die Sequenz-Nummer für First-Un-Acked-Data (SND.UNA), die Sequenz-Nummer für das nächste SEND (SND.NEXT), die maximale Sequenz-Nummer, die jemals gesendet wurde (SND.MAX), das maximale Send Window (MAX_WIN), das aktuelle Congestion Window (CWIN), der slow start threshold (SSTHRESH), der smoothed RTT (8*A), Delta (8*D), der aktuelle Wiederübermittlungszähler, die Zeit verbleibend für den Next-Retransmit, und der Zeitstempel zum Wiederholen.
Die CONST-Variablen für den Netzwerk-Layer 302 schließen die Ziel-IP-Adresse (entweder für IPv4 oder IPv6) und die Quell-Ziel-IP-Adresse (entweder für Ipv4 oder Ipv6) ein. Die CACHED-Variablen für den Netzwerk-Layer 302 schließen den NIC-Handle für den Framing-Layer 304 ein. Die DELEGATED-Variablen für den Netzwerk-Layer 302 schließen den IP-Paket-ID-Startwert ein. Die CACHED-Variablen für den Framing-Layer 304 schließen die ARP-Adresse und einen Bit-Schalter zum Kennzeichnen des Header-Formats ein (z.B. LLC/SNAP [Logical Link Control/Sub-Network Access Protocol] oder DIX [Digital, Intel, Xerox]).
Der Transport-Layer-Status schließt einen Handle für den Netzwerk-Layer ein und der Netzwerk-Layer-Status schließt einen Handle für den Framing-Status ein, weil der Netzwerk-Layer-Status zwischen vielen Verbindungen gemeinsam benutzt werden kann und der Framing-Layer-Status zwischen vielen Pfaden (z.B. IP Aliasen) gemeinsam benutzt werden kann. Diese Hierarchie wird für verschiedene Gründe beibehalten. Eine Verbindung benötigt einen NIC-Handle für den Netzwerk-Layer, weil der IP-ID-Namensraum über allen abgeladenen Verbindungen auf einer Pro-Pfad-Basis gesteuert werden muss. Ein Pfad erfordert einen NIC-Handle für den Framing-Layer, weil eine Routen-Aktualisierung die nächste Hop-Adresse ändern könnte, und deshalb zu einer neuen MAC-Adresse zeigt. Die Hierarchie reduziert auch die Menge an benötigtem Status, der durch die NIC beibehalten werden muss. Zum Beispiel könnte eine ARP-Aktualisierung für IPv4 das Mapping von einer IP-Adresse zu einer MAC-Adresse ändern (z.B. eine Schnittstelle schlug auf dem Server fehl (failed over)). Der Host behält die MAC-Adresse als eine zwischengespeicherte Variable bei, und braucht deshalb nur eine einzelne Aktualisierung des zwischengespeicherten Status durchzuführen, und alle Verbindungen werden im Fehlerfalle zu der neuen Schnittstelle übergeben.
Sobald eine TCP-Verbindung abgeladen ist, ist die NIC 170 verantwortlich für das Zuweisen von Paket-Identifizierern (z.B. IP IDs) für das Paket, das sie sendet. IP ID wird entweder auf einer Pro-Schnittstellen-Basis oder Pro-Layer-Statusobjekt-Basis abgeladen. Der NIC 170 ist ein Teil des IP-ID-Namensraumes zugeteilt. In einer Ausführungsform ist der NIC 170 die Hälfte des gesamten IP-ID-Namensraumes zugeteilt und es wird ihr ein IP-Paket ID-Startwert gegeben, um ihn zu verwenden, wenn der Netzwerk-Status zu der NIC 170 übergeben wird. Die NIC 170 verwendet die folgende Formel, um eine IP ID auf IP-Paketen zu erzeugen, die sie sendet: Cur_IPID = [(Start_IPID_For_This_Path) + (Counter_For_This_Path)mod32K]mod 64K Counter_For_This_Path = Counter_For_This_Path + 1
Wenn die abgeladene Verbindung entweder hinaufgeladen oder annuliert wird, übergibt die NIC 170 den nächsten IPID-Wert, den sie verwenden würde, an den Netzwerk-Layer, um ihn für das nächste Abladen, das stattfindet, zu speichern, und die Host-Prozessor-Einheit 120 fährt fort, den Teil des IP-ID-Namensraumes, der ihm zugewiesen war, zu verwenden. Die Host-Prozessor-Einheit 120 könnte den ganzen IP-ID-Namensraum verwenden, aber der Zähler müsste jedes Mal gesetzt werden, wenn ein Abladen stattfindet.
Die NIC 170 platziert Daten im Empfangspuffer in der Reihenfolge, wie die Daten empfangen werden, und füllt Anwendungspuffer in der Reihenfolge, wie sie für die abgeladene Verbindung bekannt gegeben wurden. Viele Anwendungen warten auf eine Empfangskennzeichnung, bevor sie einen Empfangspuffer bekannt geben. In einer Ausführungsform hat die NIC 170 einen globalen Pool an Puffern, um ihn zu verwenden, wenn Daten für eine Verbindung eintreffen und keine Anwendungs-Empfangspuffer bekannt gegeben wurden. Der globale Pool an Puffern wird quer durch die abgeladenen Verbindungen verwendet, um: 1) das Handhaben von defekten TCP-Übermittlungen; 2) das De-Fragmentieren von IP-Datagrammen; 3) einen Puffer-Kopier-Algorithmus eher als einen Null-Kopier-Algorithmus zu implementieren, wenn die Anwendung Puffer bekannt gibt, die zu klein sind für einen Null-Kopier-Algorithmus. Alternativ kann ein Pro-Verbindungs-Pool an Puffern verwendet werden, wenn die effiziente Verwendung von Ressourcen nicht von Belang ist. Der globale Pool an Puffern wird jedoch verwendet, wenn eine NIC einen Pro-Verbindungs-Pool an Puffern nicht unterstützt, oder für einen Mangel an System- Ressourcen (z.B. nicht genügend Ressourcen, um den Anwendungspuffer im Speicher festzustecken).
Nun auf die 5a-5d kommend, hat die NIC 170 einen umgekehrten Baum 500, der stellvertretend für das Abladen steht, sobald ein Abladen stattgefunden hat. In den Figuren stellen gepunktete Linien neue Stati dar, die durch die NIC 170 zugewiesen sind. In 5a hat die NIC 170 einen ARP-Eintrag 502, der mit einem Routen-Zwischenspeicher-Eintrag 504 (route cache entry) gekoppelt ist, der mit einem TCP-Eintrag 506 gekoppelt ist. Wenn z.B. der gesamte Verkehr zu einem Router geht, wird die nächste Etappe (hop) immer zu demselben ARP-Eintrag 502 sein. Wenn der Routenzwischenspeicher-Eintrag 504 für das nächste Abladen einer TCP-Verbindung verwendet wird, ist die einzige neue Ressource der neu abgeladene TCB. Wenn ein Abladen den Netzwerkstack 202 hinunter initiiert wird, würden die dazwischenliegenden Software-Layer, die ihren Status bereits abgeladen haben (z.B. Netzwerk-Layer 302 und Framing-Layer 304) deshalb einfach das von der NIC erzeugte Ablade-Handle einfügen, das bei einer vorherigen Ablade-Anfrage zugewiesen wurde. Die NIC 170 muss nur neue Ressourcen zuweisen (z.B. TCP-Eintrag 508) und Ablade-Handles für die neuen Ressourcen den Netzwerkstack 202 hinauf zurücksenden. Der umgekehrte Baum 500 hat jetzt einen TCP-Eintrag 508, gekoppelt mit dem Routen-Zwischenspeichereintrag 504 (siehe 5b). Dieser Ansatz spart NIC-Ressourcen und beschleunigt das Abladen. Zusätzlich muss nur eine einzelne Struktur aktualisiert werden, wenn ein zwischengespeicherter variabler Status sich ändert. Wenn alle Stati für die verschiedenen Software-Layer in dem Chimney als ein einzelner Eintrag abgeladen wären, würde jede unterhalb des höchsten Software-Layers liegende Status-Aktualisierung mehrere Aktualisierungen erfordern.
5C zeigt einen umgekehrten Baum 500 mit einer komplexeren Konfiguration. Es gibt zwei Routen-Zwischenspeicher-Einträge 504 und 510, die durch den ARP-Tabelleneintrag 502 gehen. Die TCP-Verbindungen 506 und 508 benutzen den Routen-Zwischenspeicher-Eintrag 504. Die TCP-Verbindungen 512 und 514 beziehen sich auf den Routen-Zwischenspeicher-Eintrag 510. Wenn irgendwelche ARP-Aktualisierungen auftreten (z.B. eine multi-homed Server-Schnittstelle schlägt fehl (fails over)), muss nur der Eintrag 502 aktualisiert werden. Dies ermöglicht potentiell Tausenden oder Hunderttausenden von Verbindungen im Fehlerfalle zu einer neuen Schnittstelle überzugehen (failed-over), wobei nur eine einzelne Aktualisierung der NIC 170 erforderlich ist. 5d zeigt zwei unabhängige umgekehrte Bäume (Einträge 502–508 und Einträge 510–516), die zu einem einzelnen umgekehrten Baum 500 vereinigt sind, nachdem eine Routen-Aktualisierung eingetreten ist. Vor der Routen-Aktualisierung ist der nächste Etappen-ARP-Eintrag für den Routen-Zwischenspeicher-Eintrag 510 der ARP-Tabellen-Eintrag 516. Nach der Routen-Aktualisierung ist der nächste Etappen-ARP-Tabellen-Eintrag der ARP-Tabellen-Eintrag 502. Die Verwendung von einem umgekehrten Baum ermöglicht deshalb, dass Routen-Aktualisierungen als eine einzelne Transaktion zu der NIC 170 bearbeitet werden, statt vielmehr Tausende oder Zehntausende von Aktualisierungen, wenn der Netzwerkstack-Status als ein einzelner Eintrag abgeladen wäre.
Mit Blick auf 6, sobald eine Verbindung zu der NIC 170 abgeladen worden ist, gibt es zwei Pfade zu der NIC 170. Der erste Pfad ist durch den NDIS-Minidriver 310 durch den Framing-Layer 304, den Netzwerk-Layer 302 und den Transport-Layer 300. Der zweite Pfad ist durch die abgeladene Verbindung 608, welche als Kamin (chimney) bezeichnet wird. Aus Sicht des Host-Computers ist für die zwei Pfade hinsichtlich der Kommunikation alles gleich. Die zwischengespeicherten Status-Variablen synchronisieren die zwei Pfade mit der Prozessor-Einheit 120, die die zwischengespeicherten Status-Variablen in der NIC 170 wie vorher angegeben aktualisiert. Das Aktualisieren der zwischengespeicherten Variablen ist durch die Pfeile 602, 604, 606 gekennzeichnet.
Wenn ein eingehendes Datenpaket ankommt, ermittelt die NIC 170, ob das eingehende Datenpaket durch den abgeladenen Pfad oder den nicht-abgeladenen Pfad (d.h. durch den NDIS-Pfad des NDIS-Minidrivers 310 und die Layer 304, 302, 300) geht. In einer Ausführungsform ermittelt die NIC 170 durch das Ausführen einer Hashing-Funktion über die Quell- und Ziel-TCP-Anschluss-Nummer, Quell- und Ziel-IP-Adresse und Protokoll-Typ, über welchen Pfad das eingehende Datenpaket gesendet wird. Wenn der Hash mit den Parametern der abgeladenen Verbindung übereinstimmt (d.h. eine Hash-Bucket-Chain wird entlanggegangen und es erfolgen exakte Übereinstimmungen aller Tupel der Verbindung), wird der Chimney 608 verwendet. Wenn der Hash nicht mit dem Hash-Index übereinstimmt, wird der nicht-abgeladene Pfad durch den Netzwerkstack 202 verwendet. Kontroll-Nachrichten, welche die zwischengespeicherten Stati aktualisieren, werden durch den Host behandelt. Das führt dazu, dass die NIC 170 keine Kontroll-Nachrichten außerhalb der abgeladenen Verbindung behandeln muss, wie z.B. ICMP, DNS und RIP-Nachrichten.
Die vorliegende Erfindung stellt einem Benutzer die Fähigkeit bereit, unter Verwendung bestehender Werkzeuge, wie z.B. Netstat, Statistiken zu erlangen, um eine Vielfalt von Informationen abzufragen, einschließlich aller Verbindungen auf dem Host, Verbindungsparametern wie z.B. dem Protokoll-Typ, Lokal- und Remote-Port und IP-Adress-Bindungen, Status der Verbindung, Prozess-ID etc. Statistiken werden entweder auf einer Pro-Layer-Basis oder einer Pro-Layer-Statusobjekt-Basis in der vorliegenden Erfindung erfasst. Innerhalb eines Layers können die Layer-Statusobjekte kopiert werden, um Statistiken über mehrere Layer-Statusobjekte zu erfassen. Zum Beispiel können Statistiken für den Netzwerk-Layer so aufgeteilt werden, dass die Statistiken für jedes Protokoll sind, das verwendet wird (z.B. IPv4 und IPv6). Statistiken zugehörig zu den CONST und CACHED-Status-Variablen werden durch den Host bereitgestellt, und Statistiken zugehörig zu den DELEGATED-Status-Variablen werden durch das Peripherie-Gerät 204 bereitgestellt. Wenn eine Anfrage gemacht wird, werden die Statistiken zugehörig zu den DELEGATED-Status-Variablen an die Statistiken zugehörig zu den CONST- und CACHED-Status-Variablen angehängt.
Es gibt auch eine Klasse mit Statistiken, die über die gesamte Gruppierung des Host-Layer-Status und des Peripherie-Geräte-Layer-Status, wie z.B. Paketzähler, summiert ist. Ein anderer Statistik-Typ ist eine Auflistung des Status einer Funktion in dem System (z.B. eine Auflistung des Status von jedem TCB in dem System). Die Statistiken für einen TCB sind die Kombination von Statistiken, die durch den Host verfolgt werden, und den Statistiken, die durch das Peripherie-Gerät verfolgt werden. Ebenso ist die Statistik für die Paketzählung die Summe der Host-Layer-Status-Statistik und der Peripherie-Geräte-Layer-Status-Statistik.
Ein Beispiel der Aufsplittung zwischen dem Host und dem Peripherie-Gerät 204 für einen TCP MIB (Management Information Base) ist unterhalb in Tabelle 1 dargestellt, und IPv4 MIB-Statistiken sind unterhalb in Tabelle 2 dargelegt. In den Tabellen ist die erste Spalte das Feld, die zweite Spalte kennzeichnet, ob das Peripherie-Gerät oder der Host-Netzwerkstack verantwortlich für das Verfolgen der Statistiken ist, und das dritte Feld gibt an, wie das Feld verfolgt wird. Statistiken, für die das Peripherie-Gerät verantwortlich ist, werden auf einer Pro-Layer-Status-Objekt-Basis verfolgt oder auf einer Pro-Layer-Basis. Pro-Layer, wie es hier verwendet wird, bedeutet, dass die Statistik Pro-Layer Pro-Peripheriegerät Pro-Protokoll verfolgt wird. Es ist jedoch zu beachten, dass, wenn die Statistik von dem Host-Status und dem Status von dem/den Peripherie-Gerät(en) aufgebaut wird, sie im Allgemeinen auf einer Pro-Protokoll-Basis dargelegt wird. Statistiken, die der Host-Netzwerkstack ohne das Abfragen des Peripherie-Gerätes erzeugen kann, werden als „der Stack hat vollständige Information" oder „nur durch Stack erledigt" kategorisiert. Die „Stack hat vollständige Information"-Kategorie kennzeichnet, dass das Peripherie-Gerät über die Statistik Bescheid weiß, aber die Statistik nicht verfolgt. Die „nur durch Stack erledigt"-Statistik kennzeichnet, dass das Peripherie-Gerät nicht über die Statistik Bescheid weiß. Adapter-Statistiken werden durch die normale NDIS-Schnittstelle abgefragt. Die Adapter-Statistiken schließen Variablen, wie z.B. gesendete Bytes, empfangene Bytes, etc. ein.
Tabelle 1 TCP MIB Statistics Split
Der ts_RtoAlgorithm ist ein Wert für einen Algorithmus, der verwendet wird, um den Timeout-Wert zu ermitteln, der für die Wiederübermittlung unbeantworteter Oktette verwendet wird. Der ts_RtoMin ist ein Wert für den Minimum-Wert, der durch eine TCP-Implementierung für den Wiederübermittlungs-Timeout zugelassen ist, der in Millisekunden gemessen wird. Der ts_RtoMax ist der Maximum-Wert, der durch eine TCP-Implementierung für den Wiederübermittlungs-Timeout zugelassen ist, der in Millisekunden gemessen wird. Der ts_MaxConn ist die Gesamtanzahl der TCP-Verbindungen, die unterstützt werden können. Der ts_ActiveOpens ist die Häufigkeit, dass TCP-Verbindungen einen direkten Übergang von dem CLOSED-Status zu dem SYN_SENT-Status gemacht haben. Der ts_PassiveOpens ist die Häufigkeit, dass TCP-Verbindungen einen direkten Übergang von dem LISTEN-Status zu dem SYN_RCVD-Status gemacht haben. Der ts_AttemptFails is die Häufigkeit, dass TCP-Verbindungen einen direkten Übergang entweder von dem SYN-SENT-Status oder dem SYN-RCVD-Status zu dem CLOSED-Status gemacht haben plus die Häufigkeit, dass TCP-Verbindungen einen direkten Übergang von dem SYN-RCVD-Status zu dem LISTEN-Status gemacht haben. Der ts_EstabRest ist die Häufigkeit, dass TCP-Verbindungen einen direkten Übergang entweder von dem ESTABLISHED-Status oder dem CLOSE-WAIT-Status zu dem CLOSED-Status gemacht haben. Der ts_CurrEstab ist die Häufigkeit, dass TCP-Verbindungen, für die der aktuelle Status entweder ESTABLISHED oder CLOSE-WAIT ist. Der ts_InSeg ist die Gesamtanzahl an empfangenen Segmenten, einschließlich jenen, die irrtümlicherweise empfangen wurden. Der ts_OutSegs ist die Gesamtanzahl von gesendeten Segmenten, einschließlich jenen auf aktuellen Verbindungen, aber ausschließlich jenen, die nur zurückgesendete Oktette beinhalten. Der ts_RetransSegs ist die Gesamtanzahl an wiederübermittelten Segmenten. Der ts_InErrs ist die Gesamtanzahl an irrtümlicherweise empfangenen Segmenten (z.B. schlechte TCP-Prüfsummen). Der ts_OutRsts ist die Anzahl von gesendeten TCP-Segmenten, die den RST-Kennzeichner beinhalten. Der ts_NumCons ist die Gesamtanzahl an TCP-Verbindungen, die aktuell existieren.
Tabelle 2 IPv4 MIB Statistics Split
Der ipsi_Forwarding ist ein Wert, der einen Hinweis darauf bietet, ob der Host als ein IP-Router in Bezug auf das Weiterleiten von Datagrammen agiert, die durch den Host empfangen wurden, aber nicht an diesen adressiert waren. Der ipsi_DefauItTTL ist der Vorgabe-Wert, der in das Time-To-Live-Feld des IP-Headers von Datagrammen eingefügt wurde, die dieser Einheit entstammen, wann immer ein TTL-Wert nicht durch das Transport-Layer-Protokoll geliefert wurde. Der ipsi_InReceives ist die Gesamtanzahl von Eingangs-Datagrammen, die von Schnittstellen empfangen wurden, einschließlich jenen, die irrtümlicherweise empfangen wurden. Der ipsi_InHdrErrors ist die Anzahl von Eingangs-Datagrammen, die aufgrund von Fehlern in ihren IP-Headers verworfen wurden, einschließlich schlechter Prüfsumme, falsch zugeordneter Versions-Nummer, anderer Format-Fehler, überschrittene Timeto-live, Fehler, die während der Bearbeitung ihrer IP-Optionen entdeckt wurden, etc. Der ipsi_InAddrErrors ist die Anzahl von Eingangs-Datagrammen, die wiederrufen wurden, weil die IP-Adresse in ihrem Zielfeld des IP-Headers keine gültige Adresse für das Empfangen bei dem Host war. Der ipsi_ForwDatagramms ist die Anzahl von Eingangs-Datagrammen, für die der Host nicht ihr endgültiges IP-Ziel war, woraufhin als Ergebnis ein Versuch gemacht wurde, eine Route zu finden, um sie zu dem endgültigen Ziel weiterzuleiten. Der ipsi_UnknownProtos ist die Anzahl von lokal adressierten Datagrammen, die erfolgreich empfangen wurden, aber aufgrund eines unbekannten oder nicht unterstützten Protokolls verworfen wurden. Der ipsi_InDiscards ist die Anzahl von Eingangs-IP-Datagrammen, für die keine Probleme entdeckt wurden, die sie von ihrer weiteren Bearbeitung abhalten, aber welche verworfen wurden (z.B. aufgrund eines Mangels an Pufferspeicherplatz). Der ipsi_InDelivers ist die Gesamtanzahl von Eingangs-Datagrammen, die erfolgreich zu IP-Benutzer-Protokollen übergeben wurden. Der ipsi_OutRequests ist die Gesamtanzahl von IP-Datagrammen, welche lokale IP-Benutzer-Protokolle (einschließlich ICMP) an IP, in Anfragen für eine Übertragung, geliefert haben. Der ipsi_RoutingDiscards ist die Anzahl von Routing-Einträgen, welche gewählt wurden, um verworfen zu werden, obwohl sie gültig sind. Der ipsi_OutDiscards ist die Anzahl von Ausgangs-IP-Datagrammen, für welche keine Probleme entdeckt wurden, um ihre Übermittlung zu ihrem Ziel zu verhindern, aber welche verworfen wurden (z.B. aufgrund eines Mangels an Pufferspeicherplatz). Der ipsi_OutNoRoutes ist die Anzahl von IP-Datagrammen, die verworfen wurden, weil keine Route gefunden werden konnte, um sie zu ihrem Ziel zu übermitteln. Der ipsi_ReasmTimeout ist die maximale Anzahl von Sekunden, die empfangene Fragmente gehalten werden, während sie auf das Wiederzusammenfügen bei dem Host warten. Der ipsi_ReasmReqds ist die Anzahl von empfangenen IP-Fragmenten, welche bei dem Host wieder zusammengefügt werden mussten. Der ipsi_ReasmOKs ist die Anzahl von erfolgreich wieder zusammengeführten IP-Datagrammen. Der ipsi_ReasmFails ist die Anzahl von Misserfolgen, die durch den IP-Wiederzusammenführungs-Algorithmus entdeckt wurden (z.B. durch Erreichen des Timeout, Fehlern, etc.). Der ipsi_FragOKs ist die Anzahl von IP-Datagrammen, die bei dem Host erfolgreich fragmentiert worden sind. Der ipsi_FragFails ist die Anzahl von IP-Datagrammen, die verworfen wurden, weil sie bei dem Host fragmentiert werden mussten, aber nicht konnten, z.B. weil deren Nicht-Fragmentieren-Kennzeichner (Don't Fragment flag) gesetzt war. Der ipsi_FragCreates ist die Anzahl von IP-Datagramm-Fragmenten, die als ein Ergebnis der Fragmentierung bei dem Host erzeugt worden sind. Der ipsi_Numlf ist die Gesamtanzahl von verwendbaren Schnittstellen. Der ipsi_NumAddr ist die Gesamtanzahl von eindeutigen IP-Adressen in dem System. Der ipsi_NumRoutes ist die Gesamtanzahl von aktuell aktiven Routen.
Die vorliegende Erfindung stellt auch ein Verfahren zum Hinaufladen einer abgeladenen Netzwerkverbindung von dem Peripherie-Gerät zum dem Host bereit. Es gibt viele Gründe, warum ein Hinaufladen stattfindet. Als Beispiel, aber nicht Einschränkung, werden unterhalb manche der Gründe bereitgestellt. Die Route kann sich geändert haben, was es erfordert, Datenverkehr auf einer unterschiedlichen Schnittstelle zu senden. Das Verhalten von Datenverkehr einer Verbindung kann sich ändern, so dass sie nicht länger zum Abladen geeignet ist. Zum Beispiel kann es zu wenig Datenverkehr geben, einen Mangel an Aktivität geben oder die Verbindung ist für länger als eine festgesetzte Zeit flussgesteuert (z.B. es werden keine Fenster-Aktualisierungen empfangen). Zusätzlich kann das Peripherie-Gerät nicht in der Lage sein, eine bestimmte Funktion zu unterstützen, das Datenverkehrverhalten kann ungeeignet zum Abladen sein, wenn es zu viele IP-Fragmente gibt, zuviel gestörten Datenverkehr gibt, Verwendung von bandexternen Daten gibt, zu viele Wiederübermittlungen gibt, ein Keep-alive-Timeout wird erreicht, eine Sicherheitsverbindung wird ungültig und wird nicht erneuert oder zu viele Daten werden zu dem Peripherie-Gerät weitergeleitet. Andere Gründe zum Hinaufladen einer abgeladenen Verbindung beruhen auf Ressourcen-Problemen. Zum Beispiel kann das Peripherie-Gerät einen Mangel an Ressourcen haben, um mit dem Verarbeiten der Verbindung(en) fortzufahren. Eine andere Verbindung kann eine höhere Priorität als die abgeladene Verbindung haben, und das Hinaufladen einer Verbindung kann es der Verbindung mit höherer Priorität ermöglichen, mit Verwendung von Peripherie-Gerät-Ressourcen fortzufahren, wenn die Verfügbarkeit von Peripherie-Gerät-Ressourcen unterhalb eines Grenzwertes ist.
System-Ressourcen können sich verändert haben, so dass der Host-Prozessor Ressourcen hat, um eine abgeladene Verbindung zu bewältigen. Der Chimney kann unterschiedliche Ressourcen als das ursprüngliche Abladen erfordern (z.B. ein Wechsel des Sicherheitsfilters etc.). Der Host kann ermitteln, wenn sich die Ressourcen des Peripherie-Gerätes Grenzwert-Labeln annähern, wo eine abgeladene Verbindung durch die Host-Prozessor-Einheit effizienter bearbeitet würde. Zum Beispiel kann der Grenzwert die Datenverkehrsgröße (Anzahl von Bytes oder Paketen), die Anzahl von Fragmenten, Fenstergröße und Abladetyp einschließen.
Mit Bezug nun auf 7 ist das Hinaufladen entweder durch das Peripherie-Gerät 204 (z.B. die NIC 170) oder den TLI-Switch 306 initiiert. Die Verbindung kann aufgrund einer Vielfalt von Gründen hinaufgeladen werden. Die Gründe schließen ein, dass die Verbindung zu einem anderen Peripherie-Gerät geht, das Auftreten einer Trennung eines Mediums, zu viele defekte Segmente, zu viele Daten werden zu dem Peripherie-Gerät 204 weitergeleitet, die Anwendung 200 gibt im Voraus keine Zwischenspeicher bekannt (pre-posting), zu viele IP-Fragmente, eine Verbindung mit geringer Bandbreite, und zu viele Wiederübermittlungen.
7 zeigt, dass das Hinaufladen durch den TLI-Switch 306 ausgelöst ist (Linie 700). Es ist zu beachten, dass die Linie 700 nicht da wäre, wenn die NIC 170 das Hinaufladen auslöst. Sobald das Hinaufladen ausgelöst ist, beendet die NIC 170 alle ausstehenden Anfragen mit entsprechendem Status und übergibt den übertragenen Transport-Layer-Status zu dem Switch-Layer (Linie 702). Die NIC 170 kann eine Übertragung nicht beenden oder einen Empfangszwischenspeicher nicht vollständig füllen. Die NIC 170 stellt gerade sicher, dass der gesamte Übermittlungs- und Empfangs-Status mit dem übertragenen Status synchronisiert ist, der zu dem Transport-Layer 300 zurück übergeben wird. Der TLI-Switch 306 stellt alle weiteren Übertragungsanfragen in eine Schlange und stoppt das Bekanntgeben von Empfangspuffern. Der TLI-Switch 306 befiehlt dem Transport-Layer, die Kontrolle über den übertragenen Transport-Status zu übernehmen (Linie 704. Der Transport-Layer 300 stoppt das Weiterleiten irgendwelcher Segmente zu der NIC 170, die er empfängt, und übernimmt die Kontrolle des übertragenen Status und sendet eine Abschluss-Nachricht zu dem TLI-Switch 306 (Linie 706). Nachdem der TLI-Switch 306 eine Bestätigung empfängt, dass der Transport-Layer 300 die Kontrolle über den übertragenen Transport-Status übernommen hat, bestätigt der TLI-Switch 306 das Hinaufladen an die NIC 170 (Linie 708), was die NIC 170 befähigt, Ressourcen frei zu geben. Der Transport-Layer 300 informiert auch den Netzwerk-Layer 302 über das Hinaufladen der Verbindung, bevor oder nachdem die Abschluss-Nachricht an den TLI-Switch 306 gesendet wird (Linie 710).
Es sollte beachtet werden, dass der Transport-Layer 300 eingehende Datenpakete für die abgeladene Verbindung zu der NIC 170 zur Verarbeitung weiterleitet, bis er die Kontrolle über den übertragenen Status übernimmt (Linie 706). Datenpakete können zwischen der Zeit, zu der die NIC 170 den übertragenen Status an den TLI-Switch 306 über gibt (Linie 702), und der Zeit, zu der der Transport-Layer 300 die Kontrolle über den übertragenen Status übernimmt (Linie 706), ankommen. Sobald die NIC 170 den übertragenen Status zu dem TLI-Switch 306 übergibt, kann sie nicht länger eingehende Datenpakete bearbeiten. Wenn die NIC 170 ein eingehendes Datenpaket für die hinaufzuladende Verbindung empfängt, sendet sie eine Fehlermeldung an den Transport-Layer 300, die angibt, dass ein Hinaufladen im Gange ist, und kann das eingehende Paket verwerfen. Die Fehlermeldung informiert den Transport-Layer 300, das Weiterleiten eingehender Daten zu stoppen. In einer Ausführungsform speichert der Transport-Layer 300 weitere Daten zwischen, bis er den übertragenen Status empfängt.
Mehrere Verbindungen können durch dazwischenliegende Software-Layer zu dem Peripherie-Gerät abgeladen sein. Ein Referenz-Zähler mit der Anzahl von Verbindungen, die von dem dazwischenliegenden Software-Layer zu dem Peripherie-Gerät abgeladen sind, wird durch den dazwischenliegenden Software-Layer geführt. Wenn die Referenzzahl auf Null geht, wird eine Anfrage zum Hinaufladen zu dem nächsten dazwischenliegenden Software-Layer erzeugt. Dies führt zu einem Dekrementieren des Referenz-Zählers des nächsten Layers. Die Anfrage zum Hinaufladen fährt den Netzwerkstack 202 weiter runter, wenn die Referenzzahl des nächsten Layers auf Null geht. Dieser Prozess wiederholt sich, bis entweder die Referenzzahl eines dazwischenliegenden Software-Layers nicht auf Null steht oder das Peripherie-Gerät eine Anfrage zum Hinaufladen empfängt. Der Netzwerk-Layer 302 dekrementiert eine Referenzzahl der Anzahl von abgeladenen Statusobjekten zugehörig zu der NIC 170. Wenn die Referenzzahl auf Null geht, verwenden keine TCBs die Ressourcen, die in der NIC 170 für den Netzwerk-Layer 302 zugewiesen sind. Wenn die Referenzzahl auf Null geht, sendet der Netzwerk-Layer 302 eine Nachricht an die NIC 170, um das Statusobjekt für den Netzwerk-Layer 302 hinaufzuladen und um Variablen des übertragenen Netzwerk-Status zu dem Netzwerk-Layer 302 zu senden (Linie 712). Die NIC 170 löscht den Status und sendet Variablen des übertragenen Netzwerkstatus und den nächsten IPID-Wert, den die NIC 170 verwendet hätte, zu dem Netzwerk-Layer 302 (Linie 714). Der Netzwerk-Layer 302 speichert diese Information, um sie als Eingangswert zu verwenden, wenn eine Verbindung wieder abgeladen wird. Der Netzwerk-Layer 302 sendet auch eine Nachricht an den Framing-Layer 304, um den Framing-Layer 304 zu veranlassen, seine Referenzzahl zu dekrementieren (Linie 716).
Der Framing-Layer 304 führt auch eine Referenzzahl und dekrementiert seine Referenzzahl, wenn die Nachricht von dem Netzwerk-Layer 302 empfangen wird. Wenn die Referenzzahl in dem Framing-Layer 304 auf Null geht, sendet der Framing-Layer eine Nachricht an die NIC 170, um den Status des Framing-Layer zu löschen (Linie 718). Die NIC 170 löscht die Status-Variablen in der NIC 170 und sendet irgendwelche Variablen des übertragenen Status, die sie besitzt, zu dem Framing-Layer (Linie 120). Der Framing-Layer 304 sendet eine Abschluss-Nachricht an den Netzwerk-Layer 302 (Linie 722), und der Netzwerk-Layer 302 sendet eine Abschluss-Nachricht an den Transport-Layer (Linie 724).
Eine TCP-Verbindung kann erforderlich sein, um eine sichere Verbindung unter Verwendung von Sicherheitsprotokollen, wie z.B. IPSEC zu jedem Zeitpunkt ihrer Lebensdauer, zu verwenden. Wenn eine Verbindung IP sicher ist und das Peripherie-Gerät 204 die Sicherheit nicht handhaben kann, kann die Verbindung nicht abgeladen werden. Wenn eine sichere IP-Verbindung abgeladen wird, wird der Status der Sicherheitsverbindung(en) in CONST-, CACHED- und DELEGATED-Variablen geteilt und werden, wie vorher beschrieben, behandelt. Die Host-Prozessor-Einheit 120 verwaltet Kontroll-Nachrichten, wie z.B. eine neue Verhandlung von Schlüsseln. Das Peripherie-Gerät 204 führt alle notwendigen IPSEC-Daten-Funktionen unter Verwendung der Variablen des Sicherheitsverbindungsstatus aus.
Mit Bezug nun auf 8 werden die Schritte zum Abladen einer sicheren Verbindung dargestellt. In der folgenden Beschreibung bleiben die Schritte, die vorher beschrieben wurden und in 4 gezeigt sind, die gleichen und werden nicht wiederholt. Eine IPSEC-Verbindung, die in dem Transport-Modus arbeitet, soll zum Zweck der Darstellung verwendet werden. Ein Abladen eines IPSEC-Layers beginnt, wenn der Transport-Layer 300 eine Anfrage zum Abladen zu dem IPSEC-Layer 800 mit TCP-Ressource-Informationen, die zu den TLI-Switch-Ressource-Informationen hinzugefügt sind, sendet (Linie 402'). Der IPSEC-Layer 800 sendet eine Anfrage zum Abladen zu dem Netzwerk-Layer 302 mit IPSEC-Ressource-Erfordernissen, hinzugefügt zu den TCP-Ressource-Informationen und den TLI-Switch-Ressource-Informationen (Linie 802). Die Ressource-Erfordernisse schließen die Anzahl der Sicherheitsverbindungen, die der IPSEC-Layer abladen möchte, ein. Wenn die NIC die Anfrage zum Abladen akzeptiert, teilt sie Ressourcen zum Behandeln der Sicherheitsverbindungen zu. Der Netzwerk-Layer 302 sendet eine Ab schluss-Nachricht zu dem IPSEC-Layer anstatt zu dem Transport-Layer 300, die eine verknüpfte Liste mit Parametern und die Versandtabelle beinhaltet (Linie 804).
Wenn der IPSEC-Layer 800 die Abschluss-Nachricht empfängt, sendet er die IPSEC-Layer-Stati als Teil von Eingangs-Deskriptoren und Ausgangs-Deskriptoren zu der NIC 170 wenn der Status nicht vorher abgeladen worden ist, und übergibt den Besitz des übertragenen Status in der Sicherheitsverbindung an die NIC 170 (Linie 806). Wenn der Status vorher abgeladen worden ist, erhöht der IPSEC-Layer eine Referenzzahl. Sobald der Besitz übertragen worden ist, entschlüsselt und verschlüsselt die NIC 170 alle Pakete. Der IPSEC-Layer 700 sendet eine Abschluss-Nachricht, die die verknüpfte Liste mit Parametern und die Versandtabelle beinhaltet, an den Transport-Layer (Linie 414').
Die CONST-Status-Variablen, die von dem IPSEC-Layer 800 zu der NIC 170 übergeben wurden, bestehen aus Informationen, die benötigt werden, um Pakete zu einer bestimmten Sicherheitsverbindung und Informationen spezifisch für Eingangs- und Ausgangs-Sicherheitsverbindungen einzuteilen. Die CONST-Variablen schließen Quell- und Ziel-Port, Protokolltyp und Sicherheitsverbindungs-Variablen ein.
Die CACHED-Status-Variablen umfassen Faktoren zum Festsetzen der Lebensdauer der Sicherheitsverbindung und Informationen spezifisch für Eingangs- und Ausgangs-Sicherheitsverbindungen. Die CACHED-Variablen enthalten eine weiche Grenze (soft limit) (z.B. ein rekey on byte count) und eine feste Grenze (hard limit) (z.B. ein stop on byte count) basierend auf den verschlüsselten Bytes, ein soft limit (z.B. rekey bei einem vordefinierten tick) und ein hard limit (z.B. stop bei einem vordefinierten tick) auf die maximale Zeit, die die Sicherheitsverbindung verwendet werden kann, und ein hard limit (z.B. maximale Leerlauf-Ticks – maximum idle ticks) auf die maximale Leerlaufzeit, für die eine Sicherheitsverbindung verwendet werden kann. Die NIC 170 hält die soft und hard limits ein. Wenn ein soft limit erreicht wird, informiert die NIC 170 die Host-Prozessor-Einheit 120. Wenn ein hard limit erreicht wird, verwirft die NIC 170 die Sicherheitsverbindung.
Die DELEGATED-Variablen umfassen laufende Informationen und Informationen spezifisch für Eingangs- und Ausgangs-Sicherheitsverbindungen. Die DELEGATED-Variablen enthalten einen Zähler der Bytes, die mit der Sicherheitsverbindung verschlüs selt oder entschlüsselt werden, die Lebensdauer der Sicherheitsverbindung und die Leerlaufzeit der Sicherheitsverbindung.
Mit Bezug nun auf 9 wird das Hinaufladen einer abgeladenen Netzwerkverbindung mit IPSEC von dem Peripherie-Gerät zu dem Host dargestellt. In der folgenden Beschreibung bleiben die vorher beschriebenen Schritte, die in 7 gezeigt sind, die gleichen und sollen nicht wiederholt werden. Der Transport-Layer 300 informiert den IPSEC-Layer 800 über die hinaufzuladende Verbindung, bevor oder nachdem die Abschluss-Nachricht an den Switch-Layer 306 gesendet wurde (Linie 710'). Die Referenzzahl zugehörig zu allen Sicherheitsverbindungen wird dekrementiert. Wenn keine Referenzzahl auf Null geht, sendet der IPSEC-Layer 800 eine Abschluss-Nachricht an den Transport-Layer 300 (Linie 724'). Wenn die Verbindung, die abgeladen ist, die letzte Verbindung ist, die eine bestimmte Sicherheitsverbindung verwendet, sendet der IPSEC-Layer 800 eine Nachricht an die NIC 170, um die Variablen des übertragenen Status an den IPSEC-Layer 800 hinaufzuladen (Linie 900). Die NIC 170 gibt die Variablen des übertragenen Status an den IPSEC-Layer 800 zurück (Linie 902). Die NIC 170 hört auf, die Sicherheitsverbindung zu verwenden, und sendet Pakete, die der Sicherheitsverbindung gehören, zu dem IPSEC-Layer 800 durch den Stack 202. Der IPSEC-Layer 800 sendet eine Abschluss-Nachricht zu der NIC 170, und die NIC 170 setzt die Ressourcen frei, die der Sicherheitsverbindung zugeordnet waren (Linie 904).
Wenn die Referenzzahl der Sicherheitsverbindung auf Null geht, sendet der IPSEC-Layer 800 auch eine Nachricht zu dem Netzwerk-Layer 302, die den Netzwerk-Layer 302 über den hinaufgeladenen Status informiert (Linie 906). Nachdem der Framing-Layer 304 eine Abschluss-Nachricht zu dem Netzwerk-Layer 302 gesendet hat (Linie 722), sendet der Netzwerk-Layer 302 eine Abschluss-Nachricht zu dem IPSEC-Layer (Linie 908). Der IPSEC-Layer 800 sendet eine Abschluss-Nachricht zu dem Transport-Layer (Linie 724').
Wenn die Stati für den Transport-Layer 300, Netzwerk-Layer 302, Framing-Layer 304 oder IPSEC-Layer 800 abgeladen sind, ist es möglich, dass eine Aktualisierung (z.B. ARP-Aktualisierung oder RIP-Aktualisierung) eintreffen könnte. Wenn die Aktualisierung passiert, bevor die Abschluss-Nachricht empfangen wurde, wird der lokale Status einfach aktualisiert und ein Kennzeichner (flag) wird gesetzt, um anzugeben, dass der Status sich geändert hat, wenn das Statusobjekt mit der Anfrage zum Abladen gesendet wurde.
Es besteht ein möglicher Wettbewerb, wenn die Aktualisierung passiert, während die Routine der NIC-Aktualisierung aufgerufen wird, die die zwischengespeicherten Stati aktualisiert. Wenn eine getrennte Nachricht dann den Status aktualisiert, die verursacht, dass die Routine der NIC-Aktualisierung aufgerufen wird, ist es möglich, dass die NIC den zweiten Aufruf aufgrund von Zeitplanproblemen zuerst sieht, und endet an einem Punkt, wo abgelaufene Daten verwendet werden, wenn die ursprüngliche Aktualisierung eintrifft. Wenn abgelaufene Daten verwendet werden, würde der falsche Eintrag verwendet werden, bis die nächste Aktualisierung eintrifft, was dazu führen könnte, dass eine große Menge Daten entweder zu der falschen Stelle gesendet werden oder fallengelassen werden. Es gibt zwei mögliche Lösungen für diesen Wettbewerbszustand. Die erste mögliche Lösung ist, dass die Abschluss-Nachricht immer die zweite Aktualisierung ausführt, was zu Rekursionsproblemen führen kann, wenn eine große Anzahl von Aktualisierungen hereinkommt. Die zweite mögliche Lösung ist das Hinzufügen einer Laufnummer zu der Aktualisierung, um sicherzustellen, dass immer die neueste Laufnummer verwendet wird.
Ein anderer Arbeitsmodus, den IPSEC unterstützt, ist Tunneling, wo Datenpakete in einem neuen Paket als Teil einer Sicherheitsverbindung verkapselt werden. Ein Tunnel erscheint dem Netzwerkstack 202 als eine virtuelle Schnittstelle. Die Schritte zum Abladen eines IPSEC-Tunnels sind ähnlich zu den Schritten zum Abladen einer IPSEC-Verbindung in dem Transport-Modus. In dem Transport-Modus wird ein IPSEC-Header zwischen dem IP-Header und dem TCP-Header platziert. In dem Tunnel-Modus wird UDP verwendet, um einen Tunnel bereitzustellen. Die Header-Kette (header chain) ist TCP-Header zu IPSEC-Header zu UDP-Header zu IP-Header zu Framing-Layer-Header. Um einen Tunnel aufzubauen, werden ein Eingangs-Deskriptor und ein Ausgangs-Deskriptor, die die ausgehandelte Sicherheitsverbindung beschreiben, zu dem Peripherie-Gerät gesendet. Die Diskriptoren enthalten die Status-Variablen für die Verbindung und andere Informationen, die erforderlich sind, um die Verbindung herzustellen. Die Variablen des CACHED- und DELEGATED-Status für einen Tunnel sind dieselben wie die Variablen des Transport-Modus CACHED- und DELEGATED-Status. Die Variablen des CONST-Status für einen Tunnel enthalten Quell- und Ziel-Port, lokale Adresse, Remote-Adresse, Protokolltyp und Sicherheitsverbindungs-Variablen.
Ein Verfahren zum Abladen und Hinaufladen von Netzwerkstack-Verbindungen zu einem Peripherie-Gerät wurden beschrieben, die eine enge Synchronisation mit der Host- Prozessor-Einheit beibehalten. Das Verfahren kann mit vielen Protokollen verwendet werden. Protokolle, die verwendet werden können, schließen z.B. TCP, SCTP etc. ein.
Angesichts der vielen möglichen Ausführungsformen, zu denen die Grundsätze dieser Erfindung angewandt werden können, sollte es erkannt werden, dass die hier mit Bezug auf die Figuren beschriebenen Ausführungsformen nur illustrativ gemeint sind und sollten nicht zum Eingrenzen des Umfangs der Erfindung verwendet werden. Zum Beispiel werden Fachleute erkennen, dass die Elemente der dargestellten Ausführungsformen, die in Software gezeigt sind, in Hardware implementiert werden können und umgekehrt, oder dass die dargestellten Ausführungsformen in ihrer Anordnung und Einzelheit verändert werden können. Die Erfindung wie hier beschrieben, zieht deshalb all solche Ausführungsformen in Erwägung, wie sie in den Umfang der folgenden Ansprüche und Entsprechungen davon fallen.

Claims

Verfahren zum Betreiben eines Host-Computer-System, das mit einem Peripheriegerät (170, 204) verbunden ist, um ein Statusobjekt des Netzwerkstack und mindestens einen zugehörigen Protokollstack von einem ersten Pfad, der durch eine Vielzahl von Softwarelayern (206, 300-304) zu einem Peripheriegerät geht, zu einem zweiten Pfad (210, 308), der von einem Switchlayer (208, 306) zu dem Peripheriegerät geht, abzuladen, wobei die Vielzahl der Softwarelayer hostbasiert ist, wobei der Switchlayer auf dem höchsten Zwischenlayer eines hostbasierten Netzwerkstack ist oder in den höchsten Zwischenlayer eines hostbasierten Netzwerkstack integriert ist, um zu steuern, ob Daten durch den ersten Pfad oder durch den zweiten Pfad zu dem Peripheriegerät gesendet werden, und wobei das Statusobjekt des Netzwerkstack eine zwischengespeicherte Statusvariable und eine konstante Statusvariable und/oder eine übertragene Statusvariable besitzt, wobei das Verfahren die folgenden Schritte umfasst: Senden (402', 400-406, 802) einer Anfrage, um das Statusobjekt des Netzwerkstack von dem Switchlayer zu dem Peripheriegerät durch die Vielzahl von Softwarelayern abzuladen, wobei die Anfrage eine Liste mit Ressourcenanforderungen besitzt; wenn das Statusobjekt des Netzwerkstack abgeladen wird: Empfangen (408, 412, 414', 416, 420, 804) eines Offload-Handle bei mindestens einem der Vielzahl von Softwarelayern; Senden (410, 414, 418, 806) des Statusobjekts des Netzwerkstack von dem mindestens einem der Vielzahl von Softwarelayern zu dem Peripheriegerät; und Übertragen (422) von Pufferspeichern von dem Switchlayer an das Peripheriegerät.
Verfahren nach Anspruch 1, wobei mindestens einer der Vielzahl von Softwarelayern Ressourcenanforderungen des Layer zu der Liste mit Ressourcenanforderungen hinzufügt.
Verfahren nach Anspruch 1, des Weiteren den Schritt des Empfangens von mindestens einer ersten Versandtabelle von dem Peripheriegerät umfassend.
Verfahren nach Anspruch 3, wobei die mindestens eine erste Versandtabelle eine Versandtabelle des Protokollstack für den gesamten Netzwerkstack und/oder eine Layer-Versandtabelle für einen der Vielzahl von Softwarelayern umfasst.
Verfahren nach Anspruch 3, des Weiteren den Schritt des Sendens von einer zweiten Versandtabelle zu dem Peripheriegerät umfassend.
Verfahren nach Anspruch 5, des Weiteren den Schritt des Anstückens der ersten Versandtabelle und der zweiten Versandtabelle umfassend, um mindestens einen Softwarelayer hinzuzufügen, um mindestens eine Funktion auszuführen.
Verfahren nach Anspruch 6, wobei der mindestens eine Softwarelayer eine hinzugefügte Funktion, eine Leistungsdiagnose, und/oder eine Funktionsdiagnose ausführt.
Verfahren nach Anspruch 1, des Weiteren die folgenden Schritte umfassend: Ermitteln, durch jeden der Vielzahl von Softwarelayern, ob ein vorheriger Offload stattgefunden hat; und wenn der vorherige Offload stattgefunden hat: Senden des Offload-Handle zu dem Peripheriegerät.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein TCP-Layer ist, und wobei die konstante Variable ein Ziel-Port, ein Ausgangs-Port, ein Fensterskalierfaktor, und/oder der Offload-Handle ist.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein TCP-Layer ist, und wobei die zwischengespeicherte Variable eine TCP-Variable und/oder eine IP-Variable einschliesst.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein TCP-Layer ist, und wobei die übertragene Variable einen aktuellen TCP-Status, eine receive window size, eine Laufnummer für ein nächstes RECV, ein maximum send window, ein aktuelles congestion window, eine maximale gesendete Laufnummer und/oder eine Laufnummer für ein nächstes SEND einschliesst.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein Netzwerk-Layer (302) ist, und wobei die konstante Variable eine Empfänger-IP-Adresse und/oder eine Quell-IP-Adresse einschliesst.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein Netzwerk-Layer (302) ist, und wobei die zwischengespeicherte Variable den Offload-Handle zum einem nächsten Layer einschliesst.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein Netzwerk-Layer (302) ist, und wobei die übertragene Variable einen id-Startwert eines IP-Pakets, eine lokale Adresse, und eine Remote-Adresse einschliesst.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein Framing-Layer (304) ist, und wobei die zwischengespeicherte Variable eine ARP-Adresse einschliesst.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein IP-Sicherheits-Layer (800) ist, und wobei die konstante Variable einen Quell-Port, einen Empfangs-Port, einen Protokolltyp, eine lokale IP-Adresse, eine Remote-IP-Adresse und/oder Sicherheits-Zuordnungs-Variablen einschliesst.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein IP-Sicherheits-Layer (800) ist, und wobei die zwischengespeicherte Variable einen rekey on byte count, einen stop on byte count, einen rekey at a predefined tick, einen stop at a predefined tick und/oder eine maximale Leerlaufzeit, für welche eine Sicherheitszuordnung verwendet werden kann, einschliesst.
Verfahren nach Anspruch 1, wobei einer aus der Vielzahl von Softwarelayern ein IP-Sicherheits-Layer (800) ist, und wobei die übertragene Variable einen Zähler der verschlüsselten oder entschlüsselten Bytes, eine restliche Lebensdauer der Sicherheitszuordnung und/oder eine restliche Leerlaufzeit der Sicherheitszuordnung einschliesst.
Verfahren nach Anspruch 1, wobei ein Host-Gerät (120) die zwischengespeicherte Variable bearbeitet und dem Peripheriegerät befiehlt, die zwischengespeicherte Variable zu aktualisieren (602-606), wenn eine Variable in dem zwischengespeicherten Status sich ändert.
Verfahren nach Anspruch 1, des Weiteren den Schritt des Sendens einer Aktualisierungsnachricht zu dem Peripheriegerät umfassend, um mindestens eine zwischengespeicherte Variable zu aktualisieren (602-606).
Verfahren nach Anspruch 20, des Weiteren den Schritt des Hinzufügens einer Laufnummer zu der Aktualisierungsnachricht umfassend.
Verfahren nach Anspruch 1, des Weiteren den Schritt des Sendens von Daten durch die Vielzahl von Softwarelayern umfassend, bis eine Offload-Abschlussnachricht empfangen wurde, so dass die Pufferspeicher zu dem Peripheriegerät übertragen worden sind.
Verfahren nach Anspruch 1, des Weiteren den Schritt des Blockierens von zusätzlichen Offload-Anfragen für einen aus der Vielzahl von Softwarelayern umfassend, wenn eine bestimmte Struktur für den einen aus der Vielzahl von Softwarelayern abgeladen wird, bis die Offload-Anfrage abgeschlossen ist.
Verfahren nach Anspruch 1, des Weiteren den Schritt des Entscheidens, ob das Statusobjekt des Netzwerkstack abgeladen wird, durch mindestens einen aus der Vielzahl von Softwarelayern, umfassend.
Verfahren nach Anspruch 1, des Weiteren den Schritt des Ermittelns, ob die Offload-Anfrage gesendet wird, umfassend.
Verfahren nach Anspruch 25, wobei der Schritt des Ermittelns, ob die Offload-Anfrage gesendet wird, einschliesst: Auswählen eines bestimmten Service zum Abladen; Ermitteln, ob eine Anzahl von Bytes und/oder eine Anzahl von Paketen zugehörig zu dem Statusobjekt des Netzwerkstack eine signifikante Menge an Host-Ressourcen verbraucht; Ermitteln, ob eine Richtlinie es erfordert, dass ein Offload stattfindet; und/oder Ermitteln, ob eine Prozessorauslastung, Verwendung eines Daten-Puffers, Verwendung eines Page-Table-Puffers und/oder Verwendung einer Speicherbandbreite über einem Grenzwert liegt.
Verfahren nach Anspruch 1, des Weiteren den Schritt des Zuweisens eines Teils eines gesamten IP-ID-Raums an das Peripheriegerät umfassend.
Verfahren nach Anspruch 27, wobei der Schritt des Zuweisens des Teils des gesamten IP-ID-Raums den Schritt des Zuweisens von ungefähr einer Hälfte des gesamten IP-ID-Raums an das Peripheriegerät umfasst.
Verfahren nach Anspruch 28, des Weiteren den Schritt des Erzeugens einer IP-ID für ein Paket gemäss der Gleichung umfassend: Cur_IPID = [(Start_IPID_For_This_Path)] + (Counter_For_This_Path) mod 32K] mod 64K Counter_For_This_Path = Counter_For_This_Path + 1.
Computer-lesbares Medium, das Computer-ausführbare Instruktionen zum Ausführen der Schritte von Anspruch 1 besitzt.
Computer-lesbares Medium nach Anspruch 30, das des Weiteren Computerausführbare Instruktionen zum Ausführen der folgenden Schritte besitzt, wobei die Schritte umfassen: Empfangen von mindestens einer ersten Versandtabelle von dem Peripheriegerät; und Senden einer zweiten Versandtabelle zu dem Peripheriegerät.
Computer-lesbares Medium nach Anspruch 30, das des Weiteren Computerausführbare Instruktionen zum Ausführen des Schritts besitzt, wobei der Schritt das Bearbeiten der zwischengespeicherten Variable und das Befehlen an das Peripheriegerät, die zwischengespeicherte Variable zu aktualisieren (602-606), wenn eine Variable in dem zwischengespeicherten Status sich ändert, umfasst.
Verfahren zum Betreiben eines Peripheriegeräts (170, 204), das mit einem Host-Computer-System verbunden ist, um ein Statusobjekt des Netzwerkstack von einem ersten Pfad, der durch eine Vielzahl von Softwarelayern (206, 300-304) zu dem Peripheriegerät geht, zu einem zweiten Pfad (210, 308), der von einem Switchlayer (208, 306) zu dem Peripheriegerät geht, abzuladen, wobei die Vielzahl der Softwarelayer hostbasiert ist, wobei der Switchlayer auf dem höchsten Zwischenlayer eines hostbasierten Netzwerkstack ist oder in den höchsten Zwischenlayer eines hostbasierten Netzwerkstack integriert ist, um zu steuern, ob Daten durch den ersten Pfad oder durch den zweiten Pfad zu dem Peripheriegerät gesendet werden, und wobei das Statusobjekt des Netzwerkstack eine zwischengespeicherte Statusvariable und eine konstante Statusvariable und/oder eine übertragene Statusvariable besitzt, wobei das Verfahren die folgenden Schritte umfasst: Empfangen (400-406, 402', 802) einer Anfrage, um das Statusobjekt des Netzwerkstack von dem Switchlayer abzuladen, wobei die Anfrage eine Liste mit Ressourcenanforderungen besitzt; Entscheiden, ob das Statusobjekt des Netzwerkstack abgeladen wird; wenn das Statusobjekt des Netzwerkstack abgeladen wird: Zuweisen von Ressourcen; Übergeben (408, 412, 414', 416, 420, 804) eines Offload-Handle an mindestens einen aus der Vielzahl von Softwarelayern; Empfangen (410, 414, 418, 806) des Statusobjekts des Netzwerkstack von dem mindestens einem der Vielzahl von Softwarelayern zu dem Peripheriegerät; und Empfangen (422) von Pufferspeichern von dem Switchlayer.
Verfahren nach Anspruch 33, des Weiteren den Schritt des Empfangens einer Versandtabelle von dem Switchlayer umfassend.
Verfahren nach Anspruch 33, des Weiteren den Schritt des Sendens einer Versandtabelle an den Switchlayer umfassend.
Computer-lesbares Medium, das Computer-ausführbare Instruktionen zum Ausführen der Schritte von Anspruch 33 besitzt.
Computer-lesbares Medium nach Anspruch 36, das des Weiteren Computerausführbare Instruktionen zum Ausführen der folgenden Schritte besitzt, wobei die Schritte umfassen: Empfangen einer ersten Versandtabelle von dem Switchlayer; und Senden einer zweiten Versandtabelle zu dem Switchlayer.
Verfahren zum Betreiben eines Host-Computer-System, das mit einem Peripheriegerät (170, 204) verbunden ist, um einen Protokollstack von einem ersten Pfad, der durch eine Vielzahl von Softwarelayern (206, 300-304) zu einem Peripheriegerät geht, zu einem zweiten Pfad (210, 308), der von einem Switchlayer (208, 306) zu dem Peripheriegerät geht, abzuladen, wobei die Vielzahl der Softwarelayer hostbasiert ist, wobei der Switchlayer auf dem höchsten Zwischenlayer eines hostbasierten Netzwerkstack ist oder in den höchsten Zwischenlayer eines hostbasierten Netzwerkstack integriert ist, um zu steuern, ob Daten durch den ersten Pfad oder durch den zweiten Pfad zu dem Peripheriegerät gesendet werden, wobei das Verfahren die folgenden Schritte umfasst: Senden (400-406, 402', 802) einer Anfrage, um den Protokollstack zu dem Peripheriegerät durch die Vielzahl von Softwarelayern abzuladen, wobei die Anfrage eine Liste mit Ressourcenanforderungen besitzt; wenn der Protokollstack abgeladen wird: für jeden Layer der Vielzahl von Softwarelayern, Ausführen von Hinzufügen von Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn der Layer keinen bestehenden Offload-Handle von einem früheren Offload hat, und/oder Hinzufügen des bestehenden Offload-Handle zu der Liste mit Ressourcenanforderungen; Senden (410, 414, 418, 806) einer zwischengespeicherten Variable zu dem Peripheriegerät für jeden der Vielzahl von Softwarelayern, der einen Status ablädt und der keinen bestehenden Offload-Handle hat; und Übertragen (422) von Pufferspeichern von dem Switchlayer an das Peripheriegerät, wenn der Protokollstack abgeladen worden ist.
Verfahren nach Anspruch 38, wobei die Vielzahl von Softwarelayern einen Transport-Layer (300), einen Netzwerk-Layer (302), und ein Framing-Layer (304) einschliesst, und wobei der Schritt des Hinzufügens von Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn sich der Statuseintrag bezüglich des ersten Statuseintrags geändert hat, folgendes einschliesst: Hinzufügen von Transport-Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn sich ein Protokollstatuseintrag bezüglich eines ersten Protokollstatuseintrags geändert hat; Hinzufügen von Netzwerk-Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn sich ein Netzwerkstatuseintrag bezüglich eines ersten Netzwerkstatuseintrags geändert hat; und Hinzufügen von Framing-Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn sich ein Framingstatuseintrag bezüglich eines ersten Framingstatuseintrags geändert hat;
Verfahren nach Anspruch 38, des Weitern den Schritt umfassend: für jeden Layer der Vielzahl von Softwarelayern: Senden des ersten Handle zu dem Peripheriegerät, wenn sich der Statuseintrag nicht geändert hat.
Verfahren nach Anspruch 40, wobei der Schritt des Sendens des ersten Handle zu dem Peripheriegerät, wenn sich der Statuseintrag nicht geändert hat, das Senden eines ersten Protokoll-Handle zu dem Peripheriegerät, wenn sich der Protokoll-Statuseintrag nicht geändert hat, einschliesst.
Verfahren nach Anspruch 40, wobei der Schritt des Sendens des ersten Handle zu dem Peripheriegerät, wenn der Statuseintrag sich nicht geändert hat, das Senden eines ersten Netzwerk-Handle zu dem Peripheriegerät, wenn sich der Netzwerk-Statuseintrag nicht geändert hat, einschliesst.
Verfahren nach Anspruch 40, wobei der Schritt des Sendens des ersten Handle zu dem Peripheriegerät, wenn der Statuseintrag sich nicht geändert hat, das Senden eines Framing-Handle zu dem Peripheriegerät, wenn sich der Framing-Statuseintrag nicht geändert hat, einschliesst.
Computer-lesbares Medium, das Computer-ausführbare Instruktionen zum Ausführen der Schritte von Anspruch 38 besitzt.
Computer-lesbares Medium nach Anspruch 44, das des Weiteren Computerausführbare Instruktionen zum Ausführen des folgenden Schritts besitzt, wobei der Schritt umfasst: für jeden Layer der Vielzahl von Softwarelayern: Senden des ersten Handle zu dem Peripheriegerät, wenn sich der Statuseintrag nicht geändert hat.
Computer-lesbares Medium nach Anspruch 44, wobei die Vielzahl von Softwarelayern einen Transport-Layer (300), einen Netzwerk-Layer (302), und ein Framing-Layer (304) einschliesst, und wobei der Schritt des Hinzufügens von Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn sich der Statuseintrag bezüglich des ersten Statuseintrags geändert hat, folgendes einschliesst: Hinzufügen von Transport-Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn sich ein Protokollstatuseintrag bezüglich eines ersten Protokollstatuseintrags geändert hat; Hinzufügen von Netzwerk-Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn sich ein Netzwerkstatuseintrag bezüglich eines ersten Netzwerkstatuseintrags geändert hat; und Hinzufügen von Framing-Ressourcenanforderungen zu der Liste mit Ressourcenanforderungen, wenn sich ein Framingstatuseintrag bezüglich eines ersten Framingstatuseintrags geändert hat;
Verfahren zum Betreiben eines Peripheriegeräts (170, 204), das mit einem Host-Computer-System verbunden ist, um einen Protokollstack von einem ersten Pfad, der durch eine Vielzahl von Softwarelayern (206, 300-304) zu dem Peripheriegerät geht, zu einem zweiten Pfad (210, 308), der von einem Switchlayer (208, 306) zu dem Peripheriegerät geht, abzuladen, wobei die Vielzahl der Softwarelayer hostbasiert ist, wobei der Switchlayer auf dem höchsten Zwischenlayer eines hostbasierten Netzwerkstack ist oder in den höchsten Zwischenlayer eines hostbasierten Netzwerkstack integriert ist, um zu steuern, ob Daten durch den ersten Pfad oder durch den zweiten Pfad zu dem Peripheriegerät gesendet werden, wobei das Verfahren die folgenden Schritte umfasst: Empfangen (400-406, 402, 802) einer Anfrage, den Protokollstack abzuladen, wobei die Anfrage eine Liste mit Ressourcenanforderungen und mindestens einen bestehenden Offload-Handle für mindestens einen der Vielzahl von Softwarelayern besitzt; Entscheiden, ob der Protokollstack abgeladen wird; Zuweisen von Ressourcen, um die Liste mit Ressourcenanforderungen zu behandeln, wenn der Protokollstack abgeladen wird; und Senden (408, 412, 414', 416, 420, 804) eines Offload-Handle an jeden Layer der Vielzahl von Softwarelayern, der keinen bestehenden Offload-Handle besitzt, wenn der Layer ein Layer-Statusobjekt abgeladen hat (410, 414, 418, 806).
Verfahren nach Anspruch 47, wobei die Vielzahl von Softwarelayern einen Protokoll-Layer, einen Netzwerk-Layer (302), und ein Framing-Layer (304) einschliesst, und wobei der Schritt des Sendens des Offload-Handle an jeden Layer der Vielzahl von Softwarelayern, der keinen bestehenden Offload-Handle besitzt, wenn der Layer ein Layer-Statusobjekt abgeladen hat, folgendes einschliesst: Senden eines Protokoll-Handle zu dem Protokoll-Layer, wenn ein Protokoll-Statusobjekt abgeladen wurde; Senden eines Netzwerk-Handle zu dem Netzwerk-Layer, wenn ein Netzwerk-Statusobjekt abgeladen wurde; und Senden eines Framing-Handle zu dem Framing-Layer, wenn ein Framing-Statusobjekt abgeladen wurde.
Computer-lesbares Medium, das Computer-ausführbare Instruktionen zum Ausführen der Schritte von Anspruch 47 besitzt.