DE60016574T2 - Verfahren und vorrichtung zur belastungsverteilung uphänging von datenflussen - Google Patents

Verfahren und vorrichtung zur belastungsverteilung uphänging von datenflussen Download PDF

Info

Publication number
DE60016574T2
DE60016574T2 DE60016574T DE60016574T DE60016574T2 DE 60016574 T2 DE60016574 T2 DE 60016574T2 DE 60016574 T DE60016574 T DE 60016574T DE 60016574 T DE60016574 T DE 60016574T DE 60016574 T2 DE60016574 T2 DE 60016574T2
Authority
DE
Germany
Prior art keywords
packet
flow
data
header
processor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60016574T
Other languages
English (en)
Other versions
DE60016574D1 (de
Inventor
Shimon Muller
Denton Gentry
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of DE60016574D1 publication Critical patent/DE60016574D1/de
Application granted granted Critical
Publication of DE60016574T2 publication Critical patent/DE60016574T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Description

  • Die Erfindung bezieht sich auf das Gebiet der Computersysteme und Computernetze. Auf dem Gebiet der TCP/IP-Netze ist es zum Beispiel aus der EP 0865180 bekannt, die Belastung auf Server zu verteilen. Die vorliegende Erfindung unterscheidet sich darin, dass sie sich insbesondere auf eine Netzschnittstellenschaltung (NIC) zur Verarbeitung von Datenpaketen bezieht, die zwischen einem Computernetz und einem Hauptrechnersystem ausgetauscht werden.
  • Die Schnittstelle zwischen einem Computer und einem Netz ist häufig ein Flaschenhals für Datenübertragung, die sich zwischen dem Computer und dem Netz abspielt. Während die Computerleistung (z.B. Prozessorgeschwindigkeit) mit den Jahren exponentiell zugenommen hat und Computernetz-Übertragungsgeschwindigkeiten ähnliche Zuwächse erfahren haben, wurden Ineffizienzen in der Art und Weise, in der Netzschnittstellenschaltungen Datenübertragung abwickeln, immer deutlicher. Mit jeder Zunahme der Computer- oder Netzgeschwindigkeit wird es noch offensichtlicher, dass die Schnittstelle zwischen dem Computer und dem Netz nicht Schritt halten kann. Diese Ineffizienzen sind mit mehreren Grundproblemen in der Art und Weise verknüpft, in der Datenübertragung zwischen einem Netz und einem Computer abgewickelt wird.
  • Die heute am meisten verbreitete Form von Netzen ist tendenziell paketbasiert. Diese Typen von Netzen, einschließlich des Internets und vieler lokaler Netze, senden Informationen in Form von Paketen. Jedes Paket wird von einer Ursprungs-Datenstation separat erzeugt und gesendet und wird von einer Ziel-Datenstation separat empfangen und verarbeitet. Zusätzlich kann jedes Paket, zum Beispiel in einem Netz mit Bus-Topologie, von zahlreichen Stationen empfangen und verarbeitet werden, die zwischen den Ursprungs- und Ziel-Datenstationen liegen.
  • Ein Grundproblem bei Paketnetzen ist, dass jedes Paket sowohl an den Ursprungs- als auch Ziel-Datenstationen durch mehrere Protokolle oder Protokollebenen (im Ganzen als "Protokollstapel" bekannt) verarbeitet werden muss. Wenn die zwischen Stationen übertragenen Daten länger als eine bestimmte Minimallänge sind, werden die Daten in mehrere Abschnitte unterteilt, und jeder Abschnitt wird von einem separaten Paket befördert. Die Datenmenge, die ein Paket befördern kann, ist im Allgemeinen durch das Netz beschränkt, das das Paket transportiert, und wird häufig als maximale Übertra gungseinheit (MTU) bezeichnet. Die ursprüngliche Ansammlung von Daten ist manchmal als "Datagramm" bekannt, und jedes Paket, das einen Teil eines einzelnen Datagramms befördert, wird sehr ähnlich wie die anderen Pakete des Datagramms verarbeitet.
  • Datenpakete werden im Allgemeinen wie folgt verarbeitet. In der Ursprungs-Datenstation wird jeder separate Datenabschnitt eines Datagramms durch einen Protokollstapel verarbeitet. Während dieser Verarbeitung werden dem Datenabschnitt mehrere Protokoll-Anfangsblöcke (z.B. TCP, IP, Ethernet) hinzugefügt, um ein Paket zu bilden, das über das Netz übertragen werden kann. Das Paket wird von einer Netzschnittstellenschaltung empfangen, die das Paket an die Ziel-Datenstation oder einen die Ziel-Datenstation bedienenden Hauptrechner überträgt. In der Ziel-Datenstation wird das Paket in der entgegengesetzten Richtung wie in der Ursprungs-Datenstation durch den Protokollstapel verarbeitet. Während dieser Verarbeitung werden die Protokoll-Anfangsblöcke in der entgegengesetzten Reihenfolge, in der sie angebracht wurden, entfernt. Der Datenabschnitt wird somit wiederhergestellt und kann einem Benutzer wie z.B. einem Anwendungsprogramm usw. zur Verfügung gestellt werden.
  • Mehrere verknüpfte Pakete (z.B. Pakete, die Daten aus einem Datagramm befördern), machen somit auf eine serielle Weise (d.h. ein Paket auf einmal) im Wesentlichen den gleichen Prozess durch. Je mehr Daten übertragen werden müssen, desto mehr Pakete müssen gesendet werden, wobei jedes separat abgewickelt und in jeder Richtung durch den Protokollstapel verarbeitet werden muss. Je mehr Pakete verarbeitet werden müssen, desto größer sind natürlich die an den Prozessor einer Datenstation gestellten Anforderungen. Die Zahl der Pakete, die verarbeitet werden müssen, wird durch mehr Faktoren als nur die in einem Datagramm gesendete Datenmenge beeinflusst. Zum Beispiel, wenn die in einem Paket eingebundene Datenmenge zunimmt, müssen weniger Pakete gesendet werden. Wie oben dargelegt, kann ein Paket jedoch eine maximale zulässige Größe haben, je nach dem benutzten Netztyp (z.B. ist die maximale Übertragungseinheit für Standard-Ethernet-Verkehr ungefähr 1.500 Byte). Die Geschwindigkeit des Netzes beeinflusst auch die Zahl der Pakete, die eine NIC in einer gegebenen Zeitspanne verarbeiten kann. Zum Beispiel benötigt ein Gigabit-Ethernet-Netz, das mit Spitzenleistung arbeitet, möglicherweise eine NIC für Empfang von ungefähr 1,48 Millionen Paketen pro Sekunde. Die Zahl der durch einen Protokollstapel zu verarbeitenden Pakete kann den Prozessor eines Computers somit erheblich belasten. Die Situation wird durch die Notwendigkeit verschlimmert, jedes Paket separat zu verarbeiten, obwohl jedes Paket auf eine im Wesentlichen ähnliche Weise verarbeitet wird.
  • Ein mit der getrennten Verarbeitung von Paketen verknüpftes Problem ist die Art und Weise, in der während Datenübertragung und -empfang Daten zwischen "Benutzerplatz" (z.B. Datenspeicher eines Anwendungsprogramms) und "Systemplatz" (z.B. Systemspeicher) bewegt werden. Gegenwärtig werden Daten einfach von dem einem, einem Benutzer oder Anwendungsprogramm zugewiesenen Speicherbereich in einen anderen, dem Prozessor zur Verfügung gestellten Speicherbereich kopiert. Da jeder Abschnitt eines Datagramms, der in einem Paket übertragen wird, möglicherweise separat kopiert wird (d.h. ein Byte auf einmal), wird eine nichttriviale Menge Prozessorzeit benötigt, und häufige Übertragungen können sehr viel Bandbreite des Speicherbusses verbrauchen. Erläuternd wird möglicherweise jedes Byte Daten in einem aus dem Netz empfangenen Paket aus dem Systemplatz gelesen und in einer separaten Kopieroperation in den Benutzerplatz geschrieben und umgekehrt für über das Netz übertragene Daten. Der Systemplatz stellt zwar im Allgemeinen einen geschützten Speicherbereich (z.B. vor Manipulation durch Benutzerprogramme geschützt) bereit, die Kopieroperation leistet aber nichts von Wert, wenn vom Standpunkt einer Netzschnittstellenschaltung aus betrachtet. Statt dessen riskiert sie Überlastung des Hauptprozessors und Bremsung seiner Fähigkeit, schnell zusätzlichen Netzverkehr von der NIC aufzunehmen. Separates Kopieren jedes Pakets kann daher sehr ineffizient sein, besonders in einer Hochgeschwindigkeitsnetz-Umgebung.
  • Außer der ineffizienten Datenübertragung (d.h. ein Paket Daten auf einmal) ist auch die Verarbeitung von Anfangsblöcken der aus einem Netz empfangenen Pakete ineffizient. Jedes Paket, das einen Teil eines einzelnen Datagramms befördert, hat zwar im Allgemeinen die gleichen Protokoll-Anfangsblöcke (z.B. TCP, IP, Ethernet), es kann aber eine Veränderung in den Werten innerhalb der Paket-Anfangsblöcke für ein bestimmtes Protokoll geben. Jedes Paket wird jedoch durch den gleichen Protokollstapel individuell verarbeitet, was mehrere Wiederholungen von identischen Operationen für verknüpfte Pakete erfordert. Aufeinander folgendes Verarbeiten von unverknüpften Paketen durch unterschiedliche Protokollstapel ist wahrscheinlich viel weniger effizient als fortschreitendes Verarbeiten einer Anzahl von verknüpften Paketen durch einen Protokollstapel auf einmal.
  • Ein anderes Grundproblem in Bezug auf die Wechselwirkung zwischen gegenwärtigen Netzschnittstellenschaltungen und Hauptrechnersystemen ist, dass die Kombination häufig keinen Nutzen aus den vergrößerten Prozessorressourcen ziehen kann, die in Mehrprozessor-Computersystemen zur Verfügung stehen. Mit anderen Worten, gegenwärtige Versuche, die Verarbeitung von Netzpaketen (z.B. durch einen Protokollstapel) in einer effizienten Weise auf eine Anzahl von Protokollen zu verteilen, sind allgemein ineffektiv. Insbesondere kommt die Leistung von gegenwärtigen NICs nicht nahe an die erwarteten oder gewünschten linearen Leistungsgewinne heran, die bei Verfügbarkeit von mehreren Prozessoren erwartungsgemäß zu realisieren wären. In manchen Mehrprozessorsystemen wird bei Verwendung von zum Beispiel mehr als 4 bis 6 Prozessoren wenig Verbesserung bei der Verarbeitung von Netzverkehr realisiert.
  • Außerdem kann es sein, dass die Geschwindigkeit, mit der Pakete von einer Netzschnittstellenschaltung an einen Hauptrechner oder ein anderes Datenübertragungsgerät übertragen werden, nicht mit der Paketankunftsgeschwindigkeit an der Netzschnittstelle Schritt hält. Das eine oder andere Element des Hauptrechners (z.B. ein Speicherbus, ein Prozessor) kann überlastet oder auf andere Weise unfähig werden, mit genügender Bereitwilligkeit Pakete anzunehmen. In diesem Fall werden möglicherweise ein oder mehr Pakete fallengelassen oder abgeworfen. Fallenlassen von Paketen kann ein Netzobjekt veranlassen, einigen Verkehr neu zu übertragen, und wenn zu viele Pakete fallengelassen werden, erfordert eine Netzverbindung möglicherweise Neuinitialisierung. Weiterhin kann das Fallenlassen eines Pakets oder Pakettyps statt eines anderen einen wesentlichen Unterschied im Gesamtnetzverkehr ausmachen. Wird zum Beispiel ein Steuerpaket fallengelassen, wird die entsprechende Netzverbindung möglicherweise massiv beeinflusst und kann wegen der typischen geringen Größe eines Steuerpakets möglicherweise wenig tun, um die Paketsättigung der Netzschnittstellenschaltung zu mildern. Wird daher das Fallenlassen von Paketen nicht auf eine Weise durchgeführt, die die Wirkung auf viele Netzverbindungen verteilt oder die auf bestimmte Typen von Paketen Rücksicht nimmt, wird der Netzverkehr möglicherweise mehr als notwendig verschlechtert.
  • Daher können gegenwärtige NICs keine angemessene Leistung zur Verbindung von heutigen Hochleistungs-Computersystemen und Hochgeschwindigkeitsnetzen bereitstellen. Außerdem kann eine Netzschnittstellenschaltung, die auf einen überlasteten Hauptrechner keine Rücksicht nehmen kann, die Computerleistung verschlechtern.
  • "IP Switching and Gigabit Routers" von Peter Newman et al., IEEE Communications Magazine, Band 35, Nr. 1, 1977, Seiten 64–69, bespricht Gigabit-Router und IP-Vermittlungsstellen zum Weiterleiten von IP-Verkehr. IP-Vermittlungsstellen leiten Verkehr auf der Basis von Flüssen, deren Abwicklung durch das erste Paket in dem Fluss bestimmt wird.
  • "IETF Multiprotocol Label Switching (MPLS) Architecture" von Francois Le Faucheur, IEEE International Conference on ATM, 22. Juni 1998, Seiten 6–15, diskutiert die Verwendung der MPLS-Technologie zum Transport eines Ebene-3-Protokolls über irgendeine Ebene-2-Technologie. Bei MPLS werden Pakete markiert, um den Datenübertragungsstrom zu kennzeichnen, zu dem sie gehören. Die Markierung eines Pakets wird an Vermittlungsstellen benutzt, um die nächste Etappe des Pakets zu bestimmen.
  • Die WO 97 28505 A offenbart ein Verfahren und eine Vorrichtung zum dynamischen Umschalten zwischen Leiten und Vermitteln von Paketen. Werden Pakete an einem stromabwärtigen Knoten empfangen, werden sie klassifiziert, um zu bestimmen, ob sie zu einem Fluss gehören, der umzuleiten ist. Wenn ja, wird dem stromaufwärtigen Knoten eine freie Markierung zur Anbringung an Paketen in diesem Fluss geliefert.
  • "RFC 1932: IP over ATM: A Framework Document" von R. Cole et al., IETF Network Working Group, http://hlapic.srce.hr/cgi-bin/rfc/rfc1932.txt, April 1996, Seiten 1–31, diskutiert Methoden zum Leiten von IP-Paketen über ATM-Teilnetze. Bei einer verbindungsorientierten Methode werden virtuelle Kanäle eingerichtet, die auf Basis eines Zeitzählers abgebrochen werden können.
  • Die US-A-5 684 954 offenbart ein Verfahren und eine Vorrichtung zum Verarbeiten von Feldern eines einem Datenstrom vorhergehenden Protokoll-Anfangsblocks, um eine Verbindungskennung zum Verarbeiten des Datenstroms zu erzeugen. Es werden Protokolltyp-Informationen eines ersten Protokolls extrahiert, und danach werden Informationen hinsichtlich der auf dem ersten Protokoll aufgebauten Protokolle gelesen. Das Protokoll und die Protokolltyp-Informationen werden benutzt, um die Verbindungskennung zu erzeugen.
  • Die WO 99 00949 A offenbart ein Mehrschicht-Netzelement zum Versenden von Paketen von einem Eingangs-Port zu einem Ausgangs-Port mit Dienstgüte. Pakete werden zufällig abgeworfen, wenn Ausgangswarteschlangen einen spezifizierten Schwellenwert unterhalb ihrer Kapazitäten erreichen. Die Priorität eines Flusses, der eine Warteschlange überlaufen lässt, wird erniedrigt.
  • Die WO 99 00737 A offenbart ein System und ein Verfahren zum Aktualisieren von Paket-Anfangsblöcken. Ein Eingangs-Port-Prozess (IPP) puffert ein Paket und liefert Anfangsblock-Informationen an eine Suchmaschine. Die Suchmaschine versorgt den IPP mit Pakettyp-Informationen, die dann selektiv Felder der Paket-Anfangsblöcke ersetzen.
  • ZUSAMMENFASSUNG
  • In einer Ausführungsform der Erfindung werden ein System und ein Verfahren zum Verteilen der Verarbeitung von Netzpaketen auf mehrere Prozessoren in einem Mehrprozessor-Computer bereitgestellt. Während so einer verteilten Verarbeitung können ein oder mehrere Anfangsblöcke, die Datenübertragungsprotokollen zugeordnet sind, die benutzt werden, um die Pakete aufzubauen und zu übertragen, entfernt werden.
  • Ein Datenübertragungsgerät wie z.B. eine Hochleistungs-Netzschnittstelle empfängt ein Paket aus einem Netz. Es werden Kennungen der Quellen- und Zielobjekte des Pakets erzeugt oder zusammengesetzt, um einen Flussschlüssel zu bilden. Der Flussschlüssel kennzeichnet den Datenfluss, die Verbindung oder die Schaltung, der bzw. die das Paket enthält.
  • In dieser Ausführungsform wird eine Hash-Funktion am Flussschlüssel durchgeführt, um eine Zahl zu erzeugen, die größenmäßig kleiner als der Flussschlüssel ist und die relativ gleichmäßig auf einen Bereich von möglichen Werten verteilt ist. Mit dem Resultat der Hash-Funktion wird dann eine Modulus-Funktion über die Zahl der Prozessoren im Hauptrechnersystem durchgeführt. Das Resultat der Modulus-Funktion ist eine Zahl, die den Prozessor kennzeichnet, der dieses Paket verarbeiten soll. Andere Pakete im selben Datenfluss, die denselben Flussschlüssel erzeugen, werden demselben Prozessor vorgelegt. Erläuternd erzeugt jedoch ein von einem anderen Quellenobjekt oder für ein anderes Zielobjekt empfangenes Paket einen anderen Flussschlüssel und wird einem anderen Prozessor vorgelegt.
  • Die Zahl der Prozessoren im Hauptrechner kann von Software gespeichert werden, die auf dem Hauptrechner arbeitet, wie z.B. einem Gerätetreiber für das Datenübertragungsgerät. Wenn die Software das Paket von dem Gerät empfängt, legt sie das Paket dem bezeichneten Prozessor zur Verarbeitung durch ein oder mehr Protokolle vor, in Übereinstimmung mit denen das Paket formatiert wurde.
  • In einer anderen Ausführungsform der Erfindung wird eine Modulus-Funktion direkt am Flussschlüssel durchgeführt.
  • In noch einer anderen Ausführungsform der Erfindung kann eine Lastverteilung für ein Paket inaktiviert werden, das nicht in Übereinstimmung mit einem oder mehreren eines Satzes von vorgewählten Protokollen formatiert ist. Ist zum Beispiel das Netz, das das Paket transportiert, das Internet, können die vorgewählten Protokolle das Internet-Protokoll und das Transportsteuerprotokollumfassen. Ein Datenübertragungsgerät in dieser Ausführungsform kann ein Anfangsblock-Analysatormodul enthalten, das konfiguriert ist, in Übereinstimmung mit diesen Protokollen formatierte Pakete zu analysieren, damit andere Operationen ermöglicht werden, wie z.B. das Wiederzusammensetzen von Daten oder die kollektive Verarbeitung von mehreren Paketen in einem Datenfluss. Das Datenübertragungsgerät kann außerdem eine Flussdatenbank oder einen Flussdatenbankmanager zum Verwalten der am Gerät empfangenen Datenübertragungsflüsse enthalten.
  • KURZE BESCHREIBUNG DER FIGUREN
  • 1A ist ein Blockdiagramm, dass eine Netzschnittstellenschaltung (NIC) für Empfang eines Pakets aus einem Netz in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 1B ist ein Flussdiagramm, das ein Verfahren zum Betrieb der NIC von 1A zur Übertragung eines aus einem Netz empfangenen Pakets an einen Hauptrechner in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt.
  • 2 ist ein Diagramm eines über ein Netz übertragenes und an einer Netzschnittstellenschaltung empfangenen Pakets in einer Ausführungsform der Erfindung.
  • 3 ist ein Blockdiagramm, dass einen Anfangsblock-Analysator einer Netzschnittstellenschaltung zum Analysieren eines Pakets in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt.
  • 4A bis 4B enthalten ein Flussdiagramm, das ein Verfahren zum Analysieren eines aus einem Netz an einer Netzschnittstellenschaltung empfangenen Pakets in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 5 ist ein Blockdiagramm, dass eine Netzschnittstellenschaltungs-Flussdatenbank in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt.
  • 6A bis 6E enthalten ein Flussdiagramm, das ein Verfahren zum Verwalten einer Netzschnittstellenschaltungs-Flussdatenbank in Übereinstimmung mit einer Ausführungsform der Erfindung darstellt.
  • 7 ist ein Flussdiagramm, das ein Verfahren zum Verteilen der Verarbeitung von Netzpaketen auf mehrere Prozessoren in einem Hauptrechner in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt.
  • 8 zeigt einen Satz von dynamischen Befehlen zum Analysieren eines Pakets in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • DETAILLIERTE BESCHREIBUNG
  • Die folgende Beschreibung wird gegeben, um einen Fachmann in die Lage zu versetzen, die Erfindung zu realisieren und zu verwenden, und wird im Kontext bestimmter Anwendungen der Erfindung und ihrer Erfordernisse gegeben. Für den Fachmann ergeben sich leicht zahlreiche Modifikationen der offenbarten Ausführungsformen, und die hierin definierten allgemeinen Prinzipien können auf andere Ausführungsformen und Anwendungen angewendet werden, ohne den Schutzbereich der vorliegenden Erfindung zu verlassen. Daher soll die vorliegende Erfindung nicht auf die gezeigten Ausführungsformen beschränkt sein, sondern ist mit dem breitesten Schutzumfang in Einklang zu bringen, der mit den hierin offenbarten Prinzipien und Merkmalen verträglich ist.
  • Insbesondere werden nachfolgend Ausführungsformen der Erfindung in Form einer Netzschnittstellenschaltung (NIC) beschrieben, die Datenpakete empfängt, die in Übereinstimmung mit bestimmten Datenübertragungsprotokollen formatiert sind, die mit dem Internet kompatibel sind. Der Fachmann erkennt jedoch, dass die vorliegende Erfindung nicht auf mit dem Internet kompatible Datenübertragungsprotokolle beschränkt ist und leicht für Verwendung mit anderen Protokollen und in anderen Kommunikationsgeräten als einer NIC angepasst werden kann.
  • Die Programmumgebung, in der eine vorliegende Ausführungsform der Erfindung ausgeführt wird, enthält erläuternd einen Universalrechner oder ein Spezialgerät wie z.B. einen tragbaren Rechner. Die Einzelheiten solcher Geräte (z.B. Prozessor, Speicher, Datenspeicher, Ein-/Ausgabe-Ports und Anzeige) sind bekannt und sind der Übersichtlichkeit halber weggelassen.
  • Außerdem versteht sich, dass die Techniken der vorliegenden Erfindung unter Verwendung mannigfacher Technologien realisiert werden können. Zum Beispiel können die hierin beschriebenen Verfahren in Software realisiert werden, die auf einem programmierbaren Mikroprozessor läuft, oder unter Verwendung einer Kombination von Mikroprozessoren oder anderen speziell gestalteten anwendungsspezifischen integrierten Schaltungen, programmierbaren Logikvorrichtungen oder verschiedenen Kombinationen davon in Hardware realisiert werden. Insbesondere können die hierin beschriebenen Verfahren durch eine Folge von computerausführbaren Befehlen realisiert werden, die sich auf einem Speichermedium wie z.B. einer Trägerwelle, einem Plattenlaufwerk oder einem anderen computerlesbaren Medium befinden.
  • Einleitung
  • In einer Ausführungsform der vorliegenden Erfindung ist eine Netzschnittstellenschaltung (NIC) konfiguriert, Datenpakete zu empfangen und zu verarbeiten, die zwischen einem Hauptrechnersystem und einem Netz wie z.B. dem Internet ausgetauscht werden. Insbesondere ist die NIC konfiguriert, Pakete zu empfangen und zu verarbeiten, die in Übereinstimmung mit einem Protokollstapel (z.B. einer Kombination von Datenübertragungsprotokollen) formatiert sind, die von einem mit der NIC verbundenen Netz unterstützt werden.
  • Ein Protokollstapel kann unter Bezugnahme auf die siebenschichtige Grundmodellstruktur ISO-OSI (International Standards Organization – Open Systems Interconnection) beschrieben werden. Somit enthält ein Beispiels-Protokollstapel das Transportsteuerprotokoll (TCP) in Schicht vier, Internet-Protokoll in Schicht drei und Ethernet in Schicht zwei. Zu Zwecken der Erörterung kann der Ausdruck "Ethernet" hierin verwendet werden, um die standardisierte Spezifikation 802.3 des IEEE (Institute of Electrical and Electronics Engineers) und auch die Version zwei der nicht standardisierten Form des Protokolls gemeinsam zu bezeichnen. Wo verschiedene Formen des Protokolls unterschieden werden müssen, kann die Standardform durch Einschluss der Bezeichnung "802.3" gekennzeichnet werden.
  • Andere Ausführungsformen der Erfindung sind konfiguriert, mit Datenübertragungen zu arbeiten, die sich an andere Protokolle klammern, die gegenwärtig bekannt (z.B. Apple-Talk, IPX (Internetwork Packet Exchange, Vernetzungspaketaustausch) usw.) oder unbekannt sind. Der Fachmann erkennt, dass die durch diese Erfindung bereitgestellten Verfahren leicht an neue Datenübertragungsprotokolle anpassbar sind.
  • Außerdem kann die nachfolgend beschriebene Verarbeitung von Paketen in anderen Datenübertragungsgeräten als einer NIC durchgeführt werden. Zum Beispiel kann ein Modem, Switch (Vermittlungsgerät), Router (Leitgerät) oder ein anderer Datenübertragungs-Port oder ein anderes Gerät (z.B. seriell, parallel, USB, SCSI) ähnlich konfiguriert und betrieben werden.
  • In den nachfolgend beschriebenen Ausführungsformen der Erfindung empfängt eine NIC ein Paket im Namen eines Hauptrechnersystems oder anderen Datenübertragungsgeräts aus einem Netz. Die NIC analysiert das Paket (z.B. durch Wiedergewinnen von bestimmten Feldern aus einem oder mehreren seiner Protokoll-Anfangsblöcke) und geht so vor, dass die Effizienz vergrößert wird, mit der das Paket an sein Zielobjekt übertragen oder geliefert wird. Die nachfolgend erörterten Geräte und Verfahren zum Vergrößern der Effizienz der Verarbeitung oder Übertragung von Paketen, die aus einem Netz empfangen werden, können auch für Pakete verwendet werden, die sich in der umgekehrten Richtung bewegen (d.h. von der NIC zum Netz).
  • Eine Technik, die auf ankommenden Netzverkehr angewandt werden kann, umfasst, einen oder mehrere Anfangsblöcke eines ankommenden Pakets (z.B. Anfangsblöcke für die Protokolle der Schichten zwei, drei und vier) zu prüfen oder zu analysieren, um die Quellen- und Zielobjekte des Pakets zu kennzeichnen und möglicherweise bestimmte andere Informationen wiederzugewinnen. Unter Verwendung von Kennungen der Datenübertragungsobjekte als Schlüssel können Daten aus mehreren Paketen angesammelt oder wiederzusammengesetzt werden. Typischerweise wird ein von einem Quellenobjekt zu einem Zielobjekt gesendetes Datagramm mittels mehrerer Pakete übertragen. Ansammeln von Daten aus mehreren verknüpften Paketen (z.B. Paketen, die Daten aus demselben Datagramm befördern) erlauben es somit, ein Datagramm wieder zusammenzusetzen und kollektiv an einen Hauptrechner zu übertragen. Das Datagramm kann dem Zielobjekt dann auf eine höchst effiziente Weise geliefert werden. Zum Beispiel, statt Daten aus einem Paket jeweils (und ein Byte auf einmal) in separaten "Kopieroperationen" zu liefern, kann eine "Seitenklapp"-Operation durchgeführt werden. Bei einem Seitenklapp kann dem Zielobjekt eine ganze Speicherseite Daten geliefert werden, möglicherweise im Austausch gegen eine leere oder unbenutzte Seite.
  • Bei einer anderen Technik werden aus einem Netz empfangene Pakete in eine Warteschlange gestellt, um auf Übertragung an einen Computer zu warten. Während sie auf Übertragung warten, können dem Hauptrechner mehrere verknüpfte Pakete gekennzeichnet werden. Nach ihrer Übertragung können sie von einem Hauptprozessor als Gruppe verarbeitet werden, statt seriell (d.h. eines auf einmal) verarbeitet zu werden.
  • Noch eine andere Technik umfasst, eine Anzahl von verknüpften Paketen einem einzelnen Prozessor eines Mehrprozessor-Hauptrechnersystems vorzulegen. Durch Verteilen von zwischen verschiedenen Paaren von Quellen- und Zielobjekten transportierten Paketen auf verschiedene Prozessoren kann die Verarbeitung von Paketen durch ihre jeweiligen Protokollstapel verteilt werden, während Pakete noch in ihrer richtigen Reihenfolge warten.
  • Die oben erörterten Techniken zum Vergrößern der Effizienz, mit der Pakete verarbeitet werden, können eine Kombination aus Hardware- und Software-Modulen umfassen, die sich in einer Netzschnittstelle und/oder einem Hauptrechnersystem befinden. In einer besonderen Ausführungsform analysiert ein Analysemodul in der NIC eines Hauptrechners Anfangsblock-Abschnitte von Paketen. Erläuternd enthält das Analysemodul eine Mikro-Ablaufsteuerung, die in Übereinstimmung mit einem Satz von austauschbaren Befehlen arbeitet, die als Mikrocode gespeichert sind. Unter Verwendung der aus den Paketen extrahierten Informationen können mehrere Pakete von einem Quellenobjekt zu einem Zielobjekt gekennzeichnet werden. Ein Hardware-Wiederzusammensetzmodul in der NIC kann dann die Daten aus den mehreren Paketen zusammenbringen. Ein weiteres Hardware-Modul in der NIC ist konfiguriert, verknüpfte Pakete zu erkennen, die auf Übertragung an den Hauptrechner warten, so dass sie durch einen geeigneten Protokollstapel kollektiv statt seriell verarbeitet werden können. Die wiederzusammengesetzten Daten und die Paket-Anfangsblöcke können dann dem Hauptrechner geliefert werden, so dass geeignete Software (d.h. ein Gerätetreiber für die NIC) die Anfangsblöcke verarbeiten und die Daten an das Zielobjekt abgeben kann.
  • Wenn der Hauptrechner mehrere Prozessoren enthält, kann ein Lastverteiler (der auch in Hardware in der NIC realisiert sein kann) einen Prozessor wählen, um die Anfangsblöcke der mehreren Pakete durch einen Protokollstapel zu verarbeiten.
  • In einer anderen Ausführungsform der Erfindung wird ein System für zufälliges Abwerfen eines Pakets von einer NIC, wenn die NIC mit Paketen, die auf Übertragung an einen Hauptrechner warten, gesättigt oder nahezu gesättigt ist, bereitgestellt.
  • Eine Ausführungsform einer Hochleistungs-Netzschnittstellenschaltung
  • 1A zeigt eine NIC 100, die in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung konfiguriert ist. Es folgt eine kurze Beschreibung von Betrieb und Wechselwirkung der verschiedenen Module der NIC 100 in dieser Ausführungsform.
  • Durch ein Mediumzugriffssteuerungs(MAC)-Modul (in 1A nicht gezeigt) kann ein Datenpaket aus einem Netz 102 an der NIC 100 empfangen werden. Das MAC-Modul führt eine Verarbeitung des Pakets auf niedriger Ebene durch, wie z.B. Lesen des Pakets aus dem Netz, Durchführen einer Fehlerprüfung, Erfassen von Paketfragmenten, Erfassen von übergroßen Paketen, Entfernen der Präambel der Schicht 1 usw.
  • Ein Eingangs-Port-Verarbeitungs(IPP)-Modul 104 empfängt dann das Paket. Das IPP-Modul speichert das ganze Paket in einer Paketwarteschlange 116, wie vom MAC-Modul oder Netz empfangen, und ein Abschnitt des Pakets wird in einen Anfangsblock- Analysator 106 kopiert. In einer Ausführungsform der Erfindung kann das IPP-Modul 104 als Sortenkoordinator zum Vorbereiten des Pakets für Übertragung an ein Hauptrechnersystem arbeiten. In so einer Rolle kann das IPP-Modul 104 Informationen hinsichtlich eines Pakets von verschiedenen Modulen der NIC 100 empfangen und solche Informationen an andere Module versenden.
  • Der Anfangsblock-Analysator 106 analysiert einen Anfangsblock-Abschnitt des Pakets, um verschiedene Informationsbruchstücke wiederzugewinnen, die zur Kennzeichnung von verknüpften Paketen (z.B. mehreren Paketen von demselben Quellenobjekt für ein Zielobjekt) verwendet werden und die die nachfolgende Verarbeitung der Pakete beeinflussen. In dem Ausführungsbeispiel kommuniziert der Anfangsblock-Analysator 106 mit einem Flussdatenbankmanager (FDBM) 108, der eine Flussdatenbank (FDB) 110 verwaltet. Insbesondere legt der Anfangsblock-Analysator 106 dem FDBM 108 eine Frage vor, um zu bestimmen, ob es einen gültigen Datenfluss (nachfolgend beschrieben) zwischen dem Quellenobjekt, das ein Paket sendet, und dem Zielobjekt gibt. Das Zielobjekt kann ein Anwendungsprogramm, ein Datenübertragungsmodul oder ein anderes Element eines Hauptrechnersystems umfassen, das das Paket empfangen soll.
  • In dem Ausführungsbeispiel der Erfindung umfasst ein Datenfluss ein oder mehrere Datagramm-Pakete von einem Quellenobjekt an ein Zielobjekt. Ein Fluss kann durch einen Flussschlüssel gekennzeichnet werden, der aus Quellen- und Zielkennungen zusammengesetzt ist, die durch den Anfangsblock-Analysator 106 aus dem Paket wiedergewonnen werden. In einer Ausführungsform der Erfindung umfasst ein Flussschlüssel Adress- und/oder Port-Informationen für die Quellen- und Zielobjekte aus den Protokoll-Anfangsblöcken der Schicht drei (z.B. IP) und/oder Schicht vier (z.B. TCP) des Pakets.
  • Für die Zwecke des Ausführungsbeispiels der Erfindung ist ein Datenfluss einer durchgehenden TCP-Verbindung ähnlich, hat aber im Allgemeinen eine kürzere Dauer. Insbesondere kann in dieser Ausführungsform die Dauer eines Flusses auf die Zeit begrenzt sein, die nötig ist, um alle Pakete zu empfangen, die zu einem einzelnen Datagramm gehören, das vom Quellenobjekt zum Zielobjekt geleitet wird.
  • Zu Zwecken des Flussmanagements gibt daher der Anfangsblock-Analysator 106 den Flussschlüssel des Pakets an den Flussdatenbankmanager 108 weiter. Der Anfangs block-Analysator kann den Flussdatenbankmanager 108 auch mit anderen Informationen hinsichtlich des aus dem Paket wiedergewonnenen Pakets versorgen (z.B. Länge des Pakets).
  • Als Antwort auf eine vom Anfangsblock-Analysator 106 empfangene Frage durchsucht der Flussdatenbankmanager 108 die FDB 110. Erläuternd speichert die Flussdatenbank 110 Informationen hinsichtlich jedes gültigen Datenflusses, der ein Zielobjekt umfasst, das von der NIC 110 bedient wird. Daher aktualisiert der FDBM 108 nötigenfalls die FDB 110, je nach den vom Anfangsblock-Analysator 106 empfangenen Informationen. Außerdem ordnet in dieser Ausführungsform der Erfindung der FDBM 108 dem empfangenen Paket einen Operations- oder Aktionscode zu. Ein Operationscode kann benutzt werden, um zu bestimmen, ob ein Paket Teil eines neuen oder vorhandenen Flusses ist, ob das Paket Daten oder nur Steuerinformationen enthält, die Datenmenge im Paket, ob die Paketdaten mit verknüpften Daten (z.B. anderen Daten in einem vom Quellenobjekt zum Zielobjekt gesendeten Datagramm) wiederzusammengesetzt werden können usw. Der FDBM 108 kann Informationen benutzen, die aus dem Paket wiedergewonnen und vom Anfangsblock-Analysator 106 geliefert werden, um einen geeigneten Operationscode auszuwählen. Der Operationscode des Pakets wird dann zusammen mit einem Index des Paketflusses innerhalb der FDB 110 an den Anfangsblock-Analysator 106 weitergegeben.
  • In einer Ausführungsform der Erfindung kann die Kombination aus Anfangsblock-Analysator 106, FDBM 108 und FDB 110 oder eine Teilmenge dieser Module als Verkehrsklassifizierer bekannt sein, wegen deren Rolle beim Klassifizieren oder Kennzeichnen von an der NIC 100 empfangenem Netzverkehr.
  • In dem Ausführungsbeispiel gibt der Anfangsblock-Analysator 106 den Paketfluss außerdem an einen Lastverteiler 112 weiter. In einem Hauptrechnersystem mit mehreren Prozessoren kann der Lastverteiler 112 ermitteln, an welchen Prozessor ein ankommendes Paket zur Verarbeitung durch den geeigneten Protokollstapel zu leiten ist. Der Lastverteiler 112 kann zum Beispiel sicherstellen, dass verknüpfte Pakete an einen einzelnen Prozessor geleitet werden. Indem alle Pakete in einem Datenfluss oder einer durchgehenden Verbindung an einen einzelnen Prozessor geleitet werden, kann das richtige Anordnen von Paketen erzwungen werden. In einer alternativen Ausführungsform der Erfindung kann der Lastverteiler 112 weggelassen werden. In einer alternati ven Ausführungsform kann der Anfangsblock-Analysator 106 auch direkt mit anderen Modulen der NIC 110 außer dem Lastverteiler und dem Flussdatenbankmanager kommunizieren.
  • Nachdem der Anfangsblock-Analysator 106 ein Paket analysiert hat, ändert oder aktualisiert der FDBM 108 die FDB 110, und der Lastverteiler 112 bestimmt einen Prozessor im Hauptrechnersystem, um das Paket zu verarbeiten. Nach diesen Aktionen gibt der Anfangsblock-Analysator verschiedene Informationen an das IPP-Modul 104 zurück. Erläuternd können diese Informationen den Flussschlüssel des Pakets, einen Index des Paketflusses innerhalb der Flussdatenbank 110, eine Kennung eines Prozessors im Hauptrechnersystem und verschiedene andere Daten hinsichtlich des Pakets (z.B. seine Länge, Länge eines Paket-Anfangsblocks) umfassen.
  • Das Paket kann nun in einer Paketwarteschlange 116 gespeichert werden, welche Pakete zur Verarbeitung durch eine DMA(Direktspeicherzugriff)-Maschine 120 und Übertragung an einen Hauptrechner festhält. Außer dass das Paket in einer Warteschlange gespeichert wird, wird ein entsprechender Eintrag für das Paket in einer Steuerwarteschlange 118 vorgenommen und können auch Informationen hinsichtlich des Paketflusses an ein dynamisches Paketschubmodul 122 weitergegeben werden. Die Steuerwarteschlange 118 enthält verknüpfte Informationen für jedes Paket in der Paketwarteschlange 116.
  • Das Paketschubmodul 122 greift auf Informationen hinsichtlich Paketen in der Paketwarteschlange 116 zurück, um die schubweise (d.h. kollektive) Verarbeitung von Anfangsblöcken von mehreren verknüpften Paketen zu ermöglichen. In einer Ausführungsform der Erfindung signalisiert das Paketschubmodul 122 dem Hauptrechner die Verfügbarkeit von Anfangsblöcken von verknüpften Paketen, so dass sie zusammen verarbeitet werden können.
  • In einer Ausführungsform der Erfindung wird die Verarbeitung der Protokoll-Anfangsblöcke eines Pakets zwar durch einen Prozessor in einem Hauptrechnersystem durchgeführt, in einer anderen Ausführungsform können die Protokoll-Anfangsblöcke aber durch einen in der NIC 110 angesiedelten Prozessor verarbeitet werden. In der ersteren Ausführungsform kann Software auf dem Hauptrechner (z.B. ein Gerätetreiber für die NIC 100) die Vorteile von zusätzlichem Speicher und einem austauschbaren oder aufrüstbaren Prozessor ernten (z.B. kann der Speicher ergänzt werden und kann der Prozessor durch ein schnelleres Modell ersetzt werden).
  • Während des Speicherns eines Pakets in der Paketwarteschlange 116 kann ein Prüfsummengenerator 114 eine Prüfsummenoperation durchführen. Die Prüfsumme kann der Paketwarteschlange als Anhang zum Paket hinzugefügt werden. Erläuternd erzeugt der Prüfsummengenerator 114 eine Prüfsumme aus einem Abschnitt des aus dem Netz 102 empfangenen Pakets. In einer Ausführungsform der Erfindung wird eine Prüfsumme aus dem TCP-Abschnitt eines Pakets (z.B. dem TCP-Anfangsblock und Daten) erzeugt. Ist ein Paket nicht in Übereinstimmung mit dem TCP-Protokoll formatiert, kann eine Prüfsumme aus einem anderen Abschnitt des Pakets erzeugt werden, und das Resultat kann nötigenfalls bei späterer Verarbeitung berichtigt werden. Zum Beispiel, wenn die vom Prüfsummengenerator 114 berechnete Prüfsumme nicht am richtigen Abschnitt des Pakets berechnet wurde, kann die Prüfsumme berichtigt werden, um den richtigen Abschnitt zu erfassen. Diese Berichtigung kann mittels Software durchgeführt werden, die auf einem Hauptrechnersystem arbeitet (z.B. einem Gerätetreiber). In einer alternativen Ausführungsform der Erfindung kann der Prüfsummengenerator 114 weggelassen oder in ein anderes Modul der NIC 100 gelegt werden.
  • Mit den vom Anfangsblock-Analysator 106 erhaltenen Informationen und den vom Flussdatenbankmanager 108 verwalteten Flussinformationen ist das von der NIC 100 bediente Hauptrechnersystem in dem Ausführungsbeispiel in der Lage, Netzverkehr sehr effizient zu verarbeiten. Zum Beispiel können Datenabschnitte von verknüpften Paketen von der DMA-Maschine 120 wiederzusammengesetzt werden, um Ansammlungen zu bilden, die effizienter verarbeitet werden können. Und indem die Daten in Puffern von der Größe einer Speicherseite zusammengesetzt werden, können die Daten durch "Seitenklappen", bei dem eine ganze von der DMA-Maschine 120 gefüllte Speicherseite auf einmal bereitgestellt wird, effizienter an ein Zielobjekt übertragen werden. Ein Seitenklapp kann somit die Stelle von mehreren Kopieroperationen einnehmen. Indessen können die Anfangsblock-Abschnitte der wiederzusammengesetzten Pakete durch ihren geeigneten Protokollstapel ähnlich als eine Gruppe verarbeitet werden.
  • Wie schon beschrieben, kann in einer anderen Ausführungsform der Erfindung die Verarbeitung von Netzverkehr durch geeignete Protokollstapel effizient in einem Mehrprozessor-Hauptrechnersystem verteilt werden. In dieser Ausführungsform ordnet oder teilt der Lastverteiler 112 verknüpfte Pakete (z.B. Pakete im selben Datenfluss) demselben Prozessor zu. Insbesondere können Pakete mit denselben Quellen- und Zieladressen in ihren Anfangsblöcken der Protokollschicht drei (z.B. IP) und/oder denselben Quellen- und Ziel-Ports in ihren Anfangsblöcken der Protokollschicht vier (z.B. TCP) an einen einzelnen Prozessor gesendet werden.
  • Bei der in 1A gezeigten NIC sind die oben erörterten Verarbeitungsverbesserungen (z.B. Wiederzusammenbau von Daten, Schubverarbeitung von Paket-Anfangsblöcken, Verteilen der Protokollstapelverarbeitung) für aus dem Netz 102 empfangene Pakete möglich, die in Übereinstimmung mit einem oder mehreren vorgewählten Protokollstapeln formatiert sind. In dieser Ausführungsform der Erfindung ist das Netz 102 das Internet, und die NIC 100 ist daher konfiguriert, Pakete unter Verwendung von einem oder mehreren Protokollstapeln zu verarbeiten, die mit dem Internet kompatibel sind. Pakete; die nicht in Übereinstimmung mit den vorgewählten Protokollen konfiguriert sind, werden ebenfalls verarbeitet, können aber nicht die Vorzüge des ganzen Gefolges von Verarbeitungseffizienzen erleben, die Paketen gegeben werden, die den vorgewählten Protokollen genügen.
  • Zum Beispiel können Pakete, die nicht zu einem der vorgewählten Protokollstapel passen, auf Basis der Quellen- und Zieladressen der Paketschicht zwei (d.h. Mediumzugriffssteuerung) statt ihrer Adressen der Schicht drei oder vier zur Verarbeitung in einem Mehrprozessorsystem verteilt werden. Kennungen der Schicht zwei zu verwenden, gibt der Lastverteilungsprozedur weniger Körnigkeit, was die Verarbeitung von Paketen möglicherweise weniger gleichmäßig verteilt als wenn Kennungen der Schicht drei/vier benutzt werden.
  • 1B zeigt ein Verfahren zur Verwendung der NIC 100 von 1A für Empfang eines Pakets aus dem Netz 102 und dessen Übertragung an einen Hauptrechner. Der Zustand 130 ist ein Startzustand, möglicherweise durch die Initialisierung oder das Zurücksetzen der NIC 100 charakterisiert.
  • Im Zustand 132 wird ein Paket von der NIC 100 aus dem Netz 102 empfangen. Wie schon beschrieben, kann das Paket in Übereinstimmung mit mannigfachen Datenübertragungsprotokollen formatiert sein. Das Paket kann von einem MAC-Modul empfangen und anfänglich verarbeitet werden, bevor es an ein IPP-Modul weitergegeben wird.
  • Im Zustand 134 wird ein Abschnitt des Pakets kopiert und an den Anfangsblock-Analysator 106 weitergegeben. Der Anfangsblock-Analysator 106 analysiert dann das Paket, um aus einem oder mehreren seiner Anfangsblöcke und/oder seiner Daten Werte zu extrahieren. Aus einigen der wiedergewonnenen Informationen wird ein Flussschlüssel erzeugt; um den Datenfluss zu kennzeichnen, der das Paket enthält. Der Grad oder das Maß, in dem das Paket analysiert wird, kann insofern von seinen Protokollen abhängen, als der Anfangsblock-Analysator konfiguriert sein kann, Anfangsblöcke von verschiedenen Protokollen in verschiedenen Tiefen zu analysieren. Insbesondere kann der Anfangsblock-Analysator 106 für einen spezifischen Satz von Protokollen oder Protokollstapeln optimiert (z.B. seine Operationsbefehle konfiguriert) sein. Wenn das Paket einem oder mehreren der spezifizierten Protokolle entspricht, kann es vollständiger analysiert werden als ein Paket, das sich an keines der Protokolle klammert.
  • Im Zustand 136 werden die aus den Paket-Anfangsblöcken extrahierten Informationen zum Flussdatenbankmanager 108 und/oder Lastverteiler 112 weitergeleitet. Der FDBM benutzt die Informationen zum Einrichten eines Flusses in der Flussdatenbank 110, wenn für diesen Datenfluss nicht schon einer existiert. Wenn schon ein Eintrag für den Paketfluss existiert, kann er aktualisiert werden, um den Empfang eines neuen Flusspakets widerzuspiegeln. Weiterhin erzeugt der FDBM 108 einen Operationscode zum Zusammenfassen von einem oder mehreren Merkmalen oder Bedingungen des Pakets. Der Operationscode kann von anderen Modulen der NIC 100 benutzt werden, um das Paket auf eine geeignete Weise abzuwickeln, wie in nachfolgenden Abschnitten beschrieben. Der Operationscode wird zusammen mit einem Index (z.B. Flussnummer) des Paketflusses in der Flussdatenbank an den Anfangsblock-Analysator zurückgesendet.
  • Im Zustand 138 ordnet der Lastverteiler 112 dem Paket eine Prozessornummer zu, wenn der Hauptrechner mehrere Prozessoren enthält, und sendet die Prozessornummer an den Anfangsblock-Prozessor zurück. Erläuternd kennzeichnet die Prozessornummer, welcher Prozessor das Paket durch seinen Protokollstapel auf dem Hauptrechner leiten soll. Der Zustand 138 kann in einer alternativen Ausführungsform der Erfindung weggelassen werden, insbesondere wenn der Hauptrechner nur aus einem einzigen Prozessor besteht.
  • Im Zustand 140 wird das Paket in der Paketwarteschlange 116 gespeichert. Wenn der Inhalt des Pakets in die Paketwarteschlange gesetzt wird, kann der Prüfsummengenerator 114 eine Prüfsumme berechnen. Dem Prüfsummengenerator kann vom IPP-Modul 104 mitgeteilt werden, für welchen Abschnitt des Pakets die Prüfsumme zu berechnen ist. Die berechnete Prüfsumme wird der Paketwarteschlange als Anhang zum Paket hinzugefügt. In einer Ausführungsform der Erfindung wird das Paket im Wesentlichen im gleichen Zeitpunkt in der Paketwarteschlange gespeichert, in dem eine Kopie des Anfangsblock-Abschnitts des Pakets dem Anfangsblock-Analysator 106 zur Verfügung gestellt wird.
  • Außerdem werden im Zustand 140 Steuerinformationen für das Paket in der Steuerwarteschlange 118 gespeichert, und Informationen hinsichtlich des Paketflusses (z.B. Flussnummer, Flussschlüssel) können dem dynamischen Paketschubmodul 122 zur Verfügung gestellt werden.
  • Im Zustand 142 ermittelt die NIC 100, ob das Paket bereit ist, an den Hauptrechnerspeicher übertragen zu werden. Bis es zur Übertragung bereit ist, wartet die dargestellte Prozedur.
  • Wenn das Paket zur Übertragung bereit ist (z.B. liegt das Paket am Kopf der Paketwarteschlange, oder der Hauptrechner empfängt das Paket vor diesem Paket in der Paketwarteschlange), ermittelt im Zustand 114 das dynamische Paketschubmodul 122, ob bald ein verknüpftes Paket übertragen wird. Wenn ja, wird, wenn das gegenwärtige Paket zum Hauptrechner übertragen wird, dem Hauptrechner signalisiert, dass bald ein verknüpftes Paket folgen wird. Der Hauptrechner kann dann die Pakete (z.B. durch ihren Protokollstapel) als eine Gruppe verarbeiten.
  • Im Zustand 146 wird das Paket (z.B. über eine Direktspeicherzugriffs-Operation) an einen Hauptrechnerspeicher übertragen. Und im Zustand 148 wird dem Hauptrechner gemeldet, dass das Paket übertragen wurde. Die dargestellte Prozedur endet im Zustand 150.
  • Der Fachmann auf dem Gebiet der Computersysteme und Vernetzung erkennt, dass die oben beschriebene Prozedur nur ein Verfahren ist, die Module der NIC 100 zu be nutzen, um ein einzelnes Paket aus einem Netz zu empfangen und es an ein Hauptrechnersystem zu übertragen. Innerhalb des Schutzbereichs der Erfindung werden auch andere geeignete Methoden erwogen.
  • Ein Beispielpaket
  • 2 ist ein Diagramm eines von der NIC 100 aus dem Netz 102 empfangenen Beispielpakets. Das Paket 200 enthält einen Datenabschnitt 202 und einen Anfangsblock-Abschnitt 204 und kann außerdem einen Anhangabschnitt 206 enthalten. Je nach der vom Paket 200 durchlaufenen Netzumgebung kann seine maximale Größe (z.B. seine maximale Übertragungseinheit oder MTU) begrenzt sein.
  • Im Ausführungsbeispiel enthält der Datenabschnitt 202 Daten, die an ein Ziel- oder Empfangsobjekt innerhalb eines Computersystems (z.B. Benutzer, Anwendungsprogramm; Betriebssystem) oder eines Datenübertragungs-Teilsystems des Computers zu liefern sind. Der Anfangsblock-Abschnitt 204 enthält einen oder mehrere Anfangsblöcke, die dem Datenabschnitt durch das Quellen- oder Ursprungsobjekt eines Computersystems, das das Quellenobjekt enthält, vorangestellt werden. Jeder Anfangsblock entspricht normalerweise einem anderen Datenübertragungsprotokoll.
  • In einer typischen Netzumgebung wie z.B. dem Internet werden individuelle Anfangsblöcke innerhalb des Anfangsblock-Abschnitts 204 angebracht (z.B. vorn angefügt), wenn das Paket durch verschiedene Schichten eines Protokollstapels (z.B. einem Satz von Protokollen für Datenübertragung zwischen Objekten) auf dem sendenden Computersystem verarbeitet wird. Zum Beispiel zeigt 2 Protokoll-Anfangsblöcke 210, 212, 214 und 216 entsprechend den Schichten eins bis vier eines geeigneten Protokollstapels. Jeder Protokoll-Anfangsblock enthält Informationen zur Verwendung durch das empfangende Computersystem, wenn das Paket durch den Protokollstapel empfangen und verarbeitet wird. Zum Schluss wird jeder Protokoll-Anfangsblock entfernt, und der Datenabschnitt 202 wird wiedergewonnen.
  • Wie in anderen Abschnitten beschrieben, werden in einer Ausführungsform der Erfindung ein System und Verfahren bereitgestellt, ein Paket 200 zu analysieren, um verschiedene Informationsbits wiederzugewinnen. In dieser Ausführungsform wird das Paket 200 analysiert, um den Beginn des Datenabschnitts 202 zu bestimmen und einen oder mehrere Werte für Felder innerhalb des Anfangsblock-Abschnitts 204 wiederzugewinnen. Erläuternd entspricht jedoch der Protokoll-Anfangsblock oder die Präambel 210 der Schicht eins einer Spezifikation auf Hardware-Ebene, die mit der Codierung von individuellen Bits verknüpft ist. Protokolle der Schicht eins werden im Allgemeinen nur für den physischen Prozess benötigt, das Paket über einen Leiter zu senden oder zu empfangen. In dieser Ausführungsform der Erfindung wird daher eine Präambel 210 der Schicht eins vom Paket 200 abgestreift, kurz nachdem es von der NIC 100 empfangen worden ist, und wird daher nicht analysiert.
  • Der Grad, bis zu dem der Anfangsblock-Abschnitt 204 analysiert wird, kann davon abhängen, wie viele, wenn es welche gibt, der im Anfangsblock-Abschnitt dargestellten Protokolle zu einem Satz von vorgewählten Protokollen passen. Zum Beispiel kann die Analysierprozedur abgekürzt oder abgebrochen werden, wenn festgestellt wird, dass einer der Anfangsblöcke des Pakets einem nicht unterstützten Protokoll entspricht.
  • Insbesondere ist in einer Ausführungsform der Erfindung die NIC 100 in erster Linie für Internet-Verkehr konfiguriert. Daher wird in dieser Ausführungsform das Paket 200 nur dann umfassend analysiert, wenn das Protokoll der Schicht zwei Ethernet ist (entweder traditionelles Ethernet oder 802.3-Ethernet, mit oder ohne Kennzeichnung für virtuelle lokalen Netze), das Protokoll der Schicht drei IP (Internet-Protokoll) ist und das Protokoll der Schicht vier TCP (Transportsteuerprotokoll) ist. Pakete, die sich an andere Protokolle klammern, können bis zu einem gewissen (z.B. kleineren) Grad analysiert werden. Die NIC 100 kann jedoch konfiguriert werden, praktisch jeden Datenübertragungsprotokoll-Anfangsblock zu unterstützen und zu analysieren. Erläuternd werden die Protokoll-Anfangsblöcke, die analysiert werden, und der Grad, bis zu dem sie analysiert werden, durch die Konfiguration eines Satzes von Befehlen zum Betrieb des Anfangsblock-Analysators 106 festgelegt.
  • Wie oben beschrieben, hängen die Protokolle entsprechend den Anfangsblöcken 212, 214 und 216 von der Netzumgebung ab, in die das Paket gesendet wird. Die Protokolle hängen außerdem von den kommunizierenden Objekten ab. Zum Beispiel kann ein Paket, das von einer Netzschnittstelle empfangen wird, ein Steuerpaket sein, das zwischen den Mediumzugriffssteuergeräten für die Quellen- und Zielcomputersysteme ausgetauscht wird. In diesem Fall würde das Paket wahrscheinlich minimale oder keine Daten enthalten und möglicherweise keinen Anfangsblock 214 der Protokollschicht drei oder Anfangsblock 216 der Protokollschicht vier enthalten. Steuerpakete werden typischerweise für verschiedene Zwecke benutzt, die mit der Verwaltung von individuellen Verbindungen verknüpft sind.
  • Ein anderer Datenfluss oder eine andere Datenverbindung könnte zwei Anwendungsprogramme umfassen. In diesem Fall kann ein Paket Anfangsblöcke 212, 214 und 216 enthalten, wie in 2 gezeigt, und kann außerdem zusätzliche Anfangsblöcke enthalten, die mit höheren Schichten eines Protokollstapels verknüpft sind (z.B. Sitzungs-, Darstellungs- und Anwendungsschichten im ISO-OSI-Modell). Außerdem können manche Anwendungen Anfangsblöcke oder Anfangsblock-ähnliche Informationen innerhalb des Datenabschnitts 202 enthalten. Zum Beispiel für eine Netzdateisystem(Network File System, NFS)-Anwendung kann der Datenabschnitt 202 NFS-Anfangsblöcke enthalten, die mit individuellen NFS-Datagrammen verknüpft sind. Ein Datagramm kann als eine Sammlung von Daten definiert sein, die von einem Objekt zu einem anderen gesendet werden, und kann Daten aufweisen, die in mehreren Paketen übertragen werden. Mit anderen Worten, die Datenmenge, die ein Datagramm bildet, kann größer sein als die Datenmenge, die in einem Paket enthalten sein kann.
  • Eine Ausführungsform eines Anfangsblock-Analysators
  • 3A zeigt den Anfangsblock-Analysator 106 von 1A in Übereinstimmung mit einer vorliegenden Ausführungsform der Erfindung. Erläuternd enthält der Anfangsblock-Analysator 106 einen Anfangsblockspeicher 302 und einen Analysator 304, und der Analysator 304 enthält einen Befehlsspeicher 306. Obwohl in 3 als getrennte Module gezeigt, sind in einer alternativen Ausführungsform der Erfindung der Anfangsblockspeicher 302 und der Befehlsspeicher 306 zusammenhängend.
  • Im Ausführungsbeispiel analysiert der Analysator 304 einen im Anfangsblockspeicher 302 gespeicherten Anfangsblock in Übereinstimmung mit Befehlen, die im Befehlsspeicher 306 gespeichert sind. Die Befehle sind für das Analysieren von bestimmten Protokollen oder eines bestimmten Protokollstapels ausgelegt, wie oben erörtert. In einer Ausführungsform der Erfindung ist der Befehlsspeicher 306 modifizierbar (z.B. ist der Speicher als RAM, EPROM, EEPROM oder dergleichen ausgeführt), so dass neue oder modifizierte Analysierbefehle heruntergeladen oder auf andere Weise installiert werden können. Befehle zum Analysieren eines Pakets werden im folgenden Abschnitt näher erörtert.
  • In 3 wird ein Anfangsblock-Abschnitt eines im IPP-Modul 104 (in 1A gezeigt) gespeicherten Pakets in den Anfangsblockspeicher 302 kopiert. Erläuternd werden eine spezifische Zahl von Bytes (z.B. 114) am Beginn des Pakets kopiert. In einer alternativen Ausführungsform der Erfindung kann der Abschnitt eines Pakets, der kopiert wird, eine andere Größe haben. Die in den Anfangsblockspeicher 302 kopierte bestimmte Menge eines Pakets sollte so groß sein, dass ein oder mehrere Protokoll-Anfangsblöcke oder mindestens so viel Informationen (z.B. ob in einem Anfangsblock- oder Datenabschnitt des Pakets enthalten) erfasst werden, um die weiter unten beschriebenen Informationen wiederzugewinnen. Der im Anfangsblockspeicher 302 gespeicherte Anfangsblock-Abschnitt enthält möglicherweise nicht den Anfangsblock der Schicht eins, der vor oder in Verbindung mit der Verarbeitung des Pakets durch das IPP-Modul 104 entfernt werden kann.
  • Nachdem ein Anfangsblock-Abschnitt im Anfangsblockspeicher 302 gespeichert worden ist, analysiert der Analysator 304 den Anfangsblock-Abschnitt in Übereinstimmung mit den im Befehlsspeicher 306 gespeicherten Befehlen. Befehle zum Betrieb des Analysators 304 in der vorliegend beschriebenen Ausführungsform wenden die Formate von ausgewählten Protokollen an, um die Inhalte des Anfangsblockspeichers 302 durchzugehen und spezifische Informationen wiederzugewinnen. Insbesondere sind Spezifikationen von Datenübertragungsprotokollen bekannt und allgemein verfügbar. Somit kann ein Protokoll-Anfangsblock Byte für Byte oder auf eine andere Weise durchquert werden, indem auf die Protokollspezifikationen Bezug genommen wird. Somit ist in einer vorliegendenden Ausführungsform der Erfindung der Analysieralgorithmus dynamisch, wobei aus einem Feld eines Anfangsblocks wiedergewonnene Informationen häufig die Art und Weise ändern, in der ein anderer Teil analysiert wird.
  • Zum Beispiel ist es bekannt, dass das Typ-Feld eines Pakets, das sich an die traditionelle Form von Ethernet (z.B. Version zwei) klammert, am dreizehnten Byte des Anfangsblocks (Schicht zwei) beginnt. Zum Vergleich beginnt das Typ-Feld eines Pakets, das der Version IEEE 802.3 von Ethernet folgt, am einundzwanzigsten Byte des Anfangsblocks. Das Typ-Feld liegt an noch anderen Stellen, wenn das Paket einen Teil einer Datenübertragung in einem virtuellen lokalen Netz (VLAN) bildet (die erläuternd Markieren oder Einkapseln eines Ethernet-Anfangsblocks umfasst). Somit werden in einer vorliegenden Ausführungsform der Erfindung die Werte in bestimmten Feldern der Reihe nach wiedergewonnen und geprüft, um sicherzustellen, dass die aus einem Anfangsblock benötigten Informationen aus dem richtigen Abschnitt des Anfangsblocks herausgeholt worden. Details hinsichtlich der Form eines VLAN-Pakets findet man in den Spezifikationen für die IEEE 802.3p- und IEEE 802.3q-Formen des Ethernet-Protokolls.
  • Der Betrieb des Anfangsblock-Analysators 106 hängt auch von anderen Unterschieden zwischen Protokollen ab, zum Beispiel ob das Paket die Version vier oder die Version sechs des Internet-Protokolls usw. benutzt. Spezifikationen für die Versionen vier und sechs des IP findet man in IETF (Internet Engineering Task Force) RFCs (Kommentaranforderungen) 791 bzw. 2460.
  • Je mehr Protokolle der Analysator 304 "kennt", auf desto mehr Protokolle kann ein Paket geprüft werden, und desto komplizierter kann das Analysieren eines Anfangsblock-Abschnitts eines Pakets werden. Der Fachmann erkennt, dass die Protokolle, die durch den Analysator 304 analysiert werden können, nur durch die Befehle beschränkt sind, nach denen er arbeitet. Durch Vermehren oder Austauschen der im Befehlsspeicher 306 gespeicherten Analysierbefehle können daher praktisch alle bekannten Protokolle vom Anfangsblock-Analysator 106 verarbeitet werden und können praktisch beliebige Informationen aus den Anfangsblöcken eines Pakets wiedergewonnen werden.
  • Wenn natürlich ein Paket-Anfangsblock keinem erwarteten oder vermuteten Protokoll entspricht, wird die Analysieroperation möglicherweise beendet. In diesem Fall ist das Paket möglicherweise ungeeignet für eine oder mehrer der von der NIC 100 gebotenen Effizienzverbesserungen (z.B. Datenwiederzusammensetzung, Paketschub, Lastverteilung).
  • Erläuternd werden die aus den Anfangsblöcken eines Pakets wiedergewonnenen Informationen von anderen Abschnitten der NIC 100 benutzt, wenn sie dieses Paket verarbeitet. Zum Beispiel wird als Folge der vom Analysator 304 durchgeführten Paketanalyse ein Flussschlüssel erzeugt, um den Datenfluss oder die Datenverbindung zu kennzeichnen, der bzw. die das Paket enthält. Erläuternd wird der Flussschlüssel zusammengesetzt, indem eine oder mehrere Adressen entsprechend einem oder mehreren der kommunizierenden Objekte verkettet werden. In einer vorliegenden Ausfüh rungsform wird ein Flussschlüssel aus einer Kombination der aus dem IP-Anfangsblock herausgeholten Quellen- und Zieladressen und der dem TCP-Anfangsblock entnommenen Quellen- und Ziel-Ports gebildet. Man kann auch andere Indizes der kommunizierenden Objekte verwenden, wie z.B. die Ethernet-Quellen- und Zieladressen (aus dem Anfangsblock der Schicht zwei herausgeholt), NFS-Dateihandhaben oder Quellen- und Zielkennungen für andere aus dem Datenabschnitt des Pakets herausgeholte Anwendungs-Datagramme.
  • Der Fachmann erkennt, dass die kommunizierenden Objekte mit höherer Auflösung gekennzeichnet werden können, indem Indexdaten benutzt werden, die aus den höheren Schichten des einem Paket zugeordneten Protokollstapels herausgeholt werden. Daher kann eine Kombination von IP- und TCP-Indizes die Objekte mit höherer Genauigkeit als Informationen der Schicht zwei kennzeichnen.
  • Außer einem Flussschlüssel erzeugt der Analysator 304 auch einen Steuer- oder Statusindikator, um zusätzliche Informationen hinsichtlich des Pakets zusammenzufassen. In einer Ausführungsform der Erfindung enthält ein Steuerindikator eine Sequenznummer (z.B. aus einem TCP-Anfangsblock herausgeholte TCP-Sequenznummer), um das richtige Ordnen von Paketen beim Wiederzusammensetzen ihrer Daten sicherzustellen. Der Steuerindikator kann außerdem verraten, ob bestimmte Anzeiger in den Paket-Anfangsblöcken gesetzt oder gelöscht sind, ob das Paket irgendwelche Daten enthält, und, wenn das Paket Daten enthält, ob die Daten eine bestimmte Größe übersteigen. Andere Daten sind ebenfalls für Einschluss in den Steuerindikator geeignet, begrenzt nur durch die Informationen, die in dem vom Analysator 304 analysierten Abschnitt des Pakets zur Verfügung stehen.
  • In einer Ausführungsform der Erfindung liefert der Anfangsblock-Analysator 106 den Flussschlüssel und den ganzen oder einen Abschnitt des Steuerindikators an den Flussdatenbankmanager 108. Wie in einem folgenden Abschnitt erörtert, verwaltet der FDBM 108 eine Datenbank oder andere Datenstruktur, die Informationen enthält, die für den durch die NIC 100 laufenden Datenfluss relevant sind.
  • In anderen Ausführungsformen der Erfindung erzeugt der Analysator 304 zusätzliche Informationen, die zur Verwendung durch andere Module der NIC 100 aus dem Anfangsblock eines Pakets gewonnen werden. Zum Beispiel kann der Anfangsblock- Analysator 106 den Versatz der Daten oder eines Nutzlast-Abschnitts eines aus einem Netz empfangenen Pakets vom Beginn des Pakets oder von irgendeinem anderen Punkt aus berichten. Wie oben beschrieben, folgt der Datenabschnitt eines Pakets typischerweise dem Anfangsblock-Abschnitt und, und ihm kann ein Anhangabschnitt folgen. Andere Daten, die der Anfangsblock-Analysator 106 berichten kann, können den Ort im Paket, an dem eine Prüfsummenoperation beginnen sollte, den Ort im Paket, an dem die Anfangsblöcke der Schicht drei und/oder Schicht vier beginnen, Diagnosedaten, Nutzlastinformationen usw. enthalten. Der Ausdruck "Nutzlast" wird häufig benutzt, um den Datenabschnitt eines Pakets zu bezeichnen. Insbesondere liefert in einer Ausführungsform der Erfindung der Anfangsblock-Analysator 106 einen Nutzlastversatz und eine Nutzlastgröße an die Steuerwarteschlange 118.
  • Unter geeigneten Umständen kann der Anfangsblock-Analysator 106 außerdem berichten (z.B. dem IPP-Modul 104 und/oder der Steuerwarteschlange 118), dass das Paket nicht in Übereinstimmung mit den Protokollen formatiert ist, für deren Verarbeitung der Analysator 304 konfiguriert ist. Dieser Bericht kann die Form eines Signals (z.B. das weiter unten beschriebene Signal No Assist), einer Warnung, eines Anzeigers oder anderen Indikators annehmen. Das Signal kann immer dann verursacht oder ausgeben werden, wenn festgestellt wird, dass das Paket ein anderes Protokoll als die vorgewählten Protokolle widerspiegelt, die mit den oben beschriebenen Verarbeitungsverbesserungen kompatibel sind (z.B. Wiederzusammenbau von Daten, Schubverarbeitung von Paket-Anfangsblöcken, Lastverteilung). Zum Beispiel kann in einer Ausführungsform der Erfindung der Analysator 304 konfiguriert sein, Pakete unter Verwendung von TCP in Schicht vier, IP in Schicht drei und Ethernet in Schicht zwei zu analysieren und effizient zu verarbeiten. In dieser Ausführungsform würde ein IPX(Internetwork Packet Exchange, Vernetzungspaketaustausch)-Paket nicht als kompatibel betrachtet, und IPX-Pakete würden daher nicht für Datenwiederzusammenbau und Schubverarbeitung gesammelt werden.
  • Am Ende des Analysierens in einer Ausführungsform der Erfindung werden die verschiedenen oben beschriebenen Informationsbruchstücke an geeignete Module der NIC 100 verbreitet. Danach (und wie in einem folgenden Abschnitt beschrieben) bestimmt der Flussdatenbankmanager 108, ob ein aktiver Fluss mit dem aus dem Paket gewonnenen Flussschlüssel verknüpft ist, und setzt einen Operationscode zur Verwendung bei der nachfolgenden Verarbeitung. Außerdem überträgt das IPP-Modul 104 das Paket an die Paketwarteschlange 116. Das IPP-Modul kann auch einige der vom Anfangsblock-Analysator 106 extrahierten Informationen empfangen und sie an ein anderes Modul der NIC 100 weitergeben.
  • In der in 3 gezeigten Ausführungsform der Erfindung wird ein ganzer Anfangsblock-Abschnitt eines zu analysierenden Pakets kopiert und dann in einer Evolution analysiert, wonach der Anfangsblock-Analysator seine Aufmerksamkeit einem anderen Paket zuwendet. In einer alternativen Ausführungsform können jedoch mehrere Kopier- und/oder Analysieroperationen an einem einzelnen Paket durchgeführt werden. Insbesondere kann in einer ersten Evolution ein anfänglicher Anfangsblock-Abschnitt in den Anfangsblock-Analysator 106 kopiert und darin analysiert werden, wonach in einer zweiten Evolution ein anderer Anfangsblock-Abschnitt in den Anfangsblock-Analysator 106 kopiert und darin analysiert werden kann. Ein Anfangsblock-Abschnitt in einer Evolution kann den Anfangsblock-Abschnitt einer anderen Evolution teilweise oder vollständig überlappen. Auf diese Weise können ausgedehnte Anfangsblöcke analysiert werden, selbst wenn der Anfangsblockspeicher 302 eine begrenzte Größe hat. Ähnlich kann es mehr als eine Operation brauchen, um einen vollen Satz von Befehlen zum Analysieren eines Pakets in den Befehlsspeicher 306 zu laden. Erläuternd kann ein erster Abschnitt der Befehle geladen und ausgeführt werden, wonach weitere Befehle geladen werden.
  • In 4A bis 4B, auf die nun Bezug genommen wird, ist ein Flussdiagramm dargestellt, um ein Verfahren zu veranschaulichen, durch das ein Anfangsblock-Analysator einen Anfangsblock-Abschnitt eines an einer Netzschnittstellenschaltung aus einem Netz empfangenen Pakets analysieren kann. In dieser Ausführung ist der Anfangsblock-Analysator konfiguriert oder optimiert, Pakete zu analysieren, die einem Satz von vorgewählten Protokollen (oder Protokollstapeln) entsprechen. Für Pakete, die diesen Kriterien genügen, werden verschiedene Informationen aus dem Anfangsblock-Abschnitt wiedergewonnen, um beim Wiederzusammenbau der Datenabschnitte von verknüpften Paketen (z.B. Paketen, die Daten aus einem einzelnen Datagramm enthalten) zu helfen. Andere verbesserte Merkmale der Netzschnittstellenschaltung können ebenfalls ermöglicht werden.
  • Die vom Anfangsblock-Analysator erzeugten Informationen enthalten insbesondere einen Flussschlüssel, mit dem der Datenfluss oder die Datenverbindung zu bestimmen ist, der bzw. die das empfangene Paket enthält. In einer Ausführungsform der Erfindung können Daten aus Paketen mit demselben Flussschlüssel bestimmt und wiederzusammengesetzt werden, um ein Datagramm zu bilden. Außerdem können Anfangsblöcke von Paketen mit demselben Flussschlüssel durch ihren Protokollstapel kollektiv verarbeitet werden (z.B. statt seriell).
  • In einer anderen Ausführungsform der Erfindung werden die durch den Anfangsblock-Analysator wiedergewonnenen Informationen außerdem benutzt, um die Verarbeitung von aus einem Netz empfangenem Netzverkehr zu verteilen. Zum Beispiel können mehrere Pakete mit demselben Flussschlüssel einem einzelnen Prozessor eines Mehrprozessor-Hauptrechnersystems vorgelegt werden.
  • Bei dem in 4A bis 4B gezeigten Verfahren entspricht der Satz von vorgewählten Protokollen Datenübertragungsprotokollen, die häufig über das Internet übertragen werden. Insbesondere umfasst der Satz von Protokollen, die bei diesem Verfahren umfassend analysiert werden können, die Folgenden. In Schicht zwei: Ethernet (traditionelle Version), 802.3-Ethernet, Ethernet-VLAN (virtuelles lokales Netz) und 802.3-Ethernet-VLAN. In Schicht drei: IPv4 (ohne Optionen) und IPv6 (ohne Optionen). Schließlich werden bei dem gezeigten Verfahren in Schicht vier nur TCP-Protokoll-Anfangsblöcke (mit oder ohne Optionen) analysiert. Anfangsblock-Analysatoren in alternativen Ausführungsformen der Erfindung analysieren durch andere Protokollstapel formatierte Pakete. Insbesondere kann eine NIC in Übereinstimmung mit den in einem gegebenen Netz gebräuchlichsten Protokollstapeln konfiguriert sein, welche die Protokolle, die mit dem in 4A bis 4B gezeigten Verfahren kompatibel sind, enthalten oder nicht enthalten können.
  • Wie weiter unten beschrieben, kann ein empfangenes Paket, das den durch ein gegebenes Verfahren analysierten Protokollen nicht entspricht, markiert werden, und der Analysieralgorithmus für dieses Paket beendet werden. Da die Protokolle, unter denen ein Paket formatiert worden ist, bei dem vorliegenden Verfahren nur bestimmt werden können, indem bestimmte Anfangsblock-Feldwerte geprüft werden, kann die Feststellung, dass ein Paket dem ausgewählten Satz von Protokollen nicht entspricht, praktisch in jedem Zeitpunkt während der Prozedur getroffen werden. Daher hat das gezeigte Analysierverfahren als ein Ziel die Kennzeichnung von Paketen, die den Formatierungskriterien für Wiederzusammenbau von Daten nicht genügen.
  • Nachfolgend werden verschiedene Protokoll-Anfangsblock-Felder beschrieben, die in Anfangsblöcken für die ausgewählten Protokolle erscheinen. Datenübertragungsprotokolle, die mit einer Ausführungsform der vorliegenden Erfindung kompatibel sind (z.B. Protokolle, die von einem Anfangsblock-Analysator analysiert werden können) sind dem Fachmann bekannt und sind in einer Anzahl von Quellen in großer Ausführlichkeit beschrieben. Sie müssen daher hierin nicht im kleinsten Detail aufgesucht werden. Außerdem ist das gezeigte Verfahren zum Analysieren eines Anfangsblock-Abschnitts eines Pakets für die ausgewählten Protokolle nur eine Methode, die weiter unten beschriebenen Informationen zu sammeln. Andere Analysierprozeduren, die dies tun können, sind gleichermaßen geeignet.
  • In der vorliegenden Ausführungsform der Erfindung ist die gezeigte Prozedur als eine Kombination aus Hardware und Software ausgeführt. Zum Beispiel können aktualisierbare Mikrocode-Befehle zur Durchführung der Prozedur von einem Mikroprozessor ausgeführt werden. Alternativ können solche Befehle fest sein (z.B. in Nur-Lese-Speicher gespeichert) oder können von einem Prozessor oder Mikroprozessor ausgeführt werden.
  • In 4A bis 4B ist der Zustand 400 ein Startzustand, während dessen ein Paket von der NIC 100 (in 1A gezeigt) empfangen wird und eine Anfangsverarbeitung durchgeführt wird. Die NIC 100 ist zu Zwecken dieser Prozedur mit dem Internet verbunden. Die Anfangsverarbeitung kann eine Basis-Fehlerprüfung und das Entfernen der Präambel der Schicht eins umfassen. Nach der Anfangsverarbeitung wird das Paket vom IPP-Modul 104 (auch in 1A gezeigt) festgehalten. In einer Ausführungsform der Erfindung umfasst der Zustand 400 eine Logikschleife, in der der Anfangsblock-Analysator in einem Leerlauf- oder Wartezustand bleibt, bis ein Paket empfangen wird.
  • Im Zustand 402 wird ein Anfangsblock-Abschnitt des Pakets in einen Speicher kopiert (z.B. den Anfangsblockspeicher 302 von 3). In einer vorliegenden Ausführungsform der Erfindung werden eine vorbestimmte Anzahl von Bytes am Beginn (z.B. 114 Bytes) des Pakets kopiert. In alternativen Ausführungsformen der Erfindung werden Paketabschnitte mit anderen Größen kopiert, deren Größen von dem Ziel geleitet werden, genug von dem Paket zu kopieren, um die notwendigen Anfangsblock-Informationen zu erfassen und/oder zu bestimmen. Erläuternd wird das ganze Paket vom IPP-Modul 104 festgehalten, während die folgenden Analysieroperationen durchgeführt werden, obwohl das Paket alternativ vor Beendigung der Analyse in der Paketwarteschlange 116 gespeichert werden kann.
  • Außerdem kann im Zustand 402 ein Zeiger zur Verwendung beim Analysieren des Pakets initialisiert werden. Da die Präambel der Schicht eins entfernt wurde, sollte der in den Speicher kopierte Anfangsblock-Abschnitt mit dem Protokoll-Anfangsblock der Schicht zwei beginnen. Erläuternd wird daher der Zeiger anfänglich so gesetzt, dass er auf das zwölfte Byte des Protokoll-Anfangsblocks der Schicht zwei zeigt, und der Zwei-Byte-Wert an der Zeigerposition wird gelesen. Wie der Fachmann erkennt, können diese zwei Bytes Teil einer Anzahl von verschiedenen Feldern sein, je nachdem, welches Protokoll die Schicht zwei des Protokollstapels des Pakets bildet. Zum Beispiel können diese zwei Bytes das Typ-Feld eines traditionellen Ethernet-Anfangsblocks, das Länge-Feld eines 802.3-Ethernet-Anfangsblocks oder das TPID(Tag Protocol IDentifier, Markierungsprotokollkennung)-Feld eines VLAN-markierten Anfangsblocks aufweisen.
  • Im Zustand 404 wird eine erste Prüfung des Anfangsblocks der Schicht zwei vorgenommen, um zu bestimmen, ob er einen VLAN-markierten Protokoll-Anfangsblock der Schicht zwei aufweist. Erläuternd hängt diese Bestimmung davon ab, ob die zwei Bytes an der Zeigerposition den Hexadezimalwert 8100 speichern. Wenn ja, liegt der Zeiger voraussichtlich im TPID-Feld eines VLAN-markierten Anfangsblocks. Wenn es keinen VLAN-Anfangsblock gibt, geht die Prozedur zum Zustand 408 weiter.
  • Wenn jedoch der Anfangsblock der Schicht zwei ein VLAN-markierter Anfangsblock ist, wird im Zustand 406 das CFI(Canonical Format Indicator, kanonischer Formatindikator)-Bit geprüft. Wenn das CFI-Bit gesetzt (z.B. gleich eins) ist, springt die gezeigte Prozedur zum Zustand 430, nach dem sie endet. In dieser Ausführungsform der Erfindung zeigt das CFI-Bit, wenn gesetzt, an, dass das Format des Pakets nicht mit den vorgewählten Protokollen kompatibel ist (d.h. ihnen nicht entspricht) (z.B. ist das Protokoll der Schicht zwei nicht Ethernet oder 802.3-Ethernet). Wenn das CFI-Bit frei (z.B. gleich null) ist, wird der Zeiger hochgezählt (z.B. um vier Bytes), um ihn am nächsten Feld zu positionieren, das geprüft werden muss.
  • Im Zustand 408 wird der Anfangsblock der Schicht zwei näher geprüft. Es ist zwar jetzt bekannt, ob dies ein VLAN-markierter Anfangsblock ist oder nicht, je nachdem, ob der Zustand 408 über den Zustand 406 oder direkt vom Zustand 404 erreicht wurde, kann der Anfangsblock aber entweder das traditionelle Ethernet-Format oder das 802.3-Ethernet-Format widerspiegeln. Zu Beginn des Zustands 408 ist der Zeiger entweder am zwölften oder sechzehnten Byte des Anfangsblocks, die beide einem Länge-Feld oder einem Typ-Feld entsprechen können. Insbesondere, wenn der Zwei-Byte-Wert an der durch den Zeiger gekennzeichneten Stelle kleiner als 0600 (hexadezimal) ist, entspricht das Paket 802.3-Ethernet, und der Zeiger wird als ein Länge-Feld kennzeichnend verstanden. Andernfalls ist das Paket ein traditionelles (z.B. Version zwei) Ethernet-Paket, und der Zeiger kennzeichnet ein Typ-Feld.
  • Wenn das Protokoll der Schicht zwei 802.3-Ethernet ist, geht die Prozedur im Zustand 410 weiter. Wenn das Protokoll der Schicht zwei traditionelles Ethernet ist, wird das Typ-Feld auf die Hexadezimalwerte 0800 und 08DD geprüft. Wenn das geprüfte Feld einen dieser Werte hat, ist auch ermittelt worden, dass das Protokoll der Schicht drei des Pakets das Internet-Protokoll ist. In diesem Fall geht die gezeigte Prozedur im Zustand 412 weiter. Zuletzt, wenn das Feld ein Typ-Feld mit einem anderen Wert als 0800 oder 08DD (hexadezimal) ist, passt das Protokoll der Schicht drei des Pakets nicht zu den vorgewählten Protokollen, in Übereinstimmung mit denen der Anfangsblock-Analysator konfiguriert wurde. Daher geht die Prozedur im Zustand 430 weiter und endet dann.
  • In einer Ausführungsform der Erfindung wird das Paket im Zustand 408 geprüft, um zu bestimmen, ob es ein Jumbo-Ethernet-Datenblock ist. Diese Bestimmung würde wahrscheinlich erfolgen, bevor entschieden wird, ob der Anfangsblock der Schicht zwei Ethernet oder 802.3-Ethernet entspricht. Erläuternd kann die Jumbo-Datenblock-Bestimmung auf Basis der Größe des Pakets erfolgen, die vom IPP-Modul 104 oder einem MAC-Modul berichtet werden kann. Wenn das Paket ein Jumbo-Datenblock ist, kann die Prozedur im Zustand 410 weitergehen; andernfalls kann sie im Zustand 412 fortfahren.
  • Im Zustand 410 verifiziert die Prozedur, dass das Protokoll der Schicht zwei 802.3-Ethernet mit LLC-SNAP-Kapselung ist. Insbesondere wird der Zeiger vorgerückt (z.B. um zwei Bytes), und der Acht-Byte-Wert im Anschluss an das Länge-Feld im Anfangsblock der Schicht zwei wird wiedergewonnen und geprüft. Wenn der Anfangsblock ein 802.3-Ethernet-Anfangsblock ist, ist das Feld das LLC SNAP-Feld und sollte einen Wert AAAA03000000 (hexadezimal) haben. Die Ursprungsspezifikation für einen LLC-SNAP-Anfangsblock findet man in der Spezifikation für IEEE 802.2. Wenn der Wert im LLC SNAP-Feld des Pakets zu dem erwarteten Wert passt, wird der Zeiger weitere sechs Byte hochgezählt, wird das Zwei-Byte-802.3-Ethernet-Typ-Feld gelesen und geht die Prozedur im Zustand 412 weiter. Wenn die Werte nicht passen, entspricht das Paket nicht den spezifizierten Protokollen, und die Prozedur betritt den Zustand 430 und endet dann.
  • Im Zustand 412 wird der Zeiger vorgerückt (z.B. weitere zwei Bytes), um den Beginn des Anfangsblocks der Protokollschicht drei zu lokalisieren. Diese Zeigerposition kann für späteren Gebrauch bei schneller Bestimmung des Beginns dieses Anfangsblocks gespeichert werden. Das Paket entspricht nun bekanntermaßen einem akzeptierten Protokoll der Schicht zwei (z.B. traditionellem Ethernet, Ethernet mit VLAN-Markierung oder 802.3-Ethernet mit LLC-SNAP) und wird nun geprüft, um sicherzustellen, dass die Protokollschicht drei des Pakets IP ist. Wie oben erörtert, werden im Ausführungsbeispiel nur Pakete, die dem IP-Protokoll entsprechen, vom Anfangsblock-Analysator umfassend analysiert.
  • Erläuternd, wenn der Wert des Typ-Feldes im Anfangsblock der Schicht zwei (im Zustand 402 oder Zustand 410 wiedergewonnen) 0800 (hexadezimal) ist, ist das Protokoll der Schicht drei erwartungsgemäß IP, Version vier. Wenn der Wert 86DD (hexadezimal) ist, ist das Protokoll der Schicht drei erwartungsgemäß IP, Version sechs. Daher wird das Typ-Feld im Zustand 412 geprüft, und die Prozedur geht im Zustand 414 oder 418 weiter, je nachdem, ob der Hexadezimalwert 0800 bzw. 86DD ist.
  • Im Zustand 414 wird die Konformität des Anfangsblocks der Schicht drei mit Version vier von IP verifiziert. In einer Ausführungsform der Erfindung wird das Version-Feld des Anfangsblocks der Schicht drei geprüft, um sicherzustellen, dass es den Hexadezimalwert 4 enthält, entsprechend Version vier von IP. Wenn im Zustand 414 der Anfangsblock der Schicht drei als IP Version vier bestätigt wird, geht die Prozedur im Zustand 416 weiter; andernfalls geht sie zum Zustand 430 weiter und endet im Zustand 432.
  • Im Zustand 416 werden verschiedenen Informationsbruchstücke aus dem IP-Anfangs block gespeichert. Diese Informationen können die IHL(IP-Anfangsblock-Länge)-, Gesamtlänge-, Protokoll- und/oder Fragmentversatz-Felder umfassen. Die IP-Quellen-Adresse und die IP-Zieladressen können ebenfalls gespeichert werden. Die Quellen- und Zieladresswerte sind in Version vier von IP jeweils vier Bytes lang. Diese Adressen werden benutzt, wie oben beschrieben, um einen Flussschlüssel zu erzeugen, der den Datenfluss kennzeichnet, in dem dieses Paket gesendet wurde. Das Gesamtlänge-Feld speichert die Größe des IP-Segments dieses Pakets, das erläuternd den IP-Anfangsblock, den TCP-Anfangsblock und den Datenabschnitt des Pakets umfasst. Die TCP-Segmentgröße des Pakets (z.B. die Größe des TCP-Anfangsblocks plus die Größe des Datenabschnitt des Pakets) kann berechnet werden, indem zwanzig Bytes (die Größe des Anfangsblocks in IP Version vier) vom Gesamtlänge-Wert subtrahiert wird. Nach dem Zustand 416 rückt die gezeigte Prozedur zum Zustand 422 weiter.
  • Im Zustand 418 wird die Konformität des Anfangsblocks der Schicht drei mit Version sechs von IP verifiziert, indem das Version-Feld auf den Hexadezimalwert 6 geprüft wird. Wenn das Version-Feld diesen Wert nicht enthält, geht die gezeigte Prozedur zum Zustand 430 weiter.
  • Im Zustand 420 werden die Werte der Felder Nutzlast-Länge (z.B. die Größe des TCP-Segments) und Nächster Anfangsblock gespeichert, zuzüglich der IP-Quellen- und Zieladressen. Die Quellen- und Zieladressen sind in Version sechs von IP jeweils sechzehn Bytes lang.
  • Im Zustand 422 der gezeigten Prozedur wird bestimmt, ob der IP-Anfangsblock (entweder Version vier oder Version sechs) anzeigt, dass der Anfangsblock der Schicht vier TCP ist. Erläuternd wird das Protokoll-Feld eines IP-Anfangsblocks der Version vier geprüft, während das Feld Nächster Anfangsblock eines Anfangsblocks der Version sechs geprüft wird. In beiden Fällen sollte der Wert 6 (hexadezimal) sein. Der Zeiger wird dann nötigenfalls hochgezählt (z.B. zwanzig Bytes für IP Version vier, vierzig Bytes für IP Version sechs), um den Beginn des TCP-Anfangsblocks zu erreichen. Wird im Zustand 422 festgestellt, dass der Anfangsblock der Schicht vier nicht TCP ist, rückt die Prozedur zum Zustand 430 weiter und endet im Endzustand 432.
  • In einer Ausführungsform der Erfindung können im Zustand 422 weitere Felder eines IP-Anfangsblocks der Version vier geprüft werden, um sicherzustellen, dass das Paket den Kriterien für verbesserte Verarbeitung durch die NIC 100 genügt. Zum Beispiel zeigt ein anderer IHL-Feld-Wert als 5 (hexadezimal) an, dass IP-Optionen für dieses Paket gesetzt sind, in welchem Fall die Analysieroperation abgebrochen wird. Ein anderer Wert des Fragmentierung-Feldes als null zeigt an, dass das IP-Segment des Pakets ein Fragment ist, in welchem Fall das Analysieren ebenfalls abgebrochen wird. In beiden Fällen springt die Prozedur zum Zustand 430 und endet dann im Endzustand 432.
  • Im Zustand 424 wird der TCP-Anfangsblock des Pakets analysiert und werden verschiedene Daten daraus gesammelt. Insbesondere werden die TCP-Quellen-Port- und -Ziel-Port-Werte gespeichert. Die TCP-Sequenznummer, die benutzt wird, um den korrekten Wiederzusammenbau von Daten aus mehreren Paketen sicherzustellen, wird ebenfalls gespeichert. Weiterhin werden die Werte mehrerer Komponenten des Anzeiger-Feldes – erläuternd die Bits URG (Dringend), PSH (Drücken), RST (Zurücksetzen), SYN (Synchronisieren) und FIN (Beenden) – gespeichert. In einer Ausführungsform der Erfindung signalisieren diese Anzeiger, dass beim Abwickeln des Pakets verschiedene Aktionen durchzuführen oder Status zu berücksichtigen sind.
  • Im Zustand 424 können weitere Signale oder Status erzeugt werden, um Informationen widerzuspiegeln, die aus dem TCP-Anfangsblock wiedergewonnen werden. Zum Beispiel kann der Punkt gespeichert werden, von dem aus eine Prüfsummenoperation beginnen soll (erläuternd der Beginn des TCP-Anfangsblocks); der Endpunkt einer Prüfsurnmenoperation kann ebenfalls gespeichert werden (erläuternd das Ende des Datenabschnitts des Pakets). Ein Versatz des Datenabschnitts des Pakets kann bestimmt werden, indem der Wert des Feldes Anfangsblock-Länge des TCP-Anfangsblocks mit vier multipliziert wird. Die Größe des Datenabschnitts kann dann berechnet werden, indem der Versatz des Datenabschnitts von der Größe des gesamten TCP-Segments subtrahiert wird.
  • Im Zustand 426 wird ein Flussschlüssel zusammengesetzt, indem die IP-Quellen- und Zieladressen und die TCP-Quellen- und Ziel-Ports verkettet werden. Wie schon beschrieben, kann der Flussschlüssel benutzt werden, um einen Datenfluss oder eine Datenverbindung zu kennzeichnen, und kann von anderen Modulen der NIC 100 benutzt werden, um Netzverkehr effizienter zu verarbeiten. Die Größen der Quellen- und Zieladressen sind in den IP-Versionen vier und sechs zwar verschieden (z.B. jeweils vier Byte gegenüber jeweils sechzehn Byte), in der vorliegendend beschriebenen Ausführungsform der Erfindung haben alle Flussschlüssel aber einheitliche Größe. Insbesondere sind sie in dieser Ausführungsform sechsunddreißig Bytes lang, einschließlich des Zwei-Byte-TCP-Quellen-Port und des Zwei-Byte-TCP-Ziel-Port. Flussschlüssel, die aus Paket-Anfangsblöcken in IP, Version vier, erzeugt werden, werden nötigenfalls aufgefüllt (z.B. mit vierundzwanzig Freibytes), um den den Flussschlüsseln zugewiesenen Platz zu füllen.
  • Im Zustand 428 wird ein Steuer- oder Statusindikator zusammengesetzt, um einem oder mehreren Modulen der NIC 100 verschiedene Informationen zu liefern. In einer Ausführungsform der Erfindung enthält ein Steuerindikator die TCP-Sequenznummer des Pakets, einen Anzeiger oder eine Kennung (z.B. ein oder mehr Bits), der bzw. die anzeigt, ob das Paket Daten enthält (z.B. ob die TCP-Nutzlastgröße größer als null ist), einen Anzeiger, der anzeigt, ob der Datenabschnitt des Pakets eine vorbestimmte Größe übersteigt, und einen Anzeiger, der anzeigt, ob bestimmte Einträge im TCP-Anzeiger-Feld zu vorbestimmten Werten äquivalent sind. Der letztere Anzeiger kann zum Beispiel benutzt werden, um einem anderen Modul der NIC 100 mitzuteilen, dass Komponenten des Anzeiger-Feldes eine bestimmte Konfiguration haben oder nicht. Nach dem Zustand 428 endet die gezeigte Prozedur mit dem Zustand 432.
  • Der Zustand 430 kann an mehreren verschiedenen Stellen der gezeigten Prozedur betreten werden. Dieser Zustand wird zum Beispiel betreten, wenn festgestellt wird, dass ein Anfangsblock-Abschnitt, der gerade von einem Anfangsblock-Analysator analysiert wird, nicht den oben gekennzeichneten vorgewählten Protokollstapeln entspricht. Als Folge wird viel von den oben beschriebenen Informationen nicht wiedergewonnen. Eine praktische Konsequenz der Unfähigkeit, diese Informationen wiederzugewinnen, ist, dass sie nicht an andere Module der NIC 100 geliefert werden können und die hierin beschriebene verbesserte Verarbeitung für dieses Paket möglicherweise nicht durchgeführt werden kann. Insbesondere, und wie vorher beschrieben, können in einer vorliegenden Ausführungsform der Erfindung ein oder mehrere verbesserte Operationen an analysierten Paketen durchgeführt werden, um die Effizienz zu erhöhen, mit der sie verarbeitet werden. Erläuternd umfassen Operationen, die angewendet werden können, den Wiederzusammenbau von Daten aus verknüpften Paketen (z.B. Paketen, die Daten aus einem einzelnen Datagramm enthalten), Schubverarbeitung von Paket-Anfangsblöcken durch einen Protokollstapel, Lastverteilung oder Lastaufteilung von Protokollstapelverarbeitung, effiziente Übertragung von Paketdaten an ein Zielobjekt usw.
  • Bei der gezeigten Prozedur wird im Zustand 430 ein Anzeiger oder Signal (erläuternd No Assist (keine Unterstützung) gesetzt oder gelöscht, um anzuzeigen, dass das gegenwärtig vom IPP-Modul 104 festgehaltene Paket (z.B. das gerade vom Anfangsblock-Analysator verarbeitet wurde) keinem der vorgewählten Protokollstapel entspricht. Auf diesen Anzeiger oder dieses Signal kann ein anderes Modul der NIC 100 bauen, wenn es entscheidet, ob eine der verbesserten Operationen durchzuführen ist.
  • Im Zustand 430 kann ein weiterer Anzeiger oder ein weiteres Signal gesetzt oder gelöscht werden, um einen Prüfsummenparameter zu initialisieren, der anzeigt, dass eine Prüfsummenoperation, wenn durchgeführt, am Beginn des Pakets anfangen sollte (z.B. ohne Versatz in das Paket). Erläuternd können inkompatible Pakete nicht analysiert werden, um eine geeignetere Stelle zu bestimmen, von der aus die Prüfsummenoperation beginnen soll. Nach dem Zustand 430 endet die Prozedur mit dem Zustand 432.
  • Nach dem Analysieren eines Pakets kann der Anfangsblock-Analysator aus dem Paket erzeugte Informationen an ein oder mehrere Module der NIC 100 verteilen. Zum Beispiel wird in einer Ausführungsform der Erfindung der Flussschlüssel an den Flussdatenbankmanager 108, den Lastverteiler 112 und an die Steuerwarteschlange 118 oder die Paketwarteschlange 116 oder beide geliefert. Erläuternd wird der Steuerindikator an den Flussdatenbankmanager 108 geliefert. Diese und andere Steuerinformationen, wie z.B. TCP-Nutzlastgröße, TCP-Nutzlastversatz und das Signal No Assist, können an das IPP-Modul 104 zurückgesandt und an die Steuerwarteschlange 118 geliefert werden. Noch weitere Steuer- und/oder Diagnoseinformationen, wie z.B. Versätze zu den Anfangsblöcken der Schicht drei und/oder Schicht vier, können an das IPP-Modul 104, die Paketwarteschlange 116 und/oder die Steuerwarteschlange 118 geliefert werden. Prüfsummeninformationen (z.B. ein Anfangspunkt und entweder ein Endpunkt oder andere Mittel zum Kennzeichnen eines Abschnitts des Pakets, aus dem eine Prüfsumme zu berechnen ist) können an den Prüfsummengenerator 114 geliefert werden.
  • Nachdem ein empfangenes Paket in der NIC 100 analysiert worden ist (z.B. durch den Anfangsblock-Analysator 106), werden die Pakete im Ausführungsbeispiel der Erfin dung noch auf dem Hauptrechnersystem verarbeitet (z.B. durch ihre jeweiligen Protokollstapel). In einer alternativen Ausführungsform der Erfindung führt die NIC 100 nach dem Analysieren eines Pakets jedoch außerdem einen oder mehrere nachfolgende Verarbeitungsschritte durch. Zum Beispiel kann die NIC 100 einen oder mehrere Protokollprozessoren zur Verarbeitung von einem oder mehreren der Protokoll-Anfangsblöcke des Pakets enthalten.
  • Dynamische Anfangsblock-Analysierbefehle in einer Ausführungsform der Erfindung
  • In einer Ausführungsform der vorliegenden Erfindung analysiert der Anfangsblock-Analysator 106 ein aus einem Netz empfangenes Paket in Übereinstimmung mit einer dynamischen Sequenz von Befehlen. Die Befehle können im Befehlsspeicher (z.B. RAM, SRAM, DRAM, Flash) des Anfangsblock-Analysators gespeichert sein, der neuprogrammierbar ist oder der auf andere Weise mit neuen oder zusätzlichen Befehlen aktualisiert werden kann. In einer Ausführungsform der Erfindung kann Software, die auf einem Hauptrechner arbeitet (z.B. ein Gerätetreiber), einen Satz von Analysierbefehlen zum Speichern im Speicher des Anfangsblock-Analysators herunterladen.
  • Die Zahl und das Format der im Befehlsspeicher eines Anfangsblock-Analysators gespeicherten Befehle können auf ein oder mehrere spezifische Protokolle oder Protokollstapel zugeschnitten sein. Ein für eine Sammlung von Protokollen konfigurierter Befehlssatz oder ein aus diesem Befehlssatz aufgebautes Programm kann daher durch einen anderen Befehlssatz oder ein anderes Programm aktualisiert oder ersetzt werden. Für an der Netzschnittstelle empfangene Pakete, die in Übereinstimmung mit den ausgewählten Protokollen konfiguriert sind (z.B. "kompatible" Pakete"), wie durch Analysieren der Pakete bestimmt, werden daher verschiedene Verbesserungen beim Abwickeln von Netzverkehr möglich, wie anderswo beschrieben. Insbesondere können Pakete aus einem Datagramm, die in Übereinstimmung mit einem ausgewählten Protokoll konfiguriert sind, für effiziente Übertragung in einem Hauptrechner wiederzusammengesetzt werden. Außerdem können Anfangsblock-Abschnitte solcher Pakete kollektiv statt seriell verarbeitet werden. Und die Verarbeitung von Paketen aus verschiedenen Datagrammen durch einen Mehrprozessor-Hauptrechner kann auf die Prozessoren verteilt oder aufgeteilt werden. Daher ist es eine Aufgabe einer dynamischen Anfangsblock-Analysieroperation, ein Protokoll zu bestimmen, in Übereinstimmung mit dem ein empfangenes Paket formatiert worden ist, oder festzustellen, ob ein Paket-Anfangsblock einem bestimmten Protokoll entspricht.
  • 8, die alsbald im Detail erörtert wird, zeigt eine Beispielsfolge von Befehlen zum Analysieren der Anfangsblöcke der Schicht zwei, drei und vier eines Pakets, um zu bestimmen, ob sie Ethernet, IP bzw. TCP sind. Die gezeigten Befehle umfassen ein mögliches Programm oder einen möglichen Mikrocode zur Durchführung einer Analysieroperation. Wie der Fachmann erkennt, kann eine Anzahl von verschiedenen Programmen zusammengesetzt werden, nachdem ein bestimmter Satz von Analysierbefehlen in einen Analysierspeicher geladen worden ist. 8 zeigt somit nur eines von einer Anzahl von Programmen, die aus den gespeicherten Befehlen erzeugt werden können. Die in 8 gezeigten Befehle können durch eine Mikro-Ablaufsteuerung, einen Prozessor, einen Mikroprozessor oder ein anderes, ähnliches Modul, dass sich in der Netzschnittstellenschaltung befindet, durchgeführt oder ausgeführt werden.
  • Insbesondere können andere Befehlssätze und andere Programme für verschiedene Datenübertragungsprotokolle gewonnen werden und können auf andere Schichten eines Protokollstapels erweitert werden. Zum Beispiel könnte ein Satz von Befehlen zum Analysieren von NFS(Netzdateisystem)-Paketen erzeugt werden. Erläuternd würden diese Befehle konfiguriert, Anfangsblöcke der Schicht fünf und sechs zu analysieren, um zu bestimmen, ob sie Remote Procedure Call (Fernprozeduraufruf, RPC) bzw. External Data Representation (externe Datendarstellung, XDR) sind. Andere Befehle könnten konfiguriert sein, einen Abschnitt der Daten des Pakets (der als Schicht sieben betrachtet werden kann) zu analysieren. Ein NFS-Anfangsblock kann als Teil eines Anfangsblocks der Protokollschicht sechs eines Pakets oder Teil der Daten des Pakets betrachtet werden.
  • Ein Typ von Befehlen, die von einer Mikro-Ablaufsteuerung ausgeführt werden, kann darauf ausgelegt sein, ein bestimmtes Feld eines Pakets (z.B. einen spezifischen Versatz innerhalb des Pakets) zu lokalisieren und den an diesem Versatz gespeicherten Wert mit jenem Feld in einem bestimmten Datenübertragungsprotokoll zu vergleichen. Zum Beispiel kann ein Befehl die Mikro-Ablaufsteuerung auffordern, einen Wert in einem Paket-Anfangsblock an einem Versatz zu prüfen, der einem Typ-Feld eines Ethernet-Anfangsblocks entsprechen würde. Durch Vergleichen des tatsächlich im Paket gespeicherten Wertes mit dem für das Protokoll erwarteten Wert kann die Mikro- Ablaufsteuerung bestimmen, ob das Paket dem Ethernet-Protokoll zu entsprechen scheint. Erläuternd hängt der nächste im Analysierprogramm angewandte Wert davon ab, ob der vorhergehende Vergleich erfolgreich war. Daher hängen die von der Mikro-Ablaufsteuerung angewandten bestimmten Befehle und die Sequenz, in der sie angewandt werden, davon ab, welche Protokolle durch die Anfangsblöcke des Pakets dargestellt werden.
  • Die Mikro-Ablaufsteuerung kann ein oder mehrere Felder innerhalb jedes in einem Paket enthaltenen Anfangsblocks prüfen. Je mehr Felder geprüft werden und als zu dem Format eines bekannten Protokolls passend befunden werden, desto größer die Gewissheit, dass das Paket diesem Protokoll entspricht. Wie der Fachmann erkennt, kann das eine Datenübertragungsprotokoll ganz anders als das andere Protokoll sein, was eine Prüfung von unterschiedlichen Teilen von Paket-Anfangsblöcken für unterschiedliche Protokolle erfordert. Erläuternd kann das Analysieren eines Pakets im Falle eines Fehlers oder weil bestimmt wurde, dass das gerade analysierte Paket dem oder den Protokoll(en), auf die die Befehle ausgelegt sind, entspricht oder nicht entspricht, beendet werden.
  • Jeder Befehl in 8 kann durch eine Nummer und/oder einen Namen gekennzeichnet sein. Ein bestimmter Befehl kann mannigfache andere Aufgaben als Vergleichen eines Anfangsblock-Feldes mit einem erwarteten Wert durchführen. Ein Befehl kann zum Beispiel einen anderen Befehl aufrufen, um einen anderen Abschnitt eines Paket-Anfangsblocks zu prüfen, ein Register oder eine andere Datenstruktur zu initialisieren, zu laden oder zu konfigurieren, die Ankunft und das Analysieren eines anderen Pakets vorzubereiten usw. Insbesondere kann ein Register oder eine andere Speicherstruktur in Erwartung einer Operation konfiguriert sein, die in der Netzschnittstelle durchgeführt wird, nachdem das Paket analysiert worden ist. Zum Beispiel kann ein Programmbefehl in 8 eine Ausgabeoperation kennzeichnen, die durchgeführt werden kann oder nicht, je nach dem Erfolg oder Fehlschlag des Vergleichs eines aus einem Paket mit einem erwarteten Wert extrahierten Wertes. Eine Ausgabeoperation kann einen Wert in einem Register speichern, ein Register für eine Operation nach Analyse konfigurieren (z.B. ein Argument oder einen Operator laden), ein Register löschen, um auf ein neues Paket zu warten, usw.
  • Ein Zeiger kann verwendet werden, um einen Versatz in ein gerade analysiertes Paket zu kennzeichnen. In einer Ausführungsform liegt so ein Zeiger anfänglich am Beginn des Anfangsblocks der Protokollschicht zwei. In einer anderen Ausführungsform befindet sich der Zeiger jedoch an einer spezifischen Stelle innerhalb eines bestimmten Anfangsblocks (z.B. unmittelbar im Anschluss an die Ziel- und/oder Quellenadressen der Schicht zwei), wenn das Analysieren beginnt. Erläuternd wird der Zeiger durch das Paket hindurch hochgezählt, wenn die Analysierprozedur stattfindet. In einer alternativen Ausführungsform können jedoch Versätze von interessierenden Bereichen im Paket aus einer oder mehreren bekannten oder berechneten Stellen berechnet werden.
  • In dem in 8 gezeigten Analysierprogramm wird ein Anfangsblock in Schritten von zwei Bytes (z.B. Sechzehn-Bit-Worten) manövriert (z.B. der Zeiger vorgerückt). Außerdem, wenn ein bestimmtes Feld eines Anfangsblocks mit einem bekannten oder erwarteten Wert verglichen wird, werden bis zu zwei Bytes auf einmal aus dem Feld extrahiert. Und wenn ein Wert oder Anfangsblock-Feld zum Speichern in einem Register oder einer anderen Datenstruktur kopiert wird, kann die Datenmenge, die in einer Operation kopiert werden kann, in Vielfachen von Zwei-Byte-Einheiten oder in ganz anderen Einheiten (z.B. individuellen Bytes) ausgedrückt werden. Diese Maßeinheit (z.B. zwei Bytes) kann in einer alternativen Ausführungsform der Erfindung vergrößert oder verkleinert werden. Die Maßeinheit zu ändern, kann die Genauigkeit ändern, mit der ein Anfangsblock analysiert oder ein Anfangsblock-Wert extrahiert werden kann.
  • In der in 8 dargestellten Ausführungsform der Erfindung umfasst ein in den Befehlsspeicher des Anfangsblock-Analysators geladener Satz von Befehlen eine Anzahl von möglichen Operationen zur Durchführung während des Prüfens eines Pakets auf Kompatibilität mit ausgewählten Protokollen. Aus dem Befehlssatz wird ein Programm 800 erzeugt. Das Programm 800 ist somit nur ein mögliches Programm oder eine mögliche Mikro-Ablaufsteuerung oder Sequenz von Befehlen, das bzw. die aus dem verfügbaren Befehlssatz gebildet werden kann.
  • In dieser Ausführungsform erlaubt der geladene Befehlssatz die folgenden sechzehn Operationen, die an einem Paket durchgeführt werden können, das gerade analysiert wird. Spezifische Realisierungen dieser Operationen im Programm 800 werden weiter unten noch detaillierter erörtert. Diese Befehle sind selbstverständlich nur beispielhaft und beschränken die Zusammensetzung von Befehlssätzen in anderen Ausführungsformen der Erfindung nicht. Außerdem kann jeder Teilsatz dieser Operationen in einem bestimmten Analysierprogramm oder Mikrocode verwendet werden. Weiterhin können mehrere Befehle dieselbe Operation verwenden und unterschiedliche Wirkungen haben.
  • Eine Operation CLR_REG erlaubt die selektive Initialisierung von Registern oder anderen im Programm 800 benutzten Datenstrukturen und möglicherweise Datenstrukturen, die in Funktionen benutzt werden, die nach Analyse eines Pakets durchgeführt werden. Initialisierung kann umfassen, den Wert null zu speichern. Eine Anzahl von Beispielsregistern, die durch eine Operation CLR_REG initialisiert werden können, sind in den übrigen Operationen gekennzeichnet.
  • Eine Operation LD_FID kopiert eine variable Datenmenge von einem bestimmten Versatz innerhalb des Pakets in ein Register, das konfiguriert ist, den Flussschlüssel oder eine andere Flusskennung eines Pakets zu speichern. Dieses Register kann FLOWID-Register genannt werden. Die Wirkung einer Operation LD_FID ist kumulativ. Mit anderen Worten, jedes Mal, wenn sie für ein Paket aufgerufen wird, werden die erzeugten Daten an die vorher gespeicherten Flussschlüsseldaten angehängt.
  • Eine Operation LD_SEQ kopiert eine variable Datenmenge von einem bestimmten Versatz innerhalb des Pakets in ein Register, das konfiguriert ist, die Sequenznummer (z.B. eine TCP-Sequenznummer) eines Pakets zu speichern. Diesem Register kann die Bezeichnung SEQNO zugewiesen werden. Diese Operation ist ebenfalls kumulativ – die zweiten und nachfolgenden Aufrufe dieser Operation für das Paket bewirken, dass die gekennzeichneten Daten an vorher gespeicherte Daten angehängt werden.
  • Eine Operation LD_CTL lädt einen Wert aus einem spezifizierten Versatz in dem Paket in ein Register CONTROL (Steuer-Register). Das Register CONTROL kann einen Steuerindikator enthalten, um zu bestimmen, ob ein Paket für Datenwiederzusammenbau, Paketschub, Lastverteilung oder andere verbesserte Funktionen der NIC 100 geeignet ist. Insbesondere kann ein Steueranzeiger anzeigen, ob ein Anzeiger No Assist für das Paket aufzustellen ist, ob das Paket irgendwelche Daten enthält, ob die Menge der Paketdaten größer als ein vorbestimmter Schwellenwert ist, usw. Daher kann der in einer Operation LD_CTL in ein Register CONTROL geladener Wert die Nachanalyse-Verarbeitung des Pakets beeinflussen.
  • Eine Operation LD_SAP lädt einen Wert aus einem variablen Versatz innerhalb des Pakets in das Register CONTROL. Der geladene Wert kann den Ethertyp des Pakets umfassen. In einer Option, die mit einer Operation LD_SAP verbunden sein kann, kann der Versatz des Anfangsblocks der Schicht drei des Pakets ebenfalls im Register CONTROL oder anderswo gespeichert werden. Wie der Fachmann erkennt, kann ein Anfangsblock der Schicht drei eines Pakets seinem Ethertyp-Feld der Schicht zwei unmittelbar folgen, wenn das Paket den Ethernet- und IP-Protokollen entspricht.
  • Eine Operation LD_R1 kann benutzt werden, um einen Wert aus einem variablen Versatz innerhalb des Pakets in ein temporäres Register zu laden (z.B. R1 genannt). Ein temporäres Register kann für mannigfache Aufgaben benutzt werden, wie z.B. Ansammeln von Werten, um die Länge eines Anfangsblocks oder anderen Abschnitts des Pakets zu bestimmen. Eine Operation LD_R1 kann außerdem bewirken, dass ein Wert aus einem anderen variablen Versatz in einem zweiten temporären Register gespeichert wird (z.B. R2 genannt). Die während des Analysierens eines Pakets in den Registern R1 und/oder R2 gespeicherten Werte können kumulativ sein oder nicht.
  • Eine Operation LD_L3 kann einen Wert aus dem Paket in ein Register laden, das konfiguriert ist, den Ort des Anfangsblocks der Schicht drei des Pakets zu speichern. Dieses Register kann L3OFFSET genannt werden. In einem optionalen Verfahren, das diese Operation aufruft, kann sie benutzt werden, um einen festen Wert in das Register L3OFFSET zu laden. Als weitere Option kann die Operation LD_L3 einen in einem temporären Register (z.B. R1) gespeicherten Wert zu dem im Register L3OFFSET gespeicherten Wert addieren.
  • Eine Operation LD_SUM speichert den Startpunkt innerhalb des Pakets, wo dem an eine Prüfsumme zu berechnen ist. Das Register, in dem dieser Wert gespeichert wird, kann CSUMSTART genannt werden. Bei einem alternativen Aufruf dieser Operation wird ein fester oder vorbestimmter Wert in dem Register gespeichert. Als weitere Option kann die Operation LD_SUM einen in einem temporären Register (z.B. R1) gespeicherten Wert zu dem im Register CSUMSTART gespeicherten Wert addieren.
  • Eine Operation LD_HDR lädt einen Wert in ein Register, das konfiguriert ist, den Ort innerhalb des Pakets, an dem der Anfangsblock-Abschnitt geteilt werden kann, zu speichern. Der Wert, der gespeichert wird, kann während der Übertragung des Pakets an den Hauptrechner benutzt werden, um einen Datenabschnitt des Pakets an einem anderen Ort als dem Anfangsblock-Abschnitt zu speichern. Der geladene Wert kann somit den Beginn der Paketdaten oder den Beginn eines bestimmten Anfangsblocks kennzeichnen. Bei einem Aufruf einer Operation LD_HDR kann der gespeicherte Wert aus einer gegenwärtigen Position eines oben beschriebenen Analysierzeigers berechnet werden. Bei einem anderen Aufruf kann ein fester oder vorbestimmter Wert gespeichert werden. Als noch eine Alternative können ein in einem temporären Register (z.B. R1) gespeicherter Wert und/oder eine Konstante zu dem geladenen Wert addiert werden.
  • Eine Operation LN_LEN speichert die Länge der Nutzlast des Pakets in einem Register (z.B. einem Register PAYLOADLEN (Nutzlastlänge)).
  • Eine Operation IM_FID hängt einen festen oder vorbestimmten Wert an den vorhandenen Inhalt des oben beschriebenen Registers FLOWID an oder addiert ihn dazu.
  • Eine Operation IM_SEQ hängt einen festen oder vorbestimmten Wert an den Inhalt des oben beschriebenen Registers SEQNO an oder addiert ihn dazu.
  • Eine Operation IM_SAP lädt oder speichert einen festen oder vorbestimmten Wert in dem oben beschriebenen Register CSUMSTART.
  • Eine Operation IM_R1 kann einen vorbestimmten Wert in ein oder mehrere temporäre Register (z.B. R1, R2) addieren oder laden.
  • Eine Operation IM_CTL lädt oder speichert einen festen oder vorbestimmten Wert in dem oben beschriebenen Register CONTROL.
  • Eine Operation ST_FLAG lädt einen Wert aus einem spezifizierten Versatz in dem Paket in ein Register FLAG (Anzeiger). Der geladene Wert kann ein oder mehrere Felder oder Anzeiger aus einem Paket-Anfangsblock aufweisen.
  • Der Fachmann erkennt, dass die den oben und anderswo in diesem Abschnitt beschriebenen Operationen und Registern gegebenen Bezeichnungen nur beispielhaft sind und die Operationen und Analysierbefehle, die in anderen Ausführungsformen der Erfindung verwendet werden können, in keiner Weise beschränken.
  • Die Befehle im Programm 800 umfassen ein Befehlsnummer-Feld 802, das eine Nummer eines Befehls innerhalb des Programms enthält, und ein Befehlsname-Feld 804, das einen Namen eines Befehls enthält. In einer alternativen Ausführungsform der Erfindung können die Befehlsnummer- und Befehlsname-Felder zusammengelegt sein, oder eines von ihnen kann weggelassen sein.
  • Ein Befehlsinhalt-Feld 806 enthält mehrere Abschnitte zum Ausführen eines Befehls. Ein Abschnitt "Extraktionsmaske" eines Befehls ist eine Zwei-Byte-Maske in Hexadezimaldarstellung. Eine Extraktionsmaske bestimmt einen zu kopierenden oder zu extrahierenden Abschnitt eines Paket-Anfangsblocks beginnend vom gegenwärtigen Paketversatz aus (z.B. der aktuellen Position des Analysierzeigers). Erläuternd wird jedes Bit im Anfangsblock des Pakets, das einer eins in dem Hexadezimalwert entspricht, für Vergleich mit einem Vergleichs- oder Prüfwert kopiert. Zum Beispiel bedeutet ein Wert 0xFF00 im Abschnitt Extraktionsmaske eines Befehls, dass das ganze erste Byte am aktuellen Paketversatz zu kopieren ist und dass der Inhalt des zweiten Bytes irrelevant ist. Ähnlich bedeutet eine Extraktionsmaske 0x3FFF, dass alle außer den zwei signifikantesten Bits des ersten Byte zu kopieren sind. Aus dem extrahierten Inhalt wird unter Verwendung dessen, was auch immer aus dem Paket kopiert wurde, ein Zwei-Byte-Wert aufgebaut. Erläuternd wird der Rest des Pakets mit Nullen aufgefüllt. Der Fachmann erkennt, dass das Format einer Extraktionsmaste (oder einer weiter unten beschriebenen Ausgabemaske) nötigenfalls so angepasst werden kann, dass es eine Little-Endian- oder Big-Endian-Darstellung widerspiegelt.
  • Ein oder mehrere Befehle in einem Analysierprogramm benötigen möglicherweise keine an der Zeigerstelle aus dem Paket extrahierte Daten, um ihren Ausgabebetrieb durchführen zu können. Diese Befehle können einen Extraktionsmaske-Wert 0x0000 haben, um anzuzeigen, dass zwar noch ein Zwei-Byte-Wert aus der Zeigerposition wiedergewonnen wird, dass aber jedes Bit des Wertes maskiert ist. So eine Extraktionsmaske ergibt somit einen definitiven Wert null. Diese Art von Befehl kann zum Beispiel benutzt werden, wenn ein Ausgabebetrieb durchgeführt werden muss, bevor ein anderer wesentlicher Abschnitt von Anfangsblock-Daten mit einer anderen Extraktionsmaske als 0x0000 extrahiert wird.
  • Ein Abschnitt "Vergleichswert" eines Befehls ist ein Zwei-Byte-Hexadezimalwert, mit dem der extrahierte Paketinhalt zu vergleichen ist. Der Vergleichswert kann ein bekanntermaßen in einem bestimmten Feld eines spezifischen Protokoll-Anfangsblocks gespeicherter Wert sein. Der Vergleichswert kann einen Wert aufweisen, zu dem der extrahierte Abschnitt des Anfangsblocks passen oder eine spezifizierte Beziehung haben sollte, damit das Paket als mit den vorgewählten Protokollen kompatibel angesehen wird.
  • Ein Abschnitt "Operator" eines Befehls kennzeichnet einen Operator, der anzeigt, wie die extrahierten Werte und die Vergleichswerte zu vergleichen sind. Erläuternd zeigt EQ an, dass sie auf Gleichheit geprüft werden, NE zeigt an, dass sie auf Ungleichheit geprüft werden, LT zeigt an, dass der extrahierte Wert kleiner als der Vergleichswert sein muss, damit der Vergleich Erfolg hat, GE zeigt an, dass der extrahierte Wert größer als der Vergleichswert sein muss, usw. Ein Befehl, der auf die Ankunft eines neuen zu analysierenden Pakets wartet, kann eine Operation NP verwenden. Andere Operatoren für andere Funktionen können hinzugefügt werden, und den vorhandenen Operatoren können andere Namen zugewiesen werden.
  • Ein Abschnitt "Erfolgversatz" eines Befehls zeigt die Zahl der Zwei-Byte-Einheiten an, die der Zeiger vorrücken soll, wenn der Vergleich zwischen den extrahierten Werten und Prüfwerten Erfolg hat. Ein Abschnitt "Erfolgsbefehl" eines Befehls kennzeichnet, den nächsten Befehl im Programm 800 auszuführen, wenn der Vergleich erfolgreich ist.
  • Ähnlich zeigen Abschnitte "Fehlschlagversatz" und "Fehlschlagbefehl" die Zahl der Zwei-Byte-Einheiten, die der Zeiger vorrücken soll, bzw. den nächsten auszuführenden Befehl an, wenn der Vergleich fehlschlägt. In dieser Ausführungsform der Erfindung werden Versätze zwar in Einheiten von zwei Bytes ausgedrückt (z.B. Sechzehn-Bit-Worten), in einer alternativen Ausführungsform der Erfindung können sie aber kleinere oder größere Einheiten sein. Weiterhin kann ein Befehl durch eine Nummer oder einen Namen gekennzeichnet werden, wie oben erwähnt.
  • Nicht alle Befehle in einem Programm werden notwendigerweise für jedes Paket benutzt, das analysiert wird. Zum Beispiel kann ein Programm Befehle enthalten, auf mehr als eine Art oder Version eines Protokolls in einer bestimmten Schicht zu prüfen. Insbesondere prüft das Programm 800 auf Version vier oder sechs des IP-Protokolls in Schicht drei. Die Befehle, die für ein gegebenes Paket tatsächlich ausgegeben werden, hängen somit von dem Format des Pakets ab. Sobald ein Paket mit einem gegebenen Programm so weit wie möglich analysiert worden ist oder festgestellt worden ist, dass das Paket einem ausgewählten Protokoll entspricht oder nicht, kann das Analysieren aufhören oder kann ein Befehl zum Anhalten der Analysierprozedur ausgeführt werden. Erläuternd zeigt ein Abschnitt nächster Befehl eines Befehls (z.B. "Erfolgbefehl" oder "Fehlschlagbefehl") mit dem Wert "DONE" (Fertig) die Beendigung der Analyse eines Pakets an. Ein Befehl DONE oder ähnlich kann ein Leerbefehl sein. Mit anderen Worten, "DONE" kann einfach anzeigen, dass die Analyse für das gegenwärtige Paket zu beenden ist. Oder es kann, wie Befehl achtzehn des Programms 800, ein Befehl DONE irgendeine Aktion durchführen, um auf ein neues Paket zu warten (z.B. durch Initialisieren eines Registers).
  • Die übrigen Abschnitte des Befehlsinhalt-Feldes 806 werden benutzt, um eine Ausgabe- oder andere Datenspeicheroperation zu spezifizieren und zu vollenden. Insbesondere entspricht in dieser Ausführungsform ein Abschnitt "Ausgabeoperation" eines Befehls den im geladenen Befehlssatz enthaltenen Operationen. Somit kennzeichnet für das Programm 800 der Abschnitt Ausgabeoperation eines Befehls eine der sechzehn oben beschriebenen Operationen. Die im Programm 800 verwendeten Ausgabeoperationen werden weiter unten in Verbindung mit individuellen Befehlen näher beschrieben.
  • Ein Abschnitt "Operationsargument" eines Befehls enthält ein oder mehrere Argumente oder Felder, die zu speichern, zu laden oder anderweitig in Verbindung mit der Ausgabeoperation des Befehls zu benutzen sind. Erläuternd nimmt der Abschnitt Operationsargument die Form eines Mehrbit-Hexadezimalwertes an. Für das Programm 800 sind die Operationsargumente elf Bits groß. Ein Argument oder Abschnitt eines Arguments kann je nach der Ausgabeoperation verschiedene Bedeutungen haben. Zum Beispiel kann ein Operationsargument einen oder mehrere numerische Werte aufweisen, die in einem Register zu speichern oder zu benutzen sind, um einen Abschnitt eines Anfangsblocks zu lokalisieren oder einzugrenzen. Oder ein Argument-Bit kann einen Anzeiger aufweisen, um eine Aktion oder einen Status zu signalisieren. Insbesondere kann ein Argument-Bit spezifizieren, dass ein bestimmtes Register zurückzusetzen ist; ein Satz von Argument-Bits kann einen Versatz in einen Paket-Anfangsblock zu einem in einem Register zu speichernden Wert aufweisen, usw. Erläuternd wird der durch ein Opera tionsargument spezifizierte Versatz auf den Ort der Analysierzeigerposition, bevor der Zeiger vorgerückt wird, angewandt, wie durch den anwendbaren Erfolgversatz oder Fehlschlagversatz spezifiziert. Die im Programm 800 benutzten Operationsargumente werden weiter unten detaillierter erläutert.
  • Ein Abschnitt "Operationsfreigabe" eines Befehlsinhalts-Feldes spezifiziert, ob oder wann eine Befehlsausgabeoperation durchzuführen ist. Insbesondere kann im Ausführungsbeispiel der Erfindung eine Befehlsausgabeoperation durchgeführt werden oder nicht, je nach dem Ergebnis des Vergleichs zwischen einem aus einem Anfangsblock extrahierten Wert und dem Vergleichswert. Zum Beispiel kann eine Operationsfreigabe auf einen ersten Wert (z.B. null) gesetzt werden, wenn die Ausgabeoperation nie durchzuführen ist. Sie kann andere Werte annehmen, wenn sie nur dann durchzuführen ist, wenn der Vergleich den Operator befriedigt oder nicht (z.B. eins bzw. zwei). Eine Operationsfreigabe kann noch einen anderen Wert (z.B. drei) annehmen, wenn sie immer durchzuführen ist.
  • Ein Abschnitt "Verschieben" eines Befehls enthält einen Wert, der anzeigt, wie ein Ausgabewert zu verschieben ist. Eine Verschiebung kann notwendig sein, weil unterschiedliche Protokolle manchmal erfordern, dass Werte unterschiedlich formatiert werden. Außerdem erfordert ein Wert, der eine Länge oder einen Ort eines Anfangsblocks oder Anfangsblock-Feldes anzeigt, möglicherweise Verschieben, um die passende durch den Wert dargestellte Größe widerzuspiegeln. Zum Beispiel, da das Programm 800 darauf ausgelegt ist, Zwei-Byte-Einheiten zu benutzen, muss ein Wert möglicherweise verschoben werden, wenn er andere Einheiten (z.B. Bytes) widerspiegeln soll. Ein Verschiebungswert in einer vorliegenden Ausführungsform zeigt die Zahl der Stellen (z.B. Bits) an, um die ein Ausgabewert nach rechts zu verschieben ist. In einer anderen Ausführungsform der Erfindung kann ein Verschiebungswert einen anderen Verschiebungstyp oder eine andere Verschiebungsrichtung darstellen.
  • Schließlich spezifiziert eine "Ausgabemaske", wie ein Wert, der in einem Register oder einer anderen Datenstruktur gespeichert wird, zu formatieren ist. Wie oben angegeben, kann eine Ausgabeoperation erfordern, das ein extrahierter, berechneter oder zusammengesetzter Wert gespeichert wird. Ähnlich wie die Extraktionsmaske ist die Ausgabemaske ein Zwei-Byte-Hexadezimalwert. Für jede Stelle in der Ausgabemaske, die eine Eins enthält, ist in dieser Ausführungsform der Erfindung das entsprechende Bit in dem durch die Ausgabeoperation und/oder das Operationsargument gekennzeichneten Zwei-Byte-Wert zu speichern. Zum Beispiel zeigt ein Wert 0xFFFF an, dass der spezifizierte Zwei-Byte-Wert so, wie er ist, zu speichern ist. Erläuternd wird für jede Stelle in der Ausgabemaske, die eine Null enthält, eine Null gespeichert. Somit zeigt ein Wert 0xF000 an, dass die signifikantesten vier Bits des ersten Bytes zu speichern sind, aber der Rest des gespeicherten Wertes irrelevant ist und mit Nullen aufgefüllt werden kann.
  • Eine Ausgabeoperation "KEINE" kann benutzt werden, um anzuzeigen, dass keine Ausgabeoperation durchzuführen oder zu speichern ist, in welchem Fall andere, die Ausgabe betreffende Befehlsabschnitte ignoriert werden können oder spezifizierte Werte enthalten können (z.B. alles Nullen). In dem in 8 gezeigten Programm kann jedoch eine Ausgabeoperation CLR_REG, die die selektive Neuinitialisierung von Registern erlaubt, mit einem Operationsargument null benutzt werden, um effektiv keine Ausgabe durchzuführen. Insbesondere zeigt ein Operationsargument null für die Operation CLR_REG an, dass keine Register zurückzusetzen sind. In einer alternativen Ausführungsform der Erfindung könnte der Operationsfreigabe-Abschnitt eines Befehls auf einen Wert (z.B. null) gesetzt werden, der anzeigt, dass die Ausgabeoperation nie durchzuführen ist.
  • Das Format und die Sequenz der Befehle von 8 stellen selbstverständlich nur ein Verfahren zum Analysieren eines Pakets dar, um zu bestimmen, ob es einem bestimmten Datenübertragungsprotokoll entspricht. Insbesondere sind die Befehle darauf ausgelegt, einen oder mehrere Abschnitte eines oder mehrerer Paket-Anfangsblöcke auf Vergleich mit bekannten oder erwarteten Werten zu prüfen und nötigenfalls ein Register oder einen anderen Speicherplatz zu konfigurieren oder zu laden. Wie der Fachmann erkennt, können Befehle zum Analysieren eines Pakets eine beliebige Zahl von Formen annehmen und können in mannigfachen Sequenzen durchgeführt werden, ohne den Schutzbereich der Erfindung zu verlassen.
  • Unter Bezugnahme auf 8 können nun Befehle im Programm 800 im Detail beschrieben werden. Vor Ausführung des in 8 gezeigten Programms befindet sich ein Analysierzeiger am Beginn eines Anfangsblocks der Schicht zwei eines Pakets. Die Position des Analysierzeigers kann für leichte Bezugnahme und Aktualisierung während der Analysierprozedur in einem Register gespeichert werden. Insbesondere kann die Position des Analysierzeigers als ein Versatz (z.B. vom Beginn des Anfangsblocks der Schicht zwei) beim Berechnen der Position einer bestimmten Position innerhalb eines Anfangsblocks benutzt werden.
  • Das Programm 800 beginnt mit einem Befehl WAIT (z.B. Befehl null), der auf ein neues Paket wartet (z.B. durch den Operator NP angezeigt), und wenn einer empfangen wird, stellt es einen Analysierzeiger auf das zwölfte Byte des Anfangsblocks der Schicht zwei. Dieser Versatz zum zwölften Byte wird durch den Abschnitt Erfolgversatz des Befehls angezeigt. Bis ein Paket empfangen wird, schleift der Befehl WAIT in sich. Außerdem wird eine Operation CLR_REG durchgeführt, jedoch zeigt die Operationsfreigabe-Einstellung an, dass sie nur durchgeführt wird, wenn der Vergleich Erfolg hat (z.B. wenn ein neues Paket empfangen wird).
  • Die spezifizierte Operation CLR_REG arbeitet in Übereinstimmung mit dem Operationsargument des Befehls WATT (d.h. 0x3FF). In dieser Ausführungsform entspricht jedes Bit des Arguments einem Register oder einer anderen Datenstruktur. Die bei dieser Operation initialisierten Register können die Folgenden umfassen: ADDR (z.B. die Adresse oder den Ort des Analysierzeigers zu speichern), FLOWID (z.B. den Flussschlüssel des Pakets zu speichern), SEQNO (z.B. eine TCP-Sequenznummer zu speichern), SAP (z.B. der Ethertyp des Pakets) und PAYLOADLEN (z.B. Nutzlastlänge). Die folgenden Register, die konfiguriert sind, bestimmte Versätze zu speichern, können ebenfalls zurückgesetzt werden: FLOWOFF (z.B. Versatz innerhalb des Registers FLOWID), SEQOFF (z.B. Versatz innerhalb des Registers SEQNO), L3OFFSET (z.B. Versatz innerhalb des Anfangsblock der Schicht drei des Pakets), HDRSPLIT (z.B. Ort zum Aufspalten eines Pakets) und CSUMSTART (z.B. Startort zum Berechnen einer Prüfsumme). Außerdem können ein oder mehrere Status- oder Steueranzeiger (z.B. die Register CONTROL oder FLAGS) zum Berichten des Status eines oder mehrerer Anzeiger eines Paket-Anfangsblocks zurückgesetzt werden. Zusätzlich können auch ein oder mehrere temporäre Register (z.B. R1, R2) oder andere Datenstrukturen initialisiert werden. Diese Register sind für die Datenstrukturen, die in einer Ausführungsform der Erfindung verwendet werden können, nur erläuternd. In anderen Ausführungsformen können für dieselben oder andere Ausgabeoperationen andere Datenstrukturen benutzt werden.
  • Temporäre Register wie z.B. R1 und/oder R2 können im Programm 800 benutzt werden, um verschiedene Anfangsblöcke und Anfangsblock-Felder zu verfolgen. Der Fachmann erkennt die Zahl der möglichen Kombinationen von Datenübertragungsprotokollen und die Wirkung dieser verschiedenen Kombinationen auf die Struktur und das Format eines Paket-Anfangsblocks. Möglicherweise müssen mehr Informationen geprüft oder aus einem Paket entsprechend einem Protokoll oder einem Satz von Protokollen statt aus einem Paket entsprechend einem anderen Protokoll oder Satz von Protokollen gesammelt werden. Zum Beispiel, wenn Erweiterungs-Anfangsblöcke mit einem Internet-Protokoll-Anfangsblock benutzt werden, müssen möglicherweise Werte aus diesen Erweiterungs-Anfangsblöcken und/oder deren Längen gespeichert werden, welche Werte nicht benötigt werden, wenn keine Erweiterungs-Anfangsblöcke benutzt werden. Beim Berechnen eines bestimmten Versatzes wie zum Beispiel eines Versatzes zum Beginn eines Datenabschnitts eines Pakets müssen möglicherweise mehrere Register nicht aufrechterhalten und ihre Werte kombiniert oder addiert werden. In diesem Beispiel kann ein Register oder temporäres Register die Größe oder das Format eines Erweiterungs-Anfangsblocks verfolgen, während ein anderes Register den Basis-IP-Anfangsblock verfolgt.
  • Ein Befehl VLAN (z.B. Befehl eins) prüft das Zwei-Byte-Feld an der Analysierzeigerposition (möglicherweise ein Feld Typ, Länge oder TPID) auf einen Wert, der einen VLAN-markierten Anfangsblock anzeigt (z.B. 8100 in Hexadezimalschreibweise). Wenn der Anfangsblock VLAN-markiert ist, wird der Zeiger ein Paar Bytes hochgezählt (z.B. eine Zwei-Byte-Einheit), und die Ausführung geht mit dem Befehl CFI weiter; andernfalls geht die Ausführung mit dem Befehl 802.3 weiter. In jedem Fall zeigt die Operationsfreigabe des Befehls an, dass immer eine Operation IM CTL durchzuführen ist.
  • Wie oben beschrieben, bewirkt eine Operation IM CTL, dass ein Steuerregister oder eine andere Datenstruktur mit einem oder mehreren Anzeigern zu bevölkern ist, um den Status oder Zustand eines Pakets zu berichten. Ein Steuerindikator kann anzeigen, ob ein Paket für erweiterte Verarbeitung geeignet ist (z.B. ob ein Signal No Assist für das Paket erzeugt werden sollte), ob ein Paket irgendwelche Daten enthält und, wenn ja, ob die Größe des Datenabschnitts einen spezifizierten Schwellenwert übersteigt. Das Operationsargument 0x00A für den Befehl VLAN enthält den im Steuerregister zu speichernden Wert, wobei individuelle Bits des Arguments bestimmten Anzeigern entsprechen. Erläuternd können Anzeiger, die den gerade beschriebenen Zuständen zugeordnet sind, bei dieser Operation IM CTL auf eins oder wahr gesetzt werden.
  • Der Befehl CFI (z.B. Befehl zwei) prüft das CFI-Bit oder den Anzeiger in einem Anfangsblock der Schicht zwei. Wenn das CFI-Bit gesetzt ist, ist das Paket nicht für die Verarbeitungsverbesserungen einer vorliegenden Ausführungsform der Erfindung geeignet, und die Analysierprozedur endet mit Aufruf des Befehls DONE (z.B. Befehl achtzehn). Wenn das CFI-Bit nicht gesetzt ist, wird der Zeiger ein weiteres Paar Bytes hochgezählt, und die Ausführung geht mit dem Befehl 802.3 weiter. Wie oben erläutert, zeigt eine Operation Leerausgabe (z.B. "KEINE") an, dass keine Ausgabeoperation durchzuführen ist. Außerdem stellt der Ausgabefreigabewert (z.B. null) weiterhin sicher, dass keine Ausgabeoperation durchgeführt wird.
  • Im Befehl 802.3 (z.B. Befehl drei) wird ein Typ- oder Länge-Feld (je nach dem Ort des Zeigers und dem Format des Pakets) geprüft, um zu bestimmen, ob das Format der Schicht zwei des Pakets traditionelles Ethernet oder 802.3-Ethernet ist. Wenn der Wert im Anfangsblock-Feld 802.3-Ethernet anzuzeigen scheint (z.B. einen Hexadezimalwert kleiner als 0600 enthält), wird der Zeiger zwei Byte hochgezählt (auf das, was ein Feld LLC SNAP sein sollte), und die Ausführung geht mit dem Befehl LLC_1 weiter. Andernfalls kann das Protokoll der Schicht zwei als traditionelles Ethernet angesehen werden, und die Ausführung geht mit dem Befehl IPV4_1 weiter. Der Befehl 802.3 in dieser Ausführungsform der Erfindung umfasst keine Ausgabeoperation.
  • In den Befehlen LLC_1 und LLC_2 (z.B. Befehle vier und fünf) wird ein vermutetes Feld LLC SNAP der Schicht zwei geprüft, um sicherzustellen, dass das Paket dem 802.3-Ethernet-Protokoll entspricht. Im Befehl LLC_1 wird ein erster Teil des Feldes geprüft, und wenn erfolgreich, wird der Zeiger zwei Bytes hochgezählt und wird ein zweiter Teil im Befehl LLC_2 geprüft. Wenn der Befehl LLC_2 Erfolg hat, wird der Analysierzeiger vier Bytes hochgezählt, um das zu erreichen, was ein Typ-Feld sein sollte, und die Ausführung geht mit dem Befehl IPV4_1 weiter. Wenn eine der Prüfungen fehlschlägt, wird die Analysierprozedur jedoch beendet. Im Ausführungsbeispiel der Erfindung wird keine Ausgabeoperation durchgeführt, während das Feld LLC SNAP geprüft wird.
  • Im Befehl IPV4_1 (z.B. Befehl sechs) sollte der Analysierzeiger in einem Ethernet-Typ-Feld sein. Dieses Feld wird geprüft, um zu bestimmen, ob das Protokoll der Schicht drei der Version vier des Internet-Protokolls zu entsprechen scheint. Ist die Prüfung erfolgreich (z.B. enthält das Typ-Feld einen Hexadezimalwert 0800), wird der Zeiger um zwei Byte zum Beginn des Anfangsblocks der Schicht drei vorgerückt, und die Ausführung des Programms 800 geht mit dem Befehl IPV4_2 weiter. Ist die Prüfung erfolglos, geht die Ausführung mit dem Befehl IPV6_1 weiter. Unabhängig von den Prüfungsergebnissen zeigt der Operationsfreigabewert (z.B. drei) an, dass die spezifizierte LD SAP-Ausgabeoperation immer durchgeführt wird.
  • Wie vorher beschrieben, wird bei einer Operation LD SAP der Ethertyp eines Pakets (oder Service Access Point, Dienstzugangspunkt) in einem Register gespeichert. Ein Teil des Operationsarguments von 0x100, insbesondere die sechs Bits ganz rechts (z.B. null), bilden einen Versatz zu einem Zwei-Byte-Wert, der den Ethertyp aufweist. Der Versatz ist in diesem Beispiel null, weil im vorliegenden Kontext der Analysierzeiger schon im Typ-Feld ist, das den Ethertyp enthält. In der vorliegend beschriebenen Ausführungsform bildet der Rest des Operationsarguments einen Anzeiger, der spezifiziert, dass die Startposition des Anfangsblocks der Schicht drei (z.B. ein Versatz vom Beginn des Pakets) ebenfalls zu speichern ist (z.B. im Register L3OFFSET). Insbesondere liegt der Beginn des Anfangsblocks der Schicht drei bekanntermaßen unmittelbar hinter dem Zwei-Byte-Typ-Feld.
  • Der IPV4_2 (z.B. Befehl sieben) prüft ein vermutetes Version-Feld der Schicht drei, um sicherzustellen, dass das Protokoll der Schicht drei die Version vier von IP ist. Insbesondere spezifiziert eine Spezifikation für die Version vier von IP, dass die ersten vier Bits des Anfangsblocks der Schicht drei einen Wert 0x4 enthalten. Wenn die Prüfung fehlschlägt, endet die Analysierprozedur mit dem Befehl DONE. Wenn die Prüfung Erfolg hat, rückt der Zeiger sechs Bytes vor, und der Befehl IPV4_3 wird aufgerufen.
  • Die spezifizierte Operation LD SUM, die nur durchgeführt wird, wenn der Vergleich im Befehl IPV4_2 Erfolg hat, zeigt an, dass ein Versatz zum Beginn einer Stelle, von der an eine Prüfsumme berechnet werden kann, gespeichert werden sollte. Insbesondere sollte in der vorliegend beschriebenen Ausführungsform der Erfindung eine Prüfsumme vom Beginn des TCP-Anfangsblocks an berechnet werden (unter der Voraussetzung, dass der Anfangsblock der Schicht vier TCP ist). Der Wert des Operationsarguments (z.B. 0x00A) zeigt an, dass die Prüfsumme zwanzig Bytes (zum Beispiel zehn Zwei-Byte-Schritte) ab dem aktuellen Zeiger liegt. Daher wird ein Wert von zwanzig Bytes zu der Analysierzeigerposition addiert, und das Ergebnis wird in einem Register oder einer anderen Datenstruktur gespeichert (z.B. dem Register CSUMSTART).
  • Der Befehl IPV4_3 (z.B. Befehl acht) ist darauf ausgelegt, zu bestimmen, ob der IP-Anfangsblock des Pakets IP-Fragmentierung anzeigt. Wenn der in Übereinstimmung mit der Extraktionsmaske aus dem Anfangsblock extrahierte Wert nicht gleich dem Vergleichswert ist, zeigt das Paket Fragmentierung an. Wird Fragmentierung nachgewiesen, wird das Paket als für die hierin erörterten Verarbeitungsverbesserungen ungeeignet angesehen, und die Prozedur endet (zum Beispiel durch den Befehl DONE). Andernfalls wird der Zeiger zwei Bytes hochgezählt, und nach Durchführung einer Operation LD_LEN wird der Befehl IPV4_4 aufgerufen.
  • In Übereinstimmung mit der Operation LD_LEN wird die Länge des IP-Segments gespeichert. Das gezeigte Operationsargument (z.B. 0x03E) enthält einen Versatz zum Feld Gesamtlänge, wo sich der Wert befindet. Insbesondere bilden die am Wenigsten signifikanten sechs Bits den Versatz. Da der Zeiger schon an diesem Feld vorbei vorgerückt wurde, enthält das Operationsargument einen negativen Wert. Der Fachmann erkennt, dass dieser Binärwert (z.B. 111110) benutzt werden kann, um den Dezimalwert negativ zwei darzustellen. Daher wird der gegenwärtige Versatz des Zeigers, minus vier Bytes (z.B. zwei Zwei-Bytes-Einheiten) in einem Register oder einer anderen Datenstruktur gespeichert (zum Beispiel dem Register PAYLOADLEN). Man kann irgendein geeignetes Verfahren zum Darstellen eines negativen Versatzes benutzten. Oder die IP-Segment-Länge kann gespeichert werden, während der Zeiger an einem dem Feld Gesamtlänge vorhergehenden Ort ist (zum Beispiel während eines früheren Befehls).
  • Im Befehl IPV4_4 (zum Beispiel Befehl neun) wird ein Ein-Byte-Protokoll-Feld geprüft, um zu bestimmen, ob das Protokoll der Schicht vier TCP zu sein scheint. Wenn ja, wird der Zeiger vierzehn Bytes vorgerückt, und die Ausführung geht mit dem Befehl TCP_1 weiter; anderenfalls endet die Prozedur.
  • Die spezifizierte Operation LD FID, die nur durchgeführt wird, wenn der Vergleich im Befehl IPV4_4 Erfolg hat, umfasst, den Flussschlüssel des Pakets wiederzugewinnen und ihn in einem Register oder anderen Ort zu speichern (z.B. dem Register FLOWID). Der Fachmann erkennt, dass, damit der Vergleich im Befehl IPV4_4 erfolgreich ist, die Anfangsblöcke der Schicht drei und vier des Pakets IP (Version vier) bzw. TCP entsprechen müssen. Wenn ja, wird der ganze Flussschlüssel (z.B. IP-Quellen- und -Zieladressen plus TCP-Quellen- und -Ziel-Port-Nummern) zusammenhängend im Anfangsblock-Abschnitt des Pakets gespeichert. Insbesondere enthält der Flussschlüssel den letzten Abschnitt des IP-Anfangsblocks und den Anfangsabschnitt des TCP-Anfangsblocks und kann in einer Operation extrahiert werden. Das Operationsargument (z.B. 0x182) enthält somit zwei Werte, die nötig sind, um den Flussschlüssel zu lokalisieren und einzugrenzen. Erläuternd kennzeichnen die sechs Bits ganz rechts im Argument (z.B. 0x02) einen Versatz von der Zeigerposition in Zwei-Byte-Einheiten zum Beginn des Flussschlüssels. Die anderen fünf Bits des Arguments (z.B. 0x06) kennzeichnen die Größe des zu speichernden Flussschlüssels in Zwei-Byte-Einheiten.
  • Im Befehl IPV6_1 (zum Beispiel Befehl zehn), der dem durch den Befehl IPV4_1 durchgeführten Vergleich folgt, sollte der Analysierzeiger in einem Typ-Feld der Schicht zwei sein. Ist diese Prüfung erfolgreich (z.B. das Typ-Feld hält einen Hexadezimalwert 86DD), wird der Befehl IPV6_2 durchgeführt, nachdem eine Operation LD SUM durchgeführt worden ist, und der Zeiger wird zwei Bytes zum Beginn des Protokolls der Schicht drei hochgezählt. Ist die Prüfung erfolglos, endet die Prozedur.
  • Die angezeigte Operation LD SUM im Befehl IPV6_1 ist der im Befehl IPV4_2 durchgeführten Operation ähnlich, benutzt aber ein anderes Argument. Wieder ist die Prüfsumme vom Beginn des TCP-Anfangsblocks an zu berechnen (unter der Voraussetzung, dass der Anfangsblock der Schicht vier TCP ist). Das spezifizierte Operationsargument (z.B. 0x015) enthält somit einen Versatz zum Beginn des TCP-Anfangsblocks – einundzwanzig Zwei-Byte-Schritte voraus. Der angezeigte Versatz wird zu der gegenwärtigen Zeigerposition addiert und in einem Register oder einer anderen Datenstruktur gespeichert (z.B. dem Register CSUMSTART).
  • Befehl IPV6_2 (zum Beispiel Befehl elf) prüft ein vermutetes Version-Feld der Schicht drei, um noch mehr sicherzustellen, dass das Protokoll der Schicht drei Version sechs von IP ist. Wenn der Vergleich fehlschlägt, endet die Analysierprozedur mit dem Aufruf des Befehls DONE. Wenn er Erfolg hat, wird der Befehl IPV6_3 aufgerufen. Die Operation IM_R1, die nur durchgeführt wird, wenn der Vergleich in dieser Ausführungsform Erfolg hat, speichert die Länge des IP-Anfangsblocks aus einem Feld Nutzlastlänge. Wie der Fachmann erkennt, enthält das Feld Gesamtlänge (z.B. IP-Segmentgröße) eines IP-Anfangsblocks der Version vier die Größe des Anfangsblocks der Version vier. Jedoch enthält das Feld Nutzlastlänge (z.B. IP-Segmentgröße) eines IP-Anfangsblocks der Version sechs die Größe des Anfangsblocks der Version sechs nicht. Daher wird die Größe des Anfangsblocks der Version sechs, die durch die acht Bits ganz rechts im Ausgabeargument (zum Beispiel 0x14, was zwanzig Zwei-Byte-Einheiten anzeigt) gekennzeichnet wird, gespeichert. Erläuternd kennzeichnet der Rest des Arguments die Datenstruktur, in der die Anfangsblock-Länge zu speichern ist (z.B. temporäres Register R1). Wegen der Größenvariation der Anfangsblöcke der Schicht drei zwischen Protokollen wird in einer Ausführungsform der Erfindung die Anfangsblock-Größe in anderen Einheiten angezeigt, um größere Genauigkeit zu ermöglichen. Insbesondere wird in einer Ausführungsform der Erfindung die Größe des Anfangsblocks in Bytes im Befehl IPV6_2 spezifiziert, in welchem Fall das Ausgabeargument 0x128 sein könnte.
  • Der Befehl IPV6_3 (z.B. Befehl zwölf) in dieser Ausführungsform prüft keinen Anfangsblock-Wert. In dieser Ausführungsform zeigt die Kombination einer Extraktionsmaske 0x0000 mit einem Vergleichswert 0x0000 an, dass vor der nächsten Prüfung eines Abschnitt eines Anfangsblocks eine Ausgabeoperation gewünscht wird. Nach Durchführung der Operation LD FID wird der Zeiger sechs Bytes zu einem Feld Nächster Anfangsblock des Anfangsblocks in Version sechs von IP vorgerückt. Da die Extraktionsmaske und der Vergleichswert beide 0x0000 sind, sollte der Vergleich nie fehlschlagen, und der Fehlschlag-Zweig des Befehls sollte nie aufgerufen werden.
  • Wie vorher beschrieben, speichert eine Operation LD FID einen Flussschlüssel in einem geeigneten Register oder einer anderen Datenstruktur (z.B. dem Register FLOWID). Erläuternd enthält das Operationsargument 0x484 zwei Werte zum Kennzeichnen und Eingrenzen des Flussschlüssels. Insbesondere zeigen die sechs Bits ganz rechts (z.B. 0x04) an, dass der Flussschlüssel-Abschnitt in einem Versatz von acht Bytes (z.B. vier Zwei-Byte-Schritten) von der aktuellen Zeigerposition liegt. Der Rest des Operationsarguments (z.B. 0x12) zeigt an, dass sechsunddreißig Bytes (z.B. das Dezimaläquivalent von 0x12 Zwei-Byte-Einheiten) von dem berechneten Versatz zu kopieren sind. Im Ausführungsbeispiel der Erfindung wird der ganze Flussschlüssel intakt kopiert, einschließlich der Quellen- und Zieladressen der Schicht drei und der Quellen- und Ziel-Ports der Schicht vier.
  • Im Befehl IPV6_4 (zum Beispiel Befehl dreizehn) wird ein vermutetes Feld Nächster Anfangsblock geprüft, um zu bestimmen, ob das Protokoll der Schicht vier des Protokollstapels des Pakets TCP zu sein scheint. Wenn ja, rückt die Prozedur sechsunddreißig Bytes vor (z.B. achtzehn Zwei-Byte-Einheiten), und der Befehl TCP_1 wird aufgerufen; andernfalls endet die Prozedur (zum Beispiel durch den Befehl DONE). Danach wird die Operation LD_LEN durchgeführt, wenn der Wert im Feld Nächster Anfangsblock 0x06 ist. Wie oben beschrieben, speichert diese Operation die IP-Segmentgröße. Wieder enthält das Argument (z.B. 0x03F) einen negativen Versatz, in diesem Fall einen negativen. Dieser Versatz zeigt an, dass das gewünschte Feld Nutzlastlänge zwei Bytes vor der gegenwärtigen Zeigerposition liegt. Daher wird der negative Versatz zu dem gegenwärtigen Zeigerversatz addiert und das Ergebnis in einem geeigneten Register oder einer anderen Datenstruktur gespeichert (z.B. dem Register PAYLOADLEN).
  • In den Befehlen TCP_1, TCP_2, TCP_3 und TCP_4 (z.B. Befehlen vierzehn bis siebzehn) werden keine Anfangsblock-Werte – außer bestimmten in den Ausgabeoperationen des Befehls spezifizierten Anzeigern – geprüft, jedoch werden verschiedene Daten aus dem TCP-Anfangsblock des Pakets gespeichert. Im Ausführungsbeispiel enthalten die Daten, die gespeichert werden, eine TCP-Sequenznummer, eine TCP-Anfangsblock-Länge und einen oder mehrere Anzeiger. Für jeden Befehl wird die spezifizierte Operation durchgeführt und wird der nächste Befehl aufgerufen. Wie oben beschrieben, wird ein Vergleich zwischen dem Vergleichswert 0x0000 und einem Extraktionswert null, wie in allen diesen Befehlen benutzt, nie fehlschlagen. Nach dem Befehl TCP_4 kehrt die Analysierprozedur zum Befehl WAIT zurück, um auf ein neues Paket zu warten.
  • Für die Operation LD SEQ im Befehl TCP_1 enthält das Operationsargument (z.B. 0x081) zwei Werte, um eine TCP-Sequenznummer zu bestimmen und zu extrahieren. Die sechs Bits ganz rechts (z.B. 0x01) zeigen an, dass die Sequenznummer zwei Bytes von der aktuellen Zeigerposition liegt. Der Rest des Arguments (z.B. 0x2) zeigt die Zahl der Zwei-Byte-Einheiten an, die von dieser Position kopiert werden müssen, um die Sequenznummer zu erfassen. Erläuternd wird die Sequenznummer im Register SEQNO gespeichert.
  • Für die Operation ST_FLAG im Befehl TCP_2 wird das Operationsargument (z.B. 0x145) benutzt, um ein Register (z.B. das Register FLAGS) mit in einer Nachanalyseaufgabe zu benutzenden Anzeigern zu konfigurieren. Die sechs Bits ganz rechts (z.B. 0x05) bilden einen Versatz in Zwei-Byte-Einheiten zu einem Zwei-Byte-Abschnitt des TCP-Anfangsblocks, der Anzeiger enthält, die sich darauf auswirken können, ob das Paket für Nachanalyseverarbeitungs-Verbesserungen der vorliegenden Erfindung geeignet ist. Zum Beispiel können sich Anzeiger URG, PSH, RST, SYN und FIN an der Versatzposition befinden und benutzt werden, um das Register zu konfigurieren. Die Ausgabemaske (z.B. 0x002F) zeigt an, dass nur bestimmte Abschnitte (z.B. Bits) des Anzeiger-Feldes des TCP-Anfangsblocks zu speichern sind.
  • Die Operation LD_R1 des Befehls TCP_3 ist der im Befehl IPV6_2 durchgeführten Operation ähnlich. Hier enthält ein Operationsargument 0x205 einen Wert (z.B. die am Wenigsten signifikanten sechs Bits), der einen Versatz von fünf Zwei-Byte-Einheiten von der aktuellen Zeigerposition kennzeichnet. Dieser Ort sollte ein Feld Anfangsblock-Länge enthalten, das in einer Datenstruktur zu speichern ist, die durch den Rest des Arguments gekennzeichnet wird (z.B. das temporäre Register R1). Die Ausgabemaske (z.B. 0xF000) zeigt an, dass nur die ersten vier Bits gespeichert werden (z.B. ist das Feld Anfangsblock-Länge nur vier Bits groß).
  • Wie der Fachmann erkennen kann, muss im Ausführungsbeispiel der aus dem Feld Anfangsblock-Länge extrahierte Wert möglicherweise angepasst werden, um die Verwendung von Zwei-Byte-Einheiten (z.B. Sechzehn-Bit-Worten) widerzuspiegeln. In Übereinstimmung mit dem Abschnitt Verschieben des Befehls TCP_3 wird daher der aus dem Feld extrahierte und durch die Ausgabemaske (z.B. 0xF000) konfigurierte Wert an die Positionen elf rechts verschoben, wenn er gespeichert wird, um die Berechnungen zu vereinfachen.
  • Die Operation LD_HDR des Befehls TCP_4 bewirkt das Laden eines Versatzes zum ersten Byte von dem TCP-Anfangsblock folgenden Paketdaten. Erläuternd können Pakete, die mit einem vorgewählten Protokollstapel kompatibel sind, an irgendeiner Stelle in Anfangsblock- und Datenabschnitte getrennt werden. Das Speichern eines Versatzes zum Datenabschnitt macht es nun leichter, das Paket später aufzuspalten. Erläuternd enthalten die sieben Bits ganz rechts im Operationsargument 0x0FF ein erstes Element des Versatzes zu den Daten. Der Fachmann erkennt das Bitmuster (z. B. 1111111) als negativ eins gleichend. Daher wird ein Versatzwert gleich dem aktuellen Analysierzeiger (z.B. der Wert im Register ADDR) minus zwei Bytes – was den Beginn des TCP-Anfangsblocks lokalisiert – gespeichert. Der Rest des Arguments zeigt an, dass der Wert einer temporären Datenstruktur (z.B. temporäres Register R1) zu diesem Versatz zu addieren ist. In diesem bestimmten Kontext wird der im vorher gehenden Befehl gespeicherte Wert (z.B. die Länge des TCP-Anfangsblocks) addiert. Diese zwei Werte bilden in Kombination miteinander einen Versatz zum Beginn der Paketdaten, der in einem geeigneten Register oder einer anderen Datenstruktur (z.B. dem Register HDRSPLIT) gespeichert wird.
  • Schließlich, und wie oben erwähnt, zeigt der Befehl DONE (z.B. Befehl achtzehn) das Ende der Analyse eines Pakets an, wenn festgestellt wird, dass das Paket nicht einem oder mehreren der den gezeigten Befehlen zugeordneten Protokolle entspricht. Dies kann als ein Befehl "Aufräumen" angesehen werden. Insbesondere zeigt die Ausgabeoperation LD CTL mit einem Operationsargument 0x001 an, dass in dem oben in Verbindung mit dem Befehl VLAN beschriebenen Steuerregister kein Signal No Assist zu setzen ist (z.B. auf eins). Der Anzeiger No Assist, wie anderswo beschrieben, kann benutzt werden, um andere Module des Netzschnittstelle zu informieren, dass das vorliegende Paket für eine oder mehrere anderswo beschriebene Verarbeitungsverbesserungen ungeeignet ist.
  • Das gezeigte Programm oder der gezeigte Mikrocode liefert nur ein Verfahren zum Analysieren eines Pakets. Andere Programme mit denselben Befehlen in einer anderen Sequenz oder völlig anderen Befehlen mit ähnlichen oder unähnlichen Formaten können verwendet werden, um Abschnitte von Anfangsblöcken zu prüfen und zu speichern und Register und andere Datenstrukturen zu konfigurieren.
  • Die bei Anwendung der verbesserten Verarbeitung einer vorliegenden Ausführungsform der Erfindung zu realisierenden Effizienzgewinne wiegen die Zeit, die nötig ist, um ein Paket mit dem gezeigten Programm zu analysieren, mehr als auf. Und obwohl in einer aktuellen Ausführungsform ein Anfangsblock-Analysator ein Paket in einer NIC analysiert, muss das Paket möglicherweise noch von einem Prozessor in einem Hauptrechner durch seinen Protokollstapel verarbeitet werden (z.B. um die Protokoll-Anfangsblöcke zu entfernen). Dies zu tun vermeidet, das Datenverarbeitungsgerät (zum Beispiel die Netzschnittstelle) mit so einer Aufgabe zu belasten.
  • Eine Ausführungsform einer Flussdatenbank
  • 5 zeigt eine Flussdatenbank (FDB) 110 in Übereinstimmung mit einer Ausführungsform der Erfindung. Erläuternd ist die FDB 110 als CAM (inhaltsadressierbarer Spei cher) unter Verwendung einer neu beschreibbaren Speicherkomponente (z.B. RAM, SRAM, DRAM) ausgeführt. In dieser Ausführungsform enthält die FDB 110 einen assoziativen Abschnitt 502 und einen assoziierten Abschnitt 504 und kann mit einer Flussnummer 506 indexiert sein.
  • Der Schutzumfang der Erfindung beschränkt die Form oder Struktur der Flussdatenbank 110 nicht. In alternativen Ausführungsformen der Erfindung kann praktisch jede Form von Datenstruktur verwendet werden (z.B. Datenbank, Tabelle, Warteschlange, Liste, Anordnung), entweder monolithisch oder segmentiert, und kann in Hardware oder Software ausgeführt werden. Die gezeigte Form von FDB 110 ist nur eine Art, nützliche Informationen hinsichtlich Datenflüssen durch die NIC 100 aufrechtzuerhalten. Wie der Fachmann erkennt, erlaubt die Struktur einer CAM stets hoch effizientes und schnelles assoziatives Suchen.
  • Im Ausführungsbeispiel der Erfindung erlauben die in der FDB 110 gespeicherten Informationen und der Betrieb des Flussdatenbankmanagers (FDBM) 108 (weiter unten beschrieben) Funktionen wie z.B. Datenwiederzusammenbau, Schubverarbeitung von Paket-Anfangsblöcken und andere Verbesserungen. Diese Funktionen mögen wie folgt kurz beschrieben werden.
  • Eine Form von Datenwiederzusammenbau umfasst den Wiederzusammenbau oder die Kombination von Daten aus mehreren verknüpften Paketen (zum Beispiel Paketen aus einem einzelnen Datenfluss oder einem einzelnen Datagramm). Ein Verfahren für die Schubverarbeitung von Paket-Anfangsblöcken bringt mit sich, Protokoll-Anfangsblöcke aus mehreren verknüpften Paketen durch einen Protokollstapel kollektiv statt ein Paket auf einmal zu verarbeiten. Eine andere Beispielfunktion der NIC 100 umfasst die Aufteilung oder Verteilung so einer Protokollstapelverarbeitung (und/oder anderer Funktionen) auf Prozessoren in einem Mehrprozessor-Hauptrechnersystem. Noch eine andere mögliche Funktion der NIC 100 ist, die Übertragung von wiederzusammengesetzten Daten an ein Zielobjekt (z.B. ein Anwendungsprogramm) in einer effizienten Gruppierung (z.B. einer Speicherseite) zu ermöglichen, wodurch stückweise und höchst ineffiziente Übertragungen der Daten eines Pakets auf einmal vermieden werden. Daher ist es in dieser Ausführungsform der Erfindung ein Zweck der FDB 110 und des FDBM 108, Informationen für den Gebrauch der NIC 100 und/oder eines Hauptcomputersystems beim Einschalten, Ausschalten oder Durchführen einer oder mehrerer dieser Funktionen zu erzeugen.
  • Der assoziative Abschnitt 502 der FDB 110 in 5 speichert den Flussschlüssel jedes gültigen Flusses, der für ein von der NIC 100 bedientes Objekt bestimmt ist. Daher enthält in einer Ausführungsform der Erfindung der assoziative Abschnitt 502 eine IP-Quellen-Adresse 510, eine IP-Ziel-Adresse 512, einen TCP-Quellen-Port 514 und einen TCP-Ziel-Port 516. Wie in früheren Abschnitten beschrieben, können diese Felder aus einem Paket extrahiert und dem FDBM 108 durch den Anfangsblock-Analysator 106 geliefert werden.
  • Obwohl jedes von der NIC 100 bediente Zielobjekt an mehreren Datenflüssen oder durchgehenden TCP-Verbindungen teilnehmen kann, gibt es zwischen einem bestimmten Quellenobjekt und einem bestimmten Zielobjekt nur einen Fluss auf einmal. Daher sollte jeder Flussschlüssel im assoziativen Abschnitt 502, der einem gültigen Fluss entspricht, gegenüber allen anderen gültigen Flüssen einzigartig sein. In alternativen Ausführungsformen der Erfindung besteht der assoziative Abschnitt 502 aus verschiedenen Feldern, die alternative Flussschlüsselformen widerspiegeln, die durch die vom Anfangsblock-Analysator analysierten Protokolle und die zum Kennzeichnen von Datenflüssen benutzten Informationen bestimmt werden können.
  • Der assoziierte Abschnitt 504 im Ausführungsbeispiel enthält einen Flussgültigkeitsindikator 520, eine Flusssequenznummer 522 und einen Flussaktivitätsindikator 524. Diese Felder liefern Informationen hinsichtlich des Flusses, der durch den im entsprechenden Eintrag im assoziativen Abschnitt 502 gespeicherten Flussschlüssel gekennzeichnet ist. Die Felder des assoziierten Abschnitts 504 können durch den FDBM 108 wiedergewonnen und/oder aktualisiert werden, wie im folgenden Abschnitt beschrieben.
  • Der Flussgültigkeitsindikator 520 in dieser Ausführungsform zeigt an, ob der zugeordnete Fluss gültig oder ungültig ist. Erläuternd wird der Flussgültigkeitsindikator gesetzt, um einen gültigen Fluss anzuzeigen, wenn das erste Paket Daten in einem Fluss empfangen wird, und kann zurückgesetzt werden, um jedes Mal, wenn ein Abschnitt eines Datagramms eines Flusses (z.B. ein Paket) korrekt empfangen wird, erneut eine Gültigkeit des Flusses festzustellen.
  • Der Flussgültigkeitsindikator 520 kann ungültig markiert werden, nachdem das letzte Paket Daten in einem Fluss empfangen worden ist. Der Flussgültigkeitsindikator kann außerdem gesetzt werden, um einen ungültigen Fluss anzuzeigen, immer wenn aus irgendeinem anderen Grund als dem Empfang eines End-Datenpakets ein Fluss abzubrechen (z.B. zu beenden oder vorzeitig zu beenden) ist. Zum Beispiel kann es sein, dass ein Paket nicht der Reihe nach mit anderen Paketen eines Datagramms empfangen wird, dass ein Steuerpaket empfangen wird, das anzeigt, dass eine Datenübertragung oder ein Datenfluss abgebrochen wird, dass ein Versuch gemacht wird, einen Fluss wiedereinzurichten oder neu zu synchronisieren (in welchem Fall der ursprüngliche Fluss beendet wird) usw. In einer Ausführungsform ist der Flussgültigkeitsindikator 520 ein Einzelbit, Anzeiger oder Wert.
  • Die Flusssequenznummer 522 im Ausführungsbeispiel enthält eine Sequenznummer des nächsten Abschnitts Daten, der in dem zugeordneten Fluss erwartet wird. Da das in einem Fluss gesendete Datagramm typischerweise über mehrere Pakete empfangen wird, liefert die Flusssequenznummer einen Mechanismus, um sicherzustellen, dass die Pakete in der richtigen Reihenfolge empfangen werden. In einer Ausführungsform der Erfindung setzt die NIC 100 zum Beispiel Daten aus mehreren Paketen in einem Datagramm wieder zusammen. Um diesen Wiederzusammenbau auf die effizienteste Weise durchzuführen, müssten die Pakete der Reihe nach empfangen werden. Daher speichert die Flusssequenznummer 522 eine Kennung zum Kennzeichnen des nächsten Pakets oder Datenabschnitts, das bzw. der empfangen werden sollte.
  • In einer Ausführungsform der Erfindung entspricht die Flusssequenznummer 522 dem in TCP-Protokoll-Anfangsblöcken gefundenen TCP-Sequenznummer-Feld. Wie der Fachmann erkennt, kennzeichnet die TCP-Sequenznummer eines Pakets die Position der Daten des Pakets relativ zu anderen in einem Datagramm gesendeten Daten. Für Paket und Flüsse in Verbindung mit anderen Protokollen als TCP kann ein alternatives Verfahren verwendet werden, den Empfang von Daten in der richtigen Reihenfolge zu verifizieren oder sicherzustellen.
  • Der Flussaktivitätsindikator 524 im Ausführungsbeispiel spiegelt die Frische der Aktivität eines Flusses oder mit anderen Worten das Alter eines Flusses wider. In dieser Ausführungsform der Erfindung ist der Flussaktivitätsindikator 524 mit einem Zähler wie z.B. einem Flussaktivitätszähler (in 5 nicht gezeigt) verknüpft. Der Flussaktivitätszähler wird jedes Mal aktualisiert (z.B. hochgezählt), wenn ein Paket als Teil eines Flusses empfangen wird, der schon in der Flussdatenbank 110 gespeichert ist. Der aktualisierte Zählerwert wird dann im Flussaktivitätsindikator-Feld des Paketflusses gespeichert. Der Flussaktivitätszähler kann außerdem jedes Mal hochgezählt werden, wenn ein erstes Paket eines neuen Flusses empfangen wird, der der Datenbank hinzugefügt wird. In einer alternativen Ausführungsform wird ein Flussaktivitätszähler nur für Pakete aktualisiert, die Daten enthalten (z.B. wird er für Steuerpakete nicht aktualisiert). In noch einer alternativen Ausführungsform werden mehrere Zähler benutzt, um Flussaktivitätsindikatoren von verschiedenen Flüssen zu aktualisieren.
  • Da nicht immer festgestellt werden kann, wann ein Datenfluss geendet hat (z.B. kann das End-Paket verloren gegangen sein), kann der Flussaktivitätsindikator benutzt werden, um Flüsse zu bestimmen, die obsolet sind oder die aus einem anderen Grund abgebrochen werden sollten. Zum Beispiel, wenn die Flussdatenbank 110 voll besetzt zu sein scheint (z.B. ist der Flussgültigkeitsindikator 520 für jede Flussnummer gesetzt), wenn das erste Paket eines neuen Flusses empfangen wird, kann der Fluss mit dem niedrigsten Flussaktivitätsindikator durch den neuen Fluss ersetzt werden.
  • Im Ausführungsbeispiel der Erfindung kann die Größe der Felder in der FDB 110 von einem Eintrag zum anderen verschieden sein. Zum Beispiel sind IP-Quellen- und Zieladressen in Version vier des Protokolls vier Bytes groß, in Version sechs aber sechzehn Bytes groß. In einer alternativen Ausführungsform der Erfindung können Einträge für ein bestimmtes Feld einheitlich groß sein, wobei kleinere Einträge nötigenfalls aufgefüllt werden.
  • In einer anderen alternativen Ausführungsform der Erfindung können Felder innerhalb der FDB 110 zusammengelegt werden. Insbesondere kann der Flussschlüssel eines Flusses als ein einzelnes Objekt oder Feld gespeichert werden, statt als eine Anzahl von getrennten Feldern gespeichert zu werden, wie in 5 gezeigt. Ähnlich sind der Flussgültigkeitsindikator 520, die Flusssequenznummer 522 und der Flussaktivitätsindikator 524 in 5 als getrennte Einträge gezeigt. In einer alternativen Ausführungsform der Erfindung können jedoch ein oder mehrere dieser Einträge kombiniert werden. Insbesondere weisen in einer alternativen Ausführungsform der Flussgültigkeitsindikator 520 und der Flussaktivitätsindikator 524 einen einzelnen Eintrag mit einem ersten Wert (z.B. null) auf, wenn der dem Fluss zugeordnete Eintrag ungültig ist. Solange der Fluss gültig ist, wird der kombinierte Eintrag jedoch hochgezählt, wenn Pakete empfan gen werden, und bei Beendigung des Flusses auf den ersten Wert zurückgesetzt.
  • In einer Ausführungsform der Erfindung enthält die FDB 110 maximal vierundsechzig, durch die Flussnummer 506 indexierte Einträge, wodurch die Datenbank vierundsechzig gültige Flüsse auf einmal verfolgen kann. In alternativen Ausführungsformen der Erfindung können mehr oder weniger Einträge zugelassen werden, je nach der Größe des der Flussdatenbank 110 zugewiesenen Speichers. Außer durch die Flussnummer 506 kann ein Fluss durch seinen (im assoziativen Abschnitt 502 gespeicherten) Flussschlüssel kennzeichenbar sein.
  • Im Ausführungsbeispiel der Erfindung ist die Flussdatenbank 110 leer (z.B. sind alle Felder mit Nullen gefüllt), wenn die NIC 100 initialisiert wird. Wenn das erste Paket eines Flusses empfangen wird, analysiert der Anfangsblock-Analysator 106 einen Anfangsblock-Abschnitt des Pakets. Wie in einem früheren Abschnitt beschrieben, setzt der Anfangsblock-Analysator einen Flussschlüssel zum Kennzeichnen des Flusses zusammen und extrahiert weitere Informationen hinsichtlich des Pakets und/oder des Flusses. Der Flussschlüssel und weitere Informationen werden an den Flussdatenbankmanager 108 weitergegeben. Der FDBM 108 durchsucht dann die FDB 110 nach einem dem Flussschlüssel zugeordneten aktiven Fluss. Da die Datenbank leer ist, gibt es keine Übereinstimmung.
  • In diesem Beispiel wird der Flussschlüssel daher gespeichert (z.B. als Fluss Nummer null), indem die IP-Quellen-Adresse, die IP-Ziel-Adresse, der TCP-Quellen-Port und der TCP-Ziel-Port in die entsprechenden Felder kopiert werden. Der Flussgültigkeitsindikator 520 wird dann gesetzt, um einen gültigen Fluss anzuzeigen, die Flusssequenznummer 522 wird aus der TCP-Sequenznummer (erläuternd vom Anfangsblock-Analysator geliefert) gewonnen und der Flussaktivitätsindikator 524 wird auf einen Anfangswert (z.B. eins) gesetzt, der aus einem Zähler gewonnen werden kann. Ein Verfahren zum Erzeugen einer geeigneten Flusssequenznummer, das benutzt werden kann, um zu verifizieren, dass der nächste Abschnitt der für den Fluss empfangenen Daten der Reihe nach empfangen wird, ist, die TCP-Sequenznummer und die Größe der Paketdaten zu addieren. Je nach der Konfiguration des Pakets (z.B. ob das Bit SYN in einem Feld Anzeiger des TCP-Anfangsblocks des Pakets gesetzt ist) muss die Summe jedoch möglicherweise angepasst werden (z.B. durch Addieren von eins), um den nächsten erwarteten Abschnitt von Daten korrekt zu kennzeichnen.
  • Wie oben beschrieben, ist ein Verfahren zum Erzeugen eines geeigneten Anfangswertes für einen Flussaktivitätsindikator, einen Zählerwert zu kopieren, der für jedes als Teil eines Flusses empfangene Paket hochgezählt wird. Zum Beispiel für das erste Paket, das nach Initialisierung der VIC 100 empfangen wird, kann ein Flussaktivitätszähler auf den Wert eins hochgezählt werden. Dieser Wert kann dann im Flussaktivitätsindikator 542 für den zugeordneten Fluss gespeichert werden. Das nächste als Teil desselben (oder eines neuen) Flusses empfangene Paket bewirkt, dass der Zähler auf zwei hochgezählt wird, welcher Wert im Flussaktivitätsindikator für den zugeordneten Fluss gespeichert wird. In diesem Beispiel sollten keine zwei Flüsse denselben Flussaktivitätsindikator aufweisen, außer bei Initialisierung, wenn sie alle null oder ein anderer vorbestimmter Wert sein können.
  • Nach Empfang und Analyse eines späteren an der NIC 100 empfangenen Pakets wird die Flussdatenbank nach einem gültigen Fluss durchsucht, der zu dem Flussschlüssel des Pakets passt. Erläuternd wird nur nach den Flussschlüsseln von aktiven Flüssen gesucht (z.B. denjenigen Flüssen, für die der Flussgültigkeitsindikator 520 gesetzt ist). Alternativ kann nach allen Flussschlüsseln gesucht werden (z.B. allen Einträgen im assoziativen Abschnitt 502), jedoch wird eine Übereinstimmung nur berichtet, wenn ihr Flussgültigkeitsindikator einen gültigen Fluss anzeigt. Mit einer CAM wie der in 5 gezeigten FDB 110 kann parallel nach Flussschlüsseln und Flussgültigkeitsindikatoren gesucht werden.
  • Wenn ein späteres Paket den nächsten Abschnitt Daten für einen früheren Fluss (z.B. Fluss Nummer null) enthält, wird dieser Fluss geeignet aktualisiert. In einer Ausführungsform der Erfindung bringt dies mit sich, die Flusssequenznummer 522 zu aktualisieren und den Flussaktivitätsindikator 524 hochzuzählen, um ihre neueste Aktivität widerzuspiegeln. Der Flussgültigkeitsindikator 520 kann ebenfalls gesetzt werden, um die Gültigkeit des Flusses anzuzeigen, obwohl er bereits anzeigen sollte, dass der Fluss gültig ist.
  • Werden neue Flüsse bestimmt, werden sie der FDB 110 auf ähnliche Weise wie der erste Fluss hinzugefügt. Wird ein Fluss beendet oder abgebrochen, wird der zugeordnete Eintrag in der FDB 110 ungültig gemacht. In einer Ausführungsform der Erfindung wird der Flussgültigkeitsindikator 520 nur für den beendeten Fluss gelöscht (z.B. auf null gesetzt). In einer anderen Ausführungsform werden ein oder mehrere Felder eines beendeten Flusses gelöscht oder auf einen beliebigen oder vorbestimmten Wert gesetzt. Wegen der stoßweisen Natur von Netzpaketverkehr werden alle oder die meisten Daten aus einem Datagramm im Allgemeinen in einer kurzen Zeitspanne empfangen. Daher muss jeder gültige Fluss in der FDB 100 normalerweise nur eine kurze Zeit lang aufrechterhalten werden, und sein Eintrag kann dann benutzt werden, um einen anderen Fluss zu speichern.
  • Aufgrund der begrenzten Menge Speicher, die in einer Ausführungsform der Erfindung für die Flussdatenbank 110 zur Verfügung steht, kann die Größe jedes Feldes begrenzt sein. In dieser Ausführungsform werden der IP-Quellen-Adresse 510 sechzehn Bytes zugewiesen und werden der IP-Ziel-Adresse 512 sechzehn Bytes zugewiesen. Für weniger als sechzehn Bytes lange IP-Adressen kann der zusätzliche Platz mit Nullen aufgefüllt werden. Weiterhin werden dem TCP-Quellen-Port 514 und dem TCP-Ziel-Port 516 jeweils zwei Bytes zugewiesen. Außerdem weist in dieser Ausführungsform der Flussgültigkeitsindikator 520 ein Bit auf, der Flusssequenznummer 522 sind vier Bytes zugewiesen und dem Flussaktivitätsindikator 524 sind ebenfalls vier Bytes zugewiesen.
  • Wie der Fachmann aus den oben beschriebenen Ausführungsformen erkennt, ist ein Fluss einer durchgehenden TCP-Verbindung ähnlich, aber nicht damit identisch. Eine TCP-Verbindung kann für eine relativ lange Zeitspanne bestehen, die ausreicht, um mehrere Datagramme von einem Quellenobjekt an ein Zielobjekt zu übertragen. Einen Fluss kann es jedoch nur für ein Datagramm geben. Daher können während einer durchgehenden TCP-Verbindung mehrere Flüsse eingerichtet und abgebrochen werden (z.B. einmal für jedes Datagramm). Wie oben beschrieben, kann ein Fluss eingerichtet (z.B. der FDB 110 hinzugefügt und gültig markiert) werden, wenn die NIC 100 den ersten Abschnitt Daten in einem Datagramm nachweist, und kann abgebrochen (z.B. in der FDB 110 ungültig markiert) werden, wenn der letzte Abschnitt Daten empfangen wird. Erläuternd bekommt jeder während einer einzelnen durchgehenden TCP-Verbindung eingerichtete Fluss denselben Flussschlüssel, da die Adressen- und Port-Kennungen der Schicht drei und Schicht vier, die benutzt werden, um den Flussschlüssel zu bilden, dieselben bleiben.
  • Im Ausführungsbeispiel bestimmt die Größe der Flussdatenbank 110 (z.B. die Zahl der Flusseinträge) die maximale Zahl von Flüssen, die auf einmal verschachtelt (z.B. gleichzeitig aktiv sein) sein können, während die Funktionen Datenwiederzusammenbau und Schubverarbeitung von Protokoll-Anfangsblöcken ermöglicht werden. Mit anderen Worten, in der in 5 gezeigten Ausführungsform kann die NIC 100 vierundsechzig Flüsse einrichten und Pakete aus bis zu vierundsechzig verschiedenen Datagrammen empfangen (d.h. vierundsechzig Flüsse können aktiv sein), ohne einen Fluss abzubrechen. Wäre eine maximale Zahl von Flüssen durch die NIC 100 bekannt, könnte die Flussdatenbank 110 auf die entsprechende Zahl von Einträgen begrenzt werden.
  • Die Flussdatenbank kann klein gehalten werden, da in der vorliegend beschriebenen Ausführungsform ein Fluss nur ein Datagramm lang dauert, und wegen der stoßweisen Natur von Netzpaketverkehr werden die Pakete eines Datagramm im Allgemeinen in einer kurzen Zeitspanne empfangen. Die kurze Dauer eines Flusses wiegt eine begrenzte Zahl von Einträgen in der Flussdatenbank auf. In einer Ausführungsform der Erfindung wird, wenn die FDB 110 mit aktiven Flüssen gefüllt ist und ein neuer Fluss (d.h. ein erster Abschnitt Daten in einem neuen Datagramm) gestartet wird, der älteste (z.B. der am wenigsten aktive) Fluss durch den neuen Fluss ersetzt.
  • In einer alternativen Ausführungsform der Erfindung können Flüsse für eine beliebige Zahl von Datagrammen (oder ein anderes Maß von Netzverkehr) oder für eine spezifizierte Länge oder einen spezifizierten Zeitraum aktiv gehalten werden. Zum Beispiel, wenn ein Datagramm endet, kann sein Fluss in der FDB 110 "offen" gehalten werden (d.h. nicht abgebrochen werden), wenn die Datenbank nicht voll ist (z.B. der Eintrag des Flusses nicht für einen anderen Fluss benötigt wird). Dieses Schema kann den effizienten Betrieb der NIC 100 noch mehr verbessern, wenn ein anderes Datagramm mit demselben Flussschlüssel empfangen wird. Insbesondere wird der mit dem Einrichten eines anderen Flusses verbundene Aufwand vermieden, und es kann mehr Datenwiederzusammenbau und Schubverarbeitung (wie weiter unten beschrieben) durchgeführt werden. Vorteilhaft kann ein Fluss in der Flussdatenbank 110 offen gehalten werden, bis die durchgehende TCP-Verbindung endet, die den Fluss einschließt.
  • Eine Ausführungsform eines Flussdatenbankmanagers
  • 6A bis 6E zeigen ein Verfahren zum Betrieb eines Flussdatenbankmanagers (FDBM) wie z.B. des Flussdatenbankmanagers 108 von 1A zum Verwalten der Flussdatenbank (FDB) 110. Erläuternd speichert und aktualisiert der FDBM 108 in der Flussdatenbank 110 gespeicherte Flussinformationen und erzeugt einen Operationscode für ein von der NIC 100 empfangenes Paket. Der FDBM 108 bricht außerdem einen Fluss ab (z.B. ersetzt, entfernt oder macht einen Eintrag in der FDB 110 auf andere Weise ungültig), wenn der Fluss beendet oder abgebrochen wird.
  • In einer Ausführungsform der Erfindung spiegelt der Operationscode eines Pakets die Kompatibilität des Pakets mit vorbestimmten Kriterien zur Durchführung einer oder mehrerer Funktionen der NIC 100 wider (z.B. Datenwiederzusammenbau, Schubverarbeitung von Paket-Anfangsblöcken, Lastverteilung). Mit anderen Worten, je nach dem Operationscode eines Pakets können andere Module der NIC 100 eine dieser Funktionen durchführen oder nicht.
  • In einer anderen Ausführungsform der Erfindung zeigt ein Operationscode einen Paketstatus an. Zum Beispiel kann ein Operationscode anzeigen, dass ein Paket: keine Daten enthält, ein Steuerpaket ist, mehr als eine spezifizierte Datenmenge enthält, das erste Paket eines neuen Flusses ist, das letzte Paket eines vorhandenen Flusses ist, nicht der Reihe nach ist, einen bestimmten Anzeiger enthält (zum Beispiel in einem Protokoll-Anfangsblock), der nicht einen erwarteten Wert hat (somit möglicherweise einen außergewöhnlichen Umstand anzeigt), usw.
  • Der Betrieb des Flussdatenbankmanagers 108 hängt von den vom Anfangsblock-Analysator 106 gelieferten Paketinformationen und den aus der Flussdatenbank 110 herausgeholten Informationen ab. Nachdem der FDBM 108 die Paketinformationen und/oder -daten verarbeitet hat, werden Steuerinformationen (z.B. der Operationscode des Pakets) in der Steuerwarteschlange 118 gespeichert, und die FDB 110 kann geändert werden (z.B. kann ein neuer Fluss eingegeben oder ein vorhandener Fluss aktualisiert oder abgebrochen werden).
  • Unter Bezugnahme auf 6A bis 6E ist der Zustand 600 ein Startzustand, in dem der FDBM 108 auf Informationen wartet, die aus einem Paket herausgeholt werden, das von der NIC 100 aus dem Netz 102 empfangen wird. Im Zustand 602 meldet der Anfangsblock-Analysator 106 oder ein anderes Modul der NIC 100 dem FDBM 108 ein neues Paket, indem er den Flussschlüssel des Pakets und einige Steuerinformationen liefert. Empfang dieser Daten kann als Anforderung interpretiert werden, die FDB 110 zu durchsuchen, um zu bestimmen, ob es schon einen Fluss mit diesem Flussschlüssel gibt.
  • In einer Ausführungsform der Erfindung enthalten die an den FDBM 108 weitergeleiteten Steuerinformationen eine aus einem Paket-Anfangsblock herausgeholte Sequenznummer (z. B. eine TCP-Sequenznummer). Die Steuerinformationen können außerdem den Status von bestimmten Anzeigern in den Anfangsblöcken des Pakets anzeigen, ob das Paket Daten enthält, und wenn ja, ob die Datenmenge eine bestimmte Größe übersteigt. In dieser Ausführungsform empfängt der FDBM 108 außerdem ein Signal No_Assist für ein Paket, wenn der Anfangsblock-Analysator ermittelt, dass das Paket nicht in Übereinstimmung mit einem der vorgewählten Protokollstapel formatiert ist (d.h. das Paket ist nicht "kompatibel"), wie in einem früheren Abschnitt erörtert. Erläuternd zeigt das Signal No_Assist an, das eine oder mehrere Funktionen der NIC 100 (z.B. Datenwiederzusammenbau, Schubverarbeitung, Lastausgleich) möglicherweise nicht für das Paket zur Verfügung gestellt werden können.
  • Im Zustand 604 stellt der FDBM 108 fest, ob ein Signal No Assist für das Paket geltend gemacht wurde. Wenn ja, geht die Prozedur zum Zustand 668 weiter (6E). Andernfalls durchsucht der FDBM 108 im Zustand 606 die FDB 110 nach dem Flussschlüssel des Pakets. In einer Ausführungsform der Erfindung wird nur nach gültigen Flusseinträgen in der Flussdatenbank gesucht. Wie oben erörtert, kann die Gültigkeit eines Flusses durch einen Gültigkeitsindikator wie z.B. den Flussgültigkeitsindikator 520 (in 5 gezeigt) widergespiegelt werden. Wird im Zustand 608 festgestellt, dass der Flussschlüssel des Pakets nicht in der Datenbank gefunden worden ist oder dass eine Übereinstimmung gefunden wurde, aber der zugehörige Fluss nicht gültig ist, rückt die Prozedur zum Zustand 646 vor (6D).
  • Wird eine gültige Übereinstimmung in der Flussdatenbank gefunden, wird im Zustand 610 die Flussnummer (zum Beispiel der Flussdatenbank-Index für den übereinstimnienden Eintrag) des übereinstimmenden Eintrags gemeldet und werden die in der FDB 110 gespeicherten Flussinformationen gelesen. Erläuternd umfassen diese Informationen den Flussgültigkeitsindikator 520, die Flusssequenznummer 522 und den Ffussaktivitätsindikator 524 (in 5 gezeigt).
  • In Zustand 612 ermittelt der FDBM 108 aus den vom Anfangsblock-Analysator 106 empfangenen Informationen, ob das Paket TCP-Nutzlastdaten enthält. Wenn nicht, geht die gezeigte Prozedur zum Zustand 638 weiter (6C); andernfalls geht die Prozedur mit dem Zustand 614 weiter.
  • Im Zustand 614 ermittelt der Flussdatenbankmanager, ob das Paket einen Versuch darstellt, eine Datenverbindung oder einen Datenfluss zurückzusetzen. Erläuternd kann dies ermittelt werden, indem der Status eines Bits SYN in einem der Protokoll-Anfangsblöcke des Pakets (z.B. einem TCP-Anfangsblock) geprüft wird. In einer Ausführungsform der Erfindung werden der Wert eines oder mehrerer Steuer- oder Anzeigerbits (wie z.B. des Bits SYN) dem FDBM durch den Anfangsblock-Analysator geliefert. Wie der Fachmann erkennt, kann es sein, dass ein TCP-Objekt versucht, einen Datenfluss oder eine Verbindung mit einem anderen Objekt zurückzusetzen (zum Beispiel wegen eines Problems in einem der Hauptrechner des Objekts) und einen ersten Datenabschnitt zusammen mit der Wiederverbindungsanforderung zu senden. Dies ist die Situation, die der Flussdatenbankmanager im Zustand 614 wahrzunehmen versucht. Wenn das Paket Teil eines Versuchs ist, einen Fluss oder eine Verbindung wiederzuverbinden oder zurückzusetzen, geht die Prozedur im Zustand 630 weiter (6C).
  • Im Zustand 616 vergleicht der Flussdatenbankmanager 108 eine aus einem Paket-Anfangsblock extrahierte Sequenznummer (z.B. eine TCP-Sequenznummer) mit einer Sequenznummer (z.B. Flusssequenznummer 522 von 5) des nächsten erwarteten Abschnitts Daten für diesen Fluss. Erläuternd sollten diese Sequenznummern korrelieren, wenn das Paket den nächsten Abschnitt Daten des Flusses enthält. Wenn die Sequenznummern nicht übereinstimmen, geht die Prozedur im Zustand 628 weiter.
  • Im Zustand 618 ermittelt der FDBM 108, ob bestimmte aus einem oder mehreren der Protokoll-Anfangsblöcke des Pakets extrahierte Anzeiger mit erwarteten Werten übereinstimmen. Zum Beispiel sind in einer Ausführungsform der Erfindung die Anzeiger URG, PSH, RST und FIN aus den TCP-Anfangsblöcken des Pakets erwartungsgemäß frei (d.h. gleich null). Wenn irgendwelche dieser Anzeiger gesetzt sind (z.B. gleich eins), herrscht möglicherweise eine außergewöhnliche Bedingung, was es möglich macht, dass eine oder mehrere der von der NIC 100 gebotenen Funktionen (z.B. Datenwiederzusammenbau, Schubverarbeitung, Lastausgleich) für dieses Paket nicht durchgeführt werden sollten. Solange die Anzeiger frei sind, geht die Prozedur im Zustand 620 weiter; andernfalls geht die Prozedur im Zustand 626 weiter.
  • Im Zustand 620 ermittelt der Flussdatenbankmanager, ob mehr Daten während dieses Flusses erwartet werden. Wie oben erörtert, kann ein Fluss in der Dauer auf ein einzelnes Datagramm begrenzt sein. Daher ermittelt im Zustand 620 der FDBM, ob dieses Paket ein End-Abschnitt von Daten für dieses Datagramm des Flusses zu sein scheint. Erläuternd erfolgt diese Ermittlung auf Basis der in dem gegenwärtigen Paket enthaltenen Datenmenge. Wie der Fachmann erkennt, wird ein Datagramm, das mehr Daten enthält als in einem Paket befördert werden können, über mehrere Pakete gesendet. Die typische Art und Weise, ein Datagramm auf mehrere Pakete zu verbreiten, ist, so viele Daten wie möglich in jedes Paket zu setzen. Daher ist jedes Paket außer dem letzten gewöhnlich gleich oder nahezu gleich groß wie die maximale Übertragungseinheit (MTU), die für das Netz erlaubt ist, über das die Pakete gesendet werden. Das letzte Paket enthält den Rest, wodurch es gewöhnlich kleiner ist als die MTU.
  • Daher ist eine Art und Weise, den End-Abschnitt von Daten im Datagramm eines Flusses zu bestimmen, die Größe jedes Pakets zu prüfen und sie mit einer Zahl (z.B. MTU) zu vergleichen, die ein Paket erwartungsgemäß übersteigt, außer wenn es den letzten Datenabschnitt befördert. Es wurde oben beschrieben, dass die Steuerinformationen durch die FDBM 108 vom Anfangsblock-Analysator 106 empfangen werden. In diesen Informationen kann eine Anzeige der Größe der von einem Paket beförderten Daten enthalten sein. Insbesondere ist der Anfangsblock-Analysator 106 in einer Ausführungsform der Erfindung konfiguriert, die Größe jedes Datenabschnitts eines Pakets mit einem vorgewählten Wert zu vergleichen. In einer Ausführungsform der Erfindung ist dieser Wert programmierbar. Dieser Wert wird im Ausführungsbeispiel der Erfindung auf die maximale Datenmenge gesetzt, die ein Paket befördern kann, ohne die MTU zu übersteigen. In einer alternativen Ausführungsform wird der Wert auf einen Betrag etwas kleiner als die maximale Datenmenge gesetzt, die befördert werden kann.
  • Somit ermittelt im Zustand 620 der Flussdatenbankmanager 108, ob das empfangene Paket den End-Abschnitt der Daten für das Datagramm des Flusses zu befördern scheint. Wenn nicht, geht die Prozedur im Zustand 626 weiter.
  • Im Zustand 622 ist herausgefunden worden, dass das Paket mit vorgewählten Protokollen kompatibel ist und für eine oder mehrere von der NIC 100 gebotene Funktionen geeignet ist. Insbesondere ist das Paket passend für eine oder mehrere der oben erör terten Funktionen formatiert worden. Der FDBM 108 hat ermittelt, dass das empfangene Paket Teil eines vorhandenen Flusses ist, mit den vorgewählten Protokollen kompatibel ist und den nächsten Abschnitt Daten für den Fluss enthält (aber nicht den End-Abschnitt). Weiterhin ist das Paket nicht Teil eines Versuchs, einen Fluss bzw. eine Verbindung zurückzusetzen, und wichtige Anzeiger haben ihre erwarteten Werte. Daher kann die Flussdatenbank 110 wie folgt aktualisiert werden.
  • Der Aktivitätsindikator (z.B. Flussaktivitätsindikator 524 von 5) für diesen Fluss wird modifiziert, um die neueste Flussaktivität widerzuspiegeln. In einer Ausführungsform der Erfindung ist der Flussaktivitätsindikator 524 als ein Zähler ausgeführt oder ist mit einem Zähler verknüpft, der jedes Mal hochgezählt wird, wenn für einen Fluss Daten empfangen werden. In einer anderen Ausführungsform der Erfindung wird ein Aktivitätsindikator oder Zähler jedes Mal aktualisiert, wenn ein Paket mit einem Flussschlüsselempfangen wird, der mit einem gültigen Fluss übereinstimmt (z.B. ob das Paket Daten enthält oder nicht).
  • Im Ausführungsbeispiel wird, nachdem ein Flussaktivitätsindikator oder Zähler hochgezählt worden ist, geprüft, ob er null "überrollt" hat (d.h., ob er über seinen Maximalwert hinaus hochgezählt worden ist). Wenn ja, werden der Zähler und/oder die Flussaktivitätsindikatoren für jeden Eintrag in der Flussdatenbank 110 auf null gesetzt und wird der aktuelle Flussaktivitätsindikator noch einmal hochgezählt. Daher bewirkt in einer Ausführungsform der Erfindung das Überrollen eines Flussaktivitätszählers oder -indikators die Neuinitialisierung des Flussaktivitätsmechanismus für die Flussdatenbank 110. Daher wird der Zähler hochgezählt, und die Flussaktivitätsindikatoren werden wieder aktualisiert, wie vorher beschrieben. Der Fachmann erkennt, dass es viele andere geeignete Verfahren geben kann, die in einer Ausführungsform der vorliegenden Erfindung angewandt werden können, um anzuzeigen, dass ein Fluss kürzlicher aktiv war als es ein anderer war.
  • Außerdem wird im Zustand 622 die Flusssequenznummer 522 aktualisiert. Erläuternd wird die neue Flusssequenznummer bestimmt, indem die Größe der neu empfangenen Daten zu der vorhandenen Flusssequenznummer addiert wird. Je nach der Konfiguration des Pakets (z.B. den Werten in seinen Anfangsblöcken) muss diese Summe möglicherweise angepasst werden. Zum Beispiel kann es sein, dass diese Summe einfach die Gesamtmenge der so weit für das Datagramm des Flusses empfangenen Daten anzeigt. Daher muss möglicherweise ein Wert (z.B. ein Byte) addiert werden, um eine Sequenznummer des nächstens Bytes Daten für das Datagramm anzuzeigen. Wie der Fachmann erkennt, können an Stelle des hier beschriebenen Schemas andere geeignete Verfahren benutzt werden, um sicherzustellen, dass Daten der Reihe nach empfangen werden.
  • Schließlich wird im Zustand 622 in einer Ausführungsform der Erfindung der Flussgültigkeitsindikator 520 gesetzt oder zurückgesetzt, um die Gültigkeit des Flusses anzuzeigen.
  • Danach, im Zustand 624, wird dem Paket ein Operationscode zugeordnet. Im Ausführungsbeispiel der Erfindung enthält der Operationscode Codes, die vom Flussdatenbankmanager 108 erzeugt und in der Steuerwarteschlange 118 gespeichert werden. In dieser Ausführungsform ist ein Operationscode drei Bits groß, was acht Operationscodes berücksichtigt. In alternativen Ausführungsformen können Operationscodes mannigfache andere Formen und Bereiche haben. Für das Ausführungsbeispiel der Erfindung beschreibt Tabelle 1 jeden Operationscode in Form der Kriterien, die zur Auswahl jedes Codes und den Verzweigungen dieser Auswahl führen. Zu Zwecken von Tabelle 1 umfasst das Einrichten eines Flusses, einen Fluss in die Flussdatenbank 110 einzufügen. Das Abbrechen eines Flusses umfasst, einen Fluss in der Flussdatenbank 110 zu entfernen oder ungültig zu machen. Wiederzusammenbau von Daten kann von der DMA-Maschine 120 durchgeführt werden.
  • Im Ausführungsbeispiel der Erfindung wird der Operationscode 4 im Zustand 624 für Pakete im gegenwärtigen Kontext der Prozedur ausgewählt (z.B. kompatible Pakete, die den nächsten, aber nicht letzten Datenabschnitt eines Flusses befördern). Daher wird der vorhandene Fluss nicht abgebrochen, und es besteht keine Notwendigkeit, einen neuen Fluss einzurichten. Wie oben beschrieben, ist ein kompatibles Paket in dieser Ausführungsform ein Paket, das einem oder mehreren der vorgewählten Protokolle entspricht. Durch Ändern oder Vergrößern der vorgewählten Protokolle kann in einer alternativen Ausführungsform der Erfindung praktisch jedes Paket kompatibel sein.
  • Zurück zu 6A bis 6E, endet die gezeigte Prozedur nach dem Zustand 624 im Zustand 670.
  • Im Zustand 626 (vom Zustand 618 oder Zustand 620 her erreicht) wird der Operationscode 3 für das Paket ausgewählt. Erläuternd zeigt der Operationscode 3 an, dass das Paket kompatibel ist und mit einem gültigen Fluss übereinstimmt (z.B. stimmt der Flussschlüssel des Pakets mit dem Flussschlüssel eines gültigen Flusses in der FDB 110 überein). Der Operationscode 3 kann außerdem bedeuten, dass das Paket Daten enthält, keinen Versuch bildet, einen Datenfluss bzw. eine Datenverbindung neu zu synchronisieren oder zurückzusetzen, und die Sequenznummer des Pakets mit der erwarteten Sequenznummer (aus der Flussdatenbank 110) übereinstimmt. Jedoch ist entweder ein wichtiger Anzeiger (z.B. einer der TCP-Anzeiger URG, PSH, RST oder FIN) gesetzt (im Zustand 618 bestimmt), oder die Daten des Pakets sind weniger als der oben (im Zustand 620) beschriebene Schwellenwert, was anzeigt, dass diesem Paket in diesem Fluss wahrscheinlich nicht mehr Daten folgen. Daher wird der vorhandene Fluss abgebrochen, aber es wird kein neuer Fluss angelegt. Erläuternd kann der Fluss abgebrochen werden, indem der Flussgültigkeitsindikator gelöscht wird (z.B. er auf null gesetzt wird). Nach dem Zustand 626 endet die gezeigte Prozedur im Zustand 670.
  • Im Zustand 628 (vom Zustand 616 her erreicht) wird der Operationscode 2 für das Paket ausgewählt. Im vorliegenden Kontext kann der Operationscode 2 anzeigen, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt (z.B. stimmt der Flussschlüssel des Pakets mit dem Flussschlüssel eines gültigen Flusses in der FDB 110 überein), Daten enthält und keinen Versuch bildet, einen Datenfluss bzw. eine Datenverbindung neu zu synchronisieren oder zurückzusetzen. Jedoch stimmt die (im Zustand 616) aus dem Paket extrahierte Sequenznummer nicht mit der erwarteten Sequenznummer aus der Flussdatenbank 110 überein. Dies kann zum Beispiel geschehen, wenn ein Paket nicht der Reihe nach empfangen wird. Daher wird der vorhandene Fluss abgebrochen, aber es wird kein neuer Fluss eingerichtet. Erläuternd kann der Fluss abgebrochen werden, indem der Flussgültigkeitsindikator gelöscht wird (z.B. er auf null gesetzt wird). Nach dem Zustand 628 endet die gezeigte Prozedur im Zustand 670.
  • Der Zustand 630 wird vom Zustand 614 her betreten, wenn festgestellt wird, dass es empfangene Paket einen Versuch bildet, einen Datenfluss oder eine Datenverbindung zurückzusetzen (z.B. ist das TCP-Bit SYN gesetzt). Im Zustand 630 bestimmt der Flussdatenbankmanager 108, ob erwartet wird, dass mehr Daten folgen. Wie in Verbindung mit dem Zustand 620 erläutert, kann diese Bestimmung auf der Basis von Steuerinformationen getroffen werden, die durch den Flussdatenbankmanager vom Anfangsblock-Analysator empfangen werden. Werden mehr Daten erwartet (z.B. die Datenmenge im Paket gleicht einem oder übersteigt einen Schwellenwert), geht die Prozedur im Zustand 634 weiter.
  • Im Zustand 632 wird der Operationscode 2 für das Paket ausgewählt. Der Operationscode 2 wurde in anderem Kontext auch im Zustand 628 ausgewählt. Im vorliegenden Kontext kann der Operationscode 2 anzeigen, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt und Daten enthält. Der Operationscode 2 kann in diesem Kontext auch bedeuten, dass das Paket einen Versuch bildet, einen Datenfluss bzw. eine Datenverbindung neu zu synchronisieren oder zurückzusetzen, dass aber nicht mehr Daten erwartet werden, sobald der Fluss bzw. die Verbindung zurückgesetzt ist. Daher wird der vorhandene Fluss abgebrochen, und es wird ein neuer Fluss eingerichtet. Erläuternd kann der Fluss abgebrochen werden, indem der Flussgültigkeitsindikator gelöscht wird (z.B. er auf null gesetzt wird). Nach dem Zustand 632 endet die gezeigte Prozedur im Zustand 670.
  • Im Zustand 634 antwortet der Flussdatenbankmanager 108 auf einen Versuch, einen Datenfluss bzw. eine Datenverbindung zurückzusetzen oder neu zu synchronisieren, womit zusätzliche Daten erwartet werden. Daher wird der vorhandene Fluss abgebrochen und wie folgt ersetzt. Der vorhandene Fluss kann durch die im Zustand 610 wiedergewonnene Flussnummer oder durch den Flussschlüssel des Pakets gekennzeichnet werden. Die Flusssequenznummer (z.B. Flusssequenznummer 522 in 5) wird auf den nächsten erwarteten Wert gesetzt. Erläuternd hängt dieser Wert von der aus dem Paket (z.B. durch den Anfangsblock-Analysator 106) wiedergewonnenen Sequenznummer (z.B. TCP-Sequenznummer) und der im Paket enthaltenen Datenmenge ab. In einer Ausführungsform der Erfindung werden diese zwei Werte addiert, um eine neue Flusssequenznummer zu bestimmen. Wie vorher erörtert, muss diese Summe möglicherweise angepasst werden (z.B. durch Addieren von eins). Außerdem wird im Zustand 634 der Flussgültigkeitsindikator aktualisiert (z.B. hochgezählt). Wie in Verbindung mit Zustand 622 erläutert, wenn der Flussgültigkeitsindikator überrollt, werden die Aktivitätsindikatoren für alle Flüsse in der Datenbank auf null gesetzt und wird der gegenwärtige Fluss wieder hochgezählt. Schließlich wird der Flussgültigkeitsindikator gesetzt, um anzuzeigen, dass der Fluss gültig ist.
  • Im Zustand 636 wird der Operationscode 7 für das Paket ausgewählt. Im vorliegenden Kontext zeigt der Operationscode 7 an, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt und Daten enthält. Der Operationscode 7 kann in diesem Kontext weiterhin bedeuten, dass das Paket einen Versuch bildet, einen Datenfluss bzw. eine Datenverbindung neu zu synchronisieren oder zurückzusetzen, und dass zusätzliche Daten erwartet werden, sobald der Fluss bzw. die Verbindung zurückgesetzt ist. Tatsächlich wird daher der vorhandene Fluss abgebrochen, und es wird ein neuer Fluss (mit demselben Flussschlüssel) an dessen Stelle gespeichert. Nach dem Zustand 636 endet die gezeigte Prozedur im Zustand 670.
  • Der Zustand 638 wird nach dem Zustand 612 betreten, wenn bestimmt wird, dass das Paket keine Daten enthält. Dies zeigt häufig an, dass das Paket ein Steuerpaket ist. Im Zustand 638 bestimmt der Flussdatenbankmanager 108, ob ein oder mehrere durch den Anfangsblock-Analysator aus dem Paket extrahierte Anzeiger mit erwarteten oder gewünschten Werten übereinstimmen. Zum Beispiel müssen in einer Ausführungsform der Erfindung die TCP-Anzeiger URG, PSH, RST und FIN frei sein, damit die DMA-Maschine 120 Daten aus mehreren verknüpften Paketen (z.B. Paketen mit identischem Flussschlüssel) wiederzusammensetzen kann. Wie oben erörtert, kann das TCP-Bit SYN ebenfalls geprüft werden. Im vorliegenden Kontext (z.B. ein Paket ohne Daten) ist auch das Bit SYN erwartungsgemäß frei (z.B. um einen Wert null zu speichern). Wenn die Anzeiger (und das Bit SYN) ihre erwarteten Werte haben, geht die Prozedur im Zustand 624 weiter. Wenn aber irgendwelche dieser Anzeiger gesetzt sind, herrscht möglicherweise eine außergewöhnliche Bedingung, was es möglich macht, dass eine oder mehrere von der NIC 100 gebotene Funktionen (z.B. Datenwiederzusammenbau, Schubverarbeitung, Lastverteilung) für dieses Paket ungeeignet sind, in welchem Fall die Prozedur zum Zustand 640 weitergeht.
  • Im Zustand 640 wird der Operationscode 1 für das Paket ausgewählt. Erläuternd zeigt der Operationscode 1 an, dass das Paket kompatibel ist und mit einem gültigen Fluss übereinstimmt, aber keinerlei Daten enthält und ein oder mehrere wichtige Anzeiger oder Bits im Anfangsblock oder in den Anfangsblöcken des Pakets gesetzt sind. Daher wird der vorhandene Fluss abgebrochen, und es wird kein neuer Fluss eingerichtet. Erläuternd kann der Fluss abgebrochen werden, indem der Flussgültigkeitsindikator gelöscht wird (z.B. er auf null gesetzt wird). Nach dem Zustand 640 endet die gezeigte Prozedur im Zustand 670.
  • Im Zustand 642 wird der Flussaktivitätsindikator aktualisiert (z.B. hochgezählt), obwohl das Paket keine Daten enthält. Wie oben in Verbindung mit Zustand 622 beschrieben, wenn der Flussgültigkeitsindikator überrollt, werden in einer vorliegenden Ausführungsform der Erfindung alle Flussaktivitätsindikatoren in der Datenbank auf null gesetzt und wird der aktuelle Fluss wieder hochgezählt. Der Gültigkeitsindikator des Flusses kann ebenfalls zurückgesetzt werden, wie auch die Sequenznummer des Flusses.
  • Im Zustand 644 wird der Operationscode 0 für das Paket ausgewählt. Erläuternd zeigt der Operationscode 0 an, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt und dass das Paket keinerlei Daten enthält. Das Paket kann zum Beispiel ein Steuerpaket sein. Der Operationscode 0 zeigt weiterhin an, dass keiner der vom Anfangsblock-Analysator 106 geprüften und oben beschriebenen Anzeiger (z.B. URG, PSH, RST und FIN) gesetzt ist. Daher wird der vorhandene Fluss nicht abgebrochen, und es wird kein neuer Fluss eingerichtet. Nach dem Zustand 644 endet die gezeigte Prozedur im Zustand 670.
  • Der Zustand 646 wird vom Zustand 608 her betreten, wenn der Flussschlüssel des Pakets mit keinem der Flussschlüssel von gültigen Flüssen in der Flussdatenbank übereinstimmt. Im Zustand 646 bestimmt der FDBM 108, ob die Flussdatenbank 110 voll ist, und kann eine Anzeige speichern, ob die Datenbank voll ist. In einer Ausführungsform der Erfindung wird die Flussdatenbank als voll angesehen, wenn der Gültigkeitsindikator (z.B. der Flussgültigkeitsindikator 520 von 5) für jede Flussnummer (z.B. für jeden Fluss in der Datenbank) gesetzt ist. Wenn die Datenbank voll ist, geht die Prozedur im Zustand 650 weiter, anderenfalls geht sie im Zustand 648 weiter.
  • Im Zustand 648 wird die niedrigste Flussnummer eines ungültigen Flusses (z.B. eines Flusses, für den der zugeordnete Flussgültigkeitsindikator gleich null ist) bestimmt. Erläuternd ist diese Flussnummer, wo ein neuer Fluss gespeichert wird, wenn das empfangene Paket zur Erzeugung eines neuen Flusses ermächtigt. Nach dem Zustand 648 geht die Prozedur im Zustand 652 weiter.
  • Im Zustand 650 wird die Flussnummer des am wenigsten aktiven Flusses bestimmt.
  • Wie oben erörtert, wird im Ausführungsbeispiel der Erfindung ein Flussaktivitätsindikator (z.B. der Flussaktivitätsindikator 524 von 5) jedes Mal aktualisiert (z.B. hochgezählt), wenn für einen Fluss Daten empfangen werden. Daher kann in dieser Ausführungsform der am wenigsten kürzlich aktive Fluss als der Fluss bestimmt werden, der den am wenigsten kürzlich aktualisierten (z.B. niedrigsten) Flussaktivitätsindikator aufweist. Erläuternd, wenn mehrere Flüsse Flussaktivitätsindikatoren aufweisen, die auf einen gemeinsamen Wert (z.B. null) gesetzt sind, kann nach zufälligen oder anderen Kriterien eine Flussnummer von ihnen gewählt werden. Nach dem Zustand 650 geht die Prozedur im Zustand 652 weiter.
  • Im Zustand 652 bestimmt der Flussdatenbankmanager 108, ob das Paket Daten enthält. Erläuternd zeigen die vom Anfangsblock-Analysator an den FDBM 108 gelieferten Steuerinformationen an, ob das Paket Daten aufweist. Wenn das Paket keine Daten enthält (z.B. das Paket ist ein Steuerpaket), geht die gezeigte Prozedur im Zustand 668 weiter.
  • Im Zustand 654 bestimmt der Flussdatenbankmanager 108, ob die mit dem gegenwärtigen Paket empfangenen Daten den End-Abschnitt von Daten für das zugehörige Datagramm bzw. den zugehörigen Fluss zu enthalten scheinen. Wie in Verbindung mit dem Zustand 620 erläutert, kann diese Bestimmung auf der Basis der in dem Paket enthaltenen Datenmenge getroffen werden. Wenn die Datenmenge kleiner als ein Schwellenwert ist (im Ausführungsbeispiel ein programmierbarer Wert), werden nicht mehr Daten erwartet, und dies sind wahrscheinlich die einzigen Daten für diesen Fluss. In diesem Fall geht die Prozedur im Zustand 668 weiter. Wenn jedoch die Daten den Schwellenwert treffen oder übersteigen, in welchem Fall mehr Daten erwartet werden, geht die Prozedur zum Zustand 656 weiter.
  • Im Zustand 656 werden die Werte von bestimmten Anzeigern geprüft, Diese Anzeiger können zum Beispiel die Bits URG, PSH, RST, FIN eines TCP-Anfangsblocks umfassen. Wenn irgendwelche der geprüften Anzeiger nicht ihre erwarteten oder gewünschten Werte haben (z.B. wenn irgendwelche der Anzeiger gesetzt sind), kann eine außergewöhnliche Bedingung herrschen, was eine oder mehrere von der NIC 100 gebotene Funktionen (z.B. Datenwiederzusammenbau, Schubverarbeitung, Lastverteilung) für dieses Paket ungeeignet macht. In diesem Fall geht die Prozedur im Zustand 668 weiter; andernfalls geht die Prozedur zum Zustand 658 weiter.
  • Im Zustand 658 gewinnt der Flussdatenbankmanager die im Zustand 646 gespeicherten Informationen hinsichtlich dessen, ob die Flussdatenbank 110 voll ist, wieder. Wenn die Datenbank voll ist, geht die Prozedur im Zustand 664 weiter; andernfalls geht die Prozedur im Zustand 660 weiter.
  • Im Zustand 660 wird der Flussdatenbank 110 ein neuer Fluss für das gegenwärtige Paket hinzugefügt. Erläuternd wird der neue Fluss auf der im Zustand 648 bestimmten oder wiedergewonnenen Flussnummer gespeichert. Die Hinzufügung eines neuen Flusses kann umfassen, eine Sequenznummer (z.B. Flusssequenznummer 522 von 5) zu setzen. Die Flusssequenznummer 522 kann erzeugt werden, indem eine aus dem Paket wiedergewonnene Sequenznummer (z.B. TCP-Sequenznummer) und die im Paket enthaltene Datenmenge addiert werden. Wie oben erörtert, muss diese Summe möglicherweise angepasst werden (z.B. durch Addieren von eins).
  • Das Speichern eines neuen Flusses kann außerdem umfassen, einen Aktivitätsindikator (z.B. Flussaktivitätsindikator 524 von 5) zu initialisieren. In einer Ausführungsform der Erfindung umfasst diese Initialisierung, einen Wert zu speichern, der aus einem Zähler wiedergewonnen wird, der jedes Mal hochgezählt wird, wenn für einen Fluss Daten empfangen werden. Erläuternd, wenn der Zähler oder ein Flussaktivitätsindikator über seinen maximalen speicherbaren Wert hinaus hochgezählt wird, werden der Zähler und alle Flussaktivitätsindikatoren gelöscht oder zurückgesetzt. Außerdem wird im Zustand 660 ein Gültigkeitsindikator (z.B. der Flussgültigkeitsindikator 520 von 5) gesetzt, um anzuzeigen, dass der Fluss gültig ist. Schließlich wird der Flussschlüssel des Pakets ebenfalls in der Flussdatenbank gespeichert, in dem der zugeordneten Flussnummer entsprechenden Eintrag.
  • Im Zustand 662 wird der Operationscode 6 für das Paket ausgewählt. Erläuternd zeigt der Operationscode 6 an, dass das Paket kompatibel ist, mit keinerlei gültigen Flüssen übereinstimmt und den ersten Abschnitt Daten für einen neuen Fluss enthält. Weiterhin haben die Anzeiger des Pakets ihre erwarteten oder notwendigen Werte, im Fluss werden zusätzliche Daten erwartet, und die Flussdatenbank ist nicht voll. Daher zeigt der Operationscode 6 an, dass kein vorhandener Fluss abzubrechen ist und dass ein neuer Fluss in der Flussdatenbank gespeichert worden ist. Nach dem Zustand 662 endet die gezeigte Prozedur im Zustand 670.
  • Im Zustand 664 wird ein vorhandener Eintrag in der Flussdatenbank ersetzt, so dass ein neuer, durch das gegenwärtige Paket gestarteter Fluss gespeichert werden kann. Daher wird die Flussnummer des am wenigsten kürzlich aktiven Flusses, im Zustand 650 bestimmt, wiedergewonnen. Dieser Fluss kann wie folgt ersetzt werden. Die Sequenznummer des vorhandenen Flusses (z.B. Flusssequenznummer 522 von 5) wird durch einen Wert ersetzt, der gewonnen wird, indem eine aus dem Paket extrahierte Sequenznummer (z.B. TCP-Sequenznummer) mit der Größe des Datenabschnitts des Pakets kombiniert wird. Diese Summe muss möglicherweise angepasst werden (z.B. durch Addieren von eins). Danach wird der vorhandene Flussaktivitätsindikator (z.B. Flussaktivitätsindikator 524) ersetzt. Zum Beispiel kann der Wert eines Flussaktivitätszählers in den Flussaktivitätsindikator kopiert werden, wie oben erörtert. Der Flussgültigkeitsindikator (z.B. Flussgültigkeitsindikator 520 von 5) wird dann gesetzt, um anzuzeigen, dass der Fluss gültig ist. Schließlich wird der Flussschlüssel des neuen Flusses gespeichert.
  • Im Zustand 666 wird der Operationscode 7 für das Paket ausgewählt. Der Operationscode 7 wurde auch im Zustand 636 ausgewählt. Im vorliegenden Kontext kann der Operationscode 7 anzeigen, dass das Paket kompatibel ist, mit dem Flussschlüssel keines gültigen Flusses übereinstimmt und den ersten Abschnitt Daten für einen neuen Fluss enthält. Weiterhin haben die Anzeiger des Pakets kompatible Werte, und im Fluss werden zusätzliche Daten erwartet. Zuletzt zeigt der Operationscode 7 in diesem Kontext jedoch an, dass die Flussdatenbank voll ist, so dass ein vorhandener Fluss abgebrochen wurde und an seiner Stelle der neue Fluss gespeichert wurde. Nach dem Zustand 666 endet die gezeigte Prozedur im Zustand 670.
  • Im Zustand 668 wird der Operationscode 5 für das Paket ausgewählt. Der Zustand 668 wird von verschiedenen Zuständen her betreten, und der Operationscode 5 stellt somit mannigfache mögliche Bedingungen oder Situationen dar. Zum Beispiel kann der Operationscode 5 ausgewählt werden, wenn ein Signal No Assist für ein Paket nachgewiesen wird (im Zustand 604). Wie oben erörtert, kann das Signal No Assist anzeigen, dass das entsprechende Paket nicht mit einem Satz von vorgewählten Protokollen kompatibel ist. In dieser Ausführungsform der Erfindung sind inkompatible Pakete ungeeignet für eine oder mehrere der verschiedenen Funktionen der NIC 100 (z.B. Datenwiederzusammenbau, Schubverarbeitung, Lastverteilung).
  • Der Zustand 668 kann auch vom Zustand 652 her betreten und der Operationscode 5 ausgewählt werden, in welchem Fall der Code anzeigen kann, dass das empfangene Paket mit keinen gültigen Flussschlüsseln übereinstimmt und weiterhin keine Daten enthält (z.B. kann es ein Steuerpaket sein).
  • Der Zustand 668 kann auch vom Zustand 654 her betreten werden. In diesem Kontext kann der Operationscode 5 anzeigen, dass das Paket mit keinen gültigen Flussschlüsseln übereinstimmt. Er kann weiterhin anzeigen, dass das Paket Daten enthält, dass aber die Größe des Datenabschnitts kleiner als der in Verbindung mit Zustand 654 erörterte Schwellenwert ist. In diesem Kontext scheinen die Daten des Pakets vollständig zu sein (z.B. enthält es alle Daten für ein Datagramm), was bedeutet, dass keine anderen Daten mit den Daten dieses Pakets zusammenzusetzen sind und es daher keinen Grund gibt, einen neuen Eintrag in der Datenbank für diesen Ein-Paket-Fluss vorzunehmen.
  • Schließlich kann der Zustand 668 auch vom Zustand 656 her betreten werden. In diesem Kontext kann der Operationscode 5 anzeigen, dass das Paket mit keinen gültigen Flussschlüsseln übereinstimmt, Daten enthält und dass mehr Daten erwartet werden, dass aber mindestens ein Anzeiger in einem oder mehreren Protokoll-Anfangsblöcken des Pakets nicht ihre erwarteten Werte haben. Zum Beispiel sind in einer Ausführungsform der Erfindung die TCP-Anzeiger URG, PSH, RST und FIN erwartungsgemäß frei. Sind irgendwelche dieser Anzeiger gesetzt, kann eine außergewöhnliche Bedingung herrschen, was es möglich macht, dass eine der von der NIC 100 gebotenen Funktionen für dieses Paket ungeeignet ist.
  • Wie Tabelle 1 widerspiegelt, ist kein Fluss abzubrechen und ist kein neuer Fluss einzurichten, wenn der Operationscode 5 ausgewählt wird. Im Anschluss an den Zustand 668 endet die gezeigte Prozedur im Zustand 670.
  • Der Fachmann erkennt, dass die in 6A bis 6E gezeigte und oben erörterte Prozedur nur eine geeignete Prozedur ist, um eine Flussdatenbank aufrechtzuerhalten und zu aktualisieren und um die Eignung eines Pakets für bestimmte Verarbeitungsfunktionen zu ermitteln. Insbesondere können andere Operationscodes benutzt werden oder sie können auf eine andere Weise ausgeführt werden, wobei es ein Ziel ist, Informa tionen für spätere Verarbeitung des Pakets durch die NIC 100 zu erzeugen.
  • In der gezeigten Prozedur werden zwar allen Paketen durch einen Flussdatenbankmanager Operationscodes zugeordnet, in einer alternativen Prozedur kann ein durch den FDBM zugeordneter Operationscode aber durch ein anderes Modul der NIC 100 ersetzt oder geändert werden. Dies kann geschehen, um ein bestimmtes Verfahren sicherzustellen, bestimmte Typen von Paketen zu behandeln. Zum Beispiel ordnet in einer Ausführungsform der Erfindung das IPP-Modul 104 einen vorbestimmten Operationscode (z.B. Operationscode 2 von Tabelle 1) Jumbo-Paketen zu (z.B. Paketen, die größer als die MTU sind), so dass die DMA-Maschine 120 sie nicht wiederzusammensetzen wird. Insbesondere kann das IPP-Modul unabhängig ermitteln, dass das Paket ein Jumbo-Paket ist (z.B. aus vom MAC-Modul gelieferten Informationen) und daher den vorbestimmten Code zuordnen. Erläuternd führen der Anfangsblock-Analysator 106 und der FDBM 108 ihre normalen Funktionen für ein Jumbo-Paket durch, und das IPP-Modul 104 empfängt einen ersten, durch die FDBM zugeordneten Operationscode. Jedoch ersetzt das IPP-Modul diesen Code vor dem Speichern des Jumbo-Pakets und Informationen hinsichtlich des Pakets. In einer alternativen Ausführungsform können der Anfangsblock-Analysator 106 und/oder der Flussdatenbankmanager 108 konfiguriert sein, einen bestimmten Typ von Paket (z.B. Jumbo) zu erkennen und einen vorbestimmten Operationscode zuzuordnen.
  • Die in der in 6A bis 6E gezeigten Ausführungsform der Erfindung angewandten Operationscodes sind in der folgenden Tabelle 1 dargestellt und erläutert. Tabelle 1 enthält Beispielkriterien, die benutzt werden, um jeden Operationscode auszuwählen, und Beispielergebnisse oder -wirkungen jedes Codes.
  • Figure 00810001
  • Figure 00820001
    TABELLE 1
  • Eine Ausführungsform eines Lastverteilers
  • In einer Ausführungsform der Erfindung ermöglicht der Lastverteiler 112 die Verarbeitung von Paketen durch ihre Protokollstapel, um auf eine Anzahl von Prozessoren verteilt zu werden. Erläuternd erzeugt der Lastverteiler 112 eine Kennung (z.B. eine Prozessornummer) eines Prozessors, dem das Paket vorzulegen ist. Die mehreren Prozessoren können sich in einem Hauptrechnersystem befinden, das von der NIC 100 bedient wird. In einer alternativen Ausführungsform befinden sich ein oder mehrere Prozessoren zur Verarbeitung von Paketen durch einen Protokollstapel in der NIC 100.
  • Ohne ein wirksames Verfahren zum Aufteilen oder Verteilen der Verarbeitungsbelastung könnte ein Prozessor überlastet werden, wenn er den ganzen oder meisten an der NIC 100 empfangenen Netzverkehr verarbeiten müsste, insbesondere in einer Hochgeschwindigkeitsnetz-Umgebung. Die resultierende Verzögerung bei der Verarbeitung von Netzverkehr könnte den Betrieb im Hauptrechnersystem und auch anderen Computersystemen, die über das Netz mit dem Hauptsystem kommunizieren, verschlechtern.
  • Wie der Fachmann erkennt, ist es möglicherweise kein wirksames Vorhaben, Pakete einfach auf Prozessoren in einem Satz von Prozessoren zu verteilen (z.B. in einem Reihum-Schema). So ein Vorhaben könnte leicht in Paketen resultieren, die nicht der Reihe nach verarbeitet werden. Zum Beispiel, würden zwei Pakete aus einem Datenfluss oder einer Datenverbindung, die in der richtigen Reihenfolge an einer Netzschnittstelle empfangen werden, zwei verschiedenen Prozessoren vorgelegt, wird das zweite Paket möglicherweise vor dem ersten verarbeitet. Dies könnte zum Beispiel geschehen, wenn der Prozessor, der das erste Paket empfangen hat, das Paket nicht sofort verarbeiten könnte, da er mit einer anderen Aufgabe beschäftigt ist. Werden Pakete nicht der Reihe nach verarbeitet, muss im Allgemeinen ein Wiederherstellungsschema gestartet werden, was noch mehr Ineffizienz und mehr Verzögerung einführt.
  • Daher werden in einer vorliegenden Ausführungsform der Erfindung Pakete auf Basis ihrer Flusskennungen auf mehrere Prozessoren verteilt. Wie oben beschrieben, kann ein Anfangsblock-Analysator einen Flussschlüssel aus Quellen- und Zielkennungen der Schicht drei (z.B. IP) und Schicht vier (z.B. TCP) erzeugen, die aus den Anfangsblöcken eines Pakets wiedergewonnen werden. Der Flussschlüssel kann benutzt werden, um den Datenfluss zu kennzeichnen, zu dem die Pakete gehören. Daher werden in dieser Ausführungsform der Erfindung alle Pakete mit identischem Flussschlüssel einem einzelnen Prozessor vorgelegt. Solange die Pakete der Reihe nach von der NIC 100 empfangen werden, sollten sie an den Hauptrechner geliefert und der Reihe nach durch ihren zugeordneten Prozessor verarbeitet werden.
  • Erläuternd werden mehrere von einem Quellenobjekt zu einem Zielobjekt gesendete Pakete denselben Flussschlüssel haben, selbst wenn die Pakete Teil von getrennten Datagrammen sind, solange ihre Kennungen der Schicht drei und Schicht vier dieselben bleiben. Wie oben erörtert, werden für jedes Datagramm innerhalb einer durchgehenden TCP-Verbindung getrennte Flüsse eingerichtet und abgebrochen. Ebenso wie alle Pakete innerhalb eines Flusses an einen Prozessor gesendet werden, werden daher auch alle Pakete innerhalb einer durchgehenden TCP-Verbindung an denselben Prozessor gesendet. Die hilft sicherzustellen, Pakete für die ganze Verbindung korrekt anzuordnen, selbst zwischen Datagrammen.
  • Je nach der Netzumgebung, in der die NIC 100 arbeitet (z.B. den vom Netz 102 unterstützten Protokollen), ist der Flussschlüssel möglicherweise zu groß, um ihn als Kennung eines Prozessors zu benutzten. In einer oben beschriebenen Ausführungsform der Erfindung misst zum Beispiel ein Flussschlüssel 288 Bits. Indessen kann die Zahl der am Lastausgleichsschemateilnehmenden Prozessoren viel kleiner sein. Zum Beispiel in der unten in Verbindung mit 7 beschriebenen Ausführungsform der Erfindung werden maximal vierundsechzig Prozessoren unterstützt. Daher ist in dieser Ausführungsform nur eine Vierundsechzig-Bit-Nummer nötig, um den ausgewählten Prozessor zu kennzeichnen. Der größere Flussschlüssel kann daher in einen kleineren Bereich von Werten abgebildet oder Hash-codiert werden.
  • 7 zeigt ein Verfahren zum Erzeugen einer Kennung (z.B. Prozessornummer) zum Spezifizieren eines Prozessors zum Verarbeiten eines von der NIC 100 empfangenen Pakets auf Basis des Flussschlüssels des Pakets. In dieser Ausführungsform der Erfindung ist das Netz 102 das Internet, und ein empfangenes Paket ist in Übereinstimmung mit einem kompatiblen Protokollstapel (z.B. Ethernet in Schicht zwei, IP in Schicht drei und TCP in Schicht vier) formatiert.
  • Der Zustand 700 ist ein Startzustand. Im Zustand 702 wird ein Paket von der NIC 100 empfangen, und ein Anfangsblock-Abschnitt des Pakets wird vom Anfangsblock-Analysator 106 analysiert (ein Verfahren zum Analysieren eines Pakets ist in einem früheren Abschnitt beschrieben). Im Zustand 704 empfängt der Lastverteiler 112 den Flussschlüssels des Pakets, der vom Anfangsblock-Analysator 106 erzeugt wurde.
  • Da der Flussschlüssel eines Pakets in dieser Ausführungsform 288 Bits groß ist, wird im Zustand 706 eine Hash-Funktion durchgeführt, um einen Wert von geringerer Größe zu erzeugen. Die Hash-Operation kann zum Beispiel eine Zweiunddreißig-Bit-CRC-Funktion (CRC = zyklische Redundanzprüfung) wie z.B. ATM(Asynchronübertragungsmodus)-Adaptionsschicht 5 (AAL5) aufweisen. Die AAL5 erzeugt Zweiunddreißig-Bit-Nummern, die ziemlich gleichmäßig auf die 232 möglichen Werte verteilt sind. Ein anderes geeignetes Verfahren zum Hash-Codieren ist die Standard-Ethernet-CRC-32-Funktion. Andere Hash-Funktionen, die aus relativ großen Flussschlüsseln relativ kleine Nummern erzeugen können, wobei die Nummern sowohl erzeugt als auch auf einen Bereich von Werten verteilt werden, sind ebenfalls geeignet,
  • Mit dem resultierenden Hash-Wert wird im Zustand 708 eine Modulus-Operation über die Anzahl der zum Verteilen oder Aufteilen der Verarbeitung zur Verfügung stehenden Prozessoren durchgeführt. Erläuternd programmiert oder speichert Software, die auf dem Hauptcomputer ausgeführt wird (z.B. ein Gerätetreiber für die NIC 100), die Anzahl von Prozessoren, so dass sie vom Lastverteiler 112 (z.B. einem Register) gelesen oder wiedergewonnen werden kann. Die Anzahl der für Lastausgleich zur Verfügung stehenden Prozessoren kann alle oder ein Teilsatz der Anzahl der im Hauptrechnersystem eingebauten Prozessoren sein. Im Ausführungsbeispiel ist die Anzahl der in einem Hauptrechnersystem zur Verfügung stehenden Prozessoren programmierbar, mit einem Maximalwert von vierundsechzig. Das Resultat der Modulus-Operation in dieser Ausführungsform ist daher die Nummer des Prozessors (z.B. von null bis vierundsechzig), dem das Paket zur Verarbeitung vorgelegt wird. In dieser Ausführungsform der Erfindung ist der Lastverteiler 112 in Hardware ausgeführt, was schnelle Ausführung der Hash- und Modulus-Funktionen erlaubt. In einer alternativen Ausführungsform der Erfindung kann praktisch jede beliebige Anzahl von Prozessoren untergebracht werden.
  • Im Zustand 710 wird die Nummer des Prozessors, der das Paket durch seinen Protokollstapel verarbeiten wird, im Speicher des Hauptrechners gespeichert. Erläuternd wird der Zustand 710 parallel zu dem Speichern des Pakets in einem Hauptspeicherpuffer durchgeführt. In einer Ausführungsform der Erfindung wird ein Beschreiberring im Speicher des Hauptrechners eingerichtet, um die Prozessornummer und möglicherweise weitere Informationen hinsichtlich des Pakets (z.B. Größe, TCP-Prüfsumme, einen Zeiger auf das Paket) festzuhalten.
  • Ein Beschreiberring in dieser Ausführungsform ist eine Datenstruktur, die eine Anzahl von Einträgen oder "Beschreibern" zum Speichern von Informationen zur Verwendung durch das Hauptrechnersystem der Netzschnittstellenschaltung aufweist. Ein Beschreiben kann Paketinformationen vorübergehend speichern, nachdem das Paket von der NIC 100 empfangen worden ist, jedoch bevor das Paket vom Hauptrechnersystem verarbeitet wird. Die in einem Beschreiber gespeicherten Informationen können zum Beispiel vom Gerätetreiber für die NIC 100 oder zur Verarbeitung des Pakets durch seinen Protokollstapel benutzt werden.
  • Im Zustand 712 wird eine Unterbrechung oder Warnung an den Hauptrechner ausgegeben; um ihn zu benachrichtigen, dass ein neues Paket von der NIC 100 geliefert worden ist. In einer Ausführungsform der Erfindung, in der die NIC 100 durch einen PCI-(Peripheriekomponenten)-Bus mit dem Hauptrechner gekoppelt ist, kann das Signal INTA quer über den Bus geltend gemacht werden. Ein PCI-Steuergerät im Hauptrechner empfängt das Signal, und das Hauptbetriebssystem wird gewarnt (z.B. über eine Unterbrechung).
  • Im Zustand 714 wird auf dem Hauptrechner arbeitende Software (z.B. ein Gerätetreiber für die NIC 100) aufgerufen (z.B. durch den Unterbrechungsabwickler des Betriebssystems des Hauptrechners), um auf ein neu empfangenes Paket einzuwirken. Die Software sammelt Informationen aus einem oder mehreren Beschreibern im Beschreiberring und setzt Informationen, die nötig sind, um die Verarbeitung jedes neuen Pakets zu vollenden, in eine Warteschlange für den spezifizierten Prozessor (d.h. in Übereinstimmung mit der im Beschreiber des Pakets gespeicherten Prozessornummer). Erläuternd entspricht jeder Beschreiber einem getrennten Paket. Die in der Prozessorwarteschlange für jedes Paket gespeicherten Informationen können einen Zeiger auf einen Puffer, der das Paket enthält, die TCP-Prüfsumme des Pakets, Versätze von einem oder mehreren Protokoll-Anfangsblöcken usw. umfassen. Außerdem kann jeder am Lastverteilungsschemateilnehmende Prozessor eine zugeordnete Warteschlange zur Verarbeitung von Netzpaketen aufweisen. In einer alternativen Ausführungsform der Erfindung können mehrere Warteschlangen benutzt werden (z.B. für mehrere Prioritätsebenen oder für unterschiedliche Protokollstapel).
  • Erläuternd ist jeder Prozessor auf dem Hauptrechner konfiguriert, alle Warnungen und/oder Unterbrechungen zu empfangen, die mit dem Empfang von Netzpaketen von der NIC 100 verknüpft sind, und die geeignete Software-Routine oder den geeigneten Gerätetreiber zu warnen. Diese Anfangsverarbeitung kann alternativ auf mehrere Prozessoren verteilt werden. Außerdem wird in einer Ausführungsform der Erfindung ein Abschnitt der Wiedergewinnung und Verarbeitung von Beschreiber-Inhalten als Teil der Abwicklung der Unterbrechung durchgeführt, die erzeugt wird, wenn ein neues Paket im Beschreiberring gespeichert wird. Der zum Verarbeiten des Pakets ausgewählte Prozessor führt dann den Rest der Wiedergewinnungs-/Verarbeitungsprozedur durch.
  • Im Zustand 716 wird der zum Verarbeiten eines neuen Pakets bestimmte Prozessor gewarnt oder geweckt. In einer Ausführungsform der Erfindung, die auf einem SolarisTM-Arbeitsplatzrechner arbeitet, sind individuelle vom Prozessor ausgeführte Prozesse als "Threads" (gekettete Programme) konfiguriert. Ein Thread ist ein Prozess, der in einer Normalbetriebsart abläuft (z.B. nicht auf einer Unterbrechungsebene), um minimale Auswirkung auf andere auf dem Arbeitsplatzrechner ausgeführte Prozesse zu haben. Ein Normalbetriebsart-Prozess kann jedoch mit hoher Priorität ausgeführt werden. Alternativ kann ein Thread auf einer relativ niedrigen Unterbrechungsebene ablaufen.
  • Ein für Verarbeitung eines ankommenden Pakets verantwortlicher Thread kann sich selbst blockieren, wenn er keine Pakete zu verarbeiten hat, und wird geweckt, wenn er Arbeit bekommt. Um anzuzeigen, ob der Thread ein Paket zu verarbeiten hat, kann eine "Bedingungsvariable" benutzt werden. Erläuternd wird die Bedingungsvariable auf einen ersten Wert gesetzt, wenn der Thread ein Paket verarbeiten soll (z.B. wenn ein Paket zur Verarbeitung durch den Prozessor empfangen wird), und wird auf einen zweiten Wert gesetzt, wenn keine Pakete mehr zu verarbeiten sind. Im Ausführungsbeispiel der Erfindung kann jeder Prozessorwarteschlange eine Bedingungsvariable zugeordnet sein.
  • In einer alternativen Ausführungsform wird der angezeigte Prozessor im Zustand 716 durch einen "Querprozessorruf" gewarnt. Ein Querprozessorruf ist eine Art, zwischen Prozessoren zu kommunizieren, wodurch ein Prozessor durch einen anderen Prozessor fernunterbrochen wird. Anstelle von Threads und Querprozessorrufen können auch andere Verfahren benutzt werden, durch die ein Prozessor einen anderen Prozessor warnt oder ihm einen Prozess schickt.
  • Im Zustand 718 beginnt ein Thread oder anderer Prozess im ausgewählten Prozessor mit der Verarbeitung des Pakets, das in der Warteschlange des Prozessors gespeichert wurde. Die gezeigte Prozedur endet dann mit dem Endzustand 720.
  • In einer alternativen Ausführungsform der Erfindung ist eine Hochgeschwindigkeits-Netzschnittstelle konfiguriert, ATM(Asynchronübertragungsmodus)-Verkehr zu verarbeiten. In dieser Ausführungsform ist ein Lastverteiler als ein Satz von Befehlen (z.B. als Software) statt als ein Hardware-Modul ausgeführt. ATM-Verkehr kann als verbindungsorientiert charakterisiert werden und kann durch eine virtuelle Verbindungskennung (VCI) gekennzeichnet werden, die einer zwischen den Quellen- und Zielobjekten des Pakets hergestellten virtuellen Schaltung entspricht. Jedes Paket, das Teil einer virtuellen Schaltung ist, enthält die VCI in seinem Anfangsblock.
  • Vorteilhaft hat eine VCI eine relativ geringe Größe (z.B. sechzehn Bits). In dieser alternativen Ausführungsform kann daher die VCI eines Pakets anstelle eines Flussschlüssels zu dem Zweck benutzt werden, die Last der Verarbeitung von Paketen durch ihre Protokollstapel zu verteilen oder aufzuteilen. Erläuternd wird Verkehr von unterschiedlichen VCIs an unterschiedliche Prozessoren gesendet, um aber das korrekte Anordnen von Paketen sicherzustellen, können alle Pakete mit derselben VCI an denselben Prozessor gesendet werden. Wird ein ATM-Paket an einer Netzschnittstelle empfangen, wird die VCI aus seinem Anfangsblock wiedergewonnen und an den Lastverteiler geliefert. Danach wird der Modulus der VCI über die Anzahl von Prozessoren berechnet, die für Lastverteilung zur Verfügung stehen. Ähnlich wie im Ausführungsbeispiel werden das Paket und die Nummer seines zugeordneten Prozessor dann an den Hauptrechner geliefert.
  • Wie oben beschrieben, wird in einer vorliegenden Ausführungsform der Erfindung Lastverteilung auf Basis der Quellen- und Zielobjekt-Kennungen der Schicht drei und/oder Schicht vier eines Pakets durchgeführt. In einer alternativen Ausführungsform der Erfindung kann die Lastverteilung jedoch auf Basis von Adressen der Schicht zwei durchgeführt werden. In dieser alternativen Ausführungsform werden Pakete mit zum Beispiel denselben Ethernet-Quellen- und Zieladressen an einen einzelnen Prozessor gesendet.
  • Dies kann jedoch dazu führen, dass ein Prozessor mehr Pakete empfängt als er emp fangen würde, wenn Kennungen der Schicht drei und/oder Schicht vier benutzt würden. Zum Beispiel, wenn eine große Menge Verkehr über einen Router empfangen wird, der (in logischem Sinne) nahe am Hauptrechner liegt, kann es sein, dass die Quellen-Ethernet-Adresse für den ganzen Verkehr die Adresse des Routers ist, obwohl der Verkehr von einer Menge verschiedener Endnutzer und/oder Computer herrührt. Im Gegensatz dazu, wenn der Hauptrechner an demselben Ethernet-Segment wie alle Endnutzer bzw. Computer ist, werden die Quellenadressen der Schicht zwei größere Vielfalt zeigen und effizientere Lastverteilung ermöglichen.
  • Andere Verfahren zum Verteilen der Verarbeitung von aus einem Netz empfangenen Paketen können sich von der in 7 gezeigten Ausführungsform unterscheiden, ohne den Schutzbereich der Erfindung zu überschreiten. Die PCT-Veröffentlichung WO 00/52904, veröffentlicht am 8. September 2000, liefert zusätzliche Details einer Netzschnittstelle, bei der eine Ausführungsform der Erfindung in die Praxis umgesetzt werden kann.
  • Sun, Sun Microsystems, SPARC und Solaris sind Marken oder eingetragene Marken der Fa. Sun Microsystems in den Vereinigten Saaten und anderen Ländern.
  • Die vorhergehenden Beschreibungen von Ausführungsformen der Erfindung wurden nur zu Zwecken der Darstellung und Beschreibung gegeben. Sie sollen nicht erschöpfend sein oder die Erfindung auf die offenbarten Formen beschränken. Dementsprechend soll die obige Offenbarung die Erfindung nicht beschränken; der Schutzbereich der Erfindung wird durch die beigefügten Ansprüche definiert.

Claims (31)

  1. Verfahren zum Verteilen von Netzverkehrsverarbeitung auf mehrere Prozessoren in einem Mehrprozessor-Computer, das Folgendes umfasst: Empfangen (132) eines ersten Pakets an einer Netzschnittstelle eines Mehrprozessor-Computers; Analysieren (Parsen) (134) des ersten Pakets, um einen ersten Flussschlüssel zu bestimmen, der einen ersten Datenfluss kennzeichnet, der das erste Paket umfasst; Aktualisieren (136) einer Aufzeichnung in einer Flussdatenbank, um einen Status des ersten Datenflusses anzuzeigen, wobei die Aufzeichnung durch den ersten Flussschlüssel gekennzeichnet werden kann und der Status durch einen ersten Flussindex indexiert wird; Erzeugen (138) einer ersten Prozessorkennung, die konfiguriert ist, einen von mehreren Prozessoren des Mehrprozessor-Computers zu kennzeichnen; und Vorlegen (146) des ersten Pakets von der Netzschnittstelle zur Verarbeitung durch den ersten Prozessor.
  2. Verfahren nach Anspruch 1, das weiterhin Folgendes umfasst: Empfangen eines zweiten Pakets des ersten Datenflusses an der Netzschnittstelle von dem Quellenobjekt; Zuordnen der ersten Prozessorkennung zu dem zweiten Paket; und Vorlegen des zweiten Pakets von der Netzschnittstelle zur Verarbeitung durch den ersten Prozessor.
  3. Verfahren nach Anspruch 1, das weiterhin Folgendes umfasst: Empfangen eines zweiten Pakets an der Netzschnittstelle; Analysieren des zweiten Pakets, um einen zweiten Flussschlüssel zu bestimmen, der einen zweiten Datenfluss kennzeichnet, der das zweite Paket umfasst; Erzeugen einer zweiten Prozessorkennung, die konfiguriert ist, einen der mehreren Prozessoren zu kennzeichnen; Zuordnen der zweiten Prozessorkennung zu dem zweiten Paket; und Vorlegen des zweiten Pakets von der Netzschnittstelle zur Verarbeitung durch den zweiten Prozessor.
  4. Verfahren nach Anspruch 1, bei dem das Analysieren (134) Folgendes umfasst: aus dem ersten Paket eine Kennung einer Quelle des ersten Pakets wiederzugewinnen; und aus dem ersten Paket eine Kennung eines Ziels des ersten Pakets wiederzugewinnen.
  5. Verfahren nach Anspruch 4, bei dem das Analysieren (134) weiterhin umfasst, die Quellenkennung und die Zielkennung zu kombinieren, um den ersten Flussschlüssel zu bilden.
  6. Verfahren nach Anspruch 5, bei dem das Aktualisieren (136) umfasst, den ersten Flussschlüssel in der Flussdatenbank zu speichern.
  7. Verfahren nach Anspruch 4, bei dem das Analysieren (134) weiterhin umfasst, die Quellenkennung und die Zielkennung zu kombinieren, um den ersten Flussschlüssel zu bilden, und das Aktualisieren (136) umfasst, die Flussdatenbank nach dem ersten Flussschlüssel zu durchsuchen.
  8. Verfahren nach Anspruch 7, bei dem das Aktualisieren (136) weiterhin umfasst, den ersten Flussschlüssel in der Flussdatenbank zu speichern, wenn der erste Flussschlüssel nicht in der Flussdatenbank gefunden wird.
  9. Verfahren nach Anspruch 7, bei dem das Aktualisieren (136) weiterhin umfasst, einen dem ersten Flussschlüssel zugeordneten Eintrag in der Flussdatenbank zu aktualisieren, wenn der erste Flussschlüssel in der Flussdatenbank gefunden wird.
  10. Verfahren nach Anspruch 7, bei dem das Aktualisieren (136) weiterhin umfasst, einen Eintrag in der Flussdatenbank für den ersten Datenfluss anzulegen und den ersten Flussschlüssel in dem Eintrag zu speichern, wenn der erste Flussschlüssel nicht in der Flussdatenbank gefunden wird.
  11. Verfahren nach Anspruch 1, bei dem das Analysieren (134) umfasst, eine virtuelle Verbindungskennung aus dem ersten Paket wiederzugewinnen.
  12. Verfahren nach Anspruch 1, bei dem das Erzeugen (138) einer ersten Prozessorkennung Folgendes umfasst: Hash-Codieren (706) des ersten Flussschlüssels, um einen Hash-Wert zu erzeugen; Kennzeichnen einer Anzahl von Prozessoren, auf die die Netzverkehrsverarbeitung zu verteilen ist; und Berechnen (708) eines Modulus des Hash-Wertes über die Anzahl von Prozessoren.
  13. Verfahren nach Anspruch 12, bei dem das Kennzeichnen umfasst, einen Wert, der die Anzahl von Prozessoren darstellt, aus einem programmierbaren Speicher wiederzugewinnen.
  14. Verfahren nach Anspruch 1, bei dem das Erzeugen (138) einer ersten Prozessorkennung Folgendes umfasst: Kennzeichnen einer Anzahl von Prozessoren, auf die die Netzverkehrsverarbeitung zu verteilen ist; und Berechnen eines Modulus des ersten Flussschlüssels über die Anzahl von Prozessoren.
  15. Verfahren nach Anspruch 1, bei dem das Vorlegen (146) Folgendes umfasst: das erste Paket in einem ersten Speicher des Mehrprozessorcomputers zu speichern; und den ersten Prozessorschlüssel in einem zweiten Speicher zu speichern.
  16. Verfahren nach Anspruch 15, bei dem das Vorlegen (146) weiterhin umfasst, eine Warnung von der Netzschnittstelle an den Mehrprozessorcomputer auszugeben (148), um dem Mehrprozessorcomputer das Speichern des ersten Pakets zu melden.
  17. Verfahren nach Anspruch 1, bei dem das Empfangen (132), Analysieren (134), Aktualisieren (136), Erzeugen (138), Zuordnen und Vorlegen (146) alle an der Netzschnittstelle durchgeführt werden.
  18. Verfahren nach Anspruch 1, bei dem das Vorlegen (146) umfasst, das erste Paket in einem Speicher zu speichern, den die Netzschnittstelle und der Mehrprozessorcomputer gemeinsam benutzen, zur Übertragung von der Netzschnittstelle an einen der mehreren Prozessoren.
  19. Verfahren nach Anspruch 1, das weiterhin umfasst, die erste Prozessorkennung zu speichern, zur Übertragung mit dem ersten Paket von der Netzschnittstelle an einen der mehreren Prozessoren.
  20. Verfahren nach Anspruch 1, bei dem das Analysieren (134) umfasst, zu bestimmen, ob das erste Paket in Übereinstimmung mit einem vorbestimmten Satz von Datenübertragungsprotokollen aufgebaut war.
  21. Verfahren nach Anspruch 20, das weiterhin umfasst, dem ersten Paket einen Operationscode zuzuordnen (136), um anzuzeigen, ob das erste Paket in Übereinstimmung mit einem vorbestimmten Satz von Datenübertragungsprotokollen aufgebaut war.
  22. Verfahren nach Anspruch 1, bei dem das Erzeugen (138) umfasst, die erste Prozessorkennung aus der Flussdatenbank wiederzugewinnen.
  23. Verfahren nach Anspruch 1, das weiterhin umfasst, die erste Prozessorkennung dem ersten Paket zuzuordnen.
  24. Mehrprozessor-Computer zum Empfangen und Verarbeiten von Paketen von einem Netz, der Folgendes umfasst: mehrere Prozessoren; und eine Netzschnittstelle (100), die konfiguriert ist, Pakete von einem Netz (102) zu empfangen und die Pakete den mehreren Prozessoren vorzulegen, wobei die Netzschnittstelle Folgendes umfasst: eine Flussdatenbank (110), die konfiguriert ist, den jeweiligen Status von Datenflüssen zu speichern, in die Objekte einbezogen sind, die auf dem Mehrprozessor-Computer arbeiten, wobei die Datenflüsse durch Flussschlüssel gekennzeichnet werden und der jeweilige Status durch einen Flussindex indexiert wird; einen Anfangsblock-Parser (106), der konfiguriert ist, einen oder mehrere Protokoll-Anfangsblöcke eines ersten an der Netzschnittstelle empfangenen Pakets für ein erstes Objekt zu analysieren (parsen), das auf dem Mehrprozessor-Computer arbeitet, und einen ersten Flussschlüssel eines ersten Datenflusses zu erzeugen, der das erste Paket umfasst; und einen Lastverteiler (112), der konfiguriert ist, aus dem ersten Flussschlüssel oder einem ersten Flussindex eines Status des ersten Datenflusses in der Flussdatenbank eine Kennung eines ersten Prozessors der mehreren Prozessoren zur Verarbeitung des ersten Pakets zu erzeugen.
  25. Mehrprozessorcomputer nach Anspruch 24, bei dem die Netzschnittstelle (100) weiterhin Folgendes umfasst: einen Flussdatenbankmanager (108), der konfiguriert ist, den ersten Flussschlüssel zu empfangen und die Flussdatenbank mit einem Status des ersten Datenflusses zu aktualisieren.
  26. Mehrprozessorcomputer nach Anspruch 24, bei dem die Netzschnittstelle (100) weiterhin Folgendes umfasst: eine erste Datenstruktur zum Speichern des ersten Pakets zur Übertragung an einen der mehreren Prozessoren; und eine zweite Datenstruktur zum Speichern der Kennung des ersten Prozessors.
  27. Mehrprozessorcomputer nach Anspruch 24, bei dem der erste Flussschlüssel eine Kennung einer Quelle des ersten Pakets und eine Kennung des ersten Objekts umfasst.
  28. Mehrprozessorcomputer nach Anspruch 24, bei dem der Anfangsblock-Parser (106) weiterhin konfiguriert ist, ein vorbestimmtes Signal zu erzeugen, wenn einer oder mehrere Protokoll-Anfangsblöcke des ersten Pakets nicht einem vorbestimmten Satz von Protokollen entsprechen.
  29. Computerprogramm, das bei Ausführung auf einem Computer oder einem Computernetz dafür eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 23 durchzuführen.
  30. Computerprogramm nach Anspruch 29, verkörpert auf einem computerlesbaren Speichermedium.
  31. Verfahren nach Anspruch 1, bei dem das Erzeugen (138) Folgendes umfasst: Kennzeichnen einer Anzahl von Prozessoren, auf die die Netzverkehrsverarbeitung zu verteilen ist; und Berechnen eines Modulus des ersten Flussindex über die Anzahl von Prozessoren.
DE60016574T 1999-03-01 2000-02-29 Verfahren und vorrichtung zur belastungsverteilung uphänging von datenflussen Expired - Fee Related DE60016574T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US259445 1999-03-01
US09/259,445 US6389468B1 (en) 1999-03-01 1999-03-01 Method and apparatus for distributing network traffic processing on a multiprocessor computer
PCT/US2000/005306 WO2000052881A2 (en) 1999-03-01 2000-02-29 Method and apparatus for load distribution

Publications (2)

Publication Number Publication Date
DE60016574D1 DE60016574D1 (de) 2005-01-13
DE60016574T2 true DE60016574T2 (de) 2005-12-15

Family

ID=22984982

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60016574T Expired - Fee Related DE60016574T2 (de) 1999-03-01 2000-02-29 Verfahren und vorrichtung zur belastungsverteilung uphänging von datenflussen

Country Status (6)

Country Link
US (1) US6389468B1 (de)
EP (1) EP1157522B1 (de)
JP (1) JP2002538724A (de)
AU (1) AU4005000A (de)
DE (1) DE60016574T2 (de)
WO (1) WO2000052881A2 (de)

Families Citing this family (156)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6807581B1 (en) 2000-09-29 2004-10-19 Alacritech, Inc. Intelligent network storage interface system
US7185266B2 (en) 2003-02-12 2007-02-27 Alacritech, Inc. Network interface device for error detection using partial CRCS of variable length message portions
US8621101B1 (en) 2000-09-29 2013-12-31 Alacritech, Inc. Intelligent network storage interface device
US7133940B2 (en) * 1997-10-14 2006-11-07 Alacritech, Inc. Network interface device employing a DMA command queue
US6658480B2 (en) 1997-10-14 2003-12-02 Alacritech, Inc. Intelligent network interface system and method for accelerated protocol processing
US7089326B2 (en) * 1997-10-14 2006-08-08 Alacritech, Inc. Fast-path processing for receiving data on TCP connection offload devices
US6757746B2 (en) 1997-10-14 2004-06-29 Alacritech, Inc. Obtaining a destination address so that a network interface device can write network data without headers directly into host memory
US7237036B2 (en) * 1997-10-14 2007-06-26 Alacritech, Inc. Fast-path apparatus for receiving data corresponding a TCP connection
US6434620B1 (en) * 1998-08-27 2002-08-13 Alacritech, Inc. TCP/IP offload network interface device
US8782199B2 (en) 1997-10-14 2014-07-15 A-Tech Llc Parsing a packet header
US8539112B2 (en) 1997-10-14 2013-09-17 Alacritech, Inc. TCP/IP offload device
US6697868B2 (en) 2000-02-28 2004-02-24 Alacritech, Inc. Protocol processing stack for use with intelligent network interface device
US7174393B2 (en) 2000-12-26 2007-02-06 Alacritech, Inc. TCP/IP offload network interface device
US7167927B2 (en) 1997-10-14 2007-01-23 Alacritech, Inc. TCP/IP offload device with fast-path TCP ACK generating and transmitting mechanism
US7042898B2 (en) 1997-10-14 2006-05-09 Alacritech, Inc. Reducing delays associated with inserting a checksum into a network message
US6226680B1 (en) * 1997-10-14 2001-05-01 Alacritech, Inc. Intelligent network interface system method for protocol processing
US7076568B2 (en) * 1997-10-14 2006-07-11 Alacritech, Inc. Data communication apparatus for computer intelligent network interface card which transfers data between a network and a storage device according designated uniform datagram protocol socket
US6687758B2 (en) * 2001-03-07 2004-02-03 Alacritech, Inc. Port aggregation for network connections that are offloaded to network interface devices
US6473401B1 (en) * 1998-04-06 2002-10-29 Iscale, Inc. Self-scaling method for exploiting cached resources across organizational boundaries to enhance user response time and to reduce server and network load
US7664883B2 (en) * 1998-08-28 2010-02-16 Alacritech, Inc. Network interface device that fast-path processes solicited session layer read commands
US6567377B1 (en) * 1999-03-18 2003-05-20 3Com Corporation High performance load balancing of outbound internet protocol traffic over multiple network interface cards
US7549056B2 (en) 1999-03-19 2009-06-16 Broadcom Corporation System and method for processing and protecting content
US6742045B1 (en) * 1999-07-02 2004-05-25 Cisco Technology, Inc. Handling packet fragments in a distributed network service environment
US6622185B1 (en) * 1999-09-14 2003-09-16 Innovative Gaming Corporation Of America System and method for providing a real-time programmable interface to a general-purpose non-real-time computing system
US7032226B1 (en) * 2000-06-30 2006-04-18 Mips Technologies, Inc. Methods and apparatus for managing a buffer of events in the background
US7058064B2 (en) * 2000-02-08 2006-06-06 Mips Technologies, Inc. Queueing system for processors in packet routing operations
US7502876B1 (en) 2000-06-23 2009-03-10 Mips Technologies, Inc. Background memory manager that determines if data structures fits in memory with memory state transactions map
US7165257B2 (en) * 2000-02-08 2007-01-16 Mips Technologies, Inc. Context selection and activation mechanism for activating one of a group of inactive contexts in a processor core for servicing interrupts
US7139901B2 (en) 2000-02-08 2006-11-21 Mips Technologies, Inc. Extended instruction set for packet processing applications
US7058065B2 (en) 2000-02-08 2006-06-06 Mips Tech Inc Method and apparatus for preventing undesirable packet download with pending read/write operations in data packet processing
US7076630B2 (en) * 2000-02-08 2006-07-11 Mips Tech Inc Method and apparatus for allocating and de-allocating consecutive blocks of memory in background memo management
US20010052053A1 (en) * 2000-02-08 2001-12-13 Mario Nemirovsky Stream processing unit for a multi-streaming processor
US7155516B2 (en) * 2000-02-08 2006-12-26 Mips Technologies, Inc. Method and apparatus for overflowing data packets to a software-controlled memory when they do not fit into a hardware-controlled memory
US7065096B2 (en) * 2000-06-23 2006-06-20 Mips Technologies, Inc. Method for allocating memory space for limited packet head and/or tail growth
US7042887B2 (en) 2000-02-08 2006-05-09 Mips Technologies, Inc. Method and apparatus for non-speculative pre-fetch operation in data packet processing
US7649901B2 (en) * 2000-02-08 2010-01-19 Mips Technologies, Inc. Method and apparatus for optimizing selection of available contexts for packet processing in multi-stream packet processing
US7082552B2 (en) * 2000-02-08 2006-07-25 Mips Tech Inc Functional validation of a packet management unit
US7100155B1 (en) * 2000-03-10 2006-08-29 Intel Corporation Software set-value profiling and code reuse
US8300534B2 (en) * 2000-05-24 2012-10-30 Alcatel Lucent Programmable packet processor with flow resolution logic
US6711165B1 (en) * 2000-06-15 2004-03-23 Advanced Micro Devices, Inc. Apparatus and method for storing min terms in network switch port memory for access and compactness
US7003555B1 (en) * 2000-06-23 2006-02-21 Cloudshield Technologies, Inc. Apparatus and method for domain name resolution
US9444785B2 (en) 2000-06-23 2016-09-13 Cloudshield Technologies, Inc. Transparent provisioning of network access to an application
US7032031B2 (en) * 2000-06-23 2006-04-18 Cloudshield Technologies, Inc. Edge adapter apparatus and method
US8204082B2 (en) 2000-06-23 2012-06-19 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US20020069309A1 (en) * 2000-09-25 2002-06-06 Edward Balassanian Method and system for data metering
US8019901B2 (en) * 2000-09-29 2011-09-13 Alacritech, Inc. Intelligent network storage interface system
US6720074B2 (en) * 2000-10-26 2004-04-13 Inframat Corporation Insulator coated magnetic nanoparticulate composites with reduced core loss and method of manufacture thereof
US6959346B2 (en) 2000-12-22 2005-10-25 Mosaid Technologies, Inc. Method and system for packet encryption
GB2382899B (en) * 2000-12-29 2003-12-17 Zarlink Semiconductor Ltd A data queue system
US7280540B2 (en) 2001-01-09 2007-10-09 Stonesoft Oy Processing of data packets within a network element cluster
EP1356653B1 (de) * 2001-01-24 2011-07-20 Broadcom Corporation Verfahren zur verarbeitung von mehreren sicherheitsrichtlinien für eine datenpaketstruktur
US6996833B1 (en) * 2001-03-27 2006-02-07 Microsoft Corporation Protocol agnostic request response pattern
US7274706B1 (en) * 2001-04-24 2007-09-25 Syrus Ziai Methods and systems for processing network data
US6862281B1 (en) * 2001-05-10 2005-03-01 Cisco Technology, Inc. L4 lookup implementation using efficient CAM organization
US7165100B2 (en) * 2001-07-24 2007-01-16 At&T Corp. Method and apparatus for packet analysis in a network
US20030187977A1 (en) * 2001-07-24 2003-10-02 At&T Corp. System and method for monitoring a network
US7860120B1 (en) 2001-07-27 2010-12-28 Hewlett-Packard Company Network interface supporting of virtual paths for quality of service with dynamic buffer allocation
TW576061B (en) * 2001-08-13 2004-02-11 Via Tech Inc Device and method for load balancing of packet switching
US6885916B2 (en) * 2001-08-31 2005-04-26 Motorola, Inc. Data packet for a vehicle active network
US7251246B2 (en) 2001-09-14 2007-07-31 Snowshore Networks, Inc. Selective packet processing in a packet based media processor for latency reduction
US8325716B2 (en) * 2001-10-22 2012-12-04 Broadcom Corporation Data path optimization algorithm
US7088719B2 (en) * 2001-12-21 2006-08-08 Agere Systems Inc. Processor with packet processing order maintenance based on packet flow identifiers
US20030121835A1 (en) * 2001-12-31 2003-07-03 Peter Quartararo Apparatus for and method of sieving biocompatible adsorbent beaded polymers
US6957281B2 (en) * 2002-01-15 2005-10-18 Intel Corporation Ingress processing optimization via traffic classification and grouping
US7290267B2 (en) * 2002-01-23 2007-10-30 International Business Machines Corporation Multi-protocol object distribution
US7644188B2 (en) * 2002-02-25 2010-01-05 Intel Corporation Distributing tasks in data communications
US6972978B1 (en) 2002-03-15 2005-12-06 Integrated Device Technology, Inc. Content addressable memory (CAM) devices with block select and pipelined virtual sector look-up control and methods of operating same
US6867991B1 (en) 2003-07-03 2005-03-15 Integrated Device Technology, Inc. Content addressable memory devices with virtual partitioning and methods of operating the same
US7424496B1 (en) * 2002-03-20 2008-09-09 Applied Micro Circuits Corporation Asymmetric coherency protection
JP3808394B2 (ja) * 2002-04-02 2006-08-09 松下電器産業株式会社 ストリームデータ処理装置、ストリームデータ処理方法、プログラム、及び、媒体
US7496689B2 (en) * 2002-04-22 2009-02-24 Alacritech, Inc. TCP/IP offload device
US7543087B2 (en) * 2002-04-22 2009-06-02 Alacritech, Inc. Freeing transmit memory on a network interface device prior to receiving an acknowledgement that transmit data has been received by a remote device
US7339943B1 (en) 2002-05-10 2008-03-04 Altera Corporation Apparatus and method for queuing flow management between input, intermediate and output queues
US7606248B1 (en) 2002-05-10 2009-10-20 Altera Corporation Method and apparatus for using multiple network processors to achieve higher performance networking applications
US7320037B1 (en) 2002-05-10 2008-01-15 Altera Corporation Method and apparatus for packet segmentation, enqueuing and queue servicing for multiple network processor architecture
US7277437B1 (en) * 2002-05-20 2007-10-02 Altera Corporation Packet classification method
US7336669B1 (en) 2002-05-20 2008-02-26 Altera Corporation Mechanism for distributing statistics across multiple elements
US7593334B1 (en) 2002-05-20 2009-09-22 Altera Corporation Method of policing network traffic
US20040003022A1 (en) * 2002-06-27 2004-01-01 International Business Machines Corporation Method and system for using modulo arithmetic to distribute processing over multiple processors
US7724740B1 (en) 2002-08-27 2010-05-25 3Com Corporation Computer system and network interface supporting class of service queues
US7894480B1 (en) 2002-08-27 2011-02-22 Hewlett-Packard Company Computer system and network interface with hardware based rule checking for embedded firewall
US7567509B2 (en) * 2002-09-13 2009-07-28 Dialogic Corporation Methods and systems for jitter minimization in streaming media
US7337241B2 (en) * 2002-09-27 2008-02-26 Alacritech, Inc. Fast-path apparatus for receiving data corresponding to a TCP connection
US8176298B2 (en) * 2002-10-08 2012-05-08 Netlogic Microsystems, Inc. Multi-core multi-threaded processing systems with instruction reordering in an in-order pipeline
US20050033889A1 (en) * 2002-10-08 2005-02-10 Hass David T. Advanced processor with interrupt delivery mechanism for multi-threaded multi-CPU system on a chip
US7334086B2 (en) 2002-10-08 2008-02-19 Rmi Corporation Advanced processor with system on a chip interconnect technology
US7346757B2 (en) 2002-10-08 2008-03-18 Rmi Corporation Advanced processor translation lookaside buffer management in a multithreaded system
US7961723B2 (en) * 2002-10-08 2011-06-14 Netlogic Microsystems, Inc. Advanced processor with mechanism for enforcing ordering between information sent on two independent networks
US7627721B2 (en) 2002-10-08 2009-12-01 Rmi Corporation Advanced processor with cache coherency
US8015567B2 (en) * 2002-10-08 2011-09-06 Netlogic Microsystems, Inc. Advanced processor with mechanism for packet distribution at high line rate
US8478811B2 (en) * 2002-10-08 2013-07-02 Netlogic Microsystems, Inc. Advanced processor with credit based scheme for optimal packet flow in a multi-processor system on a chip
US9088474B2 (en) * 2002-10-08 2015-07-21 Broadcom Corporation Advanced processor with interfacing messaging network to a CPU
US8037224B2 (en) 2002-10-08 2011-10-11 Netlogic Microsystems, Inc. Delegating network processor operations to star topology serial bus interfaces
US7984268B2 (en) * 2002-10-08 2011-07-19 Netlogic Microsystems, Inc. Advanced processor scheduling in a multithreaded system
US7924828B2 (en) * 2002-10-08 2011-04-12 Netlogic Microsystems, Inc. Advanced processor with mechanism for fast packet queuing operations
US20040088262A1 (en) * 2002-11-06 2004-05-06 Alacritech, Inc. Enabling an enhanced function of an electronic device
US7400581B2 (en) * 2003-03-03 2008-07-15 Sun Microsystems, Inc. Load-balancing utilizing one or more threads of execution for implementing a protocol stack
US7706363B1 (en) * 2003-06-11 2010-04-27 Radlan Computer Communications, Ltd Method and apparatus for managing packets in a packet switched network
FR2857539B1 (fr) * 2003-07-11 2005-09-30 Cit Alcatel Description de contenu de paquets dans un reseau de communication par paquets
US8117392B2 (en) * 2003-10-22 2012-02-14 Intel Corporation Method and apparatus for efficient ordered stores over an interconnection network
US8423643B2 (en) * 2003-11-19 2013-04-16 International Business Machines Corporation Autonomic assignment of communication buffers by aggregating system profiles
US6996070B2 (en) * 2003-12-05 2006-02-07 Alacritech, Inc. TCP/IP offload device with reduced sequential processing
US7185147B2 (en) * 2003-12-12 2007-02-27 Intel Corporation Striping across multiple cache lines to prevent false sharing
US7391776B2 (en) * 2003-12-16 2008-06-24 Intel Corporation Microengine to network processing engine interworking for network processors
US7433364B2 (en) * 2003-12-24 2008-10-07 Intel Corporation Method for optimizing queuing performance
US7698412B2 (en) * 2003-12-31 2010-04-13 Alcatel Lucent Parallel data link layer controllers in a network switching device
US7783769B2 (en) * 2004-03-31 2010-08-24 Intel Corporation Accelerated TCP (Transport Control Protocol) stack processing
US20050286526A1 (en) * 2004-06-25 2005-12-29 Sood Sanjeev H Optimized algorithm for stream re-assembly
US7461173B2 (en) * 2004-06-30 2008-12-02 Intel Corporation Distributing timers across processors
US20060004933A1 (en) * 2004-06-30 2006-01-05 Sujoy Sen Network interface controller signaling of connection event
US20060031474A1 (en) * 2004-07-19 2006-02-09 Linden Cornett Maintaining reachability measures
US20060075142A1 (en) * 2004-09-29 2006-04-06 Linden Cornett Storing packet headers
US7512684B2 (en) * 2004-09-30 2009-03-31 Intel Corporation Flow based packet processing
US7620046B2 (en) 2004-09-30 2009-11-17 Intel Corporation Dynamically assigning packet flows
US8248939B1 (en) 2004-10-08 2012-08-21 Alacritech, Inc. Transferring control of TCP connections between hierarchy of processing mechanisms
US7680053B1 (en) 2004-10-29 2010-03-16 Marvell International Ltd. Inter-device flow control
US7620071B2 (en) * 2004-11-16 2009-11-17 Intel Corporation Packet coalescing
US20060126640A1 (en) * 2004-12-14 2006-06-15 Sood Sanjeev H High performance Transmission Control Protocol (TCP) SYN queue implementation
US7765405B2 (en) * 2005-02-25 2010-07-27 Microsoft Corporation Receive side scaling with cryptographically secure hashing
US7873048B1 (en) * 2005-12-02 2011-01-18 Marvell International Ltd. Flexible port rate limiting
US7738500B1 (en) 2005-12-14 2010-06-15 Alacritech, Inc. TCP timestamp synchronization for network connections that are offloaded to network interface devices
JP2007206955A (ja) * 2006-02-01 2007-08-16 Sony Corp 情報処理装置および方法、プログラム、並びに記録媒体
US8661160B2 (en) * 2006-08-30 2014-02-25 Intel Corporation Bidirectional receive side scaling
US7602789B2 (en) * 2006-10-23 2009-10-13 Hewlett-Packard Development Company, L.P. Low overhead method to detect new connection rate for network traffic
US8045456B1 (en) 2006-11-27 2011-10-25 Marvell International Ltd. Hierarchical port-based rate limiting
US9106606B1 (en) 2007-02-05 2015-08-11 F5 Networks, Inc. Method, intermediate device and computer program code for maintaining persistency
US8320249B2 (en) * 2007-03-07 2012-11-27 Broadcom Corporation Method and system for controlling network access on a per-flow basis
JP5045472B2 (ja) * 2008-02-07 2012-10-10 富士通株式会社 メール管理装置、メール管理方法およびメール管理プログラム
US9596324B2 (en) * 2008-02-08 2017-03-14 Broadcom Corporation System and method for parsing and allocating a plurality of packets to processor core threads
US8539513B1 (en) 2008-04-01 2013-09-17 Alacritech, Inc. Accelerating data transfer in a virtual computer system with tightly coupled TCP connections
US8014282B2 (en) * 2008-06-26 2011-09-06 Intel Corporation Hashing packet contents to determine a processor
US8341286B1 (en) 2008-07-31 2012-12-25 Alacritech, Inc. TCP offload send optimization
US9306793B1 (en) 2008-10-22 2016-04-05 Alacritech, Inc. TCP offload device that batches session layer headers to reduce interrupts as well as CPU copies
US8769067B2 (en) * 2009-06-22 2014-07-01 Citrix Systems, Inc. Systems and methods for statistics exchange between cores for load balancing
US8843651B2 (en) * 2009-06-30 2014-09-23 Oracle America, Inc. Software aware throttle based flow control
US9450804B2 (en) * 2009-09-03 2016-09-20 At&T Intellectual Property I, L.P. Anycast aware transport for content distribution networks
US8819161B1 (en) 2010-01-18 2014-08-26 Marvell International Ltd. Auto-syntonization and time-of-day synchronization for master-slave physical layer devices
DE102010028225A1 (de) * 2010-04-27 2011-10-27 Robert Bosch Gmbh Verfahren zur Bereitstellung einer Kommunikation für mindestens ein Gerät
US9032089B2 (en) * 2011-03-09 2015-05-12 Juniper Networks, Inc. Methods and apparatus for path selection within a network based on flow duration
US8990422B1 (en) * 2011-06-21 2015-03-24 Netlogic Microsystems, Inc. TCP segmentation offload (TSO) using a hybrid approach of manipulating memory pointers and actual packet data
US9137199B2 (en) 2012-02-27 2015-09-15 Microsoft Technology Licensing, Llc Stateful NAT64 function in a distributed architecture
WO2014038582A1 (ja) * 2012-09-04 2014-03-13 日本電気株式会社 パケット振分装置、パケット振分方法、およびパケット振分プログラム
US9047417B2 (en) 2012-10-29 2015-06-02 Intel Corporation NUMA aware network interface
US9391903B2 (en) * 2013-07-15 2016-07-12 Calix, Inc. Methods and apparatuses for distributed packet flow control
US9680760B2 (en) * 2013-07-16 2017-06-13 Cisco Technology, Inc. Adaptive marking for WRED with intra-flow packet priorities in network queues
US9319293B2 (en) 2013-07-31 2016-04-19 Calix, Inc. Methods and apparatuses for network flow analysis and control
US10684973B2 (en) 2013-08-30 2020-06-16 Intel Corporation NUMA node peripheral switch
US9240938B2 (en) 2013-09-23 2016-01-19 Calix, Inc. Distributed system and method for flow identification in an access network
CN103560923B (zh) * 2013-11-20 2016-08-17 烽火通信科技股份有限公司 分组传送网的网络故障快速定位方法
JP2016149698A (ja) * 2015-02-13 2016-08-18 富士通株式会社 パケット通信装置およびパケット受信処理方法
JP6773458B2 (ja) 2016-06-08 2020-10-21 日本電気通信システム株式会社 パケット処理装置、パケット処理方法、およびプログラム
US10089339B2 (en) * 2016-07-18 2018-10-02 Arm Limited Datagram reassembly
US10454965B1 (en) * 2017-04-17 2019-10-22 Symantec Corporation Detecting network packet injection
US11082540B2 (en) * 2018-11-05 2021-08-03 Cisco Technology, Inc. Network operations including protocol processing of a packet updating an operations data field of a different protocol
US11531908B2 (en) * 2019-03-12 2022-12-20 Ebay Inc. Enhancement of machine learning-based anomaly detection using knowledge graphs
US11307791B2 (en) * 2019-05-24 2022-04-19 Texas Instruments Incorporated Quick clearing of registers

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5128926A (en) 1990-03-21 1992-07-07 Digital Equipment Corporation Updating link state information in networks
FR2686755A1 (fr) 1992-01-28 1993-07-30 Electricite De France Procede de chiffrement de messages transmis entre reseaux interconnectes, appareil de chiffrement et dispositif de communication de donnees chiffrees mettant en óoeuvre un tel procede.
GB2268372B (en) 1992-06-11 1995-11-01 Roke Manor Research Improvements in or relating to data transmission systems
DE69324204T2 (de) 1992-10-22 1999-12-23 Cabletron Systems Inc Aufsuchen von Adressen bei Paketübertragung mittels Hashing und eines inhaltsadressierten Speichers
US5684954A (en) 1993-03-20 1997-11-04 International Business Machine Corp. Method and apparatus for providing connection identifier by concatenating CAM's addresses at which containing matched protocol information extracted from multiple protocol header
WO1995014269A1 (en) 1993-11-19 1995-05-26 The Trustees Of The University Of Pennsylvania A high-performance host interface for networks carrying connectionless traffic
US5758089A (en) 1995-11-02 1998-05-26 Sun Microsystems, Inc. Method and apparatus for burst transferring ATM packet header and data to a host computer system
US5778180A (en) 1995-11-06 1998-07-07 Sun Microsystems, Inc. Mechanism for reducing data copying overhead in protected memory operating systems
US5793954A (en) 1995-12-20 1998-08-11 Nb Networks System and method for general purpose network analysis
US5920705A (en) 1996-01-31 1999-07-06 Nokia Ip, Inc. Method and apparatus for dynamically shifting between routing and switching packets in a transmission network
US5778414A (en) 1996-06-13 1998-07-07 Racal-Datacom, Inc. Performance enhancing memory interleaver for data frame processing
US5870394A (en) 1996-07-23 1999-02-09 Northern Telecom Limited Method and apparatus for reassembly of data packets into messages in an asynchronous transfer mode communications system
US5748905A (en) 1996-08-30 1998-05-05 Fujitsu Network Communications, Inc. Frame classification using classification keys
US6011803A (en) 1997-01-13 2000-01-04 Lucent Technologies Inc. Distributed-protocol server
US6470389B1 (en) 1997-03-14 2002-10-22 Lucent Technologies Inc. Hosting a network service on a cluster of servers using a single-address image
US6088356A (en) 1997-06-30 2000-07-11 Sun Microsystems, Inc. System and method for a multi-layer network element
US6094435A (en) 1997-06-30 2000-07-25 Sun Microsystems, Inc. System and method for a quality of service in a multi-layer network element
US6128666A (en) 1997-06-30 2000-10-03 Sun Microsystems, Inc. Distributed VLAN mechanism for packet field replacement in a multi-layered switched network element using a control field/signal for indicating modification of a packet with a database search engine
US6115378A (en) 1997-06-30 2000-09-05 Sun Microsystems, Inc. Multi-layer distributed network element
US6014699A (en) * 1997-08-29 2000-01-11 International Business Machines Corporation Internet protocol assists for high performance LAN connections

Also Published As

Publication number Publication date
US6389468B1 (en) 2002-05-14
DE60016574D1 (de) 2005-01-13
WO2000052881A2 (en) 2000-09-08
WO2000052881A3 (en) 2000-12-14
EP1157522B1 (de) 2004-12-08
AU4005000A (en) 2000-09-21
JP2002538724A (ja) 2002-11-12
EP1157522A2 (de) 2001-11-28

Similar Documents

Publication Publication Date Title
DE60016574T2 (de) Verfahren und vorrichtung zur belastungsverteilung uphänging von datenflussen
DE60031516T2 (de) Verfahren und gerät für die verwaltung eines netzflusses in einer hochleistungs-netzschnittstelle
DE60019401T2 (de) Verfahren und gerät für die dynamische und stapelweise verarbeitung von paketen mit einer netzwerkschnittstelle
DE60021358T2 (de) Eine hoch-leistungs-netzschnittstelle
EP1159814B1 (de) Dynamisches parsing in einer hochleistungs netzwerkschnittstelle
EP1157518B1 (de) Verfahren und gerät für datenwiederversammlung mit einer hohe-leistung-netzschnittstelle
CN110383777B (zh) 端口扩展器设备的灵活处理器
DE60213509T2 (de) Verfahren und Vorrichtung zur Verbesserung der Verfügbarkeit von Wegeleitsystemen mit mehrwege-Kostengleichheit
DE60120790T2 (de) Methode und gerät zum durchsuchen von tabellen in hoher geschwindigkeit
DE60009884T2 (de) Verfahren und vorrichtung zur identifizierung und klassifizierung von netzwerkverkehr in einer hochleistungs netzwerkschnittstelle
DE60038538T2 (de) Vermittlungseinrichtung und Vermittlungsverfahren
DE112011103561T5 (de) Netzwerkprozessor und Verfahren zum Beschleunigen der Datenpaket-Syntaxanalyse
CN102427446B (zh) 分组合并
DE112016005924T5 (de) Beschleunigte Netzwerkpaketverarbeitung
DE60015186T2 (de) Verfahren und system für rahmen- und protokollklassifikation
JP2002538725A (ja) 初期のランダムなパケット廃棄方法および装置
DE602004009574T2 (de) System und verfahren zum modifizieren von daten, die von einer quelle zu einem bestimmungsort übermittelt werden
DE102021203777A1 (de) Flexibles lenken

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee