DE112004002544T5 - Verfahren, System und Programm zur Identifizierung von Datenüberlauf - Google Patents
Verfahren, System und Programm zur Identifizierung von Datenüberlauf Download PDFInfo
- Publication number
- DE112004002544T5 DE112004002544T5 DE112004002544T DE112004002544T DE112004002544T5 DE 112004002544 T5 DE112004002544 T5 DE 112004002544T5 DE 112004002544 T DE112004002544 T DE 112004002544T DE 112004002544 T DE112004002544 T DE 112004002544T DE 112004002544 T5 DE112004002544 T5 DE 112004002544T5
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/29—Flow control; Congestion control using a combination of thresholds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements 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/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/166—IP 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.
– 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 empfängt 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 eines 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 empfängt, 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 empfängt, 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 Restransmit-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 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.
- 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 Computer2 umfaßt eine oder mehrere zentrale Rechnereinheiten (CPU)4 (es ist nur eine dargestellt), einen flüchtigen Speicher6 , einen nicht-flüchtigen Speicher8 , ein Betriebssystem10 und einen Netzwerkadapter12 . Ein Anwendungsprogramm14 wird ferner im Speicher6 ausgeführt und ist zum Übertragen und Empfangen von Paketen von einem entfernten Computer geeignet. Der Computer2 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 CPU4 und jedes Betriebssystem10 , die auf dem Fachgebiet bekannt sind, können verwendet werden. Programme und Daten im Speicher6 können in den Speicher8 als Teil der Speichermanagementoperationen ausgelagert werden. - Der Netzwerkadapter
12 umfaßt eine Netzwerkprotokollschicht16 , um Netzwerkpakete über ein Netzwerk18 zu Ferngeräten zu senden und von Ferngeräten zu empfangen. Das Netzwerk18 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 Netzwerkadapter12 und zahlreiche Protokollschichten das Ethernet-Protokoll implementieren, einschließlich Ethernet-Protokolls ü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 führt im Speicher6 aus und umfaßt Netzwerkadapter 12-spezifische Befehle, um mit dem Netzwerkadapter12 zu kommunizieren und um zwischen dem Betriebssystem10 , den Anwendungen14 und dem Netzwerkadapter12 eine Schnittstelle zu bilden. In einigen Implementierungen umfaßt eine Netzwerksteuereinheit des Netzwerkadapters12 ein Paketpuffer21 und eine Transport-Offload-Engine22 sowie die Netzwerkprotokollschicht16 . 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-Engine22 ausgeführt werden, die in der Netzwerkadapter 12-Hardware oder -Firmware implementiert ist, im Gegensatz zum Gerätetreiber20 . - Die Netzwerkschicht
16 bearbeitet Netzwerkkommunikation und speichert empfangene TCP/IP-Pakete im Paketpuffer21 bevor sie von der Transport-Offload-Engine22 verarbeitet werden. Der Adapter12 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 überragen. Die LLC-Schicht kontrolliert Framesynchronisierung, Flußkontrolle und Fehlerprüfung. In der veranschaulichten Ausführungsform, befindet sich der Paketpuffer21 im MAC-Abschnitt der Netzwerksteuereinheit. Es ist ersichtlich, daß sich der Puffer21 in anderen Abschnitten des Netzwerkadapters12 sowie in anderen Abschnitten des Computers2 befinden kann. - Die Transport-Offload-Engine
22 bildet eine Schnittstelle mit dem Gerätetreiber20 oder dem Betriebssystem10 oder der Anwendung14 und führt zahlreiche Transporiprotokollschichtoperationen 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 Engine22 den Inhalt von Nachrichten verarbeiten, die in den Paketen enthalten sind, die am Netzwerkadapter12 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-Engine22 kann die Payload vom empfangenen TCP/IP-Paket entpacken und die Daten zum Gerätetreiber20 übertragen, um zurück zum Treiber20 , Betriebssystem10 oder der Anwendung14 zu gehen. - In einigen Implementierungen können die Netzwerksteuereinheit und der Netzwerkadapter
12 ferner eine RDMA-Protokollschicht, sowie die Transportprotokollschicht umfassen. Der Netzwerkadapter12 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ätetreiber20 , Betriebssystem10 oder den Anwendungen14 . In zahlreichen Ausführungsformen können die RMDA Offload-Engines Bestandteil der TOE22 oder eine separate Engine sein. - Folgendermaßen kann eine Anwendung
14 , die Nachrichten über eine RDMA-Verbindung überträgt, die Nachricht über den Gerätetreiber20 und die RDMA-Protokollschicht des Netzwerkadapters12 übertragen. Die Daten der Nachricht können zur Transportprotokollschicht vom Engine22 gesendet werden, um in ein TCP/IP-Paket verpackt zu werden. Die Transportprotokollschicht kann ferner das Paket verschlüsseln, bevor es über das Netzwerk18 durch die Netzwerkprotokollschicht16 übertragen wird. - Der Speicher
6 umfaßt ferner Dateiobjekte24 , die auch als Socketobjekte bezeichnet werden können, die Daten über eine Verbindung zu einem Ferncomputer über das Netzwerk18 umfassen. Die Anwendung14 verwendet die Daten im Dateiobjekt24 , um die Verbindung zu identifizieren. Die Anwendung14 würde das Dateiobjekt24 verwenden, um mit einem Fernsystem zu kommunizieren. Das Dateiobjekt24 kann folgendes angeben: den lokalen Port oder Socket, der verwendet wird, um mit einem Fernsystem zu kommunizieren, eine lokale Netzwerk (IP)-Adresse vom Computer2 , in dem die Anwendung14 ausführt, wie viele Daten durch die Anwendung14 gesendet und empfangen wurden, und den fernen Port und die Netzwerkadresse, z.B. IP-Adresse, mit der die Anwendung14 kommuniziert. Kontextdaten26 umfassen eine Datenstruktur mit Daten zum Gerätetreiber20 , Betriebssystem10 oder der Anwendung14 , die aufrecht erhalten werden, um Aufrufe zu verwalten, die zum Netzwerkadapter12 gesendet werden, wie nachstehend noch beschrieben wird. -
2 veranschaulicht ein Format eines Netzwerkpaketes50 , das am Netzwerkadapter12 empfangen ist. Das Netzwerkpaket50 ist in einem Format implementiert, das vom Netzwerkprotokoll14 , wie dem IP-Protokoll, verstanden wird. Das Netzwerkpaket150 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 Netzwerkpaket50 enthalten. Das Transportpaket52 ist dazu geeignet, durch die Engine22 in Übereinstimmung mit einem Transportprotokoll, wie dem TCP-Protokoll, verarbeitet zu werden. Das Paket52 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 Transportpaket52 umfaßt Payloaddaten54 sowie andere Transportschichtfelder, wie ein Header und ein Fehlerprüfcode. Im Header von jedem Paket ist die Paketfolgenummer enthalten. Die Payloaddaten52 umfassen den darunterliegenden Inhalt, der übertragen wird, z.B. Befehle, Zustände und/oder Daten. Der Treiber20 , das Betriebssystem10 oder eine Anwendung14 können eine Schicht umfassen, wie SCSI-Treiber oder Schicht, um den Inhalt der Payloaddaten54 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-Rettransmit-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 unverwartetes 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 notwendig 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-Restransmit-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 empfängt.
- 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 Netzwerkadapter12 , 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 Netzwerkprotokollschicht16 (Block100 ) ein Paket vom Netzwerk18 und bestimmt (Block102 ), ob der Puffer21 über einen bestimmten „Füllstand"-Schwellenwert hinaus gefüllt ist. Der Paketpuffer21 ist schematisch in der4 dargestellt. Ein Balkendiagramm, das das Maß veranschaulicht, zu dem der Puffer21 zu jeder bestimmten Zeit gefüllt ist, ist in der5 veranschaulicht und ist als ein prozentualer Anteil der Gesamtkapazität vom Puffer21 für das Speichern von Paketen, die vom Netzwerk18 empfangen werden, dargestellt. Ein schraffierter Abschnitt104 vom Balkendiagramm stellt den Abschnitt vom Puffer21 dar, der mit Datenpaketen gefüllt wurde, die vom Netzwerk16 empfangen wurden. Folgendermaßen stellt die Länge vom Abschnitt104 , wie bei105 angegeben, das gespeicherte Datenniveau vom Puffer21 dar. Der verbleibende Abschnitt106 vom Balkendiagramm stellt die verbleibende Kapazität vom Puffer21 dar, die noch nicht mit Datenpaketen vom Netzwerk gefüllt wurde. - Das Balkendiagramm von
5 gibt bei108 ebenfalls einen „Füllstand-Schwellenwert" an. Im Beispiel von der5 wurde der Puffer21 zu einem Niveau105 unter dem vom Füllstand-Schwellenwert108 gefüllt. Solange das gefüllte Niveau105 unter dem Füllstand-Schwellenwert108 verbleibt, speichert der Netzwerkadapter12 weiterhin (Block110 ,3 ) das gesamte Paket, das vom Netzwerk18 empfangen wird, in den Puffer21 . Die4 zeigt ein Beispiel eines vollständig gefüllten Pakets112 , das im Puffer21 gespeichert ist. - Der Füllstand-Schwellenwert
108 kann verwendet werden, um eine frühe Angabe davon zu verschaffen, daß der Puffer21 wahrscheinlich den Raum verläßt, um Datenpakete vom Netzwerk18 zu speichern. Sobald der Puffer21 den Speicherraum verläßt, werden wahrscheinlich alle weiteren empfangenen Datenpakete fallen gelassen. Solange die Transport-Offload-Engine22 Datenpakete vom Puffer21 entnehmen und verarbeiten kann mit einer Geschwindigkeit, die gleich oder schneller als die von der Netzwerkprotokollschicht16 ist, mit der sie Datenpakete im Puffer21 speichert, sollte das gefüllte Niveau105 vom Puffer21 unter dem Füllstand-Schwellenwert108 bleiben. Wenn die Netzwerkprotokollschicht16 jedoch Datenpakete mit einer Geschwindigkeit, die schneller ist als die, mit der die Transport-Offload-Engine22 die Datenpakete verarbeiten kann, im Puffer21 speichert, kann das gefüllte Niveau105 anfangen zu steigen. - Die Geschwindigkeit, mit der die Transport-Offload-Engine
22 Datenpakete verarbeitet, kann niedriger als die Geschwindigkeit sein, mit der die Netzwerkprotokollschicht16 die Datenpakete vom Netzwerk18 speichert, und dies aufgrund von mehreren Faktoren. So kann zum Beispiel die Menge der Daten, die vom Netzwerk18 zum Netzwerkadapter12 gesendet werden, bedeutend zunehmen. Ebenfalls können die Ressourcen, die die Transport-Offload-Engine22 zum Verarbeiten der Datenpakete benötigt, knapper werden. Die Bandbreite vom Bus oder von den Bussen, die verfügbar ist, um die Transport-Offload-Engine22 mit dem Rest vom Hostspeicher6 oder dem Datenspeicher8 vom Hostcomputer2 zu verbinden, kann zum Beispiel eng werden. - Sobald das gefüllte Niveau
105 (Block102 ) den Füllstand-Schwellenwert108 übersteigt, kann der Netzwerkadapter12 , 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 (Block114 ) den verbleibenden, trunkierten Abschnitt im Puffer21 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 Netzwerk18 empfangen wird, wird (Block114 ) in trunkierter Form im Puffer21 gespeichert, solange festgelegt ist (Block118 ), daß das gefüllte Niveau105 einen „Normalbetrieb"-Schwellenwert120 (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-Schwellenwert108 überschritten ist, zum Beispiel die schnelle Neuübertragung von fallen gelassenen Paketen erleichtern. -
4 zeigt einen Abschnitt130 (eine Vergrößerung von dem, was in der6 dargestellt wird), in dem Paketheader132 anstelle von vollständig gefüllten Paketen112 gespeichert werden. In diesem Beispiel ist der Puffer21 ein 256K-Byte-FIFO (zuerst abgelegtes wird zuerst bearbeitet)-Puffer und der Füllstand-Schwellenwert108 kann eingestellt werden, um anzugeben, daß der Puffer21 über einen verbleibenden FIFO-Raum von 4 K Bytes verfügt. In einigen Anwendungen können zwei vollständige Pakete112 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-Schwellenwert108 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-Schwellenwert108 dem Normalbetrieb-Schwellenwert120 gleichkommend eingestellt werden, um die Logikoperationen zu vereinfachen. -
7 zeigt Operationen eines Netzwerkadapters, wie der Netzwerkadapter12 , der eine Verbindungsprotokollschicht mit einem Transport-Offload-Engine22 umfassen kann, beim Verarbeiten der Datenpakete, die durch die Netzwerkprotokollschicht16 vom Netzwerk18 empfangen und im Puffer21 gespeichert wurden. Der Adapter12 erhält (Block150 ) ein Datenpaket vom Puffer21 und bestimmt (Block152 ), ob das Paket auf eine ähnliche Weise, wie diejenige, die weiter oben in Verbindung mit der3 beschrieben wurde, als trunkiert markiert wurde. Wenn nicht, verarbeitet der Netzwerkadapter12 (Block154 ) 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 Netzwerkadapter12 und einem Sender oder mehreren Sendern im Netzwerk18 stammen. Daher können die Datenpakete, die im Puffer21 gespeichert sind, jeweils Bestandteil von einem Paketfluß oder von mehreren verschiedenen Paketflüssen zwischen dem Netzwerkadapter12 und einem Sender oder mehreren verschiedenen Sendern sein. Beim Bestätigen eines empfangenen Pakets bestimmt der Netzwerkadapter12 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 unverwartet 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 (Block156 ) 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 (Block158 ). - Wenn das trunkierte Datenpaket den Integritätstest (Block
156 ) nicht 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 empfängenen trunkierten Datenpakets im identifizierten Fluß. Durch Verwendung dieser Headerdaten kann der Netzwerkadapter eine Duplikatbestätigung (Block160 ) vom letzten korrekt empfangenen vollständig gefüllten Paket von diesem Fluß zwischen dem Sender und dem Netzwerkadapter12 senden. - Diese Verarbeitung wird fortgeführt, indem der Netzwerkadapter (Block
150 ) ein anderes Paket vom Puffer21 erhält, bestimmt (Block152 ), ob das Paket trunkiert wurde, das trunkierte Paket prüft (Block156 ) und eine Duplikatbestätigung (Block160 ) vom letzten korrekt empfangenen vollständig gefüllten Paket dieser Verbindung zwischen dem Sender und dem Netzwerkadapter12 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ängerpuffer21 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 der6 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 eine 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-Engine22 ausgeführt beschrieben. In alternativen Ausführungsformen können Operationen, die als vom Gerätetreiber20 ausgeführt beschrieben werden, von der Transport-Offload-Engine22 ausgeführt werden, und umgekehrt. In den beschrieben Implementierungen wurde die Transportprotokollschicht in die Netzwerkadapter12 -Hardware implementiert, die Logikschaltungen umfaßt, die von der zentralen Rechnereinheit oder von den zentralen Rechnereinheiten4 vom Hostcomputer2 getrennt sind. In alternativen Implementierungen können Abschnitte von der Transportprotokollschicht im Gerätetreiber oder im Hostspeicher6 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 zahlreiche 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 und7 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 Netzwerkadapter12 verwendet wird, beschrieben, vom Hostspeicher6 getrennt zu sein und sich physisch im Adapter12 zu befinden. In anderen Ausführungsformen kann der Puffer21 ein Teil vom Hostspeicher6 oder ein Teil von anderen Steuereinheitsschaltungen auf einer getrennten Karte oder auf einer Hauptplatine sein. -
8 veranschaulicht eine Implementierung einer Computerarchitektur300 der Netzwerkkomponenten, wie die Hosts und Speichereinheiten, die in der1 dargestellt sind. Die Architektur300 kann einen Prozessor302 (z.B. einen Mikroprozessor), einen Speicher304 (z.B. eine volatile Speichereinheit) und einen Speicher306 (z.B. einen nicht-volatilen Speicher, wie Magnetplattenlaufwerke, CD-Laufwerke, ein Bandlaufwerk, usw.) umfassen. Der Speicher306 kann eine interne Speichereinheit oder einen dazugehörigen oder netzwerkzugänglichen Speicher umfassen. - Programme im Speicher
306 sind im Speicher304 geladen und werden durch den Prozessor302 auf eine im Fachgebiet bekannte Weise ausgeführt. Die Architektur umfaßt ferner eine Netzwerkkarte308 , 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-Steuereinheit309 umfassen, um Daten über einen Anzeigemonitor herauszugeben, wo die Video-Steuereinheit309 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 Eingabeeinheit310 wird verwendet, um dem Prozessor302 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 Ausgabeeinheit312 ist dazu geeignet, Daten, die vom Prozessor302 ü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.
- ZUSAMMENFASSUNG
- Es werden ein Verfahren, System und Programm bereit gestellt, um Datenüberlaufbedingungen beispielsweise beim Datenempfang zu identifizieren. Erreicht ein Empfangspuffer die Kapazität, können empfangene Datenpakete auf eine kleinere Größe trunkiert werden. Headerdaten können zum Beispiel gespeichert, Payloadkarten jedoch ausgesondert werden. Die trunkierten Pakete können verwendet werden, um das Senden von Bestätigungen zu erleichtern, um die Neuübertragung von verloren gegangenen oder fallen gelassenen Paketen zu erleichtern.
Claims (38)
- 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.
- Verfahren nach Anspruch 1, wobei das trunkierte Datenpaket die Headerdaten des empfangenen Pakets nach dem Trunkieren umfaßt.
- Verfahren nach Anspruch 1, wobei das Trunkieren das Aussondern der Payloaddaten des empfangenen Pakets umfaßt.
- Verfahren nach Anspruch 1, das ferner das Markieren des trunkierten Pakets als trunkiert umfaßt.
- 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.
- 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.
- 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.
- 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.
- Verfahren nach Anspruch 8, wobei der Integritätscheck das Ausführen eines Prüfsummentests umfaßt.
- 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.
- Artikel nach Anspruch 10, wobei das trunkierte Datenpaket die Headerdaten des empfangenen Pakets nach dem Trunkieren umfaßt.
- 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.
- Artikel nach Anspruch 10, wobei das Speichermedium ferner maschinenlesbare Befehle umfaßt, die darauf gespeichert sind, um das trunkierte Paket als trunkiert zu markieren.
- 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.
- 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.
- 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.
- Artikel nach Anspruch 15, wobei die maschinenlesbaren Befehle zum Prüfen maschinenlesbarer Befehle, 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.
- 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.
- Artikel zur Verwendung mit einem Netzwerk, der 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.
- System nach Anspruch 19, wobei ein empfangenes Paket Headerdaten aufweist und das trunkierte Datenpaket die Headerdaten des empfangenen Pakets nach dem Trunkieren umfaßt.
- System nach Anspruch 19, wobei ein empfangenes Paket Payloaddaten aufweist und das Trunkieren das Aussondern der Payloaddaten des empfangenen Pakets umfaßt.
- System nach Anspruch 19, wobei zumindest eines vom Betriebssystem, Gerätetreiber und der Netzwerksteuereinheit dazu geeignet ist, das trunkierte Paket als trunkiert zu markieren.
- 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.
- 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.
- 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.
- 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.
- System nach Anspruch 26, wobei der Integritätscheck das Ausführen eines Prüfsummentests umfaßt.
- System nach Anspruch 19 zur Verwendung mit einem nicht abgeschirmten verdrillten Kabelpaars, 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.
- System nach Anspruch 19, das ferner eine Video-Steuereinheit, die mit dem Prozessor verbunden ist, umfaßt.
- 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.
- Einrichtung nach Anspruch 30, wobei ein empfangenes Paket Headerdaten aufweist und das trunkierte Datenpaket die Headerdaten des empfangenen Pakets nach dem Trunkieren umfaßt.
- 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.
- Einrichtung nach Anspruch 30, die ferner ein Mittel umfaßt, um das trunkierte Paket als trunkiert zu markieren.
- 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.
- 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.
- 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.
- 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.
- Einrichtung nach Anspruch 37, wobei ein Mittel zum Ausführen eines Integritätschecks ein Mittel zum Ausführen eines Prüfsummentests umfaßt.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/745,774 | 2003-12-24 | ||
US10/745,774 US7773620B2 (en) | 2003-12-24 | 2003-12-24 | Method, system, and program for overrun identification |
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 true DE112004002544T5 (de) | 2006-11-09 |
DE112004002544B4 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)
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 | 扬州万方电子技术有限责任公司 | 网络协议卸载装置和数据传输系统 |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5428460A (en) * | 1993-06-04 | 1995-06-27 | Brother Kogyo Kabushiki Kaisha | Reduced rate facsimile machine |
EP0706297A1 (de) | 1994-10-07 | 1996-04-10 | International Business Machines Corporation | Verfahren zur Überlastregelung in einem Datenübertragungsnetzwerk und System zur Durchführung dieses Verfahrens |
US6122279A (en) | 1995-10-02 | 2000-09-19 | Virata Limited | Asynchronous transfer mode switch |
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 |
CN1185829C (zh) | 2001-12-19 | 2005-01-19 | 华为技术有限公司 | 一种同步数字系列传输网上控制以太网数据流量的方法 |
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 |
-
2003
- 2003-12-24 US US10/745,774 patent/US7773620B2/en not_active Expired - Fee Related
-
2004
- 2004-12-20 WO PCT/US2004/043037 patent/WO2005067258A1/en active Application Filing
- 2004-12-20 GB GB0606755A patent/GB2422994B/en not_active Expired - Fee Related
- 2004-12-20 DE DE112004002544T patent/DE112004002544B4/de not_active Expired - Fee Related
- 2004-12-21 TW TW093139792A patent/TWI295130B/zh not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
WO2005067258A1 (en) | 2005-07-21 |
US20050147110A1 (en) | 2005-07-07 |
GB2422994B (en) | 2007-11-07 |
GB2422994A (en) | 2006-08-09 |
US7773620B2 (en) | 2010-08-10 |
TW200529618A (en) | 2005-09-01 |
DE112004002544B4 (de) | 2010-07-01 |
TWI295130B (en) | 2008-03-21 |
GB0606755D0 (en) | 2006-05-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE112004002544B4 (de) | Verfahren, System und Programm zur Identifizierung von Datenüberlauf | |
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 | |
DE112020002498T5 (de) | System und verfahren zur erleichterung einer effizienten paketweiterleitung in einer netzwerkschnittstellensteuerung (nic) | |
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 | |
DE60219047T2 (de) | Eine allgemeine eingabe-/ausgabearchitektur und entsprechende verfahren zum aufbau virtueller kanäle darin | |
DE60203450T2 (de) | Verfahren und Schalter zur Überlastregelung | |
DE69934226T2 (de) | TCP/IP/PPP Modem | |
DE60123280T2 (de) | Verfahren für multimediakommunikation über paketkanäle | |
DE60305378T2 (de) | Verfahren zum Weitergeben von einem Netzwerkstapel | |
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 | |
DE69935554T2 (de) | Verfahren und Rechnerprogrammprodukt zum effizienten und zuverlässigen Übertragen von kleinen Datennachrichten von einem Sendesystem zu einer grossen Anzahl von Empfangssystemen | |
DE102015119893B4 (de) | Multiplexen von vielen Client-Datenströmen über eine einzige Verbindung | |
DE112013000411T5 (de) | Benachrichtigung durch Netzwerkelement über Paketverluste | |
DE60021358T2 (de) | Eine hoch-leistungs-netzschnittstelle | |
DE69931215T2 (de) | Verfahren und Rechnerprogrammprodukt zum effizienten und sicheren Senden von kleinen Datennachrichten von einem Sender zu einer grossen Anzahl von Empfangssystemen | |
DE112004002375B4 (de) | Verfahren, System und Programm zum Verwalten von Datenleseoperationen | |
DE60219588T2 (de) | Verfahren zur Unterscheidung von Paketverlusten | |
DE60309566T2 (de) | Halb-zuverlässiges arq verfahren und entsprechende einrichtung | |
DE112005001364T5 (de) | Verarbeiten von Empfangsprotokolldateneinheiten | |
DE602004011453T2 (de) | Sendegerät zur Steuerung der Datenübertragung | |
DE112013000839B4 (de) | Datenübertragungsprotokoll für verteilte Informationstechnologie-Architekturen | |
DE102020105776A1 (de) | Kostengünstige Überlastungsisolierung für verlustfreies Ethernet | |
DE102019109244A1 (de) | Verbindungskomprimierungsschemata mit geringer latenzzeit |
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 |