DE112004002544B4 - Verfahren, System und Programm zur Identifizierung von Datenüberlauf - Google Patents

Verfahren, System und Programm zur Identifizierung von Datenüberlauf Download PDF

Info

Publication number
DE112004002544B4
DE112004002544B4 DE112004002544T DE112004002544T DE112004002544B4 DE 112004002544 B4 DE112004002544 B4 DE 112004002544B4 DE 112004002544 T DE112004002544 T DE 112004002544T DE 112004002544 T DE112004002544 T DE 112004002544T DE 112004002544 B4 DE112004002544 B4 DE 112004002544B4
Authority
DE
Germany
Prior art keywords
packet
received
data
truncated
packets
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
DE112004002544T
Other languages
English (en)
Other versions
DE112004002544T5 (de
Inventor
Patrick Portland Connor
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.)
Intel Corp
Original Assignee
Intel Corp
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 Intel Corp filed Critical Intel Corp
Publication of DE112004002544T5 publication Critical patent/DE112004002544T5/de
Application granted granted Critical
Publication of DE112004002544B4 publication Critical patent/DE112004002544B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/29Flow control; Congestion control using a combination of thresholds
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1835Buffer management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166IP fragmentation; TCP segmentation

Abstract

Verfahren, das folgendes umfaßt:
– Empfangen eines Datenpakets von einem Netzwerk;
– Bestimmen der verbleibenden Speicherkapazität von einem Empfangspuffer;
– Speichern des empfangenen Datenpakets im Empfangspuffer, wenn die verbleibende Speicherkapazität vom Empfangspuffer über einem ersten Schwellenwert ist;
– Trunkieren des empfangenen Datenpakets, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist; und
– Speichern des trunkierten Datenpakets im Empfangspuffer, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist.

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft ein Verfahren, System und Programm zur Identifizierung von Datenüberlauf bei der Datenübertragung.
  • 2. Beschreibung des Standes der Technik
  • In einer Netzwerkumgebung empfangt ein Netzwerkadapter auf einem Hostcomputer, wie eine Ethernet-Steuereinheit, eine Faserkanal-Steuereinheit, usw., Eingabe/Ausgabe (E/A)-Aufrufe oder -Antworten auf E/A-Aufrufe, die vom Host initiiert wurden. Das Hostcomputer-Betriebssystem umfaßt häufig einen Gerätetreiber, um mit der Netzwerkadapterhardware zu kommunizieren, um E/A-Aufrufe zu verwalten, um über ein Netzwerk zu übertragen. Datenpakete, die am Netzwerkadapter empfangen werden, sind häufig in einem verfügbaren zugewiesenen Paketpuffer im Hostspeicher gespeichert. Der Hostcomputer kann ein Protokoll implementieren, um die Pakete zu verarbeiten, die durch den Netzwerkadapter empfangen werden, die im Paketpuffer gespeichert sind, und auf jedwede E/A-Befehle oder Daten, die im Paket eingebettet sind, zugreifen.
  • Der Computer kann zum Beispiel das Übertragungskontrollprotokoll (TCP) und das Internet-Protokoll (IP) implementieren, um die Payloaddaten in den TCP/IP-Paketen, die am Netzwerkadapter empfangen werden, zu dekodieren und extrahieren. Das IP spezifiziert das Format der Pakete, die auch als Datagramme bezeichnet werden, und das Adressierschema. Das TCP ist ein Higher-Niveau-Protokoll, das eine virtuelle Verbindung zwischen einem Ziel und einer Quelle erstellt. Ein anderes Protokoll, direkter Speicherfernzugriff (RDMA), erstellt eine Higher-Niveau-Verbindung und erlaubt, unter anderen Operationen, die direkte Datenvermittlung an einem spezifizierten Speicherort am Ziel.
  • Ein Gerätetreiber, eine Anwendung oder ein Betriebssystem können bedeutende Hostprozessor-Ressourcen verwenden, um Netzwerkübertragungsaufrufe zum Netzwerkadapter zu bearbeiten. Eine Technik, um die Belastung am Hostprozessor zu reduzieren, umfaßt die Verwendung einer TCP/IP-Offload-Engines (TOE), in dem die TCP/IP-Protokoll-bezogenen Operationen in der Netzwerkadapterhardware implementiert sind, im Gegensatz zum Gerätetreiber oder zu anderer Hostsoftware, wodurch der Hostprozessor davor bewahrt wird, die TCP/IP-Protokoll-bezogenen Operationen ausführen zu müssen. Die Transportprotokolloperationen umfassen das Verpacken von Daten in ein TCP/IP-Paket mit einer Prüfsumme und anderen Daten und das Entpacken eines TCP/IP-Pakets, das über das Netzwerk empfangen ist, um auf die Payload oder Daten zuzugreifen.
  • Eine andere Transportprotokolloperation, die durch eine TOE ausgeführt wird, kann das Bestätigen des Empfangs von Paketen umfassen. Pakete können verloren gehen oder fallen gelassen werden, und dies aufgrund von mehreren Faktoren, inklusive Netzwerküberlast und überbelastete Ressourcen des Empfängers. Wenn der Paketsender nicht eine Bestätigung darüber empfangt, daß ein Paket richtig empfangen wurde, kann der Paketsender das Paket zurücksenden. Wenn zum Beispiel der Paketsender im TCP/IP-Protokoll nicht eine Bestätigung innerhalb einer bestimmten Zeitspanne empfangt, wird angenommen, daß das Paket verloren gegangen ist und das unbestätigte Paket wird zurückgeschickt.
  • Da das Abwarten auf den Ablauf der Bestätigungszeitgeber den Gesamtfluß der Daten durch ein Netzwerk verlangsamen kann, werden häufig zusätzliche Techniken verwendet, um fehlende Pakete zu erkennen und den Rückversand dieser fehlenden Pakete zu beschleunigen. Im TCP/IP-Protokoll, wie in der RFC (Request for Comment, Bitte um Kommentare) 2581 – „TCP-Überlastkontrolle” dargelegt wird, wird zum Beispiel ein Fast Retransmit-Verfahren (Schnell-Neuübertragungs-Verfahren) beschrieben, das Nutzen aus der Tatsache zieht, daß im TCP/IP-Protokoll, Pakete in einer Nachricht, die von einem Sender zu einem Empfänger über ein Netzwerk gesendet werden sollen, typischerweise sequentiell geordnet sind und jedes Paket dieser Nachricht einer einzigen Folgenummer zugewiesen ist.
  • Wenn der Empfänger ein Paket empfängt, das nicht erwartet wird, wie ein Paket außerhalb der sequentiellen Reihenfolge, wird die Folgenummer des letzten korrekt empfangenen Pakets dieser Verbindung zwischen dem Sender und dem Empfänger durch den Empfänger rückbestätigt. Dies signalisiert dem Sender, daß entweder die Paketreihenfolge geändert wurde oder daß ein Paket verloren gegangen ist. Wenn die Pakete zwar alle richtig, jedoch ein wenig außerhalb der sequentiellen Reihenfolge empfangen wurden, kann der Empfänger ohne weiteres die Pakete wieder in die korrekte sequentielle Reihenfolge ordnen. Wenn der Empfänger jedoch mehrere male (typischerweise 3 mal) dieselbe Folgenummer bestätigt, dann weiß der Sender gemäß dem Protokoll, daß eine einfache Neuordnung unwahrscheinlich ist und daß das Paket, das der letzten bestätigten Folgenummer folgt, wahrscheinlich verloren gegangen ist. Der Sender kann dann das verloren gegangene Paket oder die verloren gegangenen Pakete zurücksenden. Es können zahlreiche Techniken verwendet werden, um die Pakete effizient zurückzusenden, wie der Schnell-Datenrettungs-Algorithmus (Fast Recovery alogrithm), wie er in der vorgenannten RFC 2581 – „TCP Überlastkontrolle” beschrieben wird.
  • Die zahlreichen Rückbestätigungen der Folgenummer des letzten korrekt empfangenen Pakets der Verbindung, in Übereinstimmung mit dem Fast-Retransmit-Algorithmus, wirken wie eine negative Bestätigung, indem sie anzeigen, daß das nachfolgende Paket der Sequenz verloren gegangen ist oder fallen gelassen wurde. Ein Vorteil des Fast-Retransmit-Algorithmus besteht darin, daß der Sender häufig über ein fehlendes Paket informiert werden kann, ohne den Ablauf der Bestätigungs-Zeitgeber abzuwarten. Demgemäß kann die Totzeit an einer Verbindung häufig reduziert werden.
  • WO 03/053009 A1 offenbart ein Verfahren zum Steuern eines Datenflusses in einem Ethernet. Für einen Empfangspuffer wird u. a. ein oberer Schwellenwert gesetzt, wobei ein eingehendes Datenpaket in dem Empfangspuffer nur gespeichert wird, wenn die verbleibende Speicherkapazität vom Empfangspuffer über dem Schwellenwert liegt.
  • US 6,122,279 A offenbart eine Netzwerksteuerlogik, welche für den Eingangspuffer eingehende Daten verwirft, sofern ein vorbestimmter Schwellenwert für die Belegung von Speicherzellen überschritten wird, um die verbleibende Kapazität des Puffers für eingehende Daten höherer Priorität zu reservieren.
  • US 5,790,522 A offenbart einen Schalter für einen Netzwerkknoten zum Schalten von Datenpaketen unterschiedlicher Prioritäten aus Eingangsleitungen zu Ausgangsleitungen. Dabei werden ein oder mehrere Schwellenwerte für die zur Verfügung stehende Speicherkapazität zum Durchleiten der Daten berücksichtigt.
  • Nichtsdestoweniger besteht im Stand der Technik fortbestehender Bedarf daran, die Effizienz der Datenübertragung zu verbessern.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Im Anschluß wird Bezug auf die Zeichnungen genommen, in denen gleiche Bezugszahlen entsprechende Teile in den Zeichnungen darstellen. Es zeigen:
  • 1 eine Rechnerumgebung, in der Aspekte der Erfindung implementiert sind;
  • 2 eine Paketarchitektur vom Stand der Technik, die bei Ausführungsformen der Erfindung verwendet wird;
  • 3 Operationen, die ausgeführt werden, um einen Empfang von Daten durch einen Netzwerkadapter gemäß Ausführungsformen der Erfindung zu verwalten;
  • 4 einen Puffer, der vom Netzwerkadapter gemäß Ausführungsformen der Erfindung verwendet wird;
  • 5 Schwellenwerte, die in Operationen verwendet werden, die ausgeführt werden, um einen Empfang von Daten durch den Netzwerkadapter gemäß Ausführungsformen der Erfindung zu verwalten;
  • 6 einen Abschnitt eines Puffers, der vom Netzwerkadapter gemäß Ausführungsformen der Erfindung verwendet wird; und
  • 7 Operationen, die ausgeführt werden, um die Verarbeitung von empfangenen Daten gemäß Ausführungsformen der Erfindung zu verwalten; und
  • 8 eine Architektur, die mit den beschrieben Ausführungsformen verwendet werden kann.
  • AUSFÜHRLICHE BESCHREIBUNG DER VORZUGSWEISEN AUSFÜHRUNGEN
  • In der nachstehenden Beschreibung wird Bezug auf die beiliegenden Zeichnungen genommen, die Bestandteil der Beschreibung sind und die verschiedene Ausführungsformen der vorliegenden Erfindung veranschaulichen. Es versteht sich, daß andere Ausführungsformen verwendet werden können und strukturelle und operationelle Änderungen vorgenommen werden können, ohne vom Rahmen der vorliegenden Erfindung abzuweichen.
  • 1 veranschaulicht eine Rechnerumgebung, in der Aspekte der Erfindung implementiert werden können. Ein Computer 2 umfaßt eine oder mehrere zentrale Rechnereinheiten (CPU) 4 (es ist nur eine dargestellt), einen flüchtigen Speicher 6, einen nicht-flüchtigen Speicher 8, ein Betriebssystem 10 und einen Netzwerkadapter 12. Ein Anwendungsprogramm 14 wird ferner im Speicher 6 ausgeführt und ist zum Übertragen und Empfangen von Paketen von einem entfernten Computer geeignet. Der Computer 2 kann jedwede Rechnereinheit umfassen, die auf dem Fachgebiet bekannt ist, wie ein Großrechner, ein Server, ein Personal-Computer, eine Workstation, ein Laptop, ein Handheld-Computer, eine Fernsprecheinheit, eine Netzwerkvorrichtung, eine Virtualisierungseinheit, eine Speichersteuereinheit, eine Netzwerksteuereinheit, usw. Jede CPU 4 und jedes Betriebssystem 10, die auf dem Fachgebiet bekannt sind, können verwendet werden. Programme und Daten im Speicher 6 können in den Speicher 8 als Teil der Speichermanagementoperationen ausgelagert werden.
  • Der Netzwerkadapter 12 umfaßt eine Netzwerkprotokollschicht 16, um Netzwerkpakete über ein Netzwerk 18 zu Ferngeräten zu senden und von Ferngeräten zu empfangen. Das Netzwerk 18 kann ein Local Area Network (LAN), das Internet, ein Wide Area Network (WAN), ein Storage Area Network (SAN), usw., umfassen. Die Ausführungsformen können konfiguriert sein, um Daten über ein kabelloses Netzwerk oder eine kabellose Verbindung, wie ein kabelloses LAN, Bluetooth, usw., zu übertragen. In einigen Ausführungsformen können der Netzwerkadapter 12 und zahlreiche Protokollschichten das Ethernet-Protokoll implementieren, einschließlich Ethernet-Protokoll über nicht abgeschirmtes Twisted-Pair-Kabel (verdrilltes Kabelpaar), Token-Ring-Protokoll, Faserkanal-Protokoll, Infiniband, Serial Advanced Technologie Attachment (SATA), Parallel-SCSI, Serial-Attached-SCSI-Kabel, usw., oder jedes andere Netzwerkkommunikationsprotokoll, das auf dem Fachgebiet bekannt ist.
  • Ein Gerätetreiber 20 fuhrt im Speicher 6 aus und umfaßt Netzwerkadapter 12- spezifische Befehle, um mit dem Netzwerkadapter 12 zu kommunizieren und um zwischen dem Betriebssystem 10, den Anwendungen 14 und dem Netzwerkadapter 12 eine Schnittstelle zu bilden. In einigen Implementierungen umfaßt eine Netzwerksteuereinheit des Netzwerkadapters 12 einem Paketpuffer 21 und eine Transport-Offload-Engine 22 sowie die Netzwerkprotokollschicht 16. Die Netzwerksteuereinheit kann andere Protokollschichten kontrollieren, einschließlich einer Datenlinkschicht und einer physischen Kommunikationsschicht, die Hardware, wie einen Daten-Sender-Empfänger, umfaßt. In einer Ausführungsform, die das Ethernet-Protokoll einsetzt, könnte der Daten-Sender-Empfänger ein Ethernet-Sender-Empfänger sein.
  • In der veranschaulichten Ausführungsform 12 umfaßt die Netzwerksteuereinheit des Adapters eine Transportprotokollschicht sowie eine Netzwerkprotokollschicht und andere Protokollschichten.
  • Die Netzwerksteuereinheit des Adapters 12 implementiert zum Beispiel eine TCP/IP-Offload-Engine (TOE) 22, in der Transportschicht- und Sicherheitsoperationen in der Offload-Engine 22 ausgeführt werden, die in der Netzwerkadapter 12-Hardware oder -Firmware implementiert ist, im Gegensatz zum Gerätetreiber 20.
  • Die Netzwerkschicht 16 bearbeitet Netzwerkkommunikation und speichert empfangene TCP/IP-Pakete im Paketpuffer 21 bevor sie von der Transport-Offload-Engine 22 verarbeitet werden. Der Adapter 12 umfaßt ferner eine Datenlinkschicht, die zwei Unterschichten umfaßt: die Medienzugriffskontroll(MAC)-Schicht und die Logische Linkkontroll(LLC)-Schicht. Die MAC-Unterschicht kontrolliert, wie ein Computer auf dem Netzwerk Zugriff zu den Daten erlangt und auch die Erlaubnis, sie zu übertragen. Die LLC-Schicht kontrolliert Framesynchronisierung, Flußkontrolle und Fehlerprüfung. In der veranschaulichten Ausführungsform, befindet sich der Paketpuffer 21 im MAC-Abschnitt der Netzwerksteuereinheit. Es ist ersichtlich, daß sich der Puffer 21 in anderen Abschnitten des Netzwerkadapters 12 sowie in anderen Abschnitten des Computers 2 befinden kann.
  • Die Transport-Offload-Engine 22 bildet eine Schnittstelle mit dem Gerätetreiber 20 oder dem Betriebssystem 10 oder der Anwendung 14 und führt zahlreiche Transportprotokollschichtoperationen an den empfangenen Paketen aus. Die Operationen umfassen das Senden zum Paketsender von Bestätigungen des Empfangs von Paketen in Übereinstimmung mit dem entsprechenden Protokoll. Zusätzlich kann die Engine 22 den Inhalt von Nachrichten verarbeiten, die in den Paketen enthalten sind, die am Netzwerkadapter 12 empfangen werden, die in einer Transportschicht eingewickelt sind, wie TCP und/oder IP, iSCSI (Internet Small Computer System Interface), Faserkanal-SCSI, Parallel-SCSI-Transport oder jedes andere Transportschichtprotokoll, das auf dem Fachgebiet bekannt ist. Die Transport-Offload-Engine 22 kann die Payload vom empfangenen TCP/IP-Paket entpacken und die Daten zum Gerätetreiber 20 übertragen, um zurück zum Treiber 20, Betriebssystem 10 oder der Anwendung 14 zu gehen.
  • In einigen Implementierungen können die Netzwerksteuereinheit und der Netzwerkadapter 12 ferner eine RDMA-Protokollschicht, sowie die Transportprotokollschicht umfassen. Der Netzwerkadapter 12 kann zum Beispiel eine RDMA-Offload-Engine implementieren, in der RDMA-Schichtoperationen in den Offload-Engines der RDMA-Protokollschicht ausgeführt werden, die in der Netzwerkadapter 12-Hardware implementiert sind, im Gegensatz zum Gerätetreiber 20, Betriebssystem 10 oder den Anwendungen 14. In zahlreichen Ausführungsformen können die RMDA Offload-Engines Bestandteil der TOE 22 oder eine separate Engine sein.
  • Folgendermaßen kann eine Anwendung 14, die Nachrichten über eine RDMA-Verbindung überträgt, die Nachricht über den Gerätetreiber 20 und die RDMA-Protokollschicht des Netzwerkadapters 12 übertragen. Die Daten der Nachricht können zur Transportprotokollschicht von der Engine 22 gesendet werden, um in ein TCP/IP-Paket verpackt zu werden. Die Transportprotokollschicht kann ferner das Paket verschlüsseln, bevor es über das Netzwerk 18 durch die Netzwerkprotokollschicht 16 übertragen wird.
  • Der Speicher 6 umfaßt ferner Dateiobjekte 24, die auch als Socketobjekte bezeichnet werden können, die Daten über eine Verbindung zu einem Ferncomputer über das Netzwerk 18 umfassen. Die Anwendung 14 verwendet die Daten im Dateiobjekt 24, um die Verbindung zu identifizieren. Die Anwendung 14 würde das Dateiobjekt 24 verwenden, um mit einem Fernsystem zu kommunizieren. Das Dateiobjekt 24 kann folgendes angeben: den lokalen Port oder Socket, der verwendet wird, um mit einem Fernsystem zu kommunizieren, eine lokale Netzwerk(IP)-Adresse vom Computer 2, in dem die Anwendung 14 ausführ, wie viele Daten durch die Anwendung 14 gesendet und empfangen wurden, und den fernen Port und die Netzwerkadresse, z. B. IP-Adresse, mit der die Anwendung 14 kommuniziert. Kontextdaten 26 umfassen eine Datenstruktur mit Daten zum Gerätetreiber 20, Betriebssystem 10 oder der Anwendung 14, die aufrecht erhalten werden, um Aufrufe zu verwalten, die zum Netzwerkadapter 12 gesendet werden, wie nachstehend noch beschrieben wird.
  • 2 veranschaulicht ein Format eines Netzwerkpaketes 50, das am Netzwerkadapter 12 empfangen ist. Das Netzwerkpaket 50 ist in einem Format implementiert, das vom Netzwerkprotokoll 14, wie dem IP-Protokoll, verstanden wird. Das Netzwerkpaket 150 kann ein Ethernet-Frame umfassen, das zusätzliche Ethernet-Komponenten umfassen würde, wie einen Header und Fehlerprüfcode (nicht dargestellt).
  • Es ist ein Transportpaket 52 im Netzwerkpaket 50 enthalten. Das Transportpaket 52 ist dazu geeignet, durch die Engine 22 in Übereinstimmung mit einem Transportprotokoll, wie dem TCP-Protokoll, verarbeitet zu werden. Das Paket 52 kann durch andere Schichten in Übereinstimmung mit anderen Protokollen verarbeitet werden, einschließlich Internet Small Computer System Interface (iSCSI)-Protokoll, Faserkanal-SCSI, Parallel-SCSI-Transport, usw. Das Transportpaket 52 umfaßt Payloaddaten 54 sowie andere Transportschichtfelder, wie ein Header und ein Fehlerprüfcode. Im Header von jedem Paket ist die Paketfolgenummer enthalten. Die Payloaddaten 52 umfassen den darunterliegenden Inhalt, der übertragen wird, z. B. Befehle, Zustände und/oder Daten. Der Treiber 20, das Betriebssystem 10 oder eine Anwendung 14 können eine Schicht umfassen, wie SCSI-Treiber oder Schicht, um den Inhalt der Payloaddaten 54 zu verarbeiten und auf jedwede darin befindlichen Befehle, Zustände und/oder Daten zuzugreifen.
  • Pakete können bei der Übertragung von einem Sender zu einem Empfänger von einer bestimmten Verbindung verloren gehen, und dies aufgrund von Netzwerküberlast oder Ausrüstungsversagen an einem Punkt oder an mehreren Punkten im Netzwerkpfad vom Sender zum Empfänger. Außerdem können Pakete durch den Empfänger fallen gelassen werden, wenn eine Ressource oder mehrere Ressourcen des Empfängers derart überlastet ist bzw. sind, daß alle eingehenden Pakete nicht richtig verarbeitet werden können. Wie bereits erwähnt, sorgen die Datenneuübertragungs-Algorithmen wie der Fast-Retransmit-Algorithmus für den Empfänger dafür, eine Duplikatbestätigung vom letzten richtig empfangenen Sequenz-Paket zu senden, wenn ein Nicht-Sequenz- oder anderweitig unerwartetes Paket empfangen wird. Diese Duplikatbestätigung signalisiert dem Sender, daß das nachfolgende Paket verloren gegangen oder fallen gelassen sein kann und neu geschickt werden sollte, wenn eine ausreichende Anzahl an Duplikatbestätigungen empfangen wird.
  • Hier ist es jedoch ersichtlich, daß Umstände auftreten können, in denen der Verlust von Paketen nicht die Daten-Neuübertragungs-Algorithmen, wie den Fast-Retransmit-Algorithmus, auslöst. Demzufolge kann der Sender dazu veranlaßt werden, den Ablauf eines Bestätigungszeitgebers abzuwarten, bevor die verloren gegangenen Pakete zurückgeschickt werden.
  • Insbesondere können Ereignisse dazu führen, daß nicht nur ein einziges Paket verloren geht oder fallen gelassen wird, sondern daß häufig ganze Paketfolgen, die ein Nachrichtensegment bilden, gleichzeitig verloren gehen können. Wenn einer Netzwerksteuereinheit zum Beispiel eine notwendige Ressource, wie Busbandbreite oder ein Hostpuffer, fehlt, werden wahrscheinlich alle empfangenen Pakete fallen gelassen. Wenn überdies eine ausreichend große Anzahl an Paketen fallen gelassen ist, kann der Datensender dazu veranlaßt werden, das Senden jedweder zusätzlichen Pakete zum Empfänger einzustellen, bis der Bestätigungszeitgeber vom Sender abgelaufen ist. Wenn der Sender am Senden zusätzlicher Pakete gehindert ist, kann der Empfänger am Senden von Duplikatbestätigungen gehindert werden, die den Fast-Retransmit-Algorithmus auslösen.
  • Zahlreiche Protokolle, wie das TCP/IP-Protokoll, setzen zum Beispiel zahlreiche Techniken ein, und dies mit dem Ziel, die Netzwerküberlast zu reduzieren und für eine bessere Verwendung der Netzwerkressourcen zu sorgen. Eine derartige Technik besteht darin, dem Datensender ein „Sendefenster”, wie das „TCP-Sendefenster” aufzuerlegen, das die Menge der Daten begrenzt, die der Sender senden kann, ohne eine Bestätigung des richtigen Empfangs von vorher gesendeten Daten zu empfangen. Sobald der Datensender die Grenze, die durch ein TCP-Sendefenster auferlegt ist, erreicht hat, kann es folgendermaßen dem Sender nicht durch das Verbindungsprotokoll erlaubt werden, zusätzliche Daten zu senden, bis er zusätzliche Bestätigungen vom Verbindungsempfänger empfangt.
  • Wenn ein Datensender eine derartige Grenze erreicht hat und die unbestätigten Daten, die vorher durch den Datensender gesendet wurden, verloren gegangen sind oder fallen gelassen wurden, ist es hier ersichtlich, daß der Sender nicht irgendwelche weiteren Bestätigungen vom Empfänger empfangen kann, da die gesendeten Pakete verloren gegangen sind oder fallen gelassen wurden und der Sender am Senden irgendwelcher zusätzlicher Pakete zum Empfänger gehindert wurde. Wenn der Empfänger nicht irgendwelche zusätzliche Pakete nach dem Verlust der Folge von Paketen empfängt, wird dem entgegengesetzt der Empfänger nicht ausgelöst, in Übereinstimmung mit dem Fast-Retransmit-Algorithmus, um irgendwelche Duplikatbestätigungen zu senden, um dem Datensender zu signalisieren, daß Pakete fallen gelassen wurden. Durch den fehlenden Empfang der Duplikatbestätigungen vom Empfänger kann der Datensender nicht bis zum Ablauf des Bestätigungszeitgebers über den Verlust der Pakete informiert werden. Demzufolge kann die Aufgabe des Fast-Retransmit-Algorithmus in derartigen Situationen nicht erreicht werden.
  • 3 zeigt Operationen eines Netzwerkadapters, wie der Netzwerkadapter 12, der einem Datensender deutlich angeben kann, welche Pakete fallen gelassen wurden, und dies selbst dort, wo relativ große Anzahlen von Paketen gleichzeitig fallen gelassen werden. In dieser Ausführungsform empfängt die Netzwerkprotokollschicht 16 (Block 100) ein Paket vom Netzwerk 18 und bestimmt (Block 102), ob der Puffer 21 über einen bestimmten „Füllstand”-Schwellenwert hinaus gefüllt ist. Der Paketpuffer 21 ist schematisch in der 4 dargestellt. Ein Balkendiagramm, das das Maß veranschaulicht, zu dem der Puffer 21 zu jeder bestimmten Zeit gefüllt ist, ist in der 5 veranschaulicht und ist als ein prozentualer Anteil der Gesamtkapazität vom Puffer 21 für das Speichern von Paketen, die vom Netzwerk 18 empfangen werden, dargestellt. Ein schraffierter Abschnitt 104 vom Balkendiagramm stellt den Abschnitt vom Puffer 21 dar, der mit Datenpaketen gefüllt wurde, die vom Netzwerk 16 empfangen wurden. Folgendermaßen stellt die Länge vom Abschnitt 104, wie bei 105 angegeben, das gespeicherte Datenniveau vom Puffer 21 dar. Der verbleibende Abschnitt 106 vom Balkendiagramm stellt die verbleibende Kapazität vom Puffer 21 dar, die noch nicht mit Datenpaketen vom Netzwerk gefüllt wurde.
  • Das Balkendiagramm von 5 gibt bei 108 ebenfalls einen „Füllstand-Schwellenwert” an. Im Beispiel von der 5 wurde der Puffer 21 zu einem Niveau 105 unter dem vom Füllstand-Schwellenwert 108 gefüllt. Solange das gefüllte Niveau 105 unter dem Füllstand-Schwellenwert 108 verbleibt, speichert der Netzwerkadapter 12 weiterhin (Block 110, 3) das gesamte Paket, das vom Netzwerk 18 empfangen wird, in den Puffer 21. Die 4 zeigt ein Beispiel eines vollständig gefüllten Pakets 112, das im Puffer 21 gespeichert ist.
  • Der Füllstand-Schwellenwert 108 kann verwendet werden, um eine frühe Angabe davon zu verschaffen, daß der Puffer 21 wahrscheinlich den Raum verläßt, um Datenpakete vom Netzwerk 18 zu speichern. Sobald der Puffer 21 den Speicherraum verläßt, werden wahrscheinlich alle weiteren empfangenen Datenpakete fallen gelassen. Solange die Transport-Offload-Engine 22 Datenpakete vom Puffer 21 entnehmen und verarbeiten kann mit einer Geschwindigkeit, die gleich oder schneller als die von der Netzwerkprotokollschicht 16 ist, mit der sie Datenpakete im Puffer 21 speichert, sollte das gefüllte Niveau 105 vom Puffer 21 unter dem Füllstand-Schwellenwert 108 bleiben. Wenn die Netzwerkprotokollschicht 16 jedoch Datenpakete mit einer Geschwindigkeit, die schneller ist als die, mit der die Transport-Offload-Engine 22 die Datenpakete verarbeiten kann, im Puffer 21 speichert, kann das gefüllte Niveau 105 anfangen zu steigen.
  • Die Geschwindigkeit, mit der die Transport-Offload-Engine 22 Datenpakete verarbeitet, kann niedriger als die Geschwindigkeit sein, mit der die Netzwerkprotokollschicht 16 die Datenpakete vom Netzwerk 18 speichert, und dies aufgrund von mehreren Faktoren. So kann zum Beispiel die Menge der Daten, die vom Netzwerk 18 zum Netzwerkadapter 12 gesendet werden, bedeutend zunehmen. Ebenfalls können die Ressourcen, die die Transport-Offload-Engine 22 zum Verarbeiten der Datenpakete benötigt, knapper werden. Die Bandbreite vom Bus oder von den Bussen, die verfügbar ist, um die Transport-Offload-Engine 22 mit dem Rest vom Hostspeicher 6 oder dem Datenspeicher 8 vom Hostcomputer 2 zu verbinden, kann zum Beispiel eng werden.
  • Sobald das gefüllte Niveau 105 (Block 102) den Füllstand-Schwellenwert 108 übersteigt, kann der Netzwerkadapter 12, anstatt die empfangenen Datenpakete vollständig zu speichern, in Übereinstimmung mit einer Ausführungsform, damit beginnen, das empfangene Datenpaket zu trunkieren, die trunkierten Pakete als trunkiert zu markieren und (Block 114) den verbleibenden, trunkierten Abschnitt im Puffer 21 zu speichern. Durch Trunkieren der empfangenen Datenpakete können zum Beispiel die Headerdaten einbehalten und die Payloaddaten ausgesondert werden. Demzufolge kann das trunkierte Datenpaket im Vergleich zum vollständig gefüllten Datenpaket, wie es empfangen wird, im Wesentlichen in der Größe reduziert werden. Wenn ein Paket empfangen wird, das keine Headerdaten aufweist, die nützlich für das Erzeugen von Bestätigungen sind, kann in diesem Beispiel dieses Paket eher ausgesondert als trunkiert werden.
  • Jedes zusätzliche Paket, das (Block 116) vom Netzwerk 18 empfangen wird, wird (Block 114) in trunkierter Form im Puffer 21 gespeichert, solange festgelegt ist (Block 118), daß das gefüllte Niveau 105 einen „Normalbetrieb”-Schwellenwert 120 (5) übersteigt. Wie nachstehend im Detail erklärt wird, kann das Speichern trunkierter Datenpakete anstelle von vollständig gefüllten Datenpaketen, wenn der Füllstand-Schwellenwert 108 überschritten ist, zum Beispiel die schnelle Neuübertragung von fallen gelassenen Paketen erleichtern.
  • 4 zeigt einen Abschnitt 130 (eine Vergrößerung von dem, was in der 6 dargestellt wird), in dem Paketheader 132 anstelle von vollständig gefüllten Paketen 112 gespeichert werden. In diesem Beispiel ist der Puffer 21 ein 256K-Byte-FIFO(zuerst abgelegtes wird zuerst bearbeitet)-Puffer und der Füllstand-Schwellenwert 108 kann eingestellt werden, um anzugeben, daß der Puffer 21 über einen verbleibenden FIFO-Raum von 4 K Bytes verfügt. In einigen Anwendungen können zwei vollständige Pakete 112 die verbleibenden 4 K Bytes vom FIFO-Speicher verbrauchen. In der veranschaulichten Ausführungsform kann der Umfang des Speicherraums, der durch ein Paket verbraucht wird, das zu den Headerdaten trunkiert (abgeschnitten) ist, zum Beispiel im Wesentlichen reduziert werden, wie zum Beispiel auf etwa 60 Bytes. Folgendermaßen können im verbleibenden 4 K Bytes Speicherraum viel mehr trunkierte Pakete, wie zum Beispiel etwa 68 trunkierte Pakete, im Raum gespeichert werden, den ansonsten nur zwei vollständig gefüllte Pakete einnehmen können. Diese Pakete, die ansonsten wahrscheinlich vollkommen fallen gelassen worden wären können demzufolge in einer trunkierten Form gespeichert werden, um eine frühe Neuübertragung zu erleichtern, wie nachstehend beschrieben wird.
  • In der veranschaulichten Ausführungsform ist der Normalbetrieb-Schwellenwert 120 im Wesentlichen unter dem Füllstand-Schwellenwert 108 eingestellt. Es ist ersichtlich, daß diese Schwellenwerte in Abhängigkeit von der Anwendung auf verschiedene Niveaus eingestellt werden können. Überdies kann der Füllstand-Schwellenwert 108 dem Normalbetrieb-Schwellenwert 120 gleichkommend eingestellt werden, um die Logikoperationen zu vereinfachen.
  • 7 zeigt Operationen eines Netzwerkadapters, wie der Netzwerkadapter 12, der eine Verbindungsprotokollschicht mit einer Transport-Offload-Engine 22 umfassen kann, beim Verarbeiten der Datenpakete, die durch die Netzwerkprotokollschicht 16 vom Netzwerk 18 empfangen und im Puffer 21 gespeichert wurden. Der Adapter 12 erhält (Block 150) ein Datenpaket vom Puffer 21 und bestimmt (Block 152), ob das Paket auf eine ähnliche Weise, wie diejenige, die weiter oben in Verbindung mit der 3 beschrieben wurde, als trunkiert markiert wurde. Wenn nicht, verarbeitet der Netzwerkadapter 12 (Block 154) das Datenpaket auf eine übliche Weise.
  • Wie bereits w. o. angegeben, kann diese normale Verarbeitung das Decodieren und Extrahieren von Payloaddaten in den Paketen und das Senden einer Bestätigung zum Datensender in Übereinstimmung mit dem entsprechenden Protokoll umfassen. Im Fast-Retransmit-Verfahren wird zum Beispiel, wenn das Datenpaket, das verarbeitet wird, das nächste Sequenz-Paket für eine bestimmte Verbindung ist, die Folgenummer von diesem Paket zurück zum Sender bestätigt. Wenn der Empfänger jedoch ein Paket empfängt, das nicht erwartet wird, wie ein Paket, das außerhalb der sequentiellen Reihenfolge ist, wird die Folgenummer des letzten korrekt empfangenen Pakets der Verbindung zwischen dem Sender und dem Empfänger durch den Empfänger rückbestätigt. Dies signalisiert dem Sender, daß entweder die Paketreihenfolge geändert wurde oder daß ein Paket verloren gegangen ist.
  • Die Datenpakete, die durch den Netzwerkadapter 12 während irgendeinem Intervall empfangen werden, können von mehreren verschiedenen Verbindungen zwischen dem Netzwerkadapter 12 und einem Sender oder mehreren Sendern im Netzwerk 18 stammen. Daher können die Datenpakete, die im Puffer 21 gespeichert sind, jeweils Bestandteil von einem Paketfluß oder von mehreren verschiedenen Paketflüssen zwischen dem Netzwerkadapter 12 und einem Sender oder mehreren verschiedenen Sendern sein. Beim Bestätigen eines empfangenen Pakets bestimmt der Netzwerkadapter 12 daher, zu welchem Paketfluß das empfangene Paket gehört und ob die Folgenummer des empfangenen Pakets die erwartete Folgenummer vom entsprechenden Fluß ist. Wenn es erwartet ist, wird das empfangene Paket bestätigt. Wenn es unerwartet ist, wird das letzte korrekt empfangene Paket von diesem Paketfluß zwischen dem Sender und Empfänger durch den Empfänger rückbestätigt.
  • Wenn festgelegt ist (Block 152), daß das Datenpaket trunkiert ist, kann ein Integritätstest (Block 156) am trunkierten Datenpaket ausgeführt werden. Ein derartiger Integritätstest kann zum Beispiel eine oder mehrere von TCP, IP Header-Prüfsummen und eine Ethernet-CRC (zyklische Redundanzprüfung) umfassen. Wenn das trunkierte Datenpaket den Integritätstest nicht besteht, kann das trunkierte Paket ausgesondert werden (Block 158).
  • Wenn das trunkierte Datenpaket den Integritätstest (Block 156) besteht, kann der Netzwerkadapter die Headerdaten vom trunkierten Datenpaket prüfen, um zu bestimmen, zu welchem Fluß das empfangene trunkierte Datenpaket gehört und die Folgenummer des empfangenen trunkierten Datenpakets im identifizierten Fluß. Durch Verwendung dieser Headerdaten kann der Netzwerkadapter eine Duplikatbestätigung (Block 160) vom letzten korrekt empfangenen vollständig gefüllten Paket von diesem Fluß zwischen dem Sender und dem Netzwerkadapter 12 senden.
  • Diese Verarbeitung wird fortgeführt, indem der Netzwerkadapter (Block 150) ein anderes Paket vom Puffer 21 erhält, bestimmt (Block 152), ob das Paket trunkiert wurde, das trunkierte Paket prüft (Block 156) und eine Duplikatbestätigung (Block 160) vom letzten korrekt empfangenen vollständig gefüllten Paket dieser Verbindung zwischen dem Sender und dem Netzwerkadapter 12 sendet.
  • Es ist ersichtlich, daß durch das Trunkieren der empfangenen Datenpakete, wenn sich zeigt, daß die Kapazität vom Empfangspuffer 21 kurz überschritten werden kann, die Headerdaten für eine Anzahl von Paketen bewahrt werden können, die ansonsten verloren gegangen wären, da ungenügend Raum im Empfängerpuffer 21 ist, um vollständig gefüllte Datenpakete zu speichern. Diese Headerdaten können verwendet werden, um Rückbestätigungen zu erzeugen, um ein Fast-Retransmit-Verfahren auszulösen. Diese Rückbestätigungen können folgendermaßen unter vielen Umständen nützlich sein, wie zum Beispiel, wenn der Sender am Senden zusätzlicher Datenpakete gehindert wird; da zum Beispiel das Sendefenster vom Sender erreicht wurde. Daraus ergibt sich, daß die Wahrscheinlichkeit, daß eine ausreichende Anzahl von Rückbestätigungen erzeugt werden kann, um eine schnelle Neuübertragung für einen bestimmten Fluß auszulösen, verbessert werden kann. Überdies kann durch das Trunkieren der Datenpakete, um die Paketheaderdaten primär zu speichern, eine relativ große Anzahl an trunkierten Paketen in einem relativ kleinen Raum gespeichert werden. Trunkierte Pakete können folglich erfolgreich für eine Anzahl verschiedener Datenflüsse gespeichert werden, wie als Fluß 1, Fluß 2... usw. in der 6 angegeben wird. Folgendermaßen kann ebenfalls die Wahrscheinlichkeit, daß eine ausreichende Anzahl an Rückbestätigungen erzeugt werden kann, um eine schnelle Neuübertragung für mehr als einen Fluß auszulösen, verbessert werden.
  • Zusätzliche Ausführungsdetails
  • Die beschrieben Techniken zur Verarbeitung empfangener Daten in einem Netzwerkadapter oder einer Netzwerkschnittstellenkarte können als ein Verfahren, eine Vorrichtung oder ein Herstellungsteil implementiert werden, die Standardprogrammier- und/oder – engineeringtechniken verwenden, um Software, Firmware, Hardware oder jedwede Kombination davon zu erzeugen. Der hier verwendete Begriff „Herstellungsteil” bezieht sich auf in Hardwarelogik (z. B. IC-Chip, Programmierbare Gatteranordnung (PGA), Kundenspezifische Integrierte Schaltung (ASIC), usw.) implementierten Code oder Logik oder ein computerlesbares Medium, wie Magnetspeichermedium (z. B. Festplattenlaufwerke, Disketten, Bänder, usw.), optische Speicher (CD-ROMS, optische Platten, usw.), volatile und nicht-volatile Speichergeräte (z. B. EEPROMs, ROMS, PROMs, RAMs, DRAMs, SRAMs, Firmware, programmierbare Logik, usw.). Ein Prozessor greift auf den Code im computerlesbaren Medium zu und führt ihn aus. Der Code, in dem vorzugsweise Ausführungsformen implementiert sind, kann ferner durch ein Übertragungsmedium oder von einem Dateiserver über ein Netzwerk zugänglich sein. In derartigen Fällen kann der Herstellungsteil, in dem der Code implementiert ist, ein Übertragungsmedium umfassen, wie eine Netzwerkübertragungsleitung, ein kabelloses Übertragungsmedium, durch Raum propagierende Signale, Funkwellen, Infrarotsignale, usw. Der „Herstellungsteil” kann folgendermaßen das Medium umfassen, in dem der Code eingebettet ist. Der „Herstellungsteil” kann zusätzlich eine Kombination aus Hardware- und Softwarekomponenten umfassen, in denen der Code eingebettet, verarbeitet und ausgeführt ist. Fachmännern ist es selbstverständlich ersichtlich, daß zahlreiche Änderungen an dieser Konfiguration vorgenommen werden können ohne vom Rahmen der vorliegenden Erfindung abzuweichen, und daß der Her stellungsteil jedwedes datentragende Medium, das auf dem Fachgebiet bekannt ist, umfassen kann.
  • In den beschrieben Ausführungsformen wurde die Transport-Offload-Engine beschrieben, zahlreiche Transportschichtoperationen in Übereinstimmung mit dem TCP/IP-Protokoll auszuführen. In alternativen Ausführungsformen können Daten von einem Remote-Host zum Host, die andere Protokolle verwenden, übertragen werden. Als eine solche würde eine Kommunikationsprotokoll-Offload-Engine, wie die Transport-Offload-Engine 22, einige oder alle Übertragungsoperationen ausführen, inklusive die Wiederzusammenfügung fragmentierter Daten oder die Datenpayloadextrahierung in Übereinstimmung mit einem derartigen anderen Übertragungsprotokoll.
  • In den beschrieben Ausführungsformen wurden einige Operationen als vom Gerätetreiber 20 und von der Transport-Offload-Engine 22 ausgeführt beschrieben. In alternativen Ausführungsformen können Operationen, die als vom Gerätetreiber 20 ausgeführt beschrieben werden, von der Transport-Offload-Engine 22 ausgeführt werden, und umgekehrt. In den beschrieben Implementierungen wurde die Transportprotokollschicht in die Netzwerkadapter 12-Hardware implementiert, die Logikschaltungen umfaßt, die von der zentralen Rechnereinheit oder von den zentralen Rechnereinheiten 4 vom Hostcomputer 2 getrennt sind. In alternativen Implementierungen können Abschnitte von der Transportprotokollschicht im Gerätetreiber oder im Hostspeicher 6 implementiert werden.
  • In den beschrieben Ausführungsformen wurden zahlreiche Protokollschichten und Operationen dieser Protokollschichten beschrieben. Die Operationen von jeder der zahlreichen Protokollschichten können in Hardware, Firmware, Treibern, Betriebssystemen, Anwendungen oder anderer Software implementiert werden, und dies ganz oder teilweise, alleine oder in zahlreichen Kombinationen davon.
  • In einigen Implementierungen können die Gerätetreiber- und Netzwerkadapter-Ausführungsformen in einem Computersystem mit einer Speichersteuereinheit enthalten sein, wie SCSI, Integrierte Laufwerkelektronik (IDE), Redundante Anordnung unabhängiger Festplatten (RAID), usw., Steuereinheit, die den Zugriff zu einer nicht-volatilen Speichereinheit verwaltet, wie Magnetplattenlaufwerk, Bandmedium, optische Platte, usw. Derartige Computersysteme umfassen häufig Desktop, Workstation, Server, Großrechner, Laptop, Handheld- Computer, usw. In alternativen Implementierungen können die Netzwerkadapter-Ausführungsformen in einem System enthalten sein, das nicht eine Speichersteuereinheit umfaßt, wie einige Hubs und Switche.
  • In einigen Implementierungen kann der Netzwerkadapter konfiguriert sein, um Daten über ein Kabel zu übertragen, das mit einem Port am Netzwerkadapter verbunden ist. Alternativ können die Netzwerkadapter-Ausführungsformen konfiguriert sein, um Daten über ein kabelloses Netzwerk oder eine kabellose Verbindung, wie kabelloses LAN, Bluetooth, usw., zu übertragen.
  • Die veranschaulichte Logik der 3 und 7 veranschaulicht einige Ereignisse, die in einer bestimmten Reihenfolge auftreten. In alternativen Ausführungsformen können einige Operationen in einer anderen Reihenfolge ausgeführt, geändert oder entfernt werden. Überdies können Schritte zur vorstehend beschriebenen Logik hinzugefügt werden und weiterhin den beschriebenen Ausführungsformen entsprechen. Ferner können die hiermit beschriebenen Operationen sequentiell auftreten oder einige Operationen können parallel verarbeitet werden. Ferner können Operationen durch eine einzige Rechnereinheit oder durch verteilte Rechnereinheiten ausgeführt werden.
  • In einigen Implementierungen wurde der Puffer 21, der vom Netzwerkadapter 12 verwendet wird, beschrieben, vom Hostspeicher 6 getrennt zu sein und sich physisch im Adapter 12 zu befinden. In anderen Ausführungsformen kann der Puffer 21 ein Teil vom Hostspeicher 6 oder ein Teil von anderen Steuereinheitsschaltungen auf einer getrennten Karte oder auf einer Hauptplatine sein.
  • 8 veranschaulicht eine Implementierung einer Computerarchitektur 300 der Netzwerkkomponenten, wie die Hosts und Speichereinheiten, die in der 1 dargestellt sind. Die Architektur 300 kann einen Prozessor 302 (z. B. einen Mikroprozessor), einen Speicher 304 (z. B. eine volatile Speichereinheit) und einen Speicher 306 (z. B. einen nicht-volatilen Speicher, wie Magnetplattenlaufwerke, CD-Laufwerke, ein Bandlaufwerk, usw.) umfassen. Der Speicher 306 kann eine interne Speichereinheit oder einen dazugehörigen oder netzwerkzugänglichen Speicher umfassen.
  • Programme im Speicher 306 sind im Speicher 304 geladen und werden durch den Prozessor 302 auf eine im Fachgebiet bekannte Weise ausgeführt. Die Architektur umfaßt ferner eine Netzwerkkarte 308, um die Kommunikation mit einem Netzwerk, wie Ethernet, Fiber-Channel-Arbitrated-Loop, usw., zu ermöglichen. Ferner kann die Architektur in einigen Ausführungsformen eine Video-Steuereinheit 309 umfassen, um Daten über einen Anzeigemonitor herauszugeben, wo die Video-Steuereinheit 309 in einer Videokarte implementiert werden kann oder in Integrierte-Schaltungskomponenten integriert werden kann, die auf der Hauptplatine montiert sind. Wie bereits dargelegt wurde, können einige der Netzwerkgeräte mehrfache Netzwerkkarten aufweisen. Eine Eingabeeinheit 310 wird verwendet, um dem Prozessor 302 die Benutzereingabe zu verschaffen, und kann ein Tastenfeld, eine Maus, einen Pen-Stylus, ein Mikrofon, einen berührungsempfindlichen Bildschirm oder jedweden anderen Betätigungs- oder Eingabemechanismus, der auf dem Fachgebiet bekannt ist, umfassen. Eine Ausgabeeinheit 312 ist dazu geeignet, Daten, die vom Prozessor 302 übertragen werden, herauszugeben, oder andere Komponenten, wie ein Anzeigemonitor, ein Drucker, ein Speicher, usw.
  • Der Netzwerkadapter 12, 308 kann an einer Netzwerkkarte implementiert werden, wie eine Karte zur Verbindung peripherer Komponenten (Peripheral Component Interconnect, PCI) oder jede andere E/A-Karte, oder an Integrierte-Schaltungskomponenten, die auf der Hauptplatine montiert sind.
  • Die vorstehende Beschreibung zahlreicher Ausführungsformen der Erfindung dient der Veranschaulichung und der Beschreibung. Sie erhebt keinen Anspruch auf Vollständigkeit oder dient auch nicht dazu, die Erfindung auf die genaue offenbarte Form einzuschränken. Es sind zahlreiche Änderungen und Abweichungen angesichts der vorstehenden Lehre möglich. Es gilt, daß der Umfang der Erfindung nicht durch diese ausführliche Beschreibung eingeschränkt ist, sondern durch die beiliegenden Patentansprüche. Die vorstehenden Spezifizierungen, Beispiele und Daten verschaffen eine vollständige Beschreibung der Herstellung und der Verwendung der erfindungsgemäßen Zusammensetzung. Da zahlreiche Ausführungsformen der Erfindung realisiert werden können, ohne vom Geist und Umfang der Erfindung abzuweichen, liegt die Erfindung in den beiliegenden Patentansprüchen.

Claims (38)

  1. Verfahren, das folgendes umfaßt: – Empfangen eines Datenpakets von einem Netzwerk; – Bestimmen der verbleibenden Speicherkapazität von einem Empfangspuffer; – Speichern des empfangenen Datenpakets im Empfangspuffer, wenn die verbleibende Speicherkapazität vom Empfangspuffer über einem ersten Schwellenwert ist; – Trunkieren des empfangenen Datenpakets, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist; und – Speichern des trunkierten Datenpakets im Empfangspuffer, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist.
  2. Verfahren nach Anspruch 1, wobei das trunkierte Datenpaket die Headerdaten des empfangenen Pakets nach dem Trunkieren umfaßt.
  3. Verfahren nach Anspruch 1, wobei das Trunkieren das Aussondern der Payloaddaten des empfangenen Pakets umfaßt.
  4. Verfahren nach Anspruch 1, das ferner das Markieren des trunkierten Pakets als trunkiert umfaßt.
  5. Verfahren nach Anspruch 1, wobei Pakete von einem Sender empfangen werden und wobei das Verfahren ferner das Informieren des Senders darüber umfaßt, welche vom Sender gesendeten Pakete trunkiert wurden.
  6. Verfahren nach Anspruch 3, wobei Pakete von einem Sender empfangen werden, der Datenpakete in einem sequentiell geordneten Fluß von Datenpaketen sendet, wobei das Verfahren ferner folgendes umfaßt: das Prüfen der im Empfangspuffer gespeicherten Datenpakete und das Senden einer Bestätigung für jedes nicht trunkierte Paket, das in sequentieller Reihenfolge vom Sender empfangen wird und das Senden einer Duplikatbestätigung des letzten nicht trunkierten Pakets, das in sequentieller Reihenfolge empfangen wird.
  7. Verfahren nach Anspruch 3, wobei Pakete von mehreren Sendern in mehreren Flüssen empfangen werden, in denen jeder Sender Datenpakete in einem sequentiell geordneten Fluß von Datenpaketen sendet, wobei das Verfahren ferner folgendes umfaßt: das Prüfen der im Empfangspuffer gespeicherten Datenpakete und das Senden einer Bestätigung für jedes nicht trunkierte Paket, das in sequentieller Reihenfolge vom Sender des zugehörigen Flusses empfangen wird und das Senden einer Duplikatbestätigung des letzten nicht trunkierten Pakets, das in sequentieller Reihenfolge vom Sender des zugehörigen Flusses empfangen wird.
  8. Verfahren nach Anspruch 6, wobei das Prüfen folgendes umfaßt: das Ausführen eines Integritätschecks an jedem trunkierten Paket und das Unterlassen des Sendens einer Duplikatbestätigung, wenn das trunkierte Paket den Integritätstest nicht besteht.
  9. Verfahren nach Anspruch 8, wobei der Integritätscheck das Ausführen eines Prüfsummentests umfaßt.
  10. Artikel, der ein Speichermedium umfaßt, wobei das Speichermedium maschinenlesbare Befehle umfaßt, die darauf gespeichert sind, um ein Datenpaket von einem Netzwerk zu empfangen; die verbleibende Speicherkapazität von einem Empfangspuffer zu bestimmen; das empfangene Datenpaket im Empfangspuffer zu speichern, wenn die verbleibende Speicherkapazität vom Empfangspuffer über einem ersten Schwellenwert ist; das empfangene Datenpaket zu trunkieren, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist; und das trunkierte Datenpaket im Empfangspuffer zu speichern, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist.
  11. Artikel nach Anspruch 10, wobei das trunkierte Datenpaket die Headerdaten des empfangenen Pakets nach dem Trunkieren umfaßt.
  12. Artikel nach Anspruch 10, wobei die maschinenlesbaren Befehle, die zu trunkieren sind, maschinenlesbare Befehle umfassen, die auf dem Speichermedium gespeichert sind, um die Payloaddaten des empfangenen Pakets auszusondern.
  13. Artikel nach Anspruch 10, wobei das Speichermedium ferner maschinenlesbare Befehle umfaßt, die darauf gespeichert sind, um das trunkierte Paket als trunkiert zu markieren.
  14. Artikel nach Anspruch 10, wobei Pakete von einem Sender empfangen werden, und wobei das Speichermedium ferner maschinenlesbare Befehle umfaßt, die darauf gespeichert sind, um die Sender darüber zu informieren, welche vom Sender gesendeten Pakete trunkiert wurden.
  15. Artikel nach Anspruch 12, wobei Pakete von einem Sender empfangen werden, der Datenpakete in einem sequentiell geordneten Fluß von Datenpaketen sendet, und wobei das Speichermedium ferner folgendes umfaßt: maschinenlesbare Befehle, die darauf gespeichert sind, um die im Empfangspuffer gespeicherten Datenpakete zu prüfen und eine Bestätigung für jedes nicht trunkierte Paket, das in sequentieller Reihenfolge vom Sender empfangen wird, zu senden und eine Duplikatbestätigung des letzten nicht trunkierten Pakets, das in sequentieller Reihenfolge empfangen wird, zu senden.
  16. Artikel nach Anspruch 12, wobei Pakete von mehreren Sendern in mehreren Flüssen empfangen werden, in denen jeder Sender Datenpakete in einem sequentiell geordneten Fluß von Datenpaketen sendet, und wobei das Speichermedium ferner maschinenlesbare Befehle umfaßt, die darauf gespeichert sind, um die im Empfangspuffer gespeicherten Datenpakete zu prüfen und eine Bestätigung für jedes nicht trunkierte Paket, das in sequentieller Reihenfolge vom Sender des zugehörigen Flusses empfangen wird, zu senden und eine Duplikatbestätigung des letzten nicht trunkierten Pakets, das in sequentieller Reihenfolge vom Sender des zugehörigen Flusses empfangen wird, zu senden.
  17. Artikel nach Anspruch 15, wobei die maschinenlesbaren Befehle zum Prüfen maschinenlesbare Befehle enthalten, die auf dem Speichermedium gespeichert sind, zum Ausführen eines Integritätschecks an jedem Paket und zum Unterlassen des Sendens einer Duplikatbestätigung, wenn das Paket den Integritätstest nicht besteht, umfassen.
  18. Artikel nach Anspruch 17, wobei die maschinenlesbaren Befehle zum Ausführen eines Integritätschecks maschinenlesbare Befehle, die auf dem Speichermedium gespeichert sind, zum Ausführen eines Prüfsummentests umfassen.
  19. System zur Verwendung mit einem Netzwerk, das folgendes umfaßt: – zumindest einen Speicher, der ein Betriebssystem und einen Empfangspuffer umfaßt; – einen Prozessor, der mit dem Speicher verbunden ist; – eine Netzwerksteuereinheit; – einen Datenspeicher; – eine Datenspeicher-Steuereinheit zum Verwalten vom Eingabe/Ausgabe(E/A)-Zugriff zum Datenspeicher; und – einen Gerätetreiber, der durch den Prozessor im Speicher ausführbar ist, wobei zumindest eines vom Betriebssystem, Gerätetreiber und der Netzwerksteuereinheit für folgendes eingerichtet ist: – ein Datenpaket von einem Netzwerk zu empfangen; – die verbleibende Speicherkapazität von einem Empfangspuffer zu bestimmen; – das empfangene Datenpaket im Empfangspuffer zu speichern, wenn die verbleibende Speicherkapazität vom Empfangspuffer über einem ersten Schwellenwert ist; – das empfangene Datenpaket zu trunkieren, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist; und – das trunkierte Datenpaket im Empfangspuffer zu speichern, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist.
  20. System nach Anspruch 19, wobei ein empfangenes Paket Headerdaten aufweist und das trunkierte Datenpaket die Headerdaten des empfangenen Pakets nach dem Trunkieren umfaßt.
  21. System nach Anspruch 19, wobei ein empfangenes Paket Payloaddaten aufweist und das Trunkieren das Aussondern der Payloaddaten des empfangenen Pakets umfaßt.
  22. System nach Anspruch 19, wobei zumindest eines vom Betriebssystem, Gerätetreiber und der Netzwerksteuereinheit dazu geeignet ist, das trunkierte Paket als trunkiert zu markieren.
  23. System nach Anspruch 19, wobei Pakete von einem Sender empfangen werden, und zumindest eines vom Betriebssystem, Gerätetreiber und der Netzwerksteuereinheit dazu geeignet ist, den Sender darüber zu informieren, welche vom Sender gesendeten Pakete trunkiert wurden.
  24. System nach Anspruch 21, wobei Pakete von einem Sender empfangen werden, der Datenpakete in einem sequentiell geordneten Fluß von Datenpaketen sendet, und zumindest eines vom Betriebssystem, Gerätetreiber und der Netzwerksteuereinheit dazu eingerichtet ist, die im Empfangspuffer gespeicherten Datenpakete zu prüfen und eine Bestätigung für jedes nicht trunkierte Paket, das in sequentieller Reihenfolge vom Sender empfangen wird, zu senden und eine Duplikatbestätigung des letzten nicht trunkierten Pakets, das in sequentieller Reihenfolge empfangen wird, zu senden.
  25. System nach Anspruch 21, wobei Pakete von mehreren Sendern in mehreren Flüssen empfangen werden, in denen jeder Sender Datenpakete in einem sequentiell geordneten Fluß von Datenpaketen sendet, und zumindest eines vom Betriebssystem, Gerätetreiber und der Netzwerksteuereinheit dazu eingerichtet ist, die im Empfangspuffer gespeicherten Datenpakete zu prüfen und eine Bestätigung für jedes nicht trunkierte Paket, das in sequentieller Reihenfolge vom Sender des zugehörigen Flusses empfangen wird, zu senden und eine Duplikatbestätigung des letzten nicht trunkierten Pakets, das in sequentieller Reihenfolge vom Sender des zugehörigen Flusses empfangen wird, zu senden.
  26. System nach Anspruch 24, wobei das Prüfen das Ausführen eines Integritätschecks an jedem trunkierten Paket und das Unterlassen des Sendens einer Duplikatbestätigung, wenn das trunkierte Paket den Integritätstest nicht besteht, umfaßt.
  27. System nach Anspruch 26, wobei der Integritätscheck das Ausführen eines Prüfsummentests umfaßt.
  28. System nach Anspruch 19 zur Verwendung mit einem nicht abgeschirmten verdrillten Kabelpaar, wobei das System ferner einen Ethernet-Daten-Sender-Empfänger umfaßt, das mit der Netzwerksteuereinheit und dem Kabel verbunden ist und dazu geeignet ist, Daten über das Kabel zu übertragen und zu empfangen.
  29. System nach Anspruch 19, das ferner eine Video-Steuereinheit, die mit dem Prozessor verbunden ist, umfaßt.
  30. Einrichtung zur Verwendung mit einem Netzwerk und einem Empfangspuffer, die folgendes umfaßt: ein Mittel, um ein Datenpaket von einem Netzwerk zu empfangen; ein Mittel zum Bestimmen der verbleibenden Speicherkapazität von einem Empfangspuffer; ein Mittel zum Speichern des empfangenen Datenpakets im Empfangspuffer, wenn die verbleibende Speicherkapazität vom Empfangspuffer über einem ersten Schwellenwert ist; ein Mittel zum Trunkieren des empfangenen Datenpakets, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist; und ein Mittel zum Speichern des trunkierten Datenpakets im Empfangspuffer, wenn die verbleibende Speicherkapazität vom Empfangspuffer unter dem ersten Schwellenwert ist.
  31. Einrichtung nach Anspruch 30, wobei ein empfangenes Paket Headerdaten aufweist und das trunkierte Datenpaket die Headerdaten des empfangenen Pakets nach dem Trunkieren umfaßt.
  32. Einrichtung nach Anspruch 30, wobei ein empfangenes Paket Payloaddaten aufweist und das Mittel zum Trunkieren ein Mittel zum Aussondern der Payloaddaten des empfangenen Pakets umfaßt.
  33. Einrichtung nach Anspruch 30, die ferner ein Mittel umfaßt, um das trunkierte Paket als trunkiert zu markieren.
  34. Einrichtung nach Anspruch 30, wobei Pakete von einem Sender empfangen werden, wobei die Einheit ferner ein Mittel umfaßt, um den Sender darüber zu informieren, welche vom Sender gesendeten Pakete trunkiert wurden.
  35. Einrichtung nach Anspruch 32, wobei Pakete von einem Sender empfangen werden, der Datenpakete in einem sequentiell geordneten Fluß von Datenpaketen sendet, wobei die Einheit ferner ein Mittel zum Prüfen der im Empfangspuffer gespeicherten Datenpakete und zum Senden einer Bestätigung für jedes nicht trunkierte Paket, das in sequentieller Reihenfolge vom Sender empfangen wird und zum Senden einer Duplikatbestätigung des letzten nicht trunkierten Pakets, das in sequentieller Reihenfolge empfangen wird, umfaßt.
  36. Einrichtung nach Anspruch 32, wobei Pakete von mehreren Sendern in mehreren Flüssen empfangen werden, in denen jeder Sender Datenpakete in einem sequentiell geordneten Fluß von Datenpaketen sendet, wobei die Einheit ferner ein Mittel zum Prüfen der im Empfangspuffer gespeicherten Datenpakete und zum Senden einer Bestätigung für jedes nicht trunkierte Paket, das in sequentieller Reihenfolge vom Sender des zugehörigen Flusses empfangen wird und zum Senden einer Duplikatbestätigung des letzten nicht trunkierten Pakets, das in sequentieller Reihenfolge vom Sender des zugehörigen Flusses empfangen wird, umfaßt.
  37. Einrichtung nach Anspruch 35, wobei das Mittel zum Prüfen ein Mittel zum Ausführen eines Integritätschecks an jedem trunkierten Paket und ein Mittel zum Unterlassen des Sendens einer Duplikatbestätigung, wenn das trunkierte Paket den Integritätstest nicht besteht, umfaßt.
  38. Einrichtung nach Anspruch 37, wobei ein Mittel zum Ausführen eines Integritätschecks ein Mittel zum Ausführen eines Prüfsummentests umfaßt.
DE112004002544T 2003-12-24 2004-12-20 Verfahren, System und Programm zur Identifizierung von Datenüberlauf Expired - Fee Related DE112004002544B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/745,774 US7773620B2 (en) 2003-12-24 2003-12-24 Method, system, and program for overrun identification
US10/745,774 2003-12-24
PCT/US2004/043037 WO2005067258A1 (en) 2003-12-24 2004-12-20 Method, system, and program for overrun identification

Publications (2)

Publication Number Publication Date
DE112004002544T5 DE112004002544T5 (de) 2006-11-09
DE112004002544B4 true DE112004002544B4 (de) 2010-07-01

Family

ID=34710628

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112004002544T Expired - Fee Related DE112004002544B4 (de) 2003-12-24 2004-12-20 Verfahren, System und Programm zur Identifizierung von Datenüberlauf

Country Status (5)

Country Link
US (1) US7773620B2 (de)
DE (1) DE112004002544B4 (de)
GB (1) GB2422994B (de)
TW (1) TWI295130B (de)
WO (1) WO2005067258A1 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003103294A1 (en) * 2002-06-04 2003-12-11 Koninklijke Philips Electronics N.V. Watermark detection
US7929442B2 (en) * 2004-06-30 2011-04-19 Intel Corporation Method, system, and program for managing congestion in a network controller
US7461183B2 (en) * 2004-08-03 2008-12-02 Lsi Corporation Method of processing a context for execution
CN100338915C (zh) * 2005-08-19 2007-09-19 杭州华三通信技术有限公司 报文镜像方法及具有报文镜像功能的网络设备
US8311059B2 (en) * 2005-09-07 2012-11-13 Emulex Design & Manufacturing Corporation Receive coalescing and automatic acknowledge in network interface controller
US7593393B2 (en) * 2006-01-20 2009-09-22 Sbc Knowledge Ventures, L.P. Voice over internet protocol multi-routing with packet interleaving
JP4983435B2 (ja) * 2007-06-27 2012-07-25 富士通株式会社 パケット通信品質計測装置及び方法
US9160539B1 (en) * 2011-09-30 2015-10-13 Emc Corporation Methods and apparatus for secure, stealthy and reliable transmission of alert messages from a security alerting system
US10320549B2 (en) * 2014-04-11 2019-06-11 Qualcomm Incorporated Methods and apparatus for sending fast negative acknowledgements (NACKs)
US9870339B2 (en) 2015-06-26 2018-01-16 Intel Corporation Hardware processors and methods for tightly-coupled heterogeneous computing
US10291682B1 (en) * 2016-09-22 2019-05-14 Juniper Networks, Inc. Efficient transmission control protocol (TCP) reassembly for HTTP/2 streams
EP3422658B1 (de) * 2017-06-30 2020-08-05 Intel IP Corporation Kommunikationsvorrichtung und kommunikationsverfahren zur abfrage von kommunikationsressourcen
CN112235829A (zh) * 2020-10-15 2021-01-15 展讯通信(上海)有限公司 数据传输方法、设备和存储介质
CN112688885B (zh) * 2020-12-23 2022-05-24 新华三大数据技术有限公司 一种报文处理方法及装置
CN112953967A (zh) * 2021-03-30 2021-06-11 扬州万方电子技术有限责任公司 网络协议卸载装置和数据传输系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5790522A (en) * 1994-10-07 1998-08-04 International Business Machines Corporation Method and system for performing traffic congestion control in a data communication network
US6122279A (en) * 1995-10-02 2000-09-19 Virata Limited Asynchronous transfer mode switch
WO2003053009A1 (fr) * 2001-12-19 2003-06-26 Huawei Technologies Co., Ltd. Procede de commande du flux des donnees ethernet dans un reseau de transmission hierarchique de donnees synchrone

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5428460A (en) * 1993-06-04 1995-06-27 Brother Kogyo Kabushiki Kaisha Reduced rate facsimile machine
CA2216533C (en) * 1995-12-19 2002-05-07 Motorola, Inc. Method and apparatus for rate governing communications
US6490251B2 (en) * 1997-04-14 2002-12-03 Nortel Networks Limited Method and apparatus for communicating congestion information among different protocol layers between networks
US5931915A (en) 1997-05-13 1999-08-03 International Business Machines Corporation Method for processing early arrival messages within a multinode asynchronous data communications system
US6862622B2 (en) * 1998-07-10 2005-03-01 Van Drebbel Mariner Llc Transmission control protocol/internet protocol (TCP/IP) packet-centric wireless point to multi-point (PTMP) transmission system architecture
US7007099B1 (en) * 1999-05-03 2006-02-28 Lucent Technologies Inc. High speed multi-port serial-to-PCI bus interface
US6700871B1 (en) * 1999-05-04 2004-03-02 3Com Corporation Increased throughput across data network interface by dropping redundant packets
FR2805112B1 (fr) 2000-02-11 2002-04-26 Mitsubishi Electric Inf Tech Procede et unite de controle de flux d'une connexion tcp sur un reseau a debit controle
US7136897B1 (en) * 2000-08-22 2006-11-14 International Business Machines Corporation Minimizing electronic mailbox congestion
US20020194332A1 (en) 2001-06-13 2002-12-19 Connor Patrick L. Method and apparatus to manage resources for a multi-threaded device driver
US7307996B2 (en) * 2002-07-30 2007-12-11 Brocade Communications Systems, Inc. Infiniband router having an internal subnet architecture
US7212538B2 (en) * 2003-09-05 2007-05-01 Qualcomm Incorporated Differential ack processing buffer manager and method therefor

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5790522A (en) * 1994-10-07 1998-08-04 International Business Machines Corporation Method and system for performing traffic congestion control in a data communication network
US6122279A (en) * 1995-10-02 2000-09-19 Virata Limited Asynchronous transfer mode switch
WO2003053009A1 (fr) * 2001-12-19 2003-06-26 Huawei Technologies Co., Ltd. Procede de commande du flux des donnees ethernet dans un reseau de transmission hierarchique de donnees synchrone
US20040160972A1 (en) * 2001-12-19 2004-08-19 Yong Tang Method for controlling ethernet data flow on a synchronous digital hierarchy transmission network

Also Published As

Publication number Publication date
WO2005067258A1 (en) 2005-07-21
US7773620B2 (en) 2010-08-10
GB0606755D0 (en) 2006-05-10
GB2422994B (en) 2007-11-07
US20050147110A1 (en) 2005-07-07
TWI295130B (en) 2008-03-21
TW200529618A (en) 2005-09-01
DE112004002544T5 (de) 2006-11-09
GB2422994A (en) 2006-08-09

Similar Documents

Publication Publication Date Title
DE112004002544B4 (de) Verfahren, System und Programm zur Identifizierung von Datenüberlauf
DE112020002498T5 (de) System und verfahren zur erleichterung einer effizienten paketweiterleitung in einer netzwerkschnittstellensteuerung (nic)
DE60317837T2 (de) Verfahren und System zur Messung von Last und Kapazität auf einem Kanal mit variabler Kapazität
DE60031263T2 (de) Umhüllungsverfahren für protokolldateneinheiten
DE69930992T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen
DE69932069T2 (de) Arq protokoll mit packetbasierter zuverlässigkeitseinstellung
DE60203450T2 (de) Verfahren und Schalter zur Überlastregelung
DE60023019T2 (de) Verfahren und system zur ablösung oder regeneration von quittierungspaketen in adsl kommunikationen
DE102015119893B4 (de) Multiplexen von vielen Client-Datenströmen über eine einzige Verbindung
DE60208921T2 (de) Verfahren und vorrichtung zur übertragung fehlertoleranter daten, wobei eine wiederholte übertragung fehlerhafter daten ausgeführt wird, bis die anzahl der übrigen fehlerhaften daten akzeptabel ist
DE60305378T2 (de) Verfahren zum Weitergeben von einem Netzwerkstapel
DE112013000411T5 (de) Benachrichtigung durch Netzwerkelement über Paketverluste
DE602004012361T2 (de) Verfahren und Vorrichtung zum Offload von TCP/IP Protokoll unabhängig von Bandbreitenverzögerungsprodukt
DE69934226T2 (de) TCP/IP/PPP Modem
DE69931215T2 (de) Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen
DE60021358T2 (de) Eine hoch-leistungs-netzschnittstelle
DE60112525T2 (de) Vorrichtung und Verfahren für Kopfdekomprimierung
DE60219588T2 (de) Verfahren zur Unterscheidung von Paketverlusten
DE112004002375B4 (de) Verfahren, System und Programm zum Verwalten von Datenleseoperationen
DE60309566T2 (de) Halb-zuverlässiges arq verfahren und entsprechende einrichtung
DE102020105776A1 (de) Kostengünstige Überlastungsisolierung für verlustfreies Ethernet
DE602004011453T2 (de) Sendegerät zur Steuerung der Datenübertragung
DE112005001364T5 (de) Verarbeiten von Empfangsprotokolldateneinheiten
DE112020006828T5 (de) Verbessern einer Ende-zu-Ende-Überlastungsreaktion unter Verwendung von adaptivem Routing und Überlastungshinweis-basierter Drosselung für IP-geroutete Rechenzentrumsnetzwerke
DE602004012660T2 (de) System und Verfahren für einen nachrichtenorientierten anpassungsfähigen Datentransport

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law

Ref document number: 112004002544

Country of ref document: DE

Date of ref document: 20061109

Kind code of ref document: P

8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20130702