DE112005001364T5

DE112005001364T5 - Verarbeiten von Empfangsprotokolldateneinheiten

Info

Publication number: DE112005001364T5
Application number: DE112005001364T
Authority: DE
Inventors: Nicholas Hillsboro Colman; Ramesh Hillsboro Krishnan; Anshuman Beaverton Thakur; Robert Portland Cone; Daniel Portland Manseau
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2004-06-28
Filing date: 2005-06-10
Publication date: 2009-04-02
Also published as: TWI278207B; TW200620934A; US7701973B2; CN1961540A; WO2006011963A1; US20050286560A1

Abstract

Verfahren zum Verarbeiten eines Datensegments, umfassend:
Strippen eines Headers aus einem Transportschichtsegment;
Durchführen einer Protokolldateneinheit-Erkennung, um Daten für ein Protokollsegment zu bestimmen, die Teil der Daten des Transportschichtsegments sind;
Durchführen einer Markierungsvalidierung und eines Strippings.

Description

ALLGEMEINER STAND DER TECHNIK
1. Beschreibung des Standes der Technik
OSI (Open System Interconnection) ist ein ISO-Standard (ISO = International Standards Organization), der ein Networking Framework zur Implementierung von Protokollen in sieben Schichten definiert. Die sieben Schichten sind: Anwendung, Präsentation, Sitzung, Transport, Netzwerk, Datenverbindung und PHY-Schicht. Die PHY-Schicht ist an eine physikalische Verbindung angeschlossen. Wenn Daten gesendet werden, werden diese von der Anwendungsschicht über die Präsentationsschicht, die Sitzungsschicht, die Transportschicht, die Netzwerkschicht, die Datenverbindungsschicht und die PHY-Schicht an die physikalische Verbindung weitergereicht. Wenn die Daten von der PHY-Schicht empfangen werden, werden die Daten über die PHY-Schicht, die Datenverbindungsschicht, die Netzwerkschicht, die Transportschicht, die Sitzungsschicht, die Präsentationsschicht zur Anwendungsschicht weitergereicht. Somit geht die Steuerung zum Senden und Empfangen von Daten von einer Schicht auf die nächste Schicht usw. bis zum Ende über.
Die Anwendungsschicht (Schicht 7) unterstützt Anwendungs- und Endbenutzerprozesse. Die Präsentationsschicht (Schicht 6) übersetzt die Daten aus dem Anwendungs- in das Netzwerkformat und umgekehrt. Die Sitzungsschicht (Schicht 5) erstellt, verwaltet und beendet Verbindungen zwischen Anwendungen. Die Transportschicht (Schicht 4) sorgt für die Übertragung der Daten. Die Netzwerkschicht (Schicht 3) sorgt für Switching und Routing. Die Datenverbindungsschicht (Schicht 2) codiert und decodiert Datenpakete zu Bits. Die PHY-Schicht (Schicht 1) überträgt einen Bitstrom über ein NCPI (Network critical physical infrastructure).
Der Einsatz von Netzwerkprotokollen wie OSI für die Speicherung und Zwischenprozesskommunikation breitet sich mehr und mehr aus. Diese Konvergenz bietet enorme Kostenvorteile für IT-Infrastrukturen, da sich dadurch der Einsatz eines separaten physikalischen Mediums als Träger für Speicherverkehr erübrigt. Dieser Vorteil bringt jedoch Nachteile für Endstationen mit sich, da diese kompliziertere Protokolle auf den Hostprozessoren einsetzen müssen.
Somit besteht die Aufgabe, eine verbesserte Protokollverarbeitung in der Technik bereitzustellen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Im folgenden soll auf die Zeichnungen Bezug genommen werden, in denen gleiche Bezugsziffern durchweg für gleiche Teile verwendet wurden.
1 veranschaulicht Details einer Computerumgebung, in der bestimmte Ausführungsformen implementiert wurden.
2 veranschaulicht ein Blockdiagramm eines Netzwerkadapters gemäß bestimmter Ausführungsformen.
3 veranschaulicht ein Blockdiagramm einer Protokolldateneinheit gemäß bestimmter Ausführungsformen.
4 veranschaulicht drei TCP-Segmente (TCP = Transmission Control Protocol) gemäß bestimmter Ausführungsformen.
5 veranschaulicht eine TCP-Segment- und Protokolldateneinheit (TCP = Transmission Control Protocol) gemäß bestimmter Ausführungsformen.
6 veranschaulicht Operationen, die von einer Segmentverarbeitungs-Engine gemäß bestimmter Ausführungsformen durchgeführt wurden.
7 veranschaulicht Operationen, die von einer Segmentverarbeitungs-Engine zur Erkennung der Protokolldateneinheit gemäß bestimmter Ausführungsformen durchgeführt wurden.
8 veranschaulicht Operationen, die von einer Segmentverarbeitungs-Engine für Markierungsvalidierung und Stripping gemäß bestimmter Ausführungsformen durchgeführt wurden.
9 veranschaulicht Operationen, die von einem Vorverarbeitungs-Agent gemäß bestimmter Ausführungsformen durchgeführt wurden.
10 veranschaulicht ein Format einer Empfangspufferanweisung gemäß bestimmter Ausführungsformen.
11 veranschaulicht ein Format einer CRC-Datenstruktur (CRC = zyklische Redundanzprüfung) gemäß bestimmter Ausführungsformen.
12 veranschaulicht die Zusammenwirkung einer Segmentverarbeitungs-Engine und der CRC-Engine gemäß bestimmter Ausführungsformen.
13 veranschaulicht eine Serialisierungs-Timeline in einem „VORHER" Szenario gemäß bestimmter Ausführungsformen.
14 veranschaulicht eine Serialisierungs-Timeline in einem „NACHHER" Szenario gemäß bestimmter Ausführungsformen.
15 veranschaulicht Operationen, die von einer CRC-Engine gemäß bestimmter Ausführungsformen durchgeführt wurden.
16 veranschaulicht Operationen, die von einer Segmentverarbeitungs-Engine für CRC-Prüfungen gemäß bestimmter Ausführungsformen durchgeführt wurden.
AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung wird auf die beigefügten Zeichnungen Bezug genommen, die Teil der Beschreibung sind, und die verschiedene Ausführungsformen veranschaulichen. Es versteht sich, daß andere Ausführungsformen eingesetzt und strukturelle und betriebsmäßige Änderungen vorgenommen werden können.
1 veranschaulicht Details einer Computerumgebung, in der bestimmte Ausführungsformen implementiert werden können. Ein Hostcomputer 102 enthält eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 104, einen flüchtigen Speicher 106, einen nicht-flüchtigen Speicher 108 (zum Beispiel Magnetplattenlaufwerke, optische Plattenlaufwerke, ein Bandlaufwerk, usw.), ein Betriebssystem 110 und einen oder mehrere Netzwerkadapter 128. Einer oder mehrere Speichertreiber 120, ein oder mehrere Anwendungsprogramme 122 und einer oder mehrere Netzwerktreiber 126 residierten im Speicher 106 zur Ausführung durch CPUs 104 und sind fähig, Pakete von entfernten Speichersubsystemen 140 über ein Netzwerk 176 zu senden und zu empfangen. Außerdem ist ein Teil des Speichers für Anwendungsplatz 124 reserviert, der für Anwendungsprogramme 122 zugänglich ist.
Der Hostcomputer 102 kann jede in der Technik bekannte Computervorrichtung wie zum Beispiel ein Mainframe, ein Server, ein Personalcomputer, eine Workstation, ein Laptop, ein handgehaltener Computer, eine Fernsprechvorrichtung, ein Netzwerk-Appliance, ein Virtualisierungsgerät, ein Speichercontroller usw. sein. Eingesetzt werden kann jede in der Technik bekannte CPU 104 und jedes Betriebssystem 110. Programme und Daten im Speicher 106 können im Rahmen der Speicherverwaltungsoperationen in den und aus dem Speicher 108 gesetzt/geholt werden. Das Netzwerk 176 kann jedes beliebige Netzwerk sein, wie zum Beispiel ein Speicherbereichsnetzwerk (SAN), ein lokales Netzwerk (LAN), ein Weitbereichsnetzwerk (WAN, das Internet, ein Internet usw.
Das Speichersubsystem 140 enthält einen Speicherserver 180 (das heißt eine Art von Computergerät), der an ein oder mehrere Speichergeräte 190 angeschlossen ist. Die Speichergeräte 190 könnten jeweils aus einem oder aus einer Gruppe von Speichergeräten bestehen, wie zum Beispiel DASDs (Direct Access Storage Devices), JBOD (Just a Bunch of Disks), RAID (Redundant Array of Independent Disks), Virtualisierungsgeräten usw. Der Speicherserver 180 weist einen I/O-Prozessor 182 auf, der einen Paritätsgenerator 184 enthält. Der Paritätsgenerator 184 ist fähig, Paritätsinformation gemäß der Ausführungsformen zu erzeugen.
Jeder Netzwerkadapter 128 weist verschiedene Komponenten auf, die in der Hardware des Netzwerkadapters 128 implementiert sind. Jeder Netzwerkadapter 128 ist fähig, Pakete von Daten über Netzwerk 176 zu senden und zu empfangen.
Jeder Netztreiber 126 weist netzwerkadapter-spezifische Befehle (128) auf, die zur Kommunikation mit jedem Netzwerkadapter 128 dienen und die Schnittstelle zwischen dem Betriebssystem 110, jedem Speichertreiber 120 und jedem Netzwerkadapter 128 bilden. Jeder Netzwerkadapter 128 oder Netztreiber 126 implementiert Logik zur Verarbeitung der Pakete, zum Beispiel eine Transportprotokollschicht zur Verarbeitung des Inhalts von Nachrichten in den Paketen, die in ein Kommunikationsprotokoll eingewickelt sind, wie zum Beispiel TCP (Transmission Control Protocol) (IETF RFC 793, veröffentlicht September 1981) und/oder IP (Internet Protocol) (IETF RFC 791, veröffentlicht September 1981), iSCSI (Internet Small Computer System Interface) (IETF RFC 3347, veröffentlicht Februar 2003), Fibre Channel (American National Standards Institute (ANSI) X3.269-199X, Revision 012, 4. Dezember 1955) oder irgendein anderes in der Technik bekanntes Kommunikationsprotokoll. Die Transportprotokollschicht packt eine mit dem TCP/IP-Paket empfangene Nutzlast aus und überträgt die Daten an einen Netzwerktreiber 126 zur Rückgabe an ein Anwendungsprogramm 122. Des weiteren sendet ein daten-sendendes Anwendungsprogramm 122 die Daten an einen Netzwerktreiber 126, der daraufhin die Daten an die Transportprotokollschicht zur Verpackung in einem TCP/IP-Paket sendet, bevor sie über das Netzwerk 176 übertragen werden.
Der Speicher 108 könnte aus einem internen Speichergerät oder aus einem angehängten oder für das Netzwerk zugänglichen Speicher bestehen. Im Speicher 108 enthaltene Programme könnten in den Speicher 106 geladen und von der CPU 104 ausgeführt werden. Ein Eingabegerät 150 liefert Benutzereingaben an die CPU 104 und könnte eine Tastatur, eine Maus, einen Schreibstift, ein Mikrofon, einen berührungsempfindlichen Anzeigebildschirm oder einen anderen in der Technik bekannten Aktivierungs- oder Eingabemechanismus umfassen. Ein Ausgabegerät 152 ist fähig, Information auszugeben, die von der CPU 104 oder einer anderen Komponente wie einem Anzeigemonitor, einem Drucker, Speicher usw. übertragen wurde.
Verschiedene Strukturen und/oder Puffer (nicht dargestellt) könnten im Speicher 106 residieren oder in bestimmten Ausführungsformen in einer vom Speicher 106 separaten Speichereinheit angeordnet sein.
2 veranschaulicht ein Blockdiagramm eines Netzwerkadapters 128 gemäß bestimmter Ausführungsformen. Der Netzwerkadapter beinhaltet einen Vorverarbeitungs-Agent 210, der die Register 212 benutzt, eine DMA-Engine 220 (Direct Memory Access), die eine CRC-Engine 224 (zyklische Redundanzprüfung) enthält, eine Segmentverarbeitungs-Engine 230, einen I/O-Prozessor 240, eine physikalische Kommunikationsschicht 242 und einen Buscontroller 244. Die CRC-Engine 224 beinhaltet eine oder mehrere CRC-Datenstrukturen 226 und einen CRC-Speicherbereich 228. In bestimmten Ausführungsformen vorverarbeitet der Vorverarbeitungs-Agent 210 mit „Layer 4+ Protokollen" konforme Datensegmente, die einfachheitshalber im folgenden als Protokollsegmente bezeichnet werden. Der Einfachheit halber werden die „Layer 4+ Protokolle" zur Beschreibung neu auftauchender Protokolle, wie iSCSI und RDMA (RDMA Consortium, RDMA Protocol-over-TCP/IP Network, Version 1.0, October 2002) benutzt. Obwohl iSCSI und RDMA Protokolle als Höherebenenprotokolle (zum Beispiel Layer 5 oder darüber) bezeichnet werden können, werden in den Ausführungsformen die iSCSI und RDMA Protokolle als Layer 4+ Protokolle bezeichnet, da sie eng mit der Verarbeitung von Layer 4 Protokollen verknüpft sind. Bestimmte Protokolle (zum Beispiel RDMA) könnten mit dem Transportschicht-Protokoll (das heißt Layer 4) (zum Beispiel TCP) verknüpft sein. In bestimmten Ausführungsformen verarbeitet die Segmentverarbeitungs-Engine 230 Datensegmente (zum Beispiel TCP-Segmente), die einfachheitshalber im folgenden als „Transportschichtsegmente" bezeichnet werden. Eine Protokolldateneinheit könnte als Einheit zur Übertragung für die Layer 4 Protokolle beschrieben werden. Ein Protokollsegment könnte als Teil einer oder als die ganze Protokolldateneinheit bezeichnet werden (das heißt eine Protokolldateneinheit könnte aus einem oder mehreren Protokollsegmenten zusammengesetzt sein).
In bestimmten Ausführungsformen könnte der Vorverarbeitungs-Agent 210 als dedizierter Prozessor beschrieben werden, der einen Kontext-empfindlichen Registerplatz (Register 212) aufweist, und der in Verbindung mit der Segmentverarbeitungs-Engine 230 benutzt werden kann, um wirksame und programmierbare Empfangsverarbeitung zu erzielen.
Ein Buscontroller 244 ermöglicht jedem Netzwerkadapter 128 das Kommunizieren über einen Computerbus 160, der jede beliebige in der Technik bekannte Schnittstelle wie jeden Typ von PCI-Bus (Peripheral Component Interconnect) aufweisen kann (beispielsweise einen PCI-Bus (PCI Special Interest Group, PCI Local Bus Specification, Rev 2.3, veröffentlicht März 2002), einen PCI-X Bus (PCI-X 2.0a Protocol Specification, veröffentlicht 2002) oder einen PCI Express Bus (PCI Special Interest Group, PCI Express Base Specification 1.0a. veröffentlicht 2002), Small Computer System Interface (SCSI) (American National Standards Institute (ANSI) SCSI Controller Commands-2 (SCC-2) NCITS.318:1998), Serial ATA ((SATA) 1.0a Specification, veröffentlicht 4. Februar 2003) usw.
Der Netzwerkadapter 128 enthält ein Netzwerkprotokoll zur Implementierung einer physikalischen Kommunikationsschicht 242 zum Senden und Empfangen von Netzwerkpaketen zu und von entfernten Datenspeichern über ein Netzwerk 176. In bestimmten Ausführungsformen könnte ein Netzwerkadapter 128 das Ethernet-Protokoll (IEEE Std. 802.3, veröffentlicht 8. März 2002), das Fibre Channel Protokoll (ANSI X3.269-199X, Revision 012, 4. Dezember 1995) oder irgendein anderes in der Technik bekanntes Netzwerkkommunikationsprotokoll implementieren.
Der Netzwerkadapter 128 enthält einen I/O-Controller 240. In bestimmten Ausführungsformen könnte der I/O-Controller 240 iSCSI-Controller (Internet Small Computer System Interface) umfassen, und es versteht sich, daß andere Netzwerkcontrollertypen, wie MAC-Controller (Media Access Controller) oder Karten benutzt werden können.
Um den Einsatz von komplizierteren Protokollen auf Hostprozessoren zu vermeiden, erfolgt bei bestimmten Ausführungsformen die Protokollverarbeitung, wie Datenplatzierung, außerhalb des Hostprozessors. In bestimmten Ausführungsformen könnte Offload Protokollverarbeitung mit dedizierter Hardware versehen werden. In bestimmten Ausführungsformen könnte der Netzwerkadapter 128 eine TOE-Engine (Transport Layer Offload Engine) implementieren, um die Transportprotokollschicht im Netzwerkadapter zur Reduzierung der auf den Hostcomputer ausgeübten Verarbeitungslast zu verwenden. Das Offloaden der Protokollverarbeitung führt zu wirksamer Verarbeitung und Platzierung von empfangenen Daten. Die Ausführungsformen stellen Empfangspfadverarbeitung bereit. In bestimmten Ausführungsformen erfolgt die Empfangspfadverarbeitung für Layer 4+ (iSCSI, RDMA) Protokolldateneinheiten.
Die Ausführungsformen verbessern die Erkennung von Layer 4+ Protokolldateneinheiten (PDU), Markierungsvalidierung und Stripping, Layer 4+ Header-Verarbeitung (einschließlich solcher Header, die über Layer 4+ Grenzen hinweg aufgeteilt sind), direkte Datenübertragung in den Anwendungsplatz und die Berechnung von CRC-Algorithmen.
Zyklische Redundanzprüfung kann als Technik zur Erkennung von Datenübertragungsfehlern benutzt werden. Zum Beispiel könnte bei der zyklischen Redundanzprüfungstechnik eine Nachricht in vorherbestimmte Längen aufgeteilt werden, die durch einen feststehenden Divisor dividiert werden, und wobei der Rest an die Nachricht angehängt wird. Wenn die Nachricht mit dem angehängten Rest empfangen wird, berechnet das empfangende Computergerät erneut den Rest und vergleicht den neuberechneten Rest mit dem angehängten Rest. Wenn die Reste nicht übereinstimmen, wird ein Fehler erkannt.
3 veranschaulicht ein Blockdiagramm einer Protokolldateneinheit 300 gemäß bestimmter Ausführungsformen. Die Protokolldateneinheit 300 umfasst mehrere Felder wie einen Header 310, einen oder zwei Algorithmen 312, 318, eine Markierung 314 und eine Nutzlast 316. Der Header 310 enthält die Länge der gesamten Protokolldateneinheit zusammen mit anderer Information. Der Algorithmus 312, 318 kann mit Hilfe einer auf den abgedeckten Daten durchgeführten zyklischen Redundanzprüfung (zum Beispiel CRC-32C Technik) abgeleitet werden. Das iSCSI-Protokoll hat zwei Algorithmen – einen für den Header und einen für die Nutzlast. Das RDMA-Protokoll hat einen Algorithmus für die gesamte Protokolldateneinheit. Die Markierung 314 ist ein Feld, welches in einem TCP-Strom vorkommt. Jede Markierung 314 ist ein Zeiger auf den Start oder/und das Ende der Protokolldateneinheit. Die Nutzlast besteht aus Daten.
Zuerst werden Layer 4+ Protokolldateneinheiten konstruiert, die dann als Byte-Strom zur TCP-Verarbeitung weitergereicht werden. Die TCP-Verarbeitung kann jedes Protokollsegment in viele Transportschichtsegmente umsegmentieren, so daß jedes Transportschichtsegment, welches ausgesendet wird, nicht eine maximale wirksame Datensegmentgröße überschreitet. 4 veranschaulicht drei Transportschichtsegmente 410, 420, 430 gemäß bestimmter Ausführungsformen. Jedes Transportschichtsegment 410, 420, 430 enthält einen Layer 4+ Header #1, #2 bzw. #3. Ferner könnte eine Transportschichtsegment-Nutzlast (zum Beispiel 410) Layer 4+ Header und Daten enthalten.
In manchen Fällen ist eine Protokolldateneinheit für ein Layer 4+ Protokoll nicht vollständig in einem Transportschichtsegment enthalten. Zum Beispiel hat eine einzelne Protokolldateneinheit #1 440 einen Header-Abschnitt und zwei Datenabschnitte, wobei das Transportschichtsegment 410 den Layer 4+ Header#1 und die Layer 4+ Daten#1 (das heißt einen Abschnitt von Daten für Protokolldateneinheit#1), und das Transportschichtsegment 420 die Layer 4+ Daten#1 (das heißt zusätzliche Daten für Protokolleinheit#1) enthält. Somit könnte eine Protokolldateneinheit in einem einzelnen Transportschichtsegment enthalten sein, über Transportschichtsegmente hinweg segmentiert sein, und ein Transportschichtsegment könnte mehrere Protokolldateneinheiten oder eine Kombination derselben enthalten.
5 veranschaulicht die Verarbeitung von Transportschichtsegmenten und Protokolldateneinheiten gemäß bestimmter Ausführungsformen. Während Transportschichtsegmente 502, 504 ankommen und Protokolldateneinheiten für Layer 4+ von der Segmentverarbeitungs-Engine 230 erkannt werden, wird eine Kopie von N Bytes relevanter Daten von einem Layer 4+ 520 Header direkt in den Registerplatz 212 des Vorverarbeitungs-Agent 210 platziert, und der Inhalt wird geladen. Inhalt kann beschrieben werden als Information, die sich auf eine bestimmte TCP-Verbindung bezieht. In bestimmten Ausführungsformen hat eine TCP-Verbindung einen einzigen Inhalt. In bestimmten anderen Ausführungsformen kann eine TCP-Verbindung einen oder mehrere Inhalte aufweisen. In diesem Beispiel beinhalten die von einem Layer 4+ 520 Header kommenden relevanten Daten zwei Abschnitte 512 und 514, die in zwei Transportschichtsegmenten 512, 514 festgestellt wurden. Inline-Verarbeitung von Layer 4+ Header Bytes reduziert die Verarbeitungslatenz durch Eliminieren des in konventionellen Systemen zum Speichern und Weiterleiten benutzten architektonischen Musterbeispiels. Außerdem könnten eingehende Daten von der DMA-Engine 220 (Direct Memory Access) zur Platzierung in den Anwendungsplatz 124 abgerufen werden, nachdem der Vorverarbeitungs-Agent 220 einen Befehl an die DMA-Engine 220 ausgegeben hat.
6 veranschaulicht Operationen, die gemäß bestimmter Ausführungsformen von der Segmentverarbeitungs-Engine 230 durchgeführt werden. Die Steuerung beginnt bei Block 600 mit dem Empfang eines Transportschichtsegments durch die Segmentverarbeitungs-Engine 230. In bestimmten Ausführungsformen entfernt die Segmentverarbeitungs-Engine 230 einen Header aus einem folgerichtigen Transportschichtsegment (Block 602), führt Protokolldateneinheit- Erkennung durch (Block 604), führt Markierungsvalidierung und Stripping durch (Block 606) und verarbeitet parallel dazu einen Peek-Befehl, wenn einer empfangen wird (Block 608–614). In bestimmten anderen Ausführungsformen könnte die Verarbeitung von Block 602, 604, 606 und 608 seriell oder teilweise parallel und teilweise seriell durchgeführt werden. In bestimmten Ausführungsformen wird die Verarbeitung von Block 602 für die Verarbeitung von Block 604 und 606 durchgeführt. Ferner wird bei bestimmten Ausführungsformen, wenn ein Transportschichtsegment außerhalb der Reihenfolge empfangen wurde, auf die fehlenden Transportschichtsegmente gewartet und die Transportschichtsegmente korrekt eingereiht, bevor sie verarbeitet werden.
Bei Block 604 identifiziert die Protokolldateneinheit-Erkennung einen Ort eines Layer 4+ Headers. Von den Blöcken 602, 604 und 606 geht die Verarbeitung zurück zu Block 600.
In Block 608 bestimmt die Segmentverarbeitungs-Engine 230, ob ein Peek-Befehl ausgegeben wurde. Falls ja, fährt die Verarbeitung bei Block 610 fort, andernfalls bei Block 614. Ein Peek-Befehl ist ein Befehl, der die Segmentverarbeitungs-Engine 230 auffordert, einen vorausschauenden Blick in die eingehenden Transportschichtsegmente zu werfen und nach bestimmten Daten zu suchen. Bei Block 610 wartet die Segmentverarbeitungs-Engine 230 auf die angeforderten Daten. Nachdem die angeforderten Daten empfangen wurden, geht die Verarbeitung von Block 610 zu 612 weiter. Bei Block 612 leitet die Segmentverarbeitungs-Engine 230 eine Anzeige des Orts eines Layer 4+ Headers weiter und/oder leitet den tatsächlichen Layer 4+ Header der erkannten Protokolldateneinheit an den Vorverarbeitungs-Agent 210 weiter. In bestimmten Ausführungsformen wird die Ortsanzeige dadurch bereitgestellt, daß Zeiger an einen Anfangsort und einen Endeort der Protokolldateneinheit gesendet werden. Von Block 612 geht die Verarbeitung zurück zu Block 600. Bei Block 614 können andere Verarbeitungsaufgaben durchgeführt werden, bevor die Rückkehr zu Block 600 erfolgt. Obwohl in der Darstellung die Segmentverarbeitungs-Engine 230 bei Block 608 prüft, ob ein Peek-Befehl eingegangen ist, können andere Verarbeitungsoperationen vor der Verarbeitung von Block 608 erfolgen. Die anderen Verarbeitungsoperationen könnten die Verarbeitung von zusätzlichen eingehenden Transportschichtsegmenten beinhalten.
Für Empfangsprotokolldateneinheiten stellen die Ausführungsformen einen konfigurierbaren Markierungsverarbeitungs-Agent (MPA) und Protokolldateneinheit-Erkennung; einen direkten Peek-Befehl von Daten für die Register 212 des Vorverarbeitungs-Agent 210; Datenplatzierung in den Anwendungsplatz 124 (das heißt Platzierung von Daten in den Speicher zum Zugriff durch eine Anwendung, nicht in einen allgemeinen Speicherbereich, aus dem die Daten in den von der Anwendung aufgerufenen Speicher verschoben werden); und zyklische Redundanzprüfungsvalidierung (zum Beispiel CRC-32C Technik) bereit.
In bestimmten Ausführungsformen könnte der MPA Teil der Segmentverarbeitungs-Engine 230 sein. Wie für den konfigurierbaren MPA und die Protokolldateneinheit-Erkennung wird von den Ausführungsformen ein Konfigurationsmechanismus für jede TCP-Verbindung vorgesehen, der Markierungss-Stripping/Validierung und Protokolldateneinheit-Erkennung bereitstellt. Insbesondere weist ein Computer verschiedene Verbindungen mit verschiedenen Computer auf (zum Beispiel hätte ein Browser an einem ersten Computer, der an ein Email-Konto auf einem zweiten Computer angeschlossen ist, eine Verbindung mit dem zweiten Computer). In bestimmten Ausführungsformen könnte die TCP-Verbindung für die Dauer der Datenübertragung eingerichtet werden.
Für die Ausführungsformen wurde folgende neuen Parameter für jede Layer 4+ TCP-Verbindung eingerichtet:

(a) Längenfeld-Offset in Layer 4+ Header (oder „O")
(b) Längenfeldbreite in Layer 4+ Header (oder „W")
(c) Längenfeldmultiplizierer (oder „M")
(d) Längenfeldaddierer (oder „A")
(e) Multipliz./Addier-Folge (oder „D")
(f) Markierungsintervall (oder „I")
(g) Anfängliches Offset (oder „S")
(h) Markierungslänge (oder „L")
(i) Markierungstyp (oder „T")

Von den neuen TCP-Verbindungsparametern werden der Längenfeldmultiplizierparameter (M) und der Längenfeldaddierer-Parameter (A) zum Zeitpunkt einer Layer 4+ Verbindung verhandelt. Der Multiplizier-/Addier-Folgeparameter (D) ist eine Konstante für eine gegebene TCP-Verbindung, die von den beiden Berechnungsgeräten, für die die Verbindungen erstellt werden, verhandelt wird, und dieser Parameter bestimmt, wie eine endgültige Länge von Daten für eine Protokolldateneinheit zu berechnen ist, da diese Information nicht vom Layer 4+ Protokoll bereitgestellt wird.
Die neuen TCP-Verbindungsparameter können gesetzt werden, sobald eine Verbindung erstellt wird, und bevor irgendwelche Daten übertragen werden. Diese Felder werden mit folgerichtigen Transportschicht-Segmenten benutzt, um Protokolldateneinheitsgrenzen, Validierungsmarkierungen und Löschmarkierungen (Strip) zu erkennen.
7 veranschaulicht Operationen, die von der Segmentverarbeitungs-Engine 230 zur Protokolldateneinheit-Erkennung (Block 604) gemäß bestimmter Ausführungsformen durchgeführt werden. Die Steuerung beginnt bei Block 700, wo die Segmentverarbeitungs-Engine 230 einen Wert aus einem Offset des Längenfeldes im Header einer Protokolldateneinheit (Parameter „O") für die Breite des Längenfeldes im Header extrahiert (Parameter „W"). Zum Beispiel, wenn das Längenfeld an einem Offset von vier Bytes beginnt und eine Breite von fünf Bytes hat, wird der Wert aus den Bytes vier, fünf, sechs, sieben und acht extrahiert. In Block 702 bestimmt die Segmentverarbeitungs-Engine 230 eine endgültige Länge einer Protokolldateneinheit auf Basis des extrahierten Werts (aus Block 700) und den Werten einer Folge bestehend aus Multiplizier-/Addierparameter („D", Längenfeldmultiplizier-Parameter („M") und Längenfeldaddier-Parameter („A"). In bestimmten Ausführungsformen benutzt die Segmentverarbeitungs-Engine 230 den folgenden Pseudocode zur Bestimmung der endgültigen Länge, wobei (Wert bei [O..O + W]) der extrahierte Wert aus den Verarbeitung von Block 700 ist:
Das heißt, wenn der Wert der Folge von Multiplizier-/Addierparameter („D") Null ist, wird die endgültige Länge dadurch bestimmt, daß man den Wert beginnend am Wert des Offsets des Längenfeldes im Layer 4+ Header-Parameter („O") durch den Wert des Offset-Parameters („O") hindurch plus den Wert der Breite des Längenfelds im Layer 4+ Header Parameter („W") nimmt.
Dieser Wert wird mit dem Wert des Längenfeldmultiplizierers („M") multipliziert, und dann wird das Ergebnis zum Wert des Längenfeldaddier-Parameters („A") hinzugefügt.
Andererseits, wenn der Wert der Folge von Multiplizier-/Addierparameter („D") nicht Null ist, wird die endgültige Länge dadurch bestimmt, daß man den Wert beginnend am Wert des Offsets des Längenfeldes im Layer 4+ Header-Parameter („O") durch den Wert des Offset-Parameters („O") hindurch plus den Wert der Breite des Längenfelds im Layer 4+ Header Parameter („W") nimmt. Dieser Wert wird zum Wert des Längenfeldaddierers („A") hinzu addiert, und dann wird das Ergebnis mit dem Wert des Längenfeldmultiplizierers („M") multipliziert.
In Block 704 erkennt die Segmentverarbeitungs-Engine 230 die Protokolldateneinheit aufgrund eines Startorts und der endgültigen Länge der Protokolldateneinheit. In bestimmten Ausführungsformen wird die Protokolldateneinheit ab einem Startort („Start”) bis zum Startort plus der bestimmten endgültigen Länge („Start" + endgültige_Länge) erkannt. In bestimmten Ausführungsformen könnte „Start" als der Start der Daten einer Protokolldateneinheit beschrieben werden.
8 veranschaulicht Operationen, die von der Segmentverarbeitungs-Engine 230 für Markierungsvalidierung und Stripping (Block 606) gemäß bestimmter Ausführungsformen durchgeführt werden. Die Steuerung beginnt bei Block 800, wo die Segmentverarbeitungs-Engine 230 Markierungslängenparameter („L") Bytes ab eines anfängliches Offsets extrahiert. In bestimmten Ausführungsformen ist das anfängliche Offset der Start eines Protokollsegments oder der Start einer Protokolldateneinheit und kann als Parameter „S" bezeichnet werden, welcher eine Variable ist. In Block 802 führt die Segmentverarbeitungs-Engine 230 Markierungsvalidierung aufgrund eines Markierungstyps durch, der auf den Anfang und/oder das Ende einer Protokolldateneinheit zeigen kann. In bestimmten Ausführungsformen validiert die Segmentverarbeitungs-Engine 230 die Markierung mit Hilfe des folgenden Pseudocodes:
Das heißt, für Markierungsvalidierung bestimmt die Segmentverarbeitungs-Engine 230, ob der Wert des Markierungstypparameters („T") auf den Anfang gesetzt ist. Falls ja, prüft die Segmentverarbeitungs-Engine 230, ob die Markierung auf den Anfang einer Protokolldateneinheit zeigt (das heißt, den bei der Verarbeitung der Protokolldateneinheit-Erkennung in 7 gefundenen „Start"). Wenn der Wert des Markierungstypparameters („T") auf Ende gesetzt ist, prüft die Segmentverarbeitungs-Engine 230, ob die Markierung auf das Ende einer Protokolldateneinheit zeigt. Wenn der Wert des Markierungstypparameters („T") auf Beide gesetzt ist, teilt die Segmentverarbeitungs-Engine 230 das Markierungsfeld in zwei Abschnitte auf und prüft, ob ein Abschnitt der Markierung auf den Anfang und der andere Abschnitt der Markierung auf das Ende zeigt.
Nach Validierung der Markierung in Block 804 überspringt die Segmentverarbeitungs-Engine 230 ein Markierungsintervall im eingehenden Byte-Strom.
9 veranschaulicht Operationen, die gemäß bestimmter Ausführungsformen vom Vorverarbeitungs-Agent 210 durchgeführt werden. Die Empfangsverarbeitung einer Layer 4+ Protokolldateneinheit beinhaltet das Untersuchen eines Headers und das Verarbeiten des Headers. In bestimmten Ausführungsformen wird die Verarbeitung durchgeführt, bevor die Daten einer vorhergehenden Nachricht vollständig an den Hostcomputer 102 übertragen wurden. Da diese Layer 4+ Protokolle für Anwendungsprogramme 122 wie Diskzugriff und Zwischenprozesskommunikation benutzt werden, sind geringe Verarbeitungslatenzen wünschenswert. In bestimmten Ausführungsformen wird Hardcodierungs-Header-Verarbeitung in Silizium vermieden, da dies eine weniger flexible Lösung für Header-Verarbeitung bietet.
Die Ausführungsformen führen Header-Verarbeitung in flexibler Weise durch, indem sie einen Vorverarbeitungs-Agent 210 verwenden, der kontextempfindlichen Registerplatz 212 aufweist (zum Beispiel eine Mikro-Engine).
Die Steuerung beginnt bei Block 900, wo der Vorverarbeitungs-Agent 210 eine Anzeige des Orts der oder der tatsächlichen Header-Daten für ein Protokollsegment von der Segmentverarbeitungs-Engine 230 empfängt. Bei Block 902 interpretiert der Vorverarbeitungs-Agent 210 den Header-Abschnitt der empfangenen Daten, um den Ort eines nächsten Header-Abschnitts eines nächsten Datenabschnitts für eine Protokolldateneinheit zu bestimmen. Bei Block 904 sendet der Vorverarbeitungs-Agent 210 einen Peek-Befehl an die Segmentverarbeitungs-Engine 230 für einen Header-Abschnitt der nächsten Protokolldateneinheit und empfängt die angeforderten Daten aus dem ausgegebenen Peek-Befehl. In bestimmten Ausführungsformen sind die empfangenen Daten eine Anzeige des Orts eines Layer 4+ Headers und/oder des tatsächlichen Layer 4+ Headers einer Protokolldateneinheit. Obwohl in der Darstellung der Empfang von Daten aus dem ausgegebenen Peek-Befehl auf die Ausgabe des Peek-Befehls folgt, kann der Empfang der Daten zu jeder beliebigen Zeit nach Ausgabe des Peek-Befehls erfolgen (zum Beispiel nach der Verarbeitung von Block 906). Mit Hilfe des Peek-Befehls stellen bestimmte Ausführungsformen direkte Peek-Ergebnisse in den Registern 212 des Vorverarbeitungs-Agent 210 bereit.
Bestimmte Ausführungsformen sorgen auch für die Platzierung der empfangenen Daten in den Anwendungsplatz 124. In Block 906 informiert der Vorverarbeitungs-Agent 210 die DMA-Engine 220 (DMA = Direktspeicherzugriff) „n" Bytes von Daten (wobei „n" einen positiven Ganzzahlwert darstellt) für eine Protokolldateneinheit in den Anwendungsplatz 124 zu setzen. In bestimmten Ausführungsformen gibt der Vorverarbeitungs-Agent 210 eine Empfangspufferanweisung an die DMA-Engine 220 aus. 10 veranschaulicht ein Format einer Empfangspufferanweisung 1000 gemäß bestimmter Ausführungsformen. Die Empfangspufferanweisung 1000 beinhaltet einen Opcode 1010, Flags 1012, eine Sprunglänge 1014 und eine Liste von Adreß/Längenpaaren 1016, 1018, 1020, ... 1022. Obwohl vier Adreß/Längenpaare dargestellt sind, kann jede beliebige Anzahl in die Empfangspufferanweisung aufgenommen werden. Der Opcode 1000 stellt einen Anweisungstyp bereit, der in diesem Fall der Anweisungstyp „Empfangspuffer" ist.
Auf den Opcode 1010 folgen Flags 1012, die relevant für die Übertragung von Daten in den Anweisungsplatz 124 sind. Einige der Flags, die mit der Anweisung bereitgestellt werden, sind: C zur Berechnung eines CRC-Algorithmus über die Übertragungsmenge (zum Beispiel mit der CRC-Technik) und P, welches Strip Pad Bytes darstellt, die aus der Nutzlast, die übertragen wird, zu entfernen sind.
Auf die Flags 1012 folgt die Sprunglänge 1014, die zu überspringen ist, wenn Daten übertragen werden. Die Sprunglänge 1014 ist nützlich für das Überspringen von Layer 4+ Headers, damit Daten im Anwendungsplatz 124 gespeichert werden. Auf die Sprunglänge 1014 folgt eine Scatter-Liste von Adreß/Längenpaaren 1016...1024. Ein Adreß/Längenpaar 1016...1024 stellt eine Adresse im Anwendungsplatz 124 und eine zugehörige Länge bereit, damit Daten unter dieser Adresse für die angegebene Länge gespeichert werden können.
Nach Einplanung der Empfangspufferanweisung in die DMA-Engine 220 wird die Empfangspufferanweisung an die eingehenden Transportschichtsegmente angelegt. Die Empfangspufferanweisung entfernt die TCP-Nutzlast für eine Protokolldateneinheit aus einem Transportschichtsegment, schließt die Übertragung der Nutzlast an den Zielanwendungsplatz 124 ab und aktualisiert die Adreß/Längenparameter in Anpassung an die aktuelle Übertragung. Aufgrund dieses Prozesses erübrigt sich die temporäre Pufferung von folgerichtigen Transportschichtsegmenten.
Die Ausführungsformen berechnen einen zyklischen Redundanzprüfungsalgorithmus (zum Beispiel CRC-32C), während die Daten in den Anwendungsplatz übertragen werden. Das Berechnen des CRC-32C-Algorithmus ist schwierig, wenn die Nutzlast für eine mit jedem Transportschichtsegment verknüpfte Protokolldateneinheit übertragen wird, sobald das Transportschichtsegment ankommt. Ferner könnte in bestimmten Ausführungsformen der Algorithmus für die zyklische Redundanzprüfung mit einer Granularität von 4-Bytes berechnet werden, die Transportschichtsegmente können jedoch jede beliebige Byte-Granularität aufweisen. Die Ausführungsformen führen die zyklische Redundanzprüfung in einer Weise durch, die effizient für die Speicherbelegung sowie für Leistung ist.
Für jede TCP-Verbindung wird eine CRC-Datenstruktur 226 für die Berechnung einer zyklischen Redundanzprüfung über ein Transportschichtsegment geführt. 12 veranschaulicht ein Format einer CRC-Datenstruktur 226 gemäß bestimmter Ausführungsformen. Die CRC-Datenstruktur 226 beinhaltet ein teilweises CRC-Algorithmusfeld 1110, eine Restzählung 1112 und Restdaten 1114. Im teilweisen CRC-Algorithmusfeld 1110 wird ein Algorithmus für die zyklische Redundanzprüfung (zum Beispiel CRC-32C) geführt, der für eine bestimmte Zahl von Bytes des vorhergehenden Transportschichtsegments berechnet wurde (zum Beispiel [floor(N/4) × 4], wobei N die Anzahl der Bytes ist, über die CRC berechnet wird). Im Restdatenfeld 1112 werden die restlichen Bytes aus dem vorhergehenden Transportschichtsegment geführt. In bestimmten Ausführungsformen ist die Anzahl der Restdatenbytes gleich {N – [floor(N/4) × 4]}(wobei N die Anzahl der Bytes ist, über die CRC berechnet wurde). Im Restzählungsfeld 1114 wird eine Anzahl von Bytes geführt, die für das Restdatenfeld gelten.
Für jedes neue Transportschichtsegment wird der CRC-Engine 224 der teilweise CRC-Algorithmus aus dem vorhergehenden Transportschichtsegment präsentiert, den sie als anfängliche CRC benutzt. Die „Restdaten werden ebenfalls präsentiert, um den nächsten CRC-Algorithmus zu berechnen. Nach Übertragung einer Protokolldateneinheit wird der endgültige CRC-Algorithmus mit dem empfangenen Algorithmus verglichen. Wenn eine Übereinstimmung gefunden wird, wird ein Anwendungsprogramm 122 über die empfangenen Daten informiert (das heißt, die CRC-Engine 224 setzt ein Flag, um den Vorverarbeitungs-Agent 210 zu benachrichtigen), andernfalls wird ein Fehler erkannt. In bestimmten Ausführungsformen wird bei Erkennung eines Fehlers ein Netzwerktreiber 126 entsprechend benachrichtigt.
12 veranschaulicht die Zusammenwirkung einer Segmentverarbeitungs-Engine 230 mit der CRC-Engine 224 gemäß bestimmter Ausführungsformen. Die Segmentverarbeitungs-Engine 230 ist verantwortlich dafür, daß die CRC-Engine 224 das nächste Transportschichtsegment für die Berechnung des CRC-Algorithmus erhält. Für jedes neue Transportschichtsegment liefert die Segmentverarbeitungs-Engine 230 den teilweisen CRC-Algorithmus aus dem vorhergehenden Transportschichtsegment zusammen mit dem nächsten Transportschichtsegment. Dieser teilweise CRC-Algorithmus wird als anfänglicher CRC-Algorithmus für das nächste Transportschichtsegment benutzt. Durch diesen Prozeß wird demnach serienmäßig eine „Rücken-an-Rücken" Transportschichtsegment-Verarbeitung im gleichen Fluß bereitgestellt.
In 13 ist gemäß bestimmter Ausführungsformen eine Serialisierungs-Timeline 1300 in einem „VORHER" Szenario dargestellt. Da der Netzwerkverkehr burst-artig auftritt, könnte sich die durch Timeline 1300 veranschaulichte Serialisierung auf die Leistung auswirken. Dies kommt in den Ausführungsformen dadurch zum Ausdruck, daß für die CRC-Datenstruktur 226 innerhalb der CRC-Engine 224 ein „One-Behind"-Speicherbereich 228 (zum Beispiel ein Cache) eingeführt wird. Der Speicherbereich 228 speichert einen teilweisen CRC-Algorithmus. Die Segmentverarbeitungs-Engine 230 bestimmt, ob ein aktuelles Transportschichtsegment im gleichen Fluß wie das letzt ist, und falls ja, beginnt die Segmentverarbeitungs-Engine 230 mit der Übertragung von Daten an die CRC-Engine 224, ohne auf den teilweisen CRC-Algorithmus und den Austausch von Restdaten zu warten. Der CRC-Engine 224 ist die Situation ebenfalls bekannt, und sie benutzt die gecachte Version des teilweisen CRC-Algorithmus. In 14 ist gemäß bestimmter Ausführungsformen eine Serialisierungs-Timeline 1400 in einem „NACHHER" Szenario dargestellt. Die Timeline 1400 in 14 zeigt, daß die „Verzögerung" im „VORHER"-Szenario von 13 im Falle des „NACHHER"-Szenarios verschwunden ist.
15 veranschaulicht Operationen, die gemäß bestimmter Ausführungsformen von der CRC-Engine 224 durchgeführt werden. Die Steuerung beginnt bei Block 1500, wo die CRC-Engine 224 ein Transportschichtsegment empfängt. Bei Block 1502 bestimmt die CRC-Engine 224, ob zusammen mit dem Transportschichtsegment ein teilweiser CRC-Algorithmus und Restdaten empfangen wurden. Falls ja, geht die Verarbeitung bei Block 1506 weiter, andernfalls bei Block 1504. Bei Block 1504 ruft die CRC-Engine 224 einen teilweisen CRC-Algorithmus und Restdaten für ein vorhergehendes Transportschichtsegment aus einem CRC-Speicherbereich 228 ab.
Bei Block 1506 bestimmt die CRC-Engine 224, ob zusammen mit diesem Transportschichtsegment eine vollständige Protokolldateneinheit empfangen wurde. Das heißt, da in eine Protokolldateneinheit mehrere Protokollsegmente innerhalb mehrerer Transportschichtsegmente eingebettet sein könnten, bestimmt die CRC-Engine 224, ob sie jetzt eine vollständige Protokolldateneinheit empfangen hat. Falls ja, geht die Verarbeitung zu Block 1508, andernfalls fährt sie bei Block 1516 fort.
Bei Block 1508 berechnet die CRC-Engine 224 einen vollständigen CRC-Algorithmus für die Protokolldateneinheit unter Einsatz des empfangenen oder abgerufenen CRC-Algorithmus und der Restdaten. Zum Beispiel könnten eine Zustandsmaschine und zugehörige Register zur Berechnung des vollständigen CRC-Algorithmus verwendet werden, und der teilweise CRC-Algorithmus und die Restdaten könnten zum Speichern des Zustands der Register verwendet werden, bevor alle Daten für die Protokolldateneinheit empfangen wurden. Bei Block 1510 bestimmt die CRC-Engine 224, ob der berechnete CRC-Algorithmus mit dem empfangenen Algorithmus übereinstimmt. Falls ja, fährt die Verarbeitung bei Block 1512 fort, andernfalls geht sie zu Block 1514. Bei Block 1512 benachrichtigt die CRC-Engine 224 ein Anwendungsprogramm 122, daß die Daten erfolgreich empfangen wurden. Bei Block 1514 verarbeitet die CRC-Engine 224 einen Fehler.
Bei Block 1516 berechnet die CRC-Engine 224 einen neuen teilweisen CRC-Algorithmus, wobei der empfangene oder abgerufene CRC-Algorithmus und Restdaten zum Einsatz kommen. Bei Block 1518 werden der neue teilweise CRC-Algorithmus und die Restdaten aufgrund des empfangenen oder abgerufenen teilweisen CRC-Algorithmus und der Restdaten an die Segmentverarbeitungs-Engine 230 weitergeleitet. Bei Block 1520 werden der neue teilweise CRC-Algorithmus und die Restdaten aufgrund des empfangenen oder abgerufenen teilweisen CRC-Algorithmus und der Restdaten in einer CRC-Datenstruktur 226 und in einem CRC-Speicherbereich 228 gespeichert. Danach kehrt die Verarbeitung in einer Schleife zu Block 1500 zurück.
16 veranschaulicht Operationen, die gemäß bestimmter Ausführungsformen von der Segmentverarbeitungs-Engine 230 für zyklische Redundanzprüfung durchgeführt werden. Die Steuerung beginnt bei Block 1602, wobei die Segmentverarbeitungs-Engine 230 ein aktuelles Transportschichtsegment empfängt. Bei Block 1602 bestimmt die Segmentverarbeitungs-Engine 230, ob ein teilweiser CRC-Algorithmus und Restdaten für das letzte Transportschichtsegment empfangen wurden. Falls ja, fährt die Verarbeitung bei Block 1604 fort, andernfalls geht sie zu Block 1606. Bei Block 1604 leitet die Segmentverarbeitungs-Engine 230 das aktuelle Transportschichtsegment an die CRC-Engine 224 zusammen mit dem teilweisen CRC-Algorithmus und den Restdaten für das letzte Transportschichtsegment weiter.
Bei Block 1606 bestimmt die Segmentverarbeitungs-Engine 230, ob das aktuelle Transportschichtsegment im gleichen Fluß wie das letzte Transportschichtsegment ist. Das aktuelle Transportschichtsegment kann als im gleichen Fluß befindlich wie das letzte Transportschichtsegment bestimmt werden, wenn beide die gleiche TCP-Verbindung aufweisen und in der korrekten Reihenfolge empfangen wurden. Falls ja, fährt die Verarbeitung bei Block 1608 fort, andernfalls kehrt sie in einer Schleife zu Block 1604 zurück. Bei Block 1608 leitet die Segmentverarbeitungs-Engine 230 das aktuelle Transportschichtsegment an die CRC-Engine 224 ohne den teilweisen CRC-Algorithmus und die Restdaten für das letzte Transportschichtsegment weiter.
Somit lösen die Ausführungsformen ein praktisches Problem für den Empfang von Layer 4+ Protokolldaten-einheiten und Datenplatzierung. Vorgesehen ist eine wirksame und vollständige Lösung für jedes kritische Stadium der Verarbeitung von empfangenen Transportschichtsegmenten, deren Datenabschnitte Protokollsegmente enthalten könnten.
Die Ausführungsformen sorgen für eine Lösung für Layer 4+ Protokolldateneinheit-Erkennung, Markierungsvalidierung und Stripping, für Layer 4+ Direkt-Header-Untersuchung unter Einsatz eines Vorverarbeitungs-Agent 210 und CRC-Berechnung von Protokolldateneinheit-Nutzlasten, die viele byte-ausgerichtete Transportschichtsegmente umspannen könnten. Stromlinienförmige Verarbeitung von Empfangsverkehr wird für die Verarbeitung von Layer 4+ Verkehr bereitgestellt. Die wirksame Handhabung von Empfangsverkehr wiederum verbessert insgesamt die Systemleistung.
Somit verarbeiten bestimmte Ausführungsformen Empfangsprotokolldateneinheiten für Protokolle der oberen Schichten wie iSCSI und RDMA.
Weitere Angaben zu Ausführungsformen
Die beschriebenen Ausführungsformen können als Verfahren, Vorrichtung oder Herstellungsartikel unter Einsatz von Programmier- und/oder Engineering-Techniken zur Herstellung von Software, Firmware, Hardware oder Kombinationen derselben implementiert werden. Die hier benutzten Ausdrücke „Herstellungsartikel" und „Schaltungen" beziehen sich auf eine Zustandsmaschine, auf Code oder Logik, die in Hardware-Logik (zum Beispiel in einem integrierten Schaltungschip, einem programmierbaren Gate Array (PGA), einer anwendungsspezifischen integrierten Schaltung (ASIC), usw.) oder in einem computerlesbaren Medium implementiert ist, wie in magnetischen Speichermedien (zum Beispiel in optischen Speichern (CD-ROMs, optischen Platten, usw.), flüchtigen oder nichtflüchtigen Speichergeräten (zum Beispiel EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, Firmware, programmierbaren Logik usw.). Der Zugriff auf, und die Ausführung von, Code in computerlesbaren Medien erfolgt durch einen Prozessor. Wenn der Code oder die Logik von einem Prozessor ausgeführt werden, könnten die Schaltungen das Medium einschließlich des Codes oder der Logik sowie den Prozessor enthalten, der den aus dem Medium geladenen Code ausführt. Der Zugriff auf den Code, in dem die Ausführungsformen implementiert sind, könnte ferner über ein Übertragungsmedium oder durch einen Dateiserver über ein Netzwerk erfolgen. In diesen Fällen könnte der Herstellungsartikel, in dem der Code implementiert ist, ein Übertragungsmedium, wie eine Netzwerkübertragungsleitung, ein drahtloses Übertragungsmedium, Signalausbreitung über Raum, Funkwellen, Infrarotsignale usw. sein. Somit könnte der „Herstellungsartikel" das Medium beinhalten, in dem Code eingebettet ist. Ferner könnte der „Herstellungsartikel" eine Kombination aus Hardware- und Softwarekomponenten umfassen, in denen der Code eingebettet ist, verarbeitet und ausgeführt wird. Ein Fachmann wird selbstverständlich ohne weiteres erkennen, daß viele Modifikationen an dieser Konfiguration vorgenommen werden können, und daß der Herstellungsartikel jedes aus der Technik bekannte informationstragende Medium umfassen könnte. Ferner könnten die Geräte, Adapter usw. in einer oder mehreren integrierten Schaltungen auf dem Adapter oder auf einer Hauptplatine implementiert werden.
In den dargestellten Operationen in 6, 7, 8, 9, 15 und 16 sind bestimmte Ereignisse in einer bestimmten Reihenfolge dargestellt. In anderen Ausführungsformen könnten bestimmte Operationen in einer anderen Reihenfolge durchgeführt, modifiziert oder entfernt werden. Darüber hinaus könnten Operationen zur beschriebenen Logik hinzugefügt werden und dennoch den beschriebenen Ausführungsformen entsprechen. Des weiteren könnten hier beschriebene Operationen sequentiell oder parallel zueinander erfolgen. Und ferner könnten Operationen von einer einzelnen Verarbeitungseinheit oder von verteilten Verarbeitungseinheiten durchgeführt werden.
Die vorhergehende Beschreibung verschiedener Ausführungsformen wurde zum Zwecke der Veranschaulichung und Beschreibung präsentiert. Sie sollte weder erschöpfend noch einschränkend sein. Viele Modifikationen und Variationen sind angesichts der obigen Lehren denkbar.
Zusammenfassung
Bereitgestellt werden Techniken zur Verarbeitung eines Datensegments durch Entfernen eines Headers aus einem Transportschichtsegment, zur Durchführung von Protokolldateneinheit-Erkennung zur Bestimmung von Daten für ein Protokollsegment, welches Teil der Transportschicht-Segmentdaten ist, und zur Durchführung von Markierungsvalidierung und Stripping. Bereitgestellt werden ferner Techniken zur Verarbeitung eines Datensegments, in dem ein Header-Abschnitt einer Protokolldateneinheit empfangen wird. Eine Anzahl von Datenbytes, die in einem Anwendungsplatz zu speichern sind, werden mit Hilfe des empfangenen Header-Abschnitts bestimmt. Ferner wird ein nächster Header-Abschnitt einer nächsten Protokolldateneinheit mit Hilfe des empfangenen Header-Abschnitts bestimmt. Dann wird ein Peek-Befehl ausgegeben, um den nächsten Header-Abschnitt zu erhalten. Zusätzlich sind Techniken zur Durchführung zyklischer Redundanzprüfungen vorgesehen, wobei ein gespeicherter teilweiser zyklischer Redundanzprüfungs-Algorithmus und Restdaten zum Einsatz kommen.

Claims

Verfahren zum Verarbeiten eines Datensegments, umfassend: Strippen eines Headers aus einem Transportschichtsegment; Durchführen einer Protokolldateneinheit-Erkennung, um Daten für ein Protokollsegment zu bestimmen, die Teil der Daten des Transportschichtsegments sind; Durchführen einer Markierungsvalidierung und eines Strippings.
Verfahren nach Anspruch 1, wobei die Durchführung von Protokolldateneinheit-Erkennung weiterhin umfaßt: Extrahieren eines Werts aus einem Offset eines Längenfelds eines Headers einer Protokolldateneinheit für eine Breite des Längenfelds des Headers; Bestimmen einer endgültigen Länge der Protokolldateneinheit; und Erkennen einer Protokolldateneinheit auf der Basis eines Anfangsorts und der endgültigen Länge der Protokolldateneinheit.
Verfahren nach Anspruch 2, wobei das Bestimmen der endgültigen Länge der Protokolldateneinheit auf dem extrahierten Wert und Werten einer Multiplizier-Addierparameter-Folge, einem Längenfeld-Multiplizierparameter und einem Längenfeld-Addierparameter basiert.
Verfahren nach Anspruch 1, wobei die Durchführung von Markierungsvalidierung und Stripping ferner umfaßt: Extrahieren einer Markierungslängen-Byteanzahl ab eines anfänglichen Offsets; Validieren der Markierung basierend auf einem Markierungstyp; und Überspringen eines Markierungsintervalls in einem eingehenden Byte-Strom.
Verfahren nach Anspruch 1, ferner umfassend: Empfangen eines Peek-Befehls zur Anforderung eines Header-Abschnitts einer nächsten Protokolldateneinheit; Warten auf die angeforderten Daten; und Zurückgeben der angeforderten Daten in Antwort auf einen Peek-Befehl.
Verfahren nach Anspruch 5, wobei die Rückgabe der angeforderten Daten ferner umfaßt: Liefern eines Orts eines Headers der Protokolldateneinheit an einen Vorverarbeitungs-Agent.
Verfahren nach Anspruch 5, wobei die Rückgabe der angeforderten Daten ferner umfaßt: Liefern eines Headers der Protokolldateneinheit an einen Vorverarbeitungs-Agent.
Verfahren zur Verarbeitung eines Datensegments, umfassend: Empfangen eines Header-Abschnitts einer Protokolldateneinheit; Bestimmen einer Anzahl von Datenbytes, die unter Einsatz des empfangenen Header-Abschnitts in einem Anwendungsplatz gespeichert werden sollen; Bestimmen eines nächsten Header-Abschnitts einer nächsten Protokolldateneinheit aufgrund des empfangenen Header-Abschnitts; und Ausgeben eines Peek-Befehls, um den nächsten Header-Abschnitt zu erhalten.
Verfahren nach Anspruch 8, ferner umfassend: Benachrichtigen einer Direktspeicherzugriffs-Engine (DMA), die bestimmte Anzahl von Bytes direkt im Anwendungsplatz zu speichern.
Verfahren zur Durchführung von zyklischer Redundanzprüfung, umfassend: Empfangen eines Transportschichtsegments; Bestimmen, ob eine vollständige Protokolldateneinheit empfangen wurde; und in Antwort auf das Bestimmen, daß eine vollständige Protokolldateneinheit nicht empfangen wurde, Berechnen eines neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus; und Speichern des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten aus der Berechnung.
Verfahren nach Anspruch 10, wobei der neue teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten in einem zyklischen Redundanzprüfungs-Speicherbereich und einer zyklischen Redundanzprüfungs-Datenstruktur gespeichert werden.
Verfahren nach Anspruch 10, ferner umfassend: Weiterleiten des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten an eine Segmentverarbeitungs-Engine.
Verfahren nach Anspruch 10, ferner umfassend: Bestimmen, ob ein teilweiser zyklischer Redundanzprüfungs-Algorithmus und Restdaten zusammen mit dem Transportschichtsegment empfangen wurden; Abrufen des teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten in Antwort auf das Bestimmen, ob der teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten nicht empfangen wurden; und Berechnen des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus unter Einsatz des abgerufenen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten.
Verfahren nach Anspruch 10, ferner umfassend: In Antwort auf das Bestimmen, daß die vollständige Protokolldateneinheit empfangen wurde, Berechnen eines vollständigen zyklischen Redundanzprüfungs-Algorithmus für die Protokolldateneinheit; Bestimmen, ob der berechnete zyklische Redundanzprüfungs-Algorithmus mit einem zusammen mit der Protokolldateneinheit empfangenen zyklischen Redundanzprüfungs-Algorithmus übereinstimmt; Benachrichtigen eines Anwendungsprogramms von dem erfolgreichen Empfang der Daten in Antwort auf das Bestimmen, daß eine Übereinstimmung besteht; und Durchführen von Fehlerverarbeitung in Antwort auf das Bestimmen, daß keine Übereinstimmung besteht.
Verfahren zur Durchführung von zyklischer Redundanzprüfung, umfassend: Empfangen eines aktuellen Transportschichtsegments; Bestimmen, ob ein teilweiser zyklischer Redundanzprüfungs-Algorithmus und Restdaten für das letzte Transportschichtsegment empfangen wurden; und in Antwort auf das Bestimmen, daß der teilweise zyklische Redundanzprüfungs-Algorithmus und Restdaten empfangen wurden, Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine mit dem teilweisen zyklischen Redundanzprüfungs-Algorithmus und den Restdaten für das letzte Transportschichtsegment.
Verfahren nach Anspruch 15, ferner umfassend: in Antwort auf das Bestimmen, daß der teilweise zyklische Redundanzprtifungs-Algorithmus und die Restdaten nicht empfangen wurden, Bestimmen, ob sich das aktuelle Transportschichtsegment im gleichen Fluß wie das letzte Transportschichtsegment befindet; und In Antwort auf das Bestimmen, daß die Transportschichtsegmente im gleichen Fluß sind, Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine ohne den teilweisen zyklischen Redundanzprüfungs-Algorithmus und die Restdaten für das letzte Transportschichtsegment.
Verfahren nach Anspruch 16, ferner umfassend: In Antwort auf das Bestimmen, daß die Transportschichtsegmente nicht im gleichen Fluß sind, Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine mit dem teilweisen zyklischen Redundanzprüfungs-Algorithmus und den Restdaten für das letzte Transportschichtsegment.
Herstellungsartikel zur Verarbeitung eines Datensegments, wobei der Herstellungsartikel Speicheranweisungen für ein computerlesbares Medium umfaßt, und wobei der Herstellungsartikel folgenden Zwecken dient: Stripping eines Headers aus einem Transportschichtsegment; Durchführen einer Protokolldateneinheit-Erkennung, um Daten für ein Protokollsegment zu bestimmen, welches Teil der Daten des Transportschichtsegments ist; und Durchführen einer Markierungsvalidierung und eines Strippings.
Herstellungsartikel nach Anspruch 18, wobei bei der Durchführung von Protokolldateneinheit-Erkennung der Herstellungsartikel folgenden Zwecken dient: Extrahieren eines Werts aus einem Offset eines Längenfelds eines Headers einer Protokolldateneinheit für eine Breite des Längenfelds des Headers; Bestimmen einer endgültigen Länge der Protokolldateneinheit; und Erkennen einer Protokolldateneinheit aufgrund eines Anfangsorts und der endgültigen Länge der Protokolldateneinheit.
Herstellungsartikel nach Anspruch 19, wobei das Bestimmen der endgültigen Länge der Protokolldateneinheit auf dem extrahierten Wert und Werten einer Multiplizier/Addierparameter-Folge, einem Längenfeld-Multiplizierparameter und einem Längenfeld-Addierparameter basiert.
Herstellungsartikel nach Anspruch 18, wobei bei der Durchführung von Markierungsvalidierung und Stripping der Herstellungsartikel folgenden Zwecken dient: Extrahieren einer Markierungslängen-Byteanzahl aus einem anfänglichen Offset; Validieren der Markierung aufgrund eines Markierungstyps; und Überspringen eines Markierungsintervalls in einem eingehenden Byte-Strom.
Herstellungsartikel nach Anspruch 18, wobei der Herstellungsartikel folgenden Zwecken dient: Empfangen eines Peek-Befehls, mit dem ein Header-Abschnitt einer nächsten Protokolldateneinheit angefordert wird; Warten auf die angeforderten Daten; und Zurückgeben der angeforderten Daten in Antwort auf den Peek-Befehl.
Herstellungsartikel nach Anspruch 22, wobei bei der Rückgabe der angeforderten Daten der Herstellungsartikel folgenden Zwecken dient: Liefern eines Orts eines Headers der Protokolldateneinheit an einen Vorverarbeitungs-Agent.
Herstellungsartikel nach Anspruch 22, wobei bei der Rückgabe der angeforderten Daten der Herstellungsartikel folgenden Zwecken dient: Liefern eines Headers der Protokolldateneinheit an einen Vorverarbeitungs-Agent.
Herstellungsartikel zur Verarbeitung eines Datensegments, wobei der Herstellungsartikel Speicheranweisungen für ein computerlesbares Medium umfaßt, und wobei der Herstellungsartikel folgenden Zwecken dient: Empfangen eines Header-Abschnitts einer Protokolldateneinheit; Bestimmen einer Anzahl von Datenbytes, die in einem Anwendungsplatz zu speichern sind, mit Hilfe eines empfangenen Header-Abschnitts; Bestimmen eines nächsten Header-Abschnitts einer nächsten Protokolldateneinheit aufgrund des empfangenen Header-Abschnitts; und Ausgeben eines Peek-Befehls zum Erhalt des nächsten Header-Abschnitts.
Herstellungsartikel nach Anspruch 25, wobei der Herstellungsartikel folgendem Zweck dient: Benachrichtigen einer Direktspeicherzugriffs-Engine (DMA), eine vorherbestimmte Anzahl von Datenbytes direkt im Anwendungsplatz zu speichern.
Herstellungsartikel zur Durchführung von zyklischer Redundanzprüfung, wobei der Herstellungsartikel Speicheranweisungen für ein computerlesbares Medium umfaßt, und wobei der Herstellungsartikel folgenden Zwecken dient: Empfangen eines Transportschichtsegments; Bestimmen, ob eine vollständige Protokolldateneinheit empfangen wurde; und In Antwort auf das Bestimmen, daß eine vollständige Protokolldateneinheit nicht empfangen wurde, Berechnen eines neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus; und Speichern des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten aus der Berechnung.
Herstellungsartikel nach Anspruch 27, wobei der neue teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten in einem Speicherbereich für zyklische Redundanzprüfung und in einer Datenstruktur für zyklische Redundanzprüfung gespeichert werden.
Herstellungsartikel nach Anspruch 27, wobei der Herstellungsartikel folgendem Zweck dient: Weiterleiten des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten an eine Segmentverarbeitungs-Engine.
Herstellungsartikel nach Anspruch 27, wobei der Herstellungsartikel folgenden Zwecken dient: Bestimmen, ob ein zyklischer Redundanzprüfungs-Algorithmus und Restdaten zusammen mit dem Transportschichtsegment empfangen wurden; Abrufen des teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten in Antwort auf das Bestimmen, daß der teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten nicht empfangen wurden; und Berechnen des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus unter Einsatz des abgerufenen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten.
Herstellungsartikel nach Anspruch 27, wobei der Herstellungsartikel folgenden Zwecken dient: In Antwort auf das Bestimmen, daß die vollständige Protokolldateneinheit empfangen wurde, Berechnen eines vollständigen zyklischen Redundanzprüfungs-Algorithmus für die Protokolldateneinheit; Bestimmen, ob der berechnete zyklische Redundanzprüfungs-Algorithmus mit einem zusammen mit der Protokolldateneinheit empfangenen zyklische Redundanzprüfungs-Algorithmus übereinstimmt; Benachrichtigen eines Anwendungsprogramms von den erfolgreich empfangenen Daten in Antwort auf das Bestimmen, daß eine Übereinstimmung besteht; und Durchführen von Fehlerverarbeitung in Antwort auf das Bestimmen, daß keine Übereinstimmung besteht.
Herstellungsartikel zur Durchführung von zyklischer Redundanzprüfung, wobei der Herstellungsartikel Speicheranweisungen für ein computerlesbares Medium umfaßt, und wobei der Herstellungsartikel folgenden Zwecken dient: Empfangen eines aktuellen Transportschichtsegments; Bestimmen, ob ein teilweise zyklischer Redundanzprüfungs-Algorithmus und Restdaten für ein letztes Transportschichtsegment empfangen wurden; und in Antwort auf das Bestimmen, daß der teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten empfangen wurden, Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine zusammen mit dem teilweisen zyklischen Redundanzprüfungs-Algorithmus und den Restdaten für das letzte Transportschichtsegment.
Herstellungsartikel nach Anspruch 32, wobei der Herstellungsartikel folgenden Zwecken dient: in Antwort auf das Bestimmen, daß der teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten nicht empfangen wurden, bestimmen, ob sich das aktuelle Transportschichtsegment im gleichen Fluß wie das letzte Transportschichtsegment befindet; und in Antwort auf das Bestimmen, daß sich die Transportschichtsegmente im gleichen Fluß befinden, das Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine ohne den teilweisen zyklischen Redundanzprüfungs-Algorithmus und die Restdaten für das letzte Transportschichtsegment
Herstellungsartikel nach Anspruch 33, wobei der Herstellungsartikel folgendem Zweck dient: in Antwort auf das Bestimmen, daß sich die Transportschichtsegmente nicht im gleichen Fluß befinden, Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine zusammen mit dem teilweisen zyklischen Redundanzprüfungs-Algorithmus und den Restdaten für das letzte Transportschichtsegment.
System zur Verarbeitung eines Datensegments, umfassend: einen Netzwerkadapter, der an einen PCI-Bus (PCI = Peripheral Component Interconnect) gekoppelt ist; und Schaltungen am Netzwerkadapter, die folgenden Zwecken dienen: Strippen eines Headers aus einem Transportschichtsegment; Durchführen einer Protokolldateneinheit-Erkennung, um Daten für ein Protokollsegment zu bestimmen, die Teil der Daten des Transportschichtsegments sind; Durchführen einer Markierungsvalidierung und eines Strippings.
System nach Anspruch 35, wobei bei der Durchführung von Protokolldateneinheit-Erkennung, die Schaltungen folgenden Zwecken dienen: Extrahieren eines Werts aus einem Offset eines Längenfelds eines Headers einer Protokolldateneinheit für eine Breite des Längenfelds des Headers; Bestimmen einer endgültigen Länge der Protokolldateneinheit; und Erkennen einer Protokolldateneinheit auf der Basis eines Anfangsorts und der endgültigen Länge der Protokolldateneinheit.
System nach Anspruch 36, wobei das Bestimmen der endgültige Länge der Protokolldateneinheit auf dem extrahierten Wert und Werten einer Multiplizier/Addierparameter-Folge, einem Längenfeld-Multiplizierparameter und einem Längenfeld-Addierparameter basiert.
System nach Anspruch 35, wobei bei der Durchführung von Markierungsvalidierung und Stripping die Schaltungen folgenden Zwecken dienen: Extrahieren einer Markierungslängen-Byteanzahl ab eines anfänglichen Offsets; Validieren der Markierung basierend auf einem Markierungstyp; und Überspringen eines Markierungsintervalls in einem eingehenden Byte-Strom.
System nach Anspruch 35, wobei die Schaltungen folgenden Zwecken dienen: Empfangen eines Peek-Befehls zur Anforderung eines Header-Abschnitts einer nächsten Protokolldateneinheit; Warten auf die angeforderten Daten; und Zurückgeben der angeforderten Daten in Antwort auf einen Peek-Befehl.
System nach Anspruch 39, wobei bei Zurückgeben der angeforderten Daten die Schaltungen folgendem Zweck dienen: Liefern eines Orts eines Headers der Protokolldateneinheit an einen Vorverarbeitungs-Agent.
System nach Anspruch 39, wobei bei Zurückgeben der angeforderten Daten die Schaltungen folgendem Zweck dienen: Liefern eines Headers der Protokolldateneinheit an einen Vorverarbeitungs-Agent.
System zur Verarbeitung eines Datensegments, umfassend: einen Netzwerkadapter, der an einen PCI-Bus (Peripheral Component Interconnect) gekoppelt ist; und Schaltungen am Netzwerkadapter, die folgenden Zwecken dienen: Empfangen eines Header-Abschnitts einer Protokolldateneinheit; Bestimmen einer Anzahl von Datenbytes, die unter Einsatz des empfangenen Header-Abschnitts in einem Anwendungsplatz gespeichert werden sollen; Bestimmen eines nächsten Header-Abschnitts einer nächsten Protokolldateneinheit aufgrund des empfangenen Header-Abschnitts; und Ausgeben eines Peek-Befehls, um den nächsten Header-Abschnitt zu erhalten.
System nach Anspruch 42, wobei die Schaltungen folgendem Zweck dienen: Benachrichtigen einer Direktspeicherzugriffs-Engine (DMA), die bestimmte Anzahl von Bytes direkt im Anwendungsplatz zu speichern.
System zur Durchführung von zyklischer Redundanzprüfung, umfassend: einen Netzwerkadapter, der an einen PCI-Bus (PCI = Peripheral Component Interconnect) gekoppelt ist; und Schaltungen am Netzwerkadapter, die folgenden Zwecken dienen: Empfangen eines Transportschichtsegments; Bestimmen, ob eine vollständige Protokolldateneinheit empfangen wurde; und in Antwort auf das Bestimmen, daß eine vollständige Protokolldateneinheit nicht empfangen wurde, Berechnen eines neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus; und Speichern des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten aus der Berechnung.
System nach Anspruch 44, wobei der neue teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten in einem zyklischen Redundanzprüfungs-Speicherbereich und einer zyklischen Redundanzprüfungs-Datenstruktur gespeichert werden.
System nach Anspruch 44, wobei die Schaltungen folgendem Zweck dienen: Weiterleiten des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten an eine Segmentverarbeitungs-Engine.
System nach Anspruch 44, wobei die Schaltungen folgendem Zweck dienen: Bestimmen, ob ein teilweiser zyklischer Redundanzprüfungs-Algorithmus und Restdaten zusammen mit dem Transportschichtsegment empfangen wurden; Abrufen des teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten in Antwort auf das Bestimmen, ob der teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten nicht empfangen wurden; und Berechnen des neuen teilweisen zyklischen Redundanzprüfungs-Algorithmus unter Einsatz des abgerufenen teilweisen zyklischen Redundanzprüfungs-Algorithmus und der Restdaten.
System nach Anspruch 44, wobei die Schaltungen folgendem Zweck dienen: in Antwort auf das Bestimmen, daß die vollständige Protokolldateneinheit empfangen wurde, Berechnen eines vollständigen zyklischen Redundanzprüfungs-Algorithmus für die Protokolldateneinheit; Bestimmen, ob der berechnete zyklische Redundanzprüfungs-Algorithmus mit einem zusammen mit der Protokolldateneinheit empfangenen zyklischen Redundanzprüfungs-Algorithmus übereinstimmt; Benachrichtigen eines Anwendungsprogramms von dem erfolgreichen Empfang der Daten in Antwort auf das Bestimmen, daß eine Übereinstimmung besteht; und Durchführen von Fehlerverarbeitung in Antwort auf das Bestimmen, daß keine Übereinstimmung besteht.
System zur Durchführung von zyklischer Redundanzprüfung, umfassend: einen Netzwerkadapter, der an einen PCI-Bus (PCI = Peripheral Component Interconnect) gekoppelt ist; und Schaltungen am Netzwerkadapter, die folgenden Zwecken dienen: Empfangen eines aktuellen Transportschichtsegments; Bestimmen, ob ein teilweiser zyklischer Redundanzprüfungs-Algorithmus und Restdaten für das letzte Transportschichtsegment empfangen wurden; und in Antwort auf das Bestimmen, daß der teilweise zyklische Redundanzprüfungs-Algorithmus und Restdaten empfangen wurden, Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine mit dem teilweisen zyklischen Redundanzprüfungs-Algorithmus und den Restdaten für das letzte Transportschichtsegment.
System nach Anspruch 49, wobei die Schaltungen folgenden Zwecken dienen: in Antwort auf das Bestimmen, daß der teilweise zyklische Redundanzprüfungs-Algorithmus und die Restdaten nicht empfangen wurden, Bestimmen, ob sich das aktuelle Transportschichtsegment im gleichen Fluß wie das letzte Transportschichtsegment befindet; und in Antwort auf das Bestimmen, daß die Transportschichtsegmente im gleichen Fluß sind, Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine ohne den teilweisen zyklischen Redundanzprüfungs-Algorithmus und die Restdaten für das letzte Transportschichtsegment.
System nach Anspruch 50, wobei die Schaltungen folgendem Zweck dienen: in Antwort auf das Bestimmen, daß die Transportschichtsegmente nicht im gleichen Fluß sind, Weiterleiten des aktuellen Transportschichtsegments an eine zyklische Redundanzprüfungs-Engine mit dem teilweisen zyklischen Redundanzprüfungs-Algorithmus und den Restdaten für das letzte Transportschichtsegment.