DE60027404T2 - Kreditbasiertes flusskontrollverfahren - Google Patents

Kreditbasiertes flusskontrollverfahren Download PDF

Info

Publication number
DE60027404T2
DE60027404T2 DE60027404T DE60027404T DE60027404T2 DE 60027404 T2 DE60027404 T2 DE 60027404T2 DE 60027404 T DE60027404 T DE 60027404T DE 60027404 T DE60027404 T DE 60027404T DE 60027404 T2 DE60027404 T2 DE 60027404T2
Authority
DE
Germany
Prior art keywords
packet
endpoint system
data
credit
receive
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 - Lifetime
Application number
DE60027404T
Other languages
English (en)
Other versions
DE60027404D1 (de
Inventor
V. Hemal Hillsboro SHAH
S. Rajesh Hillsboro MADUKKARUMUKUMANA
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 DE60027404D1 publication Critical patent/DE60027404D1/de
Application granted granted Critical
Publication of DE60027404T2 publication Critical patent/DE60027404T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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
    • 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/43—Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)
  • Flow Control (AREA)
  • Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)

Description

  • Verweisung auf verwandte Anmeldungen
  • Diese Anmeldung beansprucht die Priorität des US-Patents Nr. 6,347,337, eingereicht am 8. Januar 1999 mit dem Titel "Kreditbasiertes Flusssteuerungsschema über eine virtuelle Schnittstellenarchitektur für Systembereichsnetzwerke".
  • Gebiet
  • Die Erfindung betrifft im Allgemeinen die Kommunikation über ein Datennetzwerk und im Besonderen ein kreditbasiertes Flusssteuerungsschema für den Einsatz über eine Virtuelle-Schnittstellen-Architektur o.ä.
  • Hintergrund
  • Eine Standard-Benutzerebenen-Netzwerkarchitektur, wie beispielsweise eine Virtuelle-Schnittstellen(Virtual Interface, VI)-Architektur, ermöglicht verteilten Anwendungen das Kommunizieren mit geringem Overhead über Systembereichsnetzwerke (System Area Networks, SANs). Die Virtuelle-Schnittstellen(VI)-Architektur ist in der Virtuelle-Schnittstellen-Architektur-Spezifikation, Version 1.0, 16. Dezember 1997, beschrieben. Mit der Einführung von Systembereichsnetzwerken (SANs) sind Verbindungen mit niedriger Latenz und großer Bandbreite Realität geworden. Dies hat neue Horizonte für das Cluster Computing eröffnet. Die zentralisierte Protokollabwicklung im Kernel bei Legacy Transports (z.B. TCP/IP) hindert Anwendungen am Realisieren der potentiellen ursprünglichen Hardwareleistung, die von den zugrunde liegenden Hochgeschwindigkeitsnetzwerken angeboten werden. Der Virtuelle-Schnittstellen(VI)-Architekturstandard hat es außerdem möglich gemacht, Kommunikation mit geringem Overhead unter Verwendung von Standard-SAN-Hardware durchzuführen. Jedoch ist das Erstellen von Hochpegel-Anwendungen unter Verwendung von von der VI-Architektur bereitgestellten Grundele menten komplex und erfordert erhebliche Entwicklungsanstrengungen, weil die VI-Architektur keine Transportebenenfunktionalität, wie beispielsweise Flusssteuerung, Puffer-Management, Fragmentierung und Wiederzusammensetzung, bereitstellt. Außerdem ist es unpraktisch, existierende Netzwerkprotokolle wie beispielsweise das Übertragungs-Steuerungsprotokoll (Transmission control protocol, TCP) über die VI-Architektur zu implementieren, weil dies einen unnötigen zusätzlichen Overhead verursachen würde. TCP verwendet ein Flusssteuerungsprotokoll mit Gleitfenster, das Folgenummern, Quittierungen, Fehlererkennung, Wiederübertragung von verlorenen Paketen etc. verwendet, weil angenommen wird, dass das zugrunde liegende Netzwerk inhärent unzuverlässig ist. SANs haben sehr geringe Fehlerraten und hohe Zuverlässigkeitsniveaus, die von der VI-Architektur (zuverlässige Übergabe (delivery) und zuverlässiger Empfang) ermöglicht werden, und betrachten Transportfehler als katastrophal. Daher sind aufgrund der zuverlässigen Übergabe und des zuverlässigen Empfangs von VIs, welche die Verbindung bei extrem seltenen Transportfehlern unterbrechen und genau eine, intakte, geordnete Datenzustellung garantieren, viele der von TCP zum Gewährleisten von Zuverlässigkeit ausgeführten Funktionen redundant und würden unnötigen Overhead hinzufügen.
  • Die US 5 748 613 stellt ein Verfahren zum Dosieren eines Datenstroms bereit, der von einer Datenquelle zu einem gepufferten Datenziel mit einer vorgegebenen Anzahl von verfügbaren Speichereinheiten übertragen wird, wobei die Datenziele zum Konsumieren von Daten und dadurch zum Verfügbarmachen von Speichereinheiten für den Empfang zusätzlicher Daten ausgelegt sind.
  • Die US 4 703 475 offenbart ein Protokoll für Mehrfach-Übermittlungsabschnitts-Interprozessor-Kommunikation, die einem Prozessorpaar das Erhöhen ihrer Kommunikationsgeschwindigkeit durch eine parallele Verwendung von mehrfachen physikalischen Übermittlungsabschnitten ermöglicht. wenn eine Nachricht von einem Prozessor zum anderen gesendet wird, wird die Nachricht in kleinere Segmente paketiert und gemäß einem einfachen Algorithmus auf die verfügbaren physikalischen Übermittlungsabschnitte geladen.
  • In „Design, Implementation, and Evaluation of a Single-copy Protocol Stack" von P. Steenkiste, Software-Practice and Experience, Vol. 28(7), 749-772, Juni 1998, wird die Host-Software für eine Host-Schnittstelle mit Pufferung und Prüfsummenunterstützung außerhalb des Boards zur Unterstützung von "Single-Copy"-Kommunikation für bestimmte Anwendungen beschrieben. Die Implementierung verwendet einen externen Mechanismus, um Datendeskriptoren durch den Stack zu schleusen.
  • Daher besteht ein Bedürfnis nach einem Kommunikationsdienst, der einige Transportebenendienste über die VI-Architektur bereitstellt, wie beispielsweise Flusskontrolle, Puffermanagement, Fragmentierung und Wiederzusammensetzung, ohne unnötigen Overhead hinzuzufügen.
  • Zusammenfassung
  • Entsprechend einer Ausführungsform der Erfindung wird ein Verfahren zum Senden von Daten von einem lokalen Endknotensystem zu einem entfernten Endknotensystem über ein Netzwerk bereitgestellt. Das lokale Endknotensystem umfasst eine Vielzahl von Arbeitswarteschlangen für das Eingeben (Posten) von Datenübertragungsanforderungen. Es wird festgestellt, ob eine ausreichende Anzahl von Sendekrediten, wobei die Kredite ein oder mehrere für das Empfangen und Speichern eines Datenpakets verfügbare Empfangspuffer sind, am lokalen Endknotensystem verfügbar ist. Ein Datenpaket wird vom lokalen Endknotensystem zum entfernten Endknotensystem über das Netzwerk gesendet, wenn eine ausreichende Anzahl von Sendekrediten verfügbar ist. Andernfalls, wenn keine ausreichende Anzahl von Sendekrediten am lokalen Endknotensystem verfügbar ist, wird ein Kredit-Anforderungspaket vom lokalen Endknotensystem zum entfernten Endknotensystem gesendet, wobei das Kredit-Anforderungspaket ein Paket ist, das Kredit vom Endknoten an fordert, und es wird vor dem Senden eines Datenpakets auf ein Kredit-Antwortpaket vom entfernten Endknotensystem gewartet, wobei das Kredit-Antwortpaket verfügbare Empfangspuffer am entfernten Endknotensystem anzeigt.
  • Gemäß einer Ausführungsform der Erfindung wird ein Verfahren zum Empfangen von Daten an einem entfernten Endknotensystem von einem lokalen Endknotensystem über ein Netzwerk bereitgestellt. Das entfernte Endknotensystem umfasst eine Vielzahl von Arbeitswarteschlangen zum Eingeben (Posten) von Datenübertragungsanforderungen, einen oder mehrere registrierte Sende- und Empfangspuffer und einen oder mehrere Anwendungs-Empfangspuffer. Ein Paket wird vom lokalen Endknotensystem empfangen. Es wird festgestellt, ob das Paket ein Datenpaket oder ein Kredit-Anforderungspaket ist, wobei das Kredit-Anforderungspaket ein Paket ist, das Kredit von dem Endknoten anfordert. Die folgenden Schritte werden ausgeführt, wenn Daten vorliegen, die vom entfernten Endknotensystem empfangen und in den registrierten Empfangspuffern gespeichert worden sind: Die Daten werden aus den registrierten Empfangspuffern in einen der Anwendungs-Empfangspuffer kopiert. Alle registrierten Empfangspuffer, die in die Anwendungs-Empfangspuffer kopiert worden sind, werden verfügbar gemacht oder freigegeben. Eine Anzahl von Empfangskrediten wird basierend auf dem Schritt des Freigebens oder Verfügbarmachens aller registrierten Empfangspuffer aktualisiert. Die folgenden Schritte werden ausgeführt, wenn das empfangene Paket ein Kredit-Anforderungspaket ist: Die Anzahl der verfügbaren oder freigegebenen registrierten Empfangspuffer wird festgestellt. Ein Kredit-Antwortpaket, wobei das Kredit-Antwortpaket die verfügbaren Empfangspuffer am lokalen Endknotensystem anzeigt, wird zum lokalen Endknotensystem gesendet, wenn eine ausreichende Anzahl von freigegebenen registrierten Empfangspuffern am entfernten Endknotensystem verfügbar ist. Andernfalls wird eine ausstehende Kredit-Antwort markiert, wenn keine ausreichende Anzahl von freigegebenen Empfangspuffern am entfernten Endknotensystem verfügbar ist.
  • Entsprechend einer weiteren Ausführungsform der Erfindung wird ein Endknotensystem zum Ausführen aller Schritte der Verfahrensansprüche 1 oder 10 bereitgestellt. Das Endknotensystem umfasst einen Host-Prozessor, eine oder mehrere Arbeitswarteschlangen zum Eingeben von Datenübertragungsanforderungen, einen oder mehrere registrierte Sendepuffer, einen oder mehrere registrierte Empfangspuffer und eine Netzwerkschnittstellen-Steuerung, die mit dem Host-Prozessor, den Arbeitswarteschlagen, den Puffern und dem Netzwerk gekoppelt ist. Die Netzwerkschnittstellen-Steuerung verarbeitet die eingegebenen Datenübertragungsanforderungen durch Übertragen von Daten zwischen den registrierten Puffern und dem Netzwerk. Der Host-Prozessor ist zum Steuern der von der Netzwerkschnittstellen-Steuerung ausgeführten Datenübertragung durch Implementieren eines kreditbasierten Flusssteuerungsschemas programmiert.
  • Kurze Beschreibung der Zeichnungen
  • Das Vorangehende und ein besseres Verständnis der vorliegenden Erfindung werden aus der folgenden detaillierten Beschreibung beispielhafter Ausführungsformen und aus den Ansprüchen deutlich werden, wenn sie in Verbindung mit den beigefügten Zeichnungen gelesen werden, wobei alles einen Teil der Offenbarung dieser Erfindung bildt. Während sich die vorangehende und folgende schriftliche und bildliche Offenbarung auf das Offenbaren von beispielhaften Ausführungsformen der Erfindung konzentriert, sollte es selbstverständlich sein, dass dieselbe nur als Veranschaulichung und Beispiel gedacht und nicht darauf beschränkt ist. Der Bereich der vorliegenden Erfindung ist nur durch die beigefügten Ansprüche begrenzt.
  • Das Folgende stellt eine kurze Beschreibung der Zeichnungen dar, in denen:
  • 1A ein Blockdiagramm ist, welches das Virtuelle-Schnittstellen(VI)-Architekturmodell veranschaulicht.
  • 1B ein Blockdiagramm ist, das eine virtuelle Schnittstelle (VI) darstellt.
  • 2 ein Blockdiagramm eines Endknotensystems gemäß einer Ausführungsform der vorliegenden Erfindung ist.
  • 3 eine Tabelle ist, die Merkmale eines Transportdienstanbieters gemäß einer Ausführungsform der vorliegenden Erfindung über eine VI-Architektur im Vergleich mit Merkmalen des Legacy-Transportebenenprotokolls TCP auflistet.
  • 4 ein Diagramm ist, das einen Überblick über eine Windows Sockets 2-Architektur darstellt.
  • 5 ein Blockdiagramm ist, das einen Benutzerebenen-Stack darstellt, der für eine VI-Architektur gemäß einer Ausführungsform der vorliegenden Erfindung optimiert ist.
  • 6 eine Funktion ist, welche die Anwendungs-zu-Anwendungs-Umlauf-Latenzzeit vergleicht.
  • 7 ein Blockdiagramm des Hardwaremodells eines Endknotensystems gemäß einer Ausführungsform der vorliegenden Erfindung ist.
  • 8 ein Diagramm ist, das den Verbindungsprozess zwischen zwei Endknoten in der VI-Architektur darstellt.
  • 9 ein Flussdiagramm ist, das den Ablauf einer Sendeoperation gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 10 ein Flussdiagramm ist, das Details des Wartens auf eine Kredit-Antwort der Sendeoperation aus 9 zeigt.
  • 11 ein Flussdiagramm ist, das eine Empfangsoperation gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • 12 ein Flussdiagramm ist, das Details des Polling-Schritts aus 11 darstellt.
  • Detaillierte Beschreibung
  • 1.0 Die VI-Architektur
  • Bei einer traditionellen Netzwerkarchitektur virtualisiert das Betriebssystem (operating system, OS) die Netzwerk-Hardware in einen Satz von logischen Kommunikationsendknoten, die den Netzwerkkonsumenten zur Verfügung stehen. Das Betriebssystem multiplext einen Zugang zur Hardware unter diesen Endknoten. In den meisten Fällen implementiert das Betriebssystem auch Protokolle auf verschiedenen Ebenen (z.B. TCP, IP), welche die Kommunikation zuverlässig machen. Der Demultiplexvorgang und die Zuverlässigkeitsprotokolle sind rechnerisch aufwendig. Außerdem haben alle Kommunikationsoperationen zur Folge, dass Pufferkopien auf verschiedenen Ebenen oder Schichten, bei Zustands- und Aufgabenumschaltungen gemacht werden, deren Ausführung recht aufwändig sein kann.
  • Die VI-Architektur wurde entworfen, um Pufferkopien und Kernel-Overheads zu beseitigen, die in der Vergangenheit traditionelle Netzwerkanwendungen zu Leistungsengpässen gemacht haben.
  • 1A zeigt ein Blockdiagramm, welches das VI-Architekturmodell darstellt. Die VI-Architektur wird kurz beschrieben werden. Die VI-Architektur ist eine Benutzerebenen-Netzwerkarchitektur, die zum Erreichen einer Kommunikation mit niedriger Latenzzeit und hoher Bandbreite innerhalb eines Clusters ausgelegt ist. Die VI-Architektur stellt einem Benutzerprozess einen direkten Zugang zu der Netzwerkschnitt stelle auf eine vollständig geschützte Weise zur Verfügung. Die VI-Architektur vermeidet Zwischendatenkopien und umgeht das Betriebssystem, um eine Datenübertragung mit niedriger Latenzzeit und hoher Bandbreite zu erreichen. Die VI-Architektur-Spezifikation, Version 1.0, 16. Dezember 1997, wurde von den Unternehmen Intel, Microsoft und Compaq Computer gemeinsam verfasst.
  • Wie in 1A gezeigt, umfasst das VI-Architekturmodell einen VI-Konsumenten 8 und einen VI-Provider 24. Ein VI-Konsument 8 ist ein Softwareprozess, der unter Verwendung einer virtuellen Schnittstelle (VI) kommuniziert. Der VI-Konsument 8 umfasst typischerweise ein Anwendungsprogramm 10, eine Betriebssystems-Kommunikationseinrichtung 12 (z.B. Sockets, Remote Procedure Call oder RPC, MPI) und einen VI-Benutzeragenten 14. Der VI-Provider 24 umfasst die Kombination einer VI-Netzwerkschnittstellensteuerung (VI network Interface controller, VI NIC) 18 und eines VI-Kernel-Agenten 16.
  • Ein Blockdiagramm, das eine virtuelle Schnittstelle (VI) darstellt, ist in 1B gezeigt. In Bezug auf 1A und 1B ist eine virtuelle Schnittstelle (VI) 9 eine Schnittstelle zwischen einer VI NIC 18 und einem Prozess oder einer Anwendung (VI-Konsument 8). Die VI 9 ermöglicht einer VI NIC 18 den direkten Zugriff auf den Prozessspeicher für Datenübertragungsoperationen zwischen der Anwendung und dem Netzwerk. Eine VI 9 umfasst ein Arbeitswarteschlangenpaar, eine für Sendeoperationen (eine Sendewarteschlange 21) und eine für Empfangsoperationen (Empfangswarteschlange 19). Die Arbeitswarteschlangen speichern einen oder mehrere Deskriptoren 23 zwischen dem Zeitpunkt, an dem er Eingegeben (in der Warteschlange platziert) wird und dem Zeitpunkt, an dem er Erledigt ist (wenn die VI NIC seine Verarbeitung vervollständigt hat). Der Deskriptor 23 ist eine von der VI NIC erkennbare Datenstruktur, die eine Datenbewegungsanforderung beschreibt, und er umfasst eine Liste von Segmenten (ein Steuersegment, ein optionales Adresssegment und ein oder mehrere Datenseg mente). Das Steuersegment identifiziert den Typ der auszuführenden VI NIC-Datenbewegungsoperation und den Status einer vervollständigten NIC-Datenbewegungsoperation. Das Datensegment beschreibt einen Kommunikationspuffer für eine VI NIC-Datenbewegungsoperation. Eine Empfangswarteschlange 19 enthält Deskriptoren, die festlegen, wo eingehende Daten zu platzieren sind. Eine Sendewarteschlange 21 enthält Deskriptoren, welche die zu übertragenden Daten festlegen. Ein Paar von VIs wird einander unter Verwendung von Verbindungsgrundelementen (z.B. VipConnectWait, VipConnectAccept, VipConnectRequest) zugeordnet, um das Empfangen von an einer VI gesendeten Paketen an der anderen VI zu ermöglichen. Eine Sende-Doorbell 25 und eine Empfangs-Doorbell 27 werden bereitgestellt, um dem VI-Konsumenten zu ermöglichen, die VI NIC 18 davon in Kenntnis zu setzen, dass Arbeit (ein Deskriptor, der eine angeforderte Datenübertragungsoperation festlegt) in der Sendewarteschlange 19 bzw. der Empfangswarteschlange 21 platziert worden ist.
  • Wiederum in Bezug auf 1A, ist der VI-Benutzeragent 14 eine Softwarekomponente, die einer Betriebssystems-Kommunikationseinrichtung 12 das Verwenden eines bestimmten VI-Providers 24 ermöglicht. Der VI-Benutzeragent abstrahiert die Details der zugrunde liegenden VI NIC-Hardware gemäß einer Schnittstelle, die von einer Betriebssystems-Kommunikationseinrichtung 12 definiert wird. Der VI-Benutzeragent umfasst eine Bibliothek von Grundelementen, bekannt als die VI-Grundelemente-Bibliothek (VI primitives library, VIPL), die Funktionen zum Erzeugen einer VI (VipCreateVI), zum Löschen einer VI (VipDestroyVI), zum Verbinden einer VI mit einer anderen VI (z.B. VipConnectWait, VipConnectRequest), zum Akzeptieren oder Zurückweisen einer VI-Verbindungsanfrage (VipConnectAccept oder VipConnectReject), zum Beenden oder Trennen einer Verbindung zwischen zwei VIs (VipDisconnect), zum Ermöglichen, dass ein Prozess Prozessspeicher bei einer VI NIC registriert (VipRegisterMem), zum Eingeben (Posten) von Deskriptoren (zum Platzieren eines Deskriptors in einer VI-Arbeitswarteschlange unter Verwendung z.B. von VipPostSend, VipPostRecv) etc. bereitstellen. Details der VI-Grundelemente (VIPL) sind in der VI-Architektur-Spezifikation, Version 1.0, 16. Dezember 1997 dargelegt.
  • Der Kernel-Agent 16 ist der privilegierte Teil des Betriebssystems, normalerweise ein von dem VI NIC-Lieferant bereitgestellter Treiber, welcher die Setup- und Betriebsmittelverwaltungsfunktionen ausführt, die zum Betreiben einer virtuellen Schnittstelle zwischen VI-Konsumenten und VI NICs gebraucht werden. Diese Funktionen umfassen die Erzeugung/Löschung von VIs, den VI-Verbindungsaufbau/-abbau, die Unterbrechungsverwaltung und/oder -verarbeitung, die Verwaltung des von der VI NIC verwendeten Systemspeichers und die Fehlerbehandlung. VI-Konsumenten greifen auf den Kernel-Agenten 16 unter Verwendung der Standard-Betriebssystemsmechanismen zu, wie z.B. Systemaufrufe. wie vom Pfeil 26 (1A) gezeigt, macht die OS-Kommunikationseinrichtung 12 Systemaufrufe für den VI-Kernel-Agenten 16, um etliche Steueroperationen auszuführen, die das Erzeugen einer VI auf dem lokalen System, das Verbinden der lokalen VI mit einer VI auf einem entfernten System und das Registrieren von Speicher umfassen. Die VI-Architektur erfordert, dass der VI-Konsument für eine Datenübertragung zu verwendenden Speicher vor der Eingabe einer Datenübertragungsanforderung registriert. Die von Deskriptoren verwendeten Speicherbereiche und Datenpuffer werden vor Datenübertragungsoperationen registriert. Die Speicherregistrierung gibt einer VI NIC ein Verfahren zum Übersetzen einer virtuellen Adresse in eine physikalische Adresse. Der Benutzer empfängt eine opake Speicherkennung als ein Ergebnis der Speicherregistrierung. Dies ermöglicht einem Benutzer die Bezugnahme auf einen Speicherbereich unter Verwendung einer Speicherkennung/eines virtuellen Adresspaars ohne Sorgen über das Verletzen von Seitengrenzen und das Verfolgen der Abbildung einer virtuellen Adresse auf ein Etikett (Tag). Die Speicherregistrierung ermöglicht dem VI-Provider, Daten direkt zwischen den registrierten Puffern eines VI-Konsumenten und dem Netzwerk zu übertragen. Traditionelle Netzwerkübertragungen kopieren Daten häufig zwischen Bedienerpuffern und einem oder mehreren Zwischen-Kernel-Puffern. Daher wird der Verarbeitungs-Overhead bei der VI-Architektur reduziert, weil Datenübertragungen zwischen einer Anwendung und der VI NIC sich nicht auf Systemaufrufe des Kernels stützen.
  • Nach dem Erzeugen einer VI auf dem lokalen System, dem Verbinden der lokalen VI mit einer entfernten VI und dem Registrieren von Speicher kann die Anwendung 10 oder die Betriebssystems-Kommunikationseinrichtung 12 die Datenübertragungsgrundelemente der VIPL-Bibliothek des VI-Benutzeragenten 14 zum Senden und Empfangen von Daten verwenden. Die VI-Architektur definiert zwei Typen von Datenübertragungsoperationen: 1) Traditionelle Sende/Empfangsoperationen, und 2) Remote-DMA (RDMA)-Schreibe/Leseoperationen. Ist eine Verbindung einmal hergestellt, gibt die Betriebssystemeinrichtung 12 die Sende- und Empfangsanforderungen der Anwendung direkt an der Lokalen VI ein (an die Sende- und Empfangswarteschlangen). Ein Konsument 8 gibt Deskriptoren ein (platziert die Deskriptoren z. B. in einer Arbeitswarteschlange) und betätigt eine Doorbell, um die NIC davon zu benachrichtigen, dass Arbeit in der Arbeitswarteschlange platziert worden ist. Der VI-Konsument kann die Doorbell ohne Kernel-Verarbeitung betätigen (die VI NIC 18 von der Arbeit in der Warteschlange benachrichtigen). Die VI NIC 18 verarbeitet daraufhin den Deskriptor durch Senden oder Empfangen von Daten, und benachrichtigt den VI-Konsument 8 danach von der vervollständigten Arbeit unter Verwendung der Vervollständigungs-Warteschlange 22. Die Verarbeitung von an einer VI eingegeben Deskriptoren wird in FIFO-Reihenfolge durchgeführt, es gibt jedoch keine implizite Beziehung zwischen der Verarbeitung von an verschiedenen VIs eingegebenen Deskriptoren. Die VI NIC 18 führt die Datenübertragungsfunktionen direkt in Reaktion auf die eingegebenen Deskriptoren durch.
  • Die VI-Architektur unterstützt drei Ebenen von Kommunikationszuverlässigkeit auf der NIC-Ebene: unzuverlässige Überga be, zuverlässige Übergabe und zuverlässiger Empfang. Bei zuverlässiger Übergabe und zuverlässigem Empfang werden verfälschte Daten detektiert, Daten genau einmal übergeben, die Datenreihenfolge ist garantiert, Datenverlust wird detektiert, und die Verbindung wird bei einer Fehlererkennung unterbrochen. Während die VI-Architektur eine hohe Zuverlässigkeit bietet, führt sie keine anderen Transportebenenfunktionen durch, einschließlich Flusssteuerung, Pufferverwaltung und Fragmentierung und Wiederzusammensetzung. Die VI-Architektur-Spezifikation, Version 1.0, 16. Dezember 1997, stellt auf S. 15 fest, dass „VI-Konsumenten für das Verwalten der Flusssteuerung bei einer Verbindung verantwortlich sind." Der Transportdienst-Provider der vorliegenden Erfindung ist zum Bereitstellen einiger Transportebenenfunktionalitäten über die VI-Architektur oder über eine der VI-Architektur ähnliche Architektur ohne das Hinzufügen von unnötigem Overhead ausgelegt.
  • 2.0 Transportdienst-Provider
  • 2 zeigt ein Blockdiagramm eines Endknotensystems gemäß einer Ausführungsform der vorliegenden Erfindung. Das Endknotensystem 30 umfasst einen VI-Konsumenten 11 und einen VI-Provider 24. Der VI-Provider 24 aus 2 ist derselbe oder sehr ähnlich wie der VI-Provider 24 aus 1A. Der VI-Konsument 11 aus 2 umfasst jedoch eine neue Komponente, einen Transportdienst-Provider 13, der zwischen die Betriebssystems-Kommunikationseinrichtung 12 und den VI-Benutzeragenten 14 gekoppelt ist. Der Transportdienst-Provider 13 ist ein Kommunikationsdienst, der eine Nachrichtenebene zum Übersetzen von Anwendungsbefehlen oder Betriebssystems-Einrichtungsbefehlen in den entsprechenden Satz von Befehlen und Operationen unter Verwendung des VI-Benutzeragenten bereitstellt. Der Transportdienst-Provider 13 stellt eine transportartige Funktionalität bereit, umfassend Flusssteuerung, Pufferverwaltung und Fragmentierung und Wie derzusammensetzung (wenn notwendig), ohne unnötigen Overhead hinzuzufügen.
  • 3 ist eine Tabelle, die Merkmale eines Transportdienst-Providers 13 gemäß einer Ausführungsform der vorliegenden Erfindung über eine VI-Architektur mit dem Legacy-Transportebenenprotokoll TCP vergleicht. TCP ist verbindungsorientiert, stellt eine Datenprüfsumme für die Fehlererkennung und positive Quittierungen (Acks) bereit, führt Zeitüberwachungen und Übertragungswiederholungen aus, wenn eine Ack nicht empfangen wird, detektiert Duplikate (weil Pakete wiederholt übertragen werden können), stellt Sequentialisierung und eine Gleitfenster-Flusssteuerung bereit. Alle dieser Funktionen werden vom Prozessor ausgeführt und verursachen deswegen einen beträchtlichen Prozessor-Overhead. Im Gegensatz dazu stellt der Transportdienst-Provider 13 der vorliegenden Erfindung eine kreditbasierte Flusssteuerung bereit und verlässt sich auf die VI NIC (die eine Hardwarekomponente sein kann), um die anderen, in 3 aufgelisteten Funktionen bereitzustellen.
  • Bevor das Flusssteuerungsschema der vorliegenden Erfindung detailliert beschrieben wird, wird zunächst die allgemeine Struktur und Wirkung des für eine VI-Architektur ausgelegten Benutzerebenen-Stacks und Hardware-Modells beschrieben. Ist die allgemeine Struktur und der Betrieb eines Endknotensystems, welches eine VI-Architektur verwendet, einmal beschrieben, werden die spezifischen Details eines Transportdienst-Providers, einschließlich eines Flusssteuerungsdienstes, beschrieben. Die vorliegende Erfindung wird unten in Bezug auf einen Socket-Typ der Betriebssystems-Kommunikationseinrichtung über die VI-Architektur beschrieben. Die Socket-Kommunikationseinrichtung ist nur eine von etlichen Kommunikationseinrichtungen, die für Anwendungen verfügbar sind. Der Transportdienst-Provider 13 und das Flusssteuerungsschema der vorliegenden Erfindung sind für eine große Vielzahl von Kommunikationsdiensten über die VI-Architektur oder eine der VI-Architektur ähnliche Architektur anwendbar. Das Flusssteuerungsschema der vorliegenden Erfindung ist nicht auf die unten beschriebene Socket-Ausführungsform begrenzt. Diese unten beschriebene Socket-Ausführungsform ist einfach als Beispiel für ein ein kreditbasiertes Flusssteuerungsschema der vorliegenden Erfindung verwendendes Endknotensystem bereitgestellt.
  • 3.0 Stream Sockets über VI-Architektur
  • Stream Sockets stellen ein verbindungsorientiertes, bidirektionales Byte-Datenstrom-orientiertes Kommunikationsmodell bereit. Die Windows Sockets 2-Architektur verwendet ein Socket-Paradigma und stellt eine protokollunabhängige Transportschnittstelle bereit. 4 zeigt ein Diagramm, das einen Überblick der Windows Sockets 2-Architektur veranschaulicht. Sie besteht aus einer von Anwendungen verwendeten Anwendungsprogrammschnittstelle (API) und aus von Dienstprovidern implementierten Dienstproviderschnittstellen (SPIs). Diese erweiterbare Architektur ermöglicht die Koexistenz verschiedener Dienstprovider. Die Transportdienst-Provider implementieren die tatsächlichen Transportprotokolle, und die Namensraum-Provider bilden eine Namensraum-SPI von WinSock auf einige existierende Namensräume ab. Beispiele der Transportdienst-Provider umfassen das Übertragungssteuerungsprotokoll (TCP), das ein verbindungsorientiertes Protokoll ist, und das User Datagram Protocol (UDP), das ein verbindungsloses Protokoll ist. Wie unten detaillierter beschrieben wird, wird gemäß einer Ausführungsform der vorliegenden Erfindung die Windows Sockets 2-Architektur verwendet, um Hochleistungs-Stream Sockets über eine VI-Architektur bereitzustellen, die einen neuen Transportdienst-Provider (Transportdienst-Provider 13, 2, der zum Betrieb über eine VI-Architektur ausgelegt ist) verwendet. Der neue Transportdienst-Provider kann auf Benutzerebene implementiert werden.
  • 5 ist ein Blockdiagramm, das einen für eine VI-Architektur gemäß einer Ausführungsform der vorliegenden Erfindung optimierten Benutzerebenen-Stack veranschaulicht. Eine spezielle Ausführungsform der Betriebssystems-Kommunikationseinrichtung 12 (2) umfasst eine WinSock-Anwenderprogrammschnittstelle (API) 42, die dynamisch verkettete WinSock-Bibliothek (Dynamically Linked Library, DLL) 44 und eine WinSock-Dienstprovider-Schnittstelle 46. Der Transportdienst-Provider 13 ist eine Nachrichtenebene, die eine transportartige Funktionalität umfasst. Außer anderen Funktionen umfasst der Transportdienst-Provider 13 Flusssteuerungsdienste 15 zum Ausführen von Flusssteuerung, Fragmentierung und Wiederzusammensetzung und Pufferverwaltung. Die in 5 gezeigte VI NIC 18 umfasst und verwaltet die Sende- bzw. Empfangswarteschlangen 21 bzw. 19 (die Arbeitswarteschlangen) (in 2 gezeigt).
  • Eine Anwendung 10 kann die Grundelemente (oder Funktionen) der WinSock-API 42 verwenden, um Befehle oder Anforderungen an die WinSock2-DLL 44 für Kommunikationsdienste auszugeben (z.B. zum Erzeugen eines Sockets, zum Herstellen einer Verbindung mit einem anderen Socket, zum Senden von Daten zwischen zwei Sockets). Die WinSock2-API-Grundelemente ermöglichen einer Anwendung 10 das Spezifizieren eines bestimmten Transportdienst-Providers, der die angeforderten Kommunikationsdienste bereitstellen wird. Die für die Anwendung 10 verfügbaren Transportdienste könnten beispielsweise TCP, UDP und den Transportdienst-Provider 13 der vorliegenden Erfindung umfassen, der zum Betrieb über eine VI-Architektur ausgelegt ist. Basierend auf der Dienstanforderung oder dem Befehl von der Anwendung identifiziert die WinSock2-DLL den angeforderten Transportdienst-Provider und gibt einen oder mehrere entsprechende Befehle an den angeforderten Transportdienst-Provider mittels der WinSock-Dienst-Provider-Schnittstelle 46 aus.
  • Der Transportdienst-Provider 13 ist eine Nachrichtenebene, die jeden von der WinSock2-DLL 44 empfangenen Befehl in einen oder mehrere entsprechende Befehle oder Operationen für das Ausführen der angeforderten Operation oder des angeforderten Dienstes unter Verwendung des VI-Benutzeragenten 14 übersetzt. Die Befehle vom Transportdienst-Provider werden dem VI-Benutzeragenten 14 mittels der Grundelemente der VI-Grundelemente-Bibliotheks(VIPL)-API 48 bereitgestellt. Der VI-Benutzeragent 14 empfängt die VIPL-Befehle von dem Transportdienst-Provider 13 und führt eine oder mehrere Operationen oder Funktionen aus, die dem jeweiligen VIPL-Befehl entsprechen. Wie in 5 gezeigt, werden Steueroperationen (wie beispielsweise Socket erzeugen, verbinden etc.) von dem VI-Benutzeragenten durch Systemaufrufe an den VI-Kernel-Agenten 16 ausgeführt. Beispielsweise erzeugt der VI-Benutzeragent in Reaktion auf einen Erzeuge-Socket-Befehl eine VI, die auf den Socket abgebildet wird (oder zu ihm gehört) (jeder Socket wird auf eine VI abgebildet), und registriert auch Speicher für die VI durch Systemaufrufe an den VI-Kernel-Agenten 16.
  • Sind die VIs einmal erzeugt und verbunden, kann der VI-Benutzeragent 14 entsprechend den Datenübertragungsanforderungen von der Anwendung 10 Datenübertragungsoperationen (wie Senden oder Empfangen) anfordern, indem er Deskriptoren direkt in die Sende- und Empfangswarteschlangen der entsprechenden VI eingibt, und dann auf die entsprechenden Vervollständigungen der Deskriptoren wartet oder nach ihnen pollt. Nachdem die Deskriptoren eingegeben (in den Warteschlangen platziert) sind, führt die VI NIC 18 dann die angeforderten, von den Deskriptoren beschriebenen Datenübertragungen durch, indem sie Daten direkt zwischen dem registrierten Prozessspeicher und dem Netzwerk ohne Eingreifen des VI-Kernel-Agenten 16 überträgt. Durch Eingeben von Deskriptoren in Arbeitswarteschlangen und Übertragen von Daten direkt zwischen dem registrierten Prozessspeicher und dem Netzwerk ohne das Erzeugen von Kernel-Kopien ist die Kernel-Verarbeitung und – pufferung aus dem kritischen Datenweg entfernt, wodurch der Prozessoroverhead für Datenübertragungsoperationen signifikant reduziert wird.
  • 3.1 Entwicklung und Implementierung
  • Dezentralisierte Protokollverarbeitung auf Benutzerebene, kreditbasierte Flusssteuerung, Cachen von festgelegten (pinned) Kommunikationspuffern und Minimieren von CPU-Overhead sind die Haupttechniken, die bei der Implementierung von Stream Sockets über eine VI-Architektur gemäß einer Ausführungsform der vorliegenden Erfindung verwendet werden. Zusammen mit der Entwicklung werden diese Techniken als Nächstes beschrieben.
  • 3.1.1 Endknotenabbildung und Verbindungsmanagement
  • Das von einer VI-Architektur bereitgestellte verbindungsorientierte Design bildet gut auf Stream Sockets ab. Jeder Stream Socket (Endknoten) wird auf eine VI abgebildet. Jeder Endknoten besteht aus Sende/Empfangsdeskriptoren, registrierten Sende/Empfangspuffern und Informationen für kreditbasierte Flusssteuerung. Jeder Endknoten hat eine Warteschlange an empfangenen Puffern, die von der Anwendung noch zu lesende Daten enthalten. Um die Anzahl von Speicherregistrierungen zu vermindern, werden globale Pools von Sende- und Empfangsdeskriptoren erzeugt und in einem Prozess während einer Dienst-Providerinitialisierung registriert. Während der Erzeugung eines Endknotens werden Deskriptoren aus diesen globalen Pools zugeordnet. Bei Löschung eines Endknotens werden die Deskriptoren an die globalen Pools zurückgegeben. Eine Warteschlange an ausstehenden Verbindungsanforderungen wird bei jedem Endknoten unterhalten. Ein reservierter Thread verwaltet Verbindungsanfragen am Endknoten. IP-Port-Nummern werden als Diskriminatoren bei der zugrunde liegenden Verbindungsherstellung zwischen VIs verwendet.
  • 3.1.2 Datenübertragung und Transportebenendienste
  • Der bei Datenübertragungen verwendete Zuverlässigkeitsmodus ist die zuverlässige Übergabe (von der VI-Architektur angeboten). Eine VI mit zuverlässiger Übergabe gewährleistet, dass die für die Übertragung vorgelegten Daten genau einmal, intakt und in der vorgelegten Reihenfolge ohne Fehler übertragen werden. Transportfehler sind extrem selten und werden als katastrophal angesehen. Bei Netzwerkschnittstellen, welche VI-Funktionalität emulieren, kann die zuverlässige Übergabe in NIC-Firmware oder -Software implementiert werden. Bei ursprünglichen VI NICs (wie beispielsweise die GNN1000 der cLAN-Produktfamilie, erhältlich von GigaNet, Inc.) stellt die Hardware eine zuverlässige Übergabe zur Verfügung. Aufgrund der Verwendung von VIs mit zuverlässiger Übergabe kann die Fragmentierung von Nachrichten ohne die Verwendung von Laufzahlen gehandhabt werden. Außerdem muss sich der Transportdienst-Provider 13 nicht um die Verwaltung von Quittierungen und die Detektion von Duplikaten kümmern. Zeitüberwachungs- und Übertragungswiederholungsmechanismen sind nicht im Transportdienst-Provider 13 integriert, da Transportfehler selten sind und die Verbindung unterbrochen wird, wenn Transportfehler auftreten.
  • Drei Nachrichtentypen, die bei der Datenübertragung verwendet werden, sind Kredit-Anforderung, Kredit-Antwort und Daten. Der Transportdienst-Provider 13 ist für das Bewerkstelligen von durchgehender Flusssteuerung zwischen zwei Endknoten unter Verwendung dieser Nachrichten verantwortlich. Zum Bereitstellen von durchgehender Flusssteuerung wird ein kreditbasiertes Schema verwendet. Details des kreditbasierten Flusssteuerungsschemas werden unten in Kapitel 3.4.1 beschrieben.
  • 3.1.3 Deskriptorverarbeitung
  • Bei einer VI-Architektur ist eine Datenübertragungsoperation in zwei Phasen aufgespalten: die Initialisierung der Operation (Eingeben eines Deskriptors) und den Abschluss der Opera tion (Pollen oder Warten, dass sich ein Deskriptor in einer Arbeitswarteschlange vervollständigt). Aufgrund eines Push-Modells für die Verarbeitung und zuverlässiger Hochgeschwindigkeits-SANs vervollständigen sich Sendedeskriptoren schnell, wenn sie einmal die Spitze der SendewWarteschlange erreicht haben. Um Unterbrechungen zu reduzieren, wird daher gemäß einer Ausführungsform der vorliegenden Erfindung Polling verwendet, um die Vervollständigung von Sendedeskriptoren zu überprüfen. Das Überprüfen der Vervollständigung eines Sendedeskriptors wird verschoben, bis entweder nicht genug Sendekredite verfügbar sind oder die gesamte Nachricht eingegeben wurde. Diese Art von verschobenen Ent-Einreihen von Sendedeskriptoren reduziert verglichen mit Polling sofort nach der Eingabe jedes Sendedeskriptors den Prozessor- oder CPU-Overhead.
  • Der Transportdienst-Provider 13 betreibt einen kleinen, Least-Recently-Used(LRU)-Cache (z.B. interne Puffer 75, unten für 7 beschrieben) aus registrierten Anwendungspuffern. Dies ermöglicht Sendungen ohne Kopien für häufig verwendete Anwendungspuffer. Die Anwendungsdaten werden nur in vorregistrierte Sendepuffer (z.B. Puffer 75, 7) kopiert, wenn der Anwendungspuffer (76, 7) nicht im Cache gefunden und nicht zum Cache hinzugefügt wird. Um eine anwendungsspezifische Einstellung zu ermöglichen, wird die maximale Anzahl von LRU-Cacheeinträgen und die minimale Größe von registrierten Anwendungspuffern konfigurierbar gehalten.
  • Empfangsdeskriptoren müssen vor dem Eingeben des passenden Sendedeskriptors auf der Senderseite voreingegeben werden. Die Daten werden immer aus den registrierten Empfangspuffern in die von der Anwendung für das Empfangen von Daten bereitgestellte Puffer kopiert. Das Kopieren von Daten auf der Empfängerseite kann mit VI NIC-Abarbeitungen und physikalischer Kommunikation überlagert werden. Der Empfänger wartet, wenn keine Daten am Socket verfügbar sind. Wenn der Empfänger aufgrund der Vervollständigung eines Empfangsdeskriptors aufwacht, reiht der Empfänger so viele vervollständigte Emp fangsdeskriptoren wie möglich aus. Dieses Schema für die Verarbeitung von Empfangsdeskriptoren reduziert die Anzahl von Unterbrechungen auf dem Host-System.
  • Der Transportdienst-Provider 13 für Stream Sockets über eine VI-Architektur wurde auf Benutzerebene implementiert. Dies ermöglicht eine dezentralisierte Protokollverarbeitung auf der Basis einzelner Prozesse. Die Pufferverwaltung auf Benutzerebene und das kreditbasierte Flusssteuerungsschema erfahren keine Kernel-artig restriktive Umgebung. Das Kommunikations-Untersystem wird ein integrierter Teil der Anwendung, was eine anwendungsspezifische Einstellung ermöglicht. Das nächste Unterkapitel stellt eine experimentelle Evaluierung von Stream Sockets über eine VI-Architektur bereit.
  • 3.2 Experimentelle Evaluierung
  • In den Mikro-Benchmarks einschließenden Experimenten wurde ein Serversystempaar mit vier 400 MHz-Pentium®II XeonTM-Prozessoren (512K L2 Cache), Intel AD450NX 64-Bit PCI Chipset und 256 MB Hauptspeicher als ein Paar von Host-Knoten verwendet. Eine cLANTM GNN1000-Verbindung (Vollduplex, 1,25 Gbps einfach gerichtet) von GigaNet mit VI-Funktionalität, implementiert auf NIC Hardware, wird als VI NIC 18 verwendet. Die für alle der Experimente verwendete Softwareumgebung umfasste Windows NTTM 4.0 mit Service Pack 3 und Microsoft Visual C++ 6.0. Als Standardeinstellung war die maximale Übertragungseinheit (maximum transfer unit, MTU) pro Paket, die von den Stream Sockets über eine VI-Architektur verwendet wurde, 8K Bytes, und das kreditbasierte Flusssteuerungsschema reservierte einen anfänglichen Empfangskredit von 32 für jede Verbindung. Wenn nicht anders angegeben, wurden alle der experimentellen Ergebnisse unter Verwendung dieser Standardeinstellung erzielt.
  • 3.2.1 Umlauf-Latenzzeit
  • Bei verteilten Anwendungen spielen die Umlauf-Latenzeiten von kleinen Nachrichten eine wichtige Rolle bei der Leistung und Skalierbarkeit des Systems. Um die Umlauf-Latenzzeit zu messen, wurde ein Ping-Pong Test bei den Experimenten verwendet. 6 ist eine Funktion, welche die von unbearbeiteten VI-Architektur-Grundelementen (wobei z.B. die Anwendung die VI-Architektur-Grundelemente, wie beispielsweise VipPostSend, VipPostRecv, VipSendDone, VipSendWait, VipRecvWait etc., direkt aufruft), Stream Sockets über eine VI-Architektur (GNN1000), TCP/IP über Gigabit Ethernet und TCP/IP über GNN1000 erzielte Anwendung-zu-Anwendungs-Umlauf-Latenzzeit vergleicht. Die von Stream Sockets über eine VI-Architektur erreichte Umlauf-Latenzzeit ist 2-3 Mal besser sowohl als die von TCP/IP über Gigabit Ethernet als auch die von TCP/IP über GNN1000 erreichte Umlauf-Latenzzeit. Außerdem liegt die für eine vorgegebene Nachrichtengröße erhaltene durchschnittliche Umlauf-Latenzzeit innerhalb von 50% der unter Verwendung von urbearbeiteten VI-Architektur-Grundelementen erzielten Umlauf-Latenzzeit.
  • Sockets (z.B. WinSock2) sind nur ein Typ einer Betriebssystems-Kommunikationseinrichtung, die zum Koppeln von Anwendungen mit der VI-Architektur verwendet werden kann. Viele andere Kommunikationseinrichtungen können gleichermaßen als Schnittstelle zwischen einer Anwendung und einem Dienst-Provider über eine VI-Architektur verwendet werden. Beispielsweise kann Microsoft Remote Procedure Call (MSRPC) als die Kommunikationseinrichtung verwendet werden. Zusätzliche Details bezüglich der Implementierung von Stream Sockets über eine VI-Architektur und einer Implementierung eines RPC über eine VI-Architektur kann in Hemal V. Shah et al., „High Performance Sockets and RPC Over Virtual Interface (VI) Architecture", Proceedings of the Third Workshop on Communication, Architecture, and Applications For Network-Based Parallel Computing (CANPC '99), 9.-10. Januar 1999, durch Referenz hierin enthalten, gefunden werden.
  • 3.3 Hardwaremodell eines Endknotensystems
  • 7 ist ein Blockdiagramm des Hardwaremodells eines Endknotensystems gemäß einer Ausführungsform der vorliegenden Erfindung. Das Endknotensystem 85 umfasst einen Host-Prozessor (oder CPU) 70 zum Steuern des Betriebs des Endknotensystems 85. Ein Host-Speicher 72 ist mit dem Host-Prozessor 70 mittels des Host-Busses 71 gekoppelt. Eine VI NIC 18 ist mit dem Host-Speicher 72, dem Host-Prozessor 70 und einem Netzwerk 80 gekoppelt. Ein Teil des Host-Speichers 72 ist den VI-Arbeitswarteschlangen 20, umfassend eine Sendewarteschlange 19, eine Empfangswarteschlange 21 und eine Vervollständigungs-Warteschlange 22, zugewiesen. Die Sende- und Empfangswarteschlangen können auch in der VI NIC 18 angeordnet sein. Die Sende- und Empfangswarteschlangen 21 und 19 werden zum Speichern von Deskriptoren verwendet, die von der VI NIC 18 auszuführende Arbeit (z.B. Datenübertragungsoperationen) beschreiben.
  • Ein Bereich des Host-Speichers 72 ist auch Anwendungs-Sendepuffern 76 und Anwendungs-Empfangspuffern 78 und internen Puffern 75 des Dienst-Providers zugeteilt. Die Sende- und Empfangspuffer 76 und 78 und die internen Puffer 75 können bei der VI NIC 18 registriert werden. Sind die Puffer einmal registriert, kann die VI NIC 18 eingehende Daten direkt vom Netzwerk 80 zu einem Empfangspuffer 78 übertragen, und ausgehende Daten können direkt von einem Sendepuffer 76 zum Netzwerk übertragen werden. Die Datenübertragungsoperationen werden von der VI NIC 18 ohne das Durchführen von Systemaufrufen zum Kernel und ohne das Erstellen von Zwischenkopien (wie Kernel-Kopien) der Daten ausgeführt.
  • Jedoch werden gemäß einer Ausführungsform der vorliegenden Erfindung nur die Sendepuffer 76 und die internen Puffer 75 aus 7 bei der VI NIC 18 registriert. In einem solchen Fall werden Daten für eine Sendeoperation typischerweise direkt von registrierten Sendepuffern 76 zum Netzwerk übertra gen. Für Empfangsoperationen müssen die Empfangspuffer 78 in der Anwendungs-Speicherstelle nicht registriert sein. Tatsächlich muss die Anwendung den Dienstprovider 13 zunächst nicht darüber informieren, welche Anwendungs-Speicherpuffer für das Speichern der Daten verwendet werden soll, wenn die Anwendung die Empfangsoperation anfordert. Als Ergebnis können die internen Puffer 75 des Transportdienst-Providers bereitgestellt und registriert werden, um einen registrierten Empfangspuffer für das Speichern von Daten bereitzustellen, wenn die Daten in Reaktion auf einen vervollständigten Empfangsdeskriptor empfangen werden (wenn die Empfangsoperation vervollständigt ist). Die empfangenen Daten können dann anschließend in die unregistrierte Anwendungs-Empfangspuffer 78 übertragen werden. Die internen Puffer 75 können auch als die registrierten Speicherpuffer zum Senden von Daten verwendet werden, wenn die Sendepuffer nicht im Cache gefunden werden.
  • 3.4 Betrieb eines Stream Sockets über eine VI-Architektur verwendenden Endknotensystems
  • Eine VI wird von einem VI-Provider auf die Anforderung eines VI-Konsumenten hin erzeugt. Eine VI umfasst ein Paar von Arbeitswarteschlangen (Sende- und Empfangswarteschlangen) und ein Paar von Doorbells, eine für jede Warteschlange. Die VI-Architektur stellt einen verbindungsorientierten Datenübertragungsdienst bereit. Wenn eine VI zunächst erzeugt wird, ist sie mit keiner anderen VI verbunden. Eine VI muss mit einer anderen VI durch einen bewussten Prozess verbunden werden, um Daten zu übertragen.
  • 8 ist ein Diagramm, das den Verbindungsprozess zwischen zwei Endknoten in der VI-Architektur zeigt. Das Endknotenverbindungsmodell in der VI-Architektur ist ein Client-Server-Modell. Ein Clientprozess 54 und ein Serverprozess 52 sind gezeigt. Der Clientprozess 54 erzeugt eine VI, Schritt 55, und gibt dann über eine Leitung 56 eine Verbindungsanforderung ab. Der Serverprozess 52 wartet auf eingehende Verbin dungsanforderungen und akzeptiert sie dann entweder oder weist sie zurück. Wenn eine empfangene Verbindungsanforderung akzeptabel ist, erzeugt der Serverprozess 52 eine VI, Schritt 58, und gibt ein Verbindung akzeptiert über eine Leitung 60 aus. Der Client-Prozess 54 empfängt dann das Verbindung akzeptiert und gibt eine Quittung oder Rückgabe auf Leitung 62 aus. Die Verbindung zwischen dem Client- und dem Serverprozess (VIs) ist nun hergestellt, Schritt 64.
  • Bevor Daten zwischen zwei Endknoten übertragen werden können, müssen etliche Arbeitsschritte ausgeführt werden, um die geeigneten Sockets und VIs zu erzeugen, Sende-Speicherpuffer (zum direkten Senden von Daten an das Netzwerk) zu registrieren, Empfangs-Speicherpuffer (zum direkten Empfangen von Daten aus dem Netzwerk) zu registrieren und eine Verbindung zwischen zwei Endknoten herzustellen etc.. Eine Client-Anwendung an einem Endknoten erzeugt einen Socket und initialisiert den Transportdienst-Provider (umfassend das Eröffnen einer VI NIC). Der Transportdienst 13 für den Client-Endknoten erzeugt dem Socket zugeordnete VI und registriert Speicher sowohl für Sendepuffer als auch für Empfangspuffer. Als nächstes fordert der Client eine Verbindung mit einer entfernten Endknotenanwendung an.
  • Einige der auf den verschiedenen Ebenen zum Erzeugen eines Sockets ausgeführten Schritte werden nun kurz beschrieben werden, um ein Beispiel zu liefern. In Bezug auf 5 ruft eine Anwendung 10 (die z.B. als ein Client-Prozess arbeitet) WSASocket (Domain, Typ, Protokoll) auf. WSASocket ( ) ist ein Befehl oder ein Grundelement von der WinSock API 42 (5). Der Socket-Typ ist als Stream Socket spezifiziert (im Gegensatz zu einem Datagram Socket), die Domain ist als AF_INET (das Internet) spezifiziert und das Protokoll ist als Transport_Dienst_Provider_Über_VI spezifiziert, was sich auf den Transportdienst-Provider 13 der vorliegenden Erfindung bezieht, der zum Arbeiten über die VI-Architektur ausgelegt ist. Die WinSock2-DLL ruft WSPSocket (...) des Transportdienstproviders 13 auf. WSPSocket (..) ist ein Befehl von der WinSock-Dienstprovider-Schnittstelle 46 (5). In Reaktion auf den WSPSocket(. .)-Befehl führt der Transportdienst-Provider etliche Funktionen aus und macht etliche Aufrufe des VI-Benutzeragenten 14 unter Verwendung der Grundelemente der VIPL-API 48. Der Transportdienst-Provider erzeugt eine zu diesem Socket gehörige VI unter Verwendung des VipCreateVi (.. )-Grundelements (der VIPL-API 48), teilt einen lokalen Pool von Anwendungs-Empfangspuffern und -Sendepuffern zu und registriert diesen Anwendungsspeicher unter Verwendung des vipRegisterMem(. .)-VIPL-Grundelements und gibt Empfangsdeskriptoren unter Verwendung des VipPostRecv(..)-VIPL-Grundelements im Voraus ein. Andere Funktionen werden ebenfalls vom Benutzeragenten ausgeführt. Details der vom Transportdienst-Provider 13 ausgeführten Operationen für Stream Sockets über eine VI-Architektur gemäß einer Ausführungsform der vorliegenden Erfindung werden in Anhang B in dieser Beschreibung spezifiziert. Die in Anhang B beschriebenen Operationen umfassen Initialisierung, Socket-Erzeugung, Socket-Löschung, Verbindung mit einem anderen Socket, Horchen nach Verbindungsanforderungen, Akzeptieren einer Verbindungsanforderung und Sende- und Empfangsoperationen.
  • 3.4.1 Flussteuerung und Sende- und Empfangsoperationen
  • Nachdem eine (zu dem Socket gehörige) VI erzeugt und mit einer anderen VI verbunden worden ist, können Daten zwischen den Sockets über die VI-Architektur übertragen werden. Wenn eine Anwendung Daten an einen bestimmten Socket senden möchte, ruft die Anwendung WSASend (..) auf. Die WinSock2-DLL ruft daraufhin WSPSend (. ..) des Transportdienst-Providers 13 auf. Gemäß einer Ausführungsform der vorliegenden Erfindung führt der Dienstprovider 13 dann die in den Flussdiagrammen von 9 und 10 gezeigten Schritte aus, um Daten an einen anderen Socket zu senden.
  • Gleichermaßen ruft die Anwendung WSPRecv (. ..) auf, wenn sie Daten von einem Socket empfangen möchte. Die WinSock2-DLL 44 ruft WSPRecv des Transportdienst-Providers 13 auf. Der Transportdienst-Provider führt dann die in 11 und 12 gezeigten Schritte zum Empfangen von Daten von einem Socket (oder einem anderen Endknoten) gemäß einer Ausführungsform der vorliegenden Erfindung aus.
  • Die in 9-12 gezeigten Sende- und Empfangsoperationen stellen eine transportartige Funktionalität einschließlich Flussteuerung, Fragmentierung und Wiederzusammensetzung und Puffermanagement bereit, ohne unnützen Overhead hinzuzufügen. Beispielsweise detektiert das kreditbasierte Flussteuerungsschema gemäß einer Ausführungsform der vorliegenden Erfindung, wie in 3 gezeigt, keine Datenfehler, stellt keine positive Paketquittierung bereit, führt keine Zeitüberwachung und Wiedeholungsübertragung aus, detektiert keine doppelten Pakete und stellt keine Paketsequenzierung bereit, weil diese Funktionen von der VI NIC bereitgestellt werden. Die in 9-12 gezeigten Sende- und Empfangsoperationen stellen ein synchrones kreditbasiertes Flusssteuerungsschema bereit, bei dem Kreditaktualisierungen vom Sender initiiert werden.
  • Die folgenden Bezeichnungen und Annahmen werden gemäß einer Ausführungsform der Sende- und Empfangsoperationen gemacht.
  • Bezeichnungen:
    • s – ein Socket
    • RecvCredits – die Anzahl von für das Empfangen von Daten verfügbaren Puffern
    • SendCredits – die Anzahl von am anderen Ende verfügbaren Empfangspuffern (aus der Sicht des Senders)
    • buf – ein Anwendungspuffer
    • len – die Länge von buf (in Bytes)
    • MTU – die maximale Übertragungseinheit
    • PendingCreditResponse – eine boolsche Variable, die anzeigt, ob eine Kreditantwort aussteht.
    • send(s,buf,len) – Sende len Datenbytes von buf auf Socket s
    • receive(s,buf,len) – Empfange bis zu len Bytes in buf auf Socket s
    • RecvCredits einer Anwendung entspricht SendCredits der angeschlossenen Anwendung und umgekehrt.
  • Annahmen:
  • Jeder Benutzerebenen-Stream Socket ist auf eine VI abgebildet.
  • Der von jeder VI verwendete Modus ist zuverlässige Übergabe. In diesem Zuverlässigkeitsmodus werden die für die Übertragung übermittelten Daten an ihrem Ziel genau einmal, intakt und in der übermittelten Reihenfolge ohne Fehler ankommen. Transportfehler sind selten und werden als katastrophal betrachtet. Die Verbindung wird bei der Detektion jedes Transportfehlers unterbrochen.
  • Die von beiden Endknoten verwendete maximale Übertragungseinheit (MTU) ist dieselbe (und wird während des Verbindungsaufbaus übertragen).
  • Vor dem Verbindungsaufbau zwischen zwei Endknoten wird eine endliche Anzahl von registrierten Empfangspuffern (jeweils der Größe MTU) an beiden Enden im Voraus eingegeben.
  • Der Anfangswert von SendCredits ist 0.
  • SendCredits, das die Anzahl von am anderen Endknoten zum Empfangen von Daten verfügbaren Anwendungspuffern anzeigt, wird bei der Socket-Erzeugung auf Null voreingestellt. Daher ist das Endknotensystem zunächst nicht in der Lage, Daten zum anderen Endknoten zu senden. RecvCredits, das die Anzahl von registrierten Empfangspuffern 75 an diesem Endknoten (zum Empfangen von Daten vom anderen Endknoten) anzeigt, wird bei der Socket-Erzeugung ebenfalls auf einen Wert, z.B. 32, voreingestellt.
  • Zu jeder vorgegebenen Zeit ist die Anzahl von Sendeoperationen auf einem Socket ausführenden Threads 1. Gleichermaßen ist die Anzahl von aktiven Threads zum Ausführen von Empfangsoperationen auf einem Socket zu jeder gegebenen Zeit höchstens 1.
  • Für die Empfangsoperationen werden die Daten von internen registrierten Empfangspuffern (z.B. Puffer 75, 7) in Anwendungspuffer kopiert (z.B. Anwendungs-Empfangspuffer 78, 7). Währenddessen wird für die Sendeoperationen ein Cache (z.B. Puffer 75) aus registrierten Anwendungspuffern geführt, um Sendeoperationen ohne Kopien zu ermöglichen.
  • Diese Annahmen sind einfach als ein Beispiel gegeben. Andere Annahmen oder Bedingungen können genauso getroffen werden. Die vorliegende Erfindung ist nicht auf die hier beschriebenen Annahmen oder Bezeichnungen beschränkt.
  • Drei bei der Datenübertragung verwendete Nachrichtentypen sind Kreditanforderung, Kreditantwort und Daten. Der Transportdienst-Provider 13 ist verantwortlich für das Bewerkstelligen von durchgehender Flussteuerung zwischen zwei Endknoten. Zum Bereitstellen von durchgehender Flussteuerung wird ein kreditbasiertes Schema verwendet. Wenn die Anzahl von Sendekrediten ausreicht, dann bereitet der Sender das Paket vor und sendet es. Andernfalls sendet der Sender eine Kreditanforderung (Kreditanforderung) und wartet auf eine Kreditantwort (Kreditantwort). Beim Empfangen der entsprechenden Kreditantwort fährt er mit dem Senden von Paketen fort. In Reaktion auf die Anfrage des Senders nach Kreditaktualisierung sendet der Empfänger die Kreditantwort nur, wenn er genug Empfangskredite hat (über einem Schwellenwert oder einer Low-Water-Marke). Falls er nicht genug Kredite hat, wenn die Kreditanforderung ankommt, verschiebt der Empfänger das Senden einer Kreditantwort, bis genügend Empfangskredite verfügbar sind (größer als die Low-Water-Marke). Dieses kreditbasierte Flussteuerungsschema und Fragmentierung und Wiederzusammensetzung sind durch die in 9-12 gezeigten Sende- und Empfangsoperationen implementiert. Wie in den Flussdiagrammen von 9-12 dargestellt, sind die einzigen registrierten Empfangspuffer die internen Puffer 75 (7) des Dienstproviders. In der in 9-12 beschriebenen Ausführungsform sind die Anwendungs-Empfangspuffer 78 typischerweise nicht registriert. Die Sendepuffer 76 sind registriert. Als Ergebnis werden empfangene, zu Empfangsdeskriptoren gehörige Daten in den internen Puffern 75 platziert, und dann werden die Daten als von der Anwendung ungelesen markiert (z.B. werden die Daten in eine Warteschlange eingereiht).
  • Die in 9 und 10 gezeigte Sendeoperation wird nun beschrieben. 9 ist ein Flussdiagramm, das den Ablauf einer Sendeoperation gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. Die Sendeoperation von 9 sendet eine Länge (len) an Datenbytes von einem Sendepuffer 76 (buf) auf einem Socket s (oder einem anderen Endknoten), wobei len die Länge der zu sendenden Daten anzeigt.
  • In Bezug auf 9 werden etliche Werte oder Variablen bei Schritt 100 initialisiert. Die Variable N wird auf [Pufferlänge/MTU] voreingestellt. Wenn die Pufferlänge (len) größer als die maximale Übertragungseinheit (MTU) ist, wird die Nachricht zum Senden über den Socket in N Pakete fragmentiert werden müssen. Die Sendeoperation führt die Fragmentierung automatisch durch. Wenn die Pufferlänge geringer als die MTU ist, dann wird N auf 1 voreingestellt. Daher zeigt N die zum Senden einer Nachricht erforderliche Anzahl von Paketen an. Die Variable I, die die Paketnummer anzeigt, ist auf Null voreingestellt.
  • Bei Schritt 102 geht der Prozess zu Schritt 106 weiter, wenn I kleiner als N ist, was bedeutet, dass nicht alle Pakete für die Nachricht gesendet worden sind. Andernfalls, wenn alle Pakete für die Nachricht gesendet worden sind (I ist größer als oder gleich N bei Schritt 102), dann ist die Sendeoperation abgeschlossen und setzt sich bei Schritt 104 fort.
  • Bei Schritt 106 stellt das Endknotensystem fest, ob SendCredits kleiner als oder gleich zwei ist. Wenigstens zwei registrierte Empfangspuffer 75 müssen am anderen Endknoten geführt sein, um dem Endknoten das Senden eines zusätzliche SendCredits anfordernden Pakets (einer Kreditanforderung) zu ermöglichen. Wenn SendCredits kleiner als oder gleich zwei ist, setzt sich der Prozess bei Schritt 110 fort. Andernfalls, wenn SendCredits größer als zwei ist (was bedeutet, dass es genug Empfängerpuffer am anderen Endknoten gibt), setzt sich der Prozess bei Schritt 108 fort.
  • Bei Schritt 108 hat das Endknotensystem genügend Sendekredite zum Senden eines Pakets. Daher bereitet das Endknotensystem einen Deskriptor für das I-te Paket vor und gibt ihn ein. Dies wird durch Vorbereiten eines Deskriptors für die Paketsendeoperation und anschließendes Eingeben des Deskriptors in die Sendewarteschlange 19 erledigt. Der Deskriptor beschreibt die Datenübertragungsoperation, einschließlich der Adresse oder der Speicherstelle des Speicherpuffers, der die zu sendenden Daten speichert. Das Eingeben kann vom Transportdienst-Provider 13 unter Verwendung des VipPostSend(..)-Grundelements der VIPL-API 48 (5) ausgeführt werden. Nachdem er Arbeit in einer Sendewarteschlange platziert hat, übermittelt der VI-Konsument 8 des Endknotensystems den Deskriptor für die Verarbeitung oder benachrichtigt die VI NIC 18 davon, dass Arbeit in der Sendewarteschlange 19 (1A, 1B und 2) platziert worden ist, indem er die Sende-Doorbell 25 (1B) betätigt. Die VI NIC 18 verarbeitet die Deskriptoren in der Sendewarteschlange in einer FIFO-Weise. Zum Verarbeiten dieses Sendedeskriptors überträgt die VI NIC 18 die vom Deskriptor beschriebenen Daten direkt aus dem registrierten Sende-Speicherpuffer zum Netzwerk, ohne irgendwelche Zwischenkopien zu machen, und ohne Eingreifen des Host-Prozessors 70 (7) oder Systemaufrufe des VI-Kernel-Agenten 16 (2). Die VI NIC 18 umfasst Speicherpuffer. Beim Übertragen der Daten muss die VI NIC 18 die Daten direkt von den Sende-Speicherpuffern 76 (7) der Anwendung in die VI NIC-Puffer kopieren, bevor sie die Daten zum Netzwerk 80 (7) überträgt. Jedoch werden keine Zwischendatenkopien gemacht.
  • Bei Schritt 112 wird entschieden, ob der Deskriptor für das I-te Paket erfolgreich in die Sendewarteschlange 21 eingegeben wurde. Wenn er nicht erfolgreich eingegeben wurde, wird ein Transportfehler zurückgegeben werden, der eine Unterbrechung der Verbindung anzeigt, und daraufhin wird die Operation abgebrochen, Schritt 114. Weil die VI-Architektur eine zuverlässige Übergabe bereitstellt, zeigt das erfolgreiche Eingeben eines Deskriptors an, dass das Paket höchstwahrscheinlich erfolgreich von der VI NIC 18 bearbeitet werden wird (z.B. sollten die Daten erfolgreich gesendet werden).
  • Wenn kein Transportfehler vorliegt (z.B. wurde der Deskriptor für das Paket erfolgreich eingegeben), wird die Paketezählvariable I um Eins inkrementiert, um das nächste Paket anzuzeigen, und SendCredits wird um 1 dekrementiert, Schritt 116.
  • Der Ablauf kehrt zurück zu Schritt 102, wo I mit N verglichen wird, um festzustellen, ob zusätzliche zu sendende Pakete vorliegen. wenn für diese Nachricht zusätzliche zu sendende Pakete vorliegen, dann geht der Prozess weiter zu Schritt 106, wo wiederum festgestellt wird, ob genügend SendCredits vorhanden sind. Diese Schleife aus den Schritten 102, 106, 108, 116 wiederholt sich, um Deskriptoren zum Senden aller Pakete für die Nachricht vorzubereiten und einzugeben. Wenn SendCredits kleiner als oder gleich zwei ist, so sind am anderen Endknoten nicht ausreichend Empfangspuffer vorhanden, und der Prozess setzt sich bei Schritt 110 fort.
  • Bei Schritt 110 wird eine Kreditanfrage zum anderen Endknoten gesendet. Dies wird ausgeführt, indem eine Kreditanforderung (z.B. ein Paket, das Kredit vom Endknoten anfordert) erzeugt, die Kreditanforderung in einem unmittelbaren Datenfeld eines Sendedeskriptors gespeichert und der Deskriptor dann für die Kreditanforderung in die Sendewarteschlange 21 eingegeben wird. Die VI NIC 18 wird diesen Deskriptor verarbeiten. Bei Schritt 118 wird, wenn der Deskriptor für die Kreditanforderung nicht erfolgreich eingegeben wurde, dem VI-Konsumenten ein Fehler zurückgegeben werden, und die Operation wird abgebrochen werden, Schritt 114.
  • Wenn der Deskriptor für die Kreditanforderung erfolgreich gesendet wurde, dann setzt sich der Ablauf bei Schritt 120 fort, bei dem das Endknotensystem auf eine Kreditantwort wartet. Eine Kreditantwort ist ein Paket von einem anderen Endknoten, das anzeigt, dass zusätzliche registrierte Empfangspuffer zum Empfangen von Daten verfügbar sind, und dass die SendCredits des Endknotens daher erhöht werden können.
  • Bei Schritt 122 kehrt der Ablauf dann zurück zu Schritt 102, wenn die Kreditantwort erfolgreich empfangen wurde. Andernfalls, wenn ein Fehler zurückgegeben wird, wird die Operation abgebrochen, Schritt 114.
  • 10 ist ein Flussdiagramm, das Details des Wartens auf eine Kreditantwort der Sendeoperation aus 9, Schritt 122, darstellt. Jeder Socket ist doppelgerichtet. Gleichermaßen ist jede VI doppelt gerichtet, sowohl mit Sende- als auch Empfangswarteschlangen. Eine Anwendung wird nicht zwei Threads oder Prozesse der Anwendung haben, die Daten unter Verwendung derselben Sendewarteschlange 21 senden. Jede Empfangswarteschlange 19 kann ein geteiltes Betriebsmittel sein. Ein Thread könnte versuchen, Daten über eine Empfangswarteschlange zu empfangen, während ein anderer Thread, der Daten sendet, erwarten könnte, eine Kreditantwort über dieselbe Empfangswarteschlange zu empfangen. Um diese Art von Konkurrenzsituation zu vermeiden, könnte ein Prozess oder Endknoten vor dem Lesen von Daten aus der Empfangswarteschlange 19 eine Verriegelung der (exklusiven Zugriff auf die) Empfangswarteschlange 19 durch einen Systemaufruf des VI-Kernel-Agenten 16 erlangen.
  • Drei verschiedene Paketarten können empfangen werden. Das Endknotensystem kann einen Deskriptor für eine Kreditantwort vom anderen Endknoten (gesendet in Reaktion auf eine Kreditanforderung) empfangen. Die Empfangswarteschlange 19 kann einen Deskriptor für vom anderen Endknoten empfangene Daten empfangen. Und die Empfangswarteschlange 19 kann einen Deskriptor für eine Kreditanforderung vom anderen Endknoten empfangen. Daher sollte das Endknotensystem eine Verriegelung der Empfangswarteschlange 19 erlangen, bevor es ermittelt, ob eine Kreditantwort empfangen worden ist, Schritt 130.
  • Bei Schritt 132 stellt das Endknotensystem fest, ob SendCredits größer als zwei ist (z.B. stellt es fest, ob SendCredits während des Wartens auf eine Kreditantwort oder während des Erlangens einer Verriegelung der Empfangswarteschlange aktualisiert worden ist). Wenn SendCredits größer als zwei ist (was bedeutet, dass ausreichende registrierte Empfangspuffer 75 am anderen Endknoten vorhanden sind), wird die Verriegelung der Empfangswarteschlange 19 aufgehoben, Schritt 134, und der Ablauf kehrt zurück zum Schritt 102 aus 9.
  • Wenn jedoch bei Schritt 132 SendCredits nicht größer als zwei ist, geht der Prozess zu Schritt 138, wo ein ankommendes Paket empfangen wird. Dies wird durch Warten auf das Vervollständigen eines Empfangsdeskriptors erledigt. Bei Schritt 140 wird dann, wenn sich ein Fehler ergibt, die Operation abgebrochen, Schritt 142. Wenn das Paket ohne Fehler empfangen wird, muss der Endknoten entscheiden, ob das empfangene Paket eine Kreditantwort, eine Kreditanforderung oder ein Datenpaket ist.
  • Bei Schritt 144 stellt das System fest, ob das Paket eine Kreditanforderung ist. Wenn das Paket eine Kreditanforderung ist, zeigt dies an, dass der andere Endknoten Daten senden möchte, aber nicht ausreichend SendCredits hat, und der Ablauf setzt sich bei Schritt 146 fort.
  • Sobald ein Empfangsdeskriptor von der VI NIC 18 vervollständigt ist (z.B. sobald die angeforderten Daten empfangen und in einem registrierten Empfangspuffer 75 gespeichert sind), wird der Empfangsdeskriptor aus der Empfangswarteschlange 19 ausgereiht (z.B. entfernt). Dieser Deskriptor ist nun frei, weil der entsprechende registrierte Empfangspuffer 75 verfügbar ist. Bei Schritt 146 gibt das System dann den freien (oder nicht verwendeten) Empfangsdeskriptor (bzw. die freien Empfangsdeskriptoren) wieder in die Empfangswarteschlange 19 ein und aktualisiert RecvCredits, um die zusätzlichen registrierten Empfangspuffer 75, die nun zum Empfangen von Daten verfügbar sind, wiederzugeben.
  • Bei Schritt 148 stellt der Endknoten fest, ob der Wert von RecvCredits ausreicht. In anderen Worten stellt der Endknoten fest, ob der Wert von RecvCredits größer als ein Schwellenwert ist. Wenn RecvCredits größer als der Schwellenwert ist, wird eine Kreditantwort zum anderen Endknoten gesendet, Schritt 150, und dann setzt sich der Ablauf bei Schritt 162 fort.
  • Wenn RecvCredits bei Schritt 148 nicht ausreicht, wird die Kreditantwort bei Schritt 152 als ausstehend markiert. Dies zeigt an, dass eine Kreditantwort später gesendet werden sollte, nachdem ausreichende freie Empfangsdeskriptoren eingegeben sind und RecvCredits aktualisiert ist, um größer als der Schwellenwert zu sein. Der Ablauf geht als nächstes zu Schritt 162.
  • Bei Schritt 144 entscheidet der Endknoten dann, wenn das empfangene Paket keine Kreditanforderung ist, ob das Paket eine Kreditantwort ist, Schritt 153. Wenn das Paket keine Kreditantwort ist, dann ist das Paket ein Datenpaket, und die Daten werden eingereiht und RecvCredits wird um 1 dekrementiert, um die Tatsache wiederzugeben, dass ein zusätzlicher registrierter Empfangspuffer 75 verwendet wird (nicht verfügbar ist). Entsprechend einer Ausführungsform bedeutet der Ausdruck „eingereiht", dass der registrierte Empfangspuffer (z.B. der interne Puffer 75, 7) als von der Anwendung ungelesen markiert wird.
  • Bei Schritt 153 stellt der Endknoten fest, ob das Paket eine Kreditantwort ist (auf die der Endknoten gewartet hat). Wenn das Paket eine Kreditantwort ist, wird der Wert von SendCredits bei Schritt 156 basierend auf der Kreditantwort aktualisiert (inkrementiert oder erhöht) (um zusätzliche Empfangspuffer am anderen Endknoten anzuzeigen). Der Deskriptor, der für die empfangene Kreditanforderung verwendet worden war, wird wieder in die Empfangswarteschlange 19 eingegeben.
  • Bei Schritt 158 stellt der Endknoten fest, ob der aktualisierte Wert von SendCredits größer als 2 ist. wenn SendCredits größer als 2 ist, wird die Verriegelung der Empfangswarteschlange aufgehoben, und der Ablauf kehrt zu Schritt 102 zurück, um zusätzliche Pakete wie notwendig vorzubereiten und zu senden.
  • Wenn das empfangene Paket entweder ein Datenpaket oder ein Kreditanforderung ist, setzt sich der Ablauf bei Schritt 162 fort, bei dem die Verriegelung aufgehoben wird. Als nächstes kehrt die Operation zu Schritt 130 zurück, wobei die Schritte 130-160 wiederholt werden. In den Schritten 130-160 wird ein Paket empfangen und überprüft, ob das Paket eine Kreditantwort ist. Wenn ausreichende Sendekredite erhalten werden (mittels der Kreditantwort), dann ist der Prozess von 10 beendet und kehrt zu Schritt 102 aus 9 zurück. Andernfalls, wenn das Paket keine Kreditantwort von ausreichendem Wert ist, dann fährt der Prozess fort, zusätzliche Pakete zu empfangen und zu verarbeiten, bis eine ausreichende Kreditantwort empfangen wird.
  • Nun wird die in 11 und 12 dargestellte Empfangsoperation beschrieben. 11 ist ein Flussdiagramm, das eine Empfangsoperation gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. Die Empfangsoperation von 11 empfängt bis zu einer Länge (len) an Datenbytes in einem Anwendungs-Empfangspuffer 78, 7 (buf) auf einem Socket s (oder Endknoten), wobei len die Länge der zu empfangenden Daten anzeigt.
  • In Bezug auf 11 erlangt das System bei Schritt 202 eine Verriegelung der registrierten Empfangswarteschlange 75. Bei Schritt 204 entscheidet das System, ob irgendwelche Daten empfangen und in den registrierten Empfangspuffern 75 gespeichert und als ungelesen gelistet worden sind (entscheidet, ob eingereihte Daten vorhanden sind). Das Endknotensystem unterhält eine verkettete Liste der eingereihten Daten (eine Liste der Daten, die empfangen und in Puffern 75 gespeichert worden sind und die als ungelesen von der Anwendung markiert worden sind). Wenn eingereihte Daten in den registrierten Empfangspuffern 75 gespeichert sind, setzt sich der Ablauf bei Schritt 206 fort.
  • Bei Schritt 206 führt das Endknotensystem vier Funktionen aus. 1. Die Verriegelung der Empfangswarteschlangen 75 wird aufgehoben. 2. Die Daten im registrierten Empfangspuffer 75 werden in den Anwendungs-Empfangspuffer 78 kopiert. 3. Sind die Daten von einem registrierten Empfangspuffer (bzw. Empfangspuffern) 75 in einen Anwendungs-Empfangspuffer 78 kopiert, wird der entsprechende Empfangsdeskriptor (bzw. die entsprechenden Empfangsdeskriptoren) verfügbar gemacht. Diese(r) den/dem freien (verfügbaren) registrierten Empfangspuffer(n) 75 entsprechend(en) Deskriptor(en) wird/werden dann wieder in die Empfangswarteschlage 19 eingegeben. 4. RecvCredits wird aktualisiert (z.B. inkrementiert), um anzuzeigen, dass nun ein oder mehrere zusätzliche registrierte Empfangspuffer 75 zum Empfangen von Daten verfügbar sind.
  • Als Nächstes stellt das Endknotensystem bei Schritt 208 fest, ob eine Kreditantwort aussteht. Wenn keine Kreditantwort aussteht, dann ist die Empfangsoperation abgeschlossen, Schritt 210. Andernfalls, wenn eine Kreditantwort aussteht, stellt das System fest, ob RecvCredits ausreichend ist (z.B. größer als ein Schwellenwert oder eine Low-Water-Marke), Schritt 212. Wenn die RecvCredits ausreichend sind, dann wird eine Kreditantwort zum anderen Endknoten gesendet, 214, und die Empfangsoperation ist erledigt, Schritt 210. wenn die RecvCredits nicht ausreichen, dann ist die Empfangsoperation abgeschlossen, Schritt 210.
  • Bei Schritt 204 wird, wenn keine Daten empfangen und in den registrierten Empfangspuffern 75 (7) gespeichert sind, dann ein Paket empfangen, Schritt 218. Das System bleibt bei Schritt 218, bis ein Paket empfangen wird. Ein Paket kann entweder durch Blockierungs- oder Wartemechanismen (z.B. VipRecvWait) oder durch Polling-Mechanismen (z.B. unter Verwendung der VipRecvDone(..)) empfangen werden. Daher wartet das System bei Schritt 204 auf den nächsten vervollständigten Empfangsdeskriptor. Wenn kein Fehler (Schritt 220) beim Empfangen des Pakets auftritt, entscheidet das Endknotensystem dann, ob das Paket einer von drei Pakettypen ist.
  • Bei Schritt 224 entscheidet das System, ob das Paket eine Kreditanforderung ist. wenn das Paket eine Kreditanforderung ist, bedeutet dies, dass der andere Endknoten Daten senden möchte, aber unzureichende SendCredits hat, und der Ablauf setzt sich bei Schritt 226 fort.
  • Sobald ein Empfangsdeskriptor von der VI NIC 18 vervollständigt ist (z.B., sobald die angeforderten Daten empfangen und in einem registrierten Empfangspuffer 75 gespeichert sind), wird der Empfangsdeskriptor aus den Empfangswarteschlangen 19 ausgereiht (z.B. entfernt). Datenpakete müssen eingereiht und dann in einen Anwendungspuffer 78 übertragen sein, bevor der Deskriptor ausgereiht werden kann. Jedoch können Empfangsdeskriptoren für Kreditantworten und Kreditanforderungen wieder eingegeben werden, direkt nachdem das Paket gelesen wird (da keine Daten zum Übertragen an die Anwendung vorhanden sind). Dieser Deskriptor ist nun frei, weil der entsprechende registrierte Empfangspuffer 75 nun verfügbar ist. Bei Schritt 226 gibt das System dann den freien (oder unverwendeten) Empfangsdeskriptor (bzw. die Empfangsdeskriptoren) wieder in die Empfangswarteschlange 19 ein und aktualisiert RecvCredits, um die zusätzlichen registrierten Empfangspuffer 75 wiederzugeben, die nun zum Empfangen von Daten verfügbar sind.
  • Bei Schritt 228 stellt der Endknoten fest, ob der Wert von RecvCredits ausreichend ist. Mit anderen Worten stellt der Endknoten fest, ob der wert von RecvCredits größer als ein Schwellwert ist. Wenn RecvCredits größer als der Schwellwert ist, wird eine Kreditantwort zum anderen Endknoten gesendet, Schritt 230, und dann setzt sich dem Ablauf bei Schritt 234 fort, bei dem die Verriegelung aufgehoben wird.
  • Wenn RecvCredits bei Schritt 228 nicht ausreichent, wird die Kreditantwort in Schritt 232 als ausstehend markiert. Dies zeigt an, dass eine Kreditantwort später gesendet werden sollte, nachdem ausreichend freie Empfangsdeskriptoren eingegeben sind und RecvCredits aktualisiert ist, um größer als der Schwellenwert zu sein. Der Ablauf setzt sich als Nächstes bei Schritt 234 fort, bei dem die Verriegelung aufgehoben wird.
  • Bei Schritt 224 entscheidet der Endknoten dann, wenn das empfangene Paket keine Kreditanforderung ist, ob das Paket eine Kreditantwort ist, Schritt 236. Wenn das Paket keine Kreditantwort ist, dann ist das Paket ein Datenpaket, und die empfangenen Daten werden eingereiht (auf der verketteten Liste gelistet, was anzeigt, dass die Daten im Puffer 75 gespeichert und von der Anwendung ungelesen sind), und die RecvCredits werden um 1 dekrementiert, um die Tatsache wiederzugeben, dass ein zusätzlicher registrierter Empfangspuffer 75 in Gebrauch ist (nicht verfügbar ist), Schritt 238.
  • Als Nächstes, bei Schritt 240, fragt das System den VI-Provider (z.B. die VI NIC 18) zyklisch ab, um festzustellen, ob zusätzliche empfangene Pakete vorliegen. Dies kann z.B. unter Verwendung des VipRecvDone(..)-VIPL-Grundelements getan werden. Das Ziel ist hier bei Schritt 240, alle zusätzlichen vervollständigten Empfangsdeskriptoren zu erhalten (die anzeigen, dass Pakete empfangen und in registrierten Empfangspuffern 75 gespeichert worden sind). Schritt 240 muss alle drei Pakettypen verarbeiten, was durch die in 12 dargestellten Schritte gehandhabt wird.
  • Nachdem alle zusätzlichen vervollständigten Deskriptoren empfangen worden sind (Schritt 240), kehrt der Prozess zurück zu Schritt 206. Bei Schritt 206 werden die empfangenen Daten in den Anwendungspuffer 78 kopiert, die freien Deskriptoren werden wieder in die Empfangswarteschlange 19 eingegeben, und die RecvCredits werden aktualisiert. Das Ziel bei Schritt 240 ist das Identifizieren aller empfangenen Pakete (in Puffer(n) 75 basierend auf der Detektion vollständiger Empfangsdeskriptoren), und dann werden die Daten für alle dieser Pakete zu den Anwendungspuffern 78 übertragen. Dies ermöglicht, dass alle der Empfangsdeskriptoren wieder eingegeben werden, um dem anderen Endknoten das Erlangen ausreichender SendCredits (die eine ausreichende Anzahl von verfügbaren Empfangspuffern anzeigen) so schnell wie möglich zu ermöglichen.
  • Bei Schritt 236 stellt der Endknoten fest, ob das Paket eine Kreditantwort ist. Wenn das Paket eine Kreditantwort ist, wird der Wert von SendCredits bei Schritt 242 basierend auf der Kreditantwort (zum Anzeigen zusätzlicher Empfangspuffer am anderen Endknoten) aktualisiert (inkrementiert oder erhöht). Der Deskriptor, der für die empfangene Kreditantwort verwendet worden war, ist nun frei und wird wieder in die Empfangswarteschlange 19 eingegeben, Schritt 242.
  • Außerdem wartet, wenn dieser Empfangsprozess eine Kreditantwort empfangen hat, ein anderer Thread, der Daten sendet, auf eine Kreditantwort. Daher hebt dieser Thread bei Schritt 244 die Verriegelung der Empfangswarteschlange auf (um dem Sender das Ent-Blockieren oder Fortsetzen zu ermöglichen), und wartet darauf, dass der Sender den Kreditanforderungs/Antwortaustausch verlässt oder vervollständigt, Schritt 246. Als Nächstes kehrt der Ablauf zurück zu Schritt 202, bei dem eine Verriegelung der Empfangswarteschlange erlangt wird und das System feststellt, ob Daten vorhanden sind (Schritt 204), oder ein Paket anfordert (Schritt 218).
  • 12 ist ein Flussdiagramm, das Details des Polling-Schritts aus 11 veranschaulicht. Bei Schritt 260 muss das System dann, wenn keine weiteren Pakete vorhanden sind (z.B. wenn ein vervollständigter Empfangsdeskriptor zurückgegeben wird), identifizieren, welcher Pakettyp es ist, und es entsprechend verarbeiten. Dieser Prozess von 12 umfasst die Schritte 262 (Ist es eine Kreditanforderung?), Schritt 278 (Ist es eine Kreditantwort?), Schritt 264 (Gebe freie Deskriptoren ein und aktualisiere RevCredits), Schritt 274 (Aktualisiere SendCredits und gebe freie Empfangsdeskriptoren ein), Schritt 276 (Reihe empfangene Daten ein, dekrementiere RecvCredits), Schritt 268 (RecvCredits ausreichend?), Schritt 270 (Sende Kreditantwort) und Schritt 272 (Markiere ausstehende Kreditantwort), die den Schritten 224, 236, 226, 242, 238, 228, 230 bzw. 232 aus 11 ähnlich sind. Demzufolge wird die Beschreibung dieser Schritte hier nicht wiederholt werden.
  • Detaillierter Pseudocode für Sende- und Empfangsoperationen gemäß weiteren Ausführungsformen der vorliegenden Erfindung sind im Anhand A dieser Beschreibung bereitgestellt.
  • Wie oben detailliert beschrieben, wird ein Transportdienst-Provider bereitgestellt, der zum Arbeiten über eine VI-Architektur ausgelegt ist und einige Transporttyp-Dienste bereitstellt. Der Transportdienst-Provider führt Flussteuerung, Fragmentierung und Wiederzusammensetzung und Puffermanagement aus, ohne unnützen Overhead hinzuzufügen. Ein kreditbasiertes Flussteuerungsschema verringert den Overhead, indem es sich auf die Zuverlässigkeitseigenschaften der zugrundeliegenden VI-Architektur stützt. Drei Nachrichtentypen werden in dem Flussteuerungsschema verwendet, einschließlich Kreditanforderung, Kreditantwort und Daten. Der Transportdienst-Provider ist für das Verwalten einer durchgehenden Flussteuerung zwischen zwei Endknoten (z.B. Sockets) verantwortlich.
  • Zum Bereitstellen der durchgehenden Flussteuerung wird ein kreditbasiertes Schema verwendet. Wenn die Länge der zu sendenden Datennachricht größer als die maximale Übertragungseinheit ist, dann wird die Nachricht in eine Vielzahl von Paketen fragmentiert. Wenn die Anzahl von Sendekrediten ausreicht, dann bereitet der Sender das Paket vor und sendet es. Andernfalls sendet der Sender eine Kreditanforderung und wartet auf eine Kreditantwort. Bei Empfang der entsprechenden Kreditantwort fährt der Sender mit dem Senden von Paketen fort. In Reaktion auf die Anfrage eines Senders nach einer Kreditaktualisierung (die Kreditanforderung) sendet der Empfänger die Kreditantwort nur, wenn er genügend Empfangskredite hat (über einem Schwellenwert oder einer Low-Water-Marke). Die Empfangskredite stellen registrierte Empfangspuffer dar, die zum Empfangen eingehender Pakete verfügbar sind. Hat der Sender nicht genügend Kredite (oder verfügbare Empfangspuffer), wenn die Kreditanforderung eintrifft, verschiebt der Empfänger das Senden einer Kreditantwort, bis ausreichende Empfangskredite verfügbar sind (eine ausreichende Anzahl von Empfangspuffern verfügbar wird). Gemäß einer Ausführungsform der vorliegenden Erfindung wird das kreditbasierte Flussteuerungsschema durch Sende- und Empfangsoperationen implementiert.
  • Während das Flusssteuerungsschema zum Arbeiten über die VI-Architektur ausgelegt ist, ist es nicht auf die VI-Architektur beschränkt. Vielmehr kann das Flusssteuerungsschema der vorliegenden Erfindung andere Architekturen angewendet werden. Außerdem kann das Flusssteuerungsschema vorteilhaft auf andere zugrundeliegende Architekturen angewendet werden, die identisch oder ähnlich wie die VI-Architektur sind oder eine oder mehrere ihrer grundlegenden Eigenschaften umfassen. Beispielsweise ist es unnötig, dass das Flusssteuerungsschema Datenfehler detektiert, positive Paketquittierung bereitstellt, Zeitüberwachung und Wiederholungsübertragung ausführt, doppelte Pakete detektiert oder Packetsequentierung bereitstellt, weil diese Zuverlässigkeitsfunktionen typischerweise in der zugrundeliegenden Architektur, wie bei spielsweise in der VI-Architektur, bereitgestellt sein werden. Die VI-Architektur umfasst auch unabhängige Sende- und Empfangswarteschlangen, die das Ausführen einer Datenübertragungsoperation in zwei Phasen ermöglichen, die asynchron ausgeführt werden. In einer Datenübertragung-Initialisierungs-(oder -Anforderungs-Phase) wird ein Deskriptor in eine Warteschlange eingegeben, der die Datenübertragungsoperation beschreibt. In der Feritgstellungsphase verarbeitet die zugrundeliegende Architektur den Deskriptor, indem sie die Daten zuverlässig überträgt. Overhead und Latenzzeit werden in der zugrundeliegenden Architektur verringert, weil sie die Datenübertragung direkt zwischen der Benutzerebene und dem Netzwerk bereitstellt (z.B. ohne Kernel-Verarbeitung und mit wenigen oder keinen Zwischenkopien). Daher kann der Transportdienst-Provider und das Flusssteuerungsschema der vorliegenden Erfindung vorteilhaft über jede Architektur angewendet werden, die eine oder mehrere dieser oder anderer grundlegender Eigenschaften der VI-Architektur umfasst.
  • Etliche Ausführungsformen der vorliegenden Erfindung sind hier spezifisch dargestellt und/oder beschrieben. Doch wird man verstehen, dass Modifikationen und Variationen der vorliegenden Erfindung unter die obigen Lehren und in den Bereich der beigefügten Ansprüche fallen, ohne vom beabsichtigten Bereich der Erfindung abzuweichen.
  • ANHANG A – PSEUDOCODE FÜR SENDE- UND EMPFANGSOPERATIONEN
  • Bezeichnungen:
    • s – ein Socket
    • RecvCredits – die Anzahl von für das Empfangen von Daten verfügbaren Puffern
    • SendCredits – die Anzahl von am anderen Ende verfügbaren Empfangspuffern (Sicht des Senders)
    • buf – ein Anwendungspuffer
    • len – die Länge von buf (in Bytes)
    • MTU – die maximale Übertragungseinheit
    • PendingCreditResponse – eine boolsche Variable, die anzeigt, ob eine Kreditantwort aussteht
    • send(s,buf,len) – Sende len Datenbytes von buf auf Socket s
    • receive(s,buf,len) – Empfange bis zu len Bytes in buf auf Socket s
  • Annahmen:
  • Jeder Benutzerebenen-Stream Socket ist auf eine VI abgebildet.
  • Der von jeder VI verwendete Modus ist zuverlässige Übergabe. In diesem Zuverlässigkeitsmodus werden die für die Übertragung übermittelten Daten an ihrem Ziel genau einmal, intakt und in der übermittelten Reihenfolge ohne Fehler ankommen. Transportfehler sind selten und werden als katastrophal betrachtet. Die Verbindung wird bei Detektion jeglichen Transportfehlers unterbrochen.
  • Die von beiden Endknoten verwendete maximale Übertragungseinheit (MTU) ist dieselbe.
  • Vor dem Verbindungsaufbau zwischen zwei Endknoten wird eine begrenzte Anzahl von registrierten Empfangspuffern (jeder von der Größe MTU) an beiden Enden im Voraus eingegeben.
  • Der Anfangswert von SendCredits ist 0.
  • Zu jeder vorgegebenen Zeit ist die Anzahl von Threads, die eine Sendeoperation an einem Socket ausführen, höchstens 1. Gleichermaßen ist die Anzahl von aktiven Threads zum Ausführen von Empfangsoperationen an einem Socket zu jeder gegebenen Zeit höchstens 1.
  • Für die Empfangsoperation können die Daten von registrierten internen Empfangspuffern in Anwendungspuffer kopiert werden.
  • Der Pseudocode für Sende- und Empfangsoperationen wird als Nächstes beschrieben. Bei der Beschreibung von Pseudocode wird ein C-artiger Programmierstil verwendet. Die im Pseudocode verwendeten Datenstrukturen sind lokale Datenstrukturen des Sockets.
  • Pseudocode für send(s,buf,len)
    Figure 00440001
  • Figure 00450001
  • Figure 00460001
  • Pseudocode für recv(s,buf,len)
    Figure 00460002
  • Figure 00470001
  • Figure 00480001
  • Figure 00490001
  • ANHANG B – Details der vom Transportdienst-Provider 13 für Stream Sockets über Virtuelle-Schnittstellen(VI)-Architektur ausgeführten Operationen
  • Dienstprovider-Initialisierung (WSPStartup(Y))
  • Wenn der erste Socket erzeugt wird, dann initialisiert Win-Sock2-DLL den Dienstprovider, der diesen Sockettyp unterstützt. Die folgenden Schritte sind die Schritte, die vom Dienstprovider ausgeführt werden, wenn seine Startroutine von WinSock2-DLL aufgerufen wird.
    • 1.1. Überprüfe nach der angeforderten Version.
    • 1.2. Fülle die Prozedur-Tabelle aus.
    • 1.3. Fülle die Aufruf-Prozedur-Tabelle aus.
    • 1.4. Öffne VI NIC (VipOpenNic(..)).
    • 1.5. Frage VI NIC nach NIC-Attributen ab (VipQueryNic(..)).
    • 1.6. Erzeuge Schutzetikett (VipCreatePtag(..)).
    • 1.7. Beschaffe Parameter vom Register, wie beispielsweise MTU, maximal ausstehende Verbindungen, maximale Anzahl von Sockets, maximale Datensegmente, maximal registrierte Anwendungspuffer, minimale Größe eines registrierten Anwendungspuffers, etc..
    • 1.8. Teile Raum für die interne Struktur von Endknoten zu.
    • 1.9. Erzeuge einen globalen Pool von Sendedeskriptoren und registriere einen für Sendedeskriptoren reservierten Speicher (VipRegisterMem(..)).
    • 1.10. Erzeuge einen globalen Pool von Empfangsdeskriptoren und registriere einen für Empfangsdeskriptoren reservierten Speicher (VipRegisterMem(..)).
    • 1.11. Initialisiere Namensdienst (VipNSInit(..)).
    • 1.12. Initialisiere globalen kritischen Abschnitt.
  • 2. Dienstprovider-Aufräumen (WSPCleanup(..))
  • Die Dienstprovider-Aufräum-Routine wird von WinSock2-DLL aufgerufen, wenn eine Anwendung WSACleanup(..) aufruft. Die folgenden Schritte sind die von einem Dienstprovider bei Aufruf seiner Startup-Routine ausgeführten Schritte.
    • 2.1 Lösche globalen kritischen Abschnitt.
    • 2.2 Beende Namensdienst (VipNSShutdown(..)).
    • 2.3 De-Registriere vom globalen Pool von Sendedeskriptoren verwendeten Speicher (VipDeregisterMem(..)) und gebe diesen Speicher frei.
    • 2.4 De-Registriere vom globalen Pool von Empfangsdeskriptoren verwendeten Speicher (VipDeregisterMem(..)) und gebe diesen Speicher frei.
    • 2.5 Lösche Schutzetikett (VipDestroyPtag(..)).
    • 2.6 Schließe VI NIC (VipCloseNic(..)).
  • 3. Dienstprovider-Socket-Erzeugung (WSPSocket(..))
  • Wenn die Anwendung WSASocket(..) (ähnlich wie socket(..)) aufruft und die Erzeugung eines Sockets mit einem bestimmten Dienstprovider fordert, ruft WinSock2-DLL WSPSocket(..) des Dienstproviders auf, und der Dienstprovider führt die folgenden Schritte aus.
    • 3.1 Überprüfe die Adressfamilie.
    • 3.2 Überprüfe den Socket-Typ.
    • 3.3 Überprüfe das Protokoll.
    • 3.4 Überprüfe die Gruppenparameter und die Flag-Optionen.
    • 3.5 Überprüfe die maximale Anzahl von Sockets.
    • 3.6 Teile Raum für die interne Struktur eines Endknotens zu.
    • 3.7 Erzeuge eine Ereignis-Kennung für das Akzeptieren von Verbindungen an diesem Socket.
    • 3.8 Teile Raum für entfernte Netzwerkadresse zu.
    • 3.9 Fülle VI-Attribute aus und erzeuge eine zu diesem Socket gehörige VI (VipCreateVi(..)).
    • 3.10 Teile Pufferraum für Senden und Empfangen zu.
    • 3.11 Beschaffe Sendedeskriptoren aus dem globalen Pool von Sendedeskriptoren.
    • 3.12 Teile einen lokalen Pool von Sendepuffern zu und registriere für die Sendepuffer verwendeten Speicher (VipRegisterMem(..)).
    • 3.13 Initialisiere SendCredits auf 0.
    • 3.14 Beschaffe Empfangsdeskriptoren aus dem globalen Pool von Empfangsdeskriptoren.
    • 3.15 Teile einen lokalen Pool von Empfangspuffern zu und registriere für die Empfangspuffer verwendeten Speicher (VipRegisterMem(..)).
    • 3.16 Gebe Empfangsdeskriptoren im Voraus ein (unter Verwendung von VipPostRecv(..)) und initialisiere RecvCredits.
    • 3.17 Initialisiere die von diesem Endknoten verwendeten kritischen Abschnitte.
    • 3.18 Erzeuge eine Socket-Kennung.
  • 4. Dienstprovider-Socket-Löschung (WSPCloseSocket(..))
  • Wenn eine Anwendung WSACloseSocket(..) (ähnlich wie closesocket(..)) aufruft und die Löschung eines Sockets mit einem bestimmten Dienstprovider fordert, ruft die WinSock2-DLL WSPCloseSocket(..) eines Dienstproviders auf, und der Dienstprovider führt die folgenden Schritte aus.
    • 4.1 Trenne die VI (VipDisconnect(..)).
    • 4.2 Reihe Sendedeskriptoren aus (VipSendDone(..)).
    • 4.3 Reihe Empfangsdeskriptoren aus (VipRecvDone(..)).
    • 4.4 Frage VI ab (VipQueryVi(..)).
    • 4.5 Lösche VI (VipDestroyVi(..)).
    • 4.6 De-Registriere mit lokalem Pool von Sendepuffern assoziierten Speicher (VipDeregisterMem(..)) und gebe ihn frei.
    • 4.7 Gebe Sendedeskriptoren zurück an den globalen Pool von Sendedeskriptoren.
    • 4.8 De-Registriere mit lokalem Pool von Sendepuffern assozierten Speicher (VipDeregisterMem(..)) und gebe ihn frei.
    • 4.9 Gebe Empfangsdeskriptoren zurück an den globalen Pool von Empfangsdeskriptoren
    • 4.10 Lösche mit diesem Endknoten verbundenen kritischen Abschnitt.
  • 5. Dienstprovider-Bindung an bestimmte Adresse (WSPBind(..))
  • Wenn die Anwendung WSABind(..) (or bind(..)) aufruft, ruft die WinSock2-DLL WSPBind(..) auf. Der Dienstprovider führt die folgenden Schritte durch.
    • 5.1 Kopiere IP-Adresse. Wenn INADDR_ANY spezifiziert ist, bindet es an die von gethostbyname(..) zurückgegebene Adresse.
    • 5.2 Kopiere Port-Nummer. Wenn Port 0 spezifiziert ist, teilt es dieser Adresse einen Port zu.
  • 6. Horchen des Dienstproviders nach Verbindungen (WSPListen(..))
  • Wenn eine Serveranwendung WSAListen(..)(oder listen(..)) aufruft und das Horchen nach Verbindungen an diesem Socket mit einem bestimmten Dienstprovider fordert, ruft die WinSock2-DLL WSPListen(..) des Dienstproviders auf, und der Dienstprovider führt die folgenden Schritte aus.
    • 6.1 Stelle Rückstands-Wert ein.
    • 6.2 Wenn der Socket sich nicht im Horch-Zustand befindet, dann starte einen zum Horchen nach Verbindungen an diesem Socket bestimmten Thread. Andernfalls, wenn die Anzahl von ausstehenden Verbindungen über dem neuen Rückstands-Wert liegt, dann weise die überhöhten Verbindungen zurück (VipConnectReject(..)).
  • Der Verbindungsthread führt die folgenden Operationen aus.
    • 1. Teile Raum für eine lokale VIP_NET_ADDRESS zu.
    • 2. Lade die lokale VIP_NET_ADDRESS (VipNSGetHostByName(..)).
    • 3. Kopiere Port-Nummer in das Diskriminatorfeld der lokalen VIP_NET_ADDRESS.
    • 4. Teile Raum für eine entfernte VIP_NET_ADDRESS zu.
  • Nun wiederhole die folgenden Schritte fortlaufend.
    • 5. Warte auf Verbindungsanforderungen (VipConnectWait(..)).
    • 6. Speichere nach dem Empfangen einer Verbindungsanforderung die Verbindungs-Kennung, kopiere die entfernte VIP_NET_ADDRESS und speichere die entfernten VI-Attribute.
    • 7. Wenn wir bereits die maximale Anzahl von ausstehenden Verbindungen haben, weise die Verbindungsanforderung zurück (VipConnectReject(..)). Reihe andernfalls diese
  • Verbindungsanforderung ein und wecke Threads auf, die auf das Akzeptieren von Verbindungen warten.
  • 7. Akzeptieren von Verbindungen durch den Dienstprovider (WSPAccept(..))
  • Wenn die Serveranwendung WSAAccept(..) (oder accept(..)) aufruft, ruft die WinSock2-DLL WSPAccept(..) des Dienstproviders auf. Dann führt der Dienstprovider die folgenden Schritte aus.
    • 7.1 Wenn keine ausstehenden Verbindungsanforderungen vorliegen, warte auf Verbindungsanforderungen (warte auf Akzeptierungsereignis). Führe bei Erhalt einer ausstehenden Verbindungsanforderung die nächsten Schritte aus.
    • 7.2 Erzeuge einen neuen Socket und teile Raum für eine interne Endknotenstruktur zu.
    • 7.3 Teile Raum für eine entfernte VIP_NET_ADDRESS zu und kopiere die entfernte VIP_NET_ADDRESS.
    • 7.4 Fülle VI-Attribute aus und erzeuge eine VI (VipCreateVi(..)).
    • 7.5 Teile Pufferraum für Senden und Empfangen zu.
    • 7.6 Beschaffe Sendedeskriptoren aus dem globalen Pool von Sendedeskriptoren.
    • 7.7 Teile einen lokalen Pool von Sendepuffern zu und registriere für die Sendepuffer verwendeten Speicher (VipRegisterMem(..)).
    • 7.8 Initialisiere SendCredits auf 0.
    • 7.9 Beschaffe Empfangsdeskriptoren aus dem globalen Pool von Empfangsdeskriptoren.
    • 7.10 Teile einen lokalen Pool von Empfangspuffern zu und registriere für die Empfangspuffer verwendeten Speicher (VipRegisterMem(..)).
    • 7.11 Gebe im Voraus Empfangsdeskriptoren (unter Verwendung von VipPostRecv(..)) ein und initialisiere RecvCredits.
    • 7.12 Initialisiere vom neuen Endknoten verwendete kritische Abschnitte.
    • 7.13 Wenn lokale und entfernte VI-Attribute nicht übereinstimmen, dann weise die Verbindung zurück (VipConnectReject(..)). Akzeptiere die Verbindung andernfalls (VipConnectAccept(..)).
    • 7.14 Wenn die Verbindung erfolgreich akzeptiert worden ist, dann reihe die Verbindungsanforderung aus und gibt die Kennung des neu erzeugten Sockets zurück.
  • 8. Verbindung des Dienstproviders zum Server (WSPConnect(..))
  • Wenn eine Client-Anwendung wSAConnect(..) (oder connect(..)) aufruft, ruft die WinSock2-DLL WSPConnect(..) auf. Der Dienstprovider führt die folgenden Schritte aus.
    • 8.1 Überprüfe nach ungültigen Operationen.
    • 8.2 Kopiere Socket-Adresse des entfernten Endknotens.
    • 8.3 Teile Raum für entfernte VIP_NET_ADDRESS zu.
    • 8.4 Kopiere Port-Nummer der entfernten Adresse in Diskriminatorfeld der VIP_NET_ADDRESS.
    • 8.5 Lade lokale VIP_NET_ADDRESS (VipNSGetHostByName(..)).
    • 8.6 Kopiere lokale Port-Nummer in Diskriminatorfeld der lokalen VIP_NET_ADDRESS.
    • 8.7 Sende eine Verbindungsanforderung an den Server (VipConnectRequest(..)).
    • 8.8 Warte auf Vervollständigung der Verbindungsanforderung.
    • 8.9 Gib Status der Vervollständigung der Verbindungsanforderung zurück.
  • 9. Sendeoperation des Dienstproviders (WSPSend(..))
  • Wenn die Client-Anwendung Daten an einen bestimmten Socket senden möchte, ruft sie WSASend(..) (oder send(..)) auf. Die WinSock2-DLL ruft dann WSPSend(..) des Dienstproviders auf. Dann führt der Dienstprovider die folgenden Operationen aus.
    • 9.1 Überprüfe nach ungültigen Operationen.
    • 9.2 Berechne die Anzahl der zu sendenden Pakete.
    • 9.3 Wiederhole für jedes Paket (in der richtigen Reihenfolge) die folgenden Schritte.
    • 9.3.1 Wenn SendCredits > 2, dann
    • 9.3.1.1 Lade einen freien Sendedeskriptor
    • 9.3.1.2 Konfiguriere Kontrollsegment des Sendedeskriptors.
    • 9.3.1.3 Wenn der Anwendungspuffer nicht registriert ist, dann kopiere Daten vom Anwendungspuffer in einen registrierten Sendepuffer.
    • 9.3.1.4 Konfiguriere Datensegmente des Sendedeskriptors.
    • 9.3.1.5 Gebe Sendedeskriptor (VipPostSend(..)) in Sendewarteschlange ein und handle etwaige Fehler ab.
    • 9.3.1.6 Dekrementiere SendCredits
    • 9.3.2 sonst,
    • 9.3.2.1 Lade einen freien Sendedeskriptor.
    • 9.3.2.2 Konfiguriere Sendedeskriptor zum Senden einer Kreditanforderung.
    • 9.3.2.3 Gebe Sendedeskriptor (VipPostSend(..)) in Sendewarteschlange ein und handle etwaige Fehler ab.
    • 9.3.2.4 Warte auf eine Kreditantwort. Führe während des Wartens die folgenden Schritte aus.
    • 9.3.2.4.1 Erlange Verriegelung der Empfangswarteschlange.
    • 9.3.2.4.2 Überprüfe, ob wir bereits eine Kreditantwort empfangen haben.
    • 9.3.2.4.3 Warte andernfalls auf das Vervollständigen eines Empfangsdeskriptors (VipRecvWait(..)) und handle etwaige Fehler ab.
    • 9.3.2.4.3.1 Wenn Empfangsdeskriptor erfolgreich vervollständigt ist, dann verarbeite ihn auf die folgende Weise.
    • 9.3.2.4.3.1.1 Wenn empfangenes Paket eine Kreditanforderung ist, dann
    • 9.3.2.4.3.1.1.1 Gebe den vervollständigten Empfangsdeskriptor in Empfangswarteschlange ein (VipPostRecv(..)) ein und handle etwaige Fehler ab.
    • 9.3.2.4.3.1.1.2 Lade einen freien Sendedeskriptor zum Senden einer Kreditantwort.
    • 9.3.2.4.3.1.1.3 Konfiguriere freie Empfangsdeskriptoren und gebe sie in Empfangswarteschlange ein (VipPostRecv(..)).
    • 9.3.2.4.3.1.1.4 Aktualisiere RecvCredits.
    • 9.3.2.4.3.1.1.5 Wenn RecvCredits ausreicht, dann
    • 9.3.2.4.3.1.1.5.1 Konfiguriere Sendedeskriptor für Kreditantwort.
    • 9.3.2.4.3.1.1.5.2 Gebe Sendedeskriptor in Sendewarte schlange ein handle etwaige Fehler ab.
    • 9.3.2.4.3.1.1.6 Ansonsten markiere Kreditantwort als ausstehend.
    • 9.3.2.4.3.1.2 Sonst, wenn empfangenes Paket eine Kreditantwort ist, dann
    • 9.3.2.4.3.1.2.1 Aktualisiere SendCredits.
    • 9.3.2.4.3.1.2.2 Gebe den Empfangsdeskriptor frei.
    • 9.3.2.4.3.1.2.3 Gebe ihn wieder in Empfangswarteschlange ein (VipPostRecv(..)) und handle etwaige Fehler ab.
    • 9.3.2.4.3.1.3 Ansonsten (es sind Daten) reihe die empfangenen Daten ein.
    • 9.3.2.4.3.1.3.1 Reihe empfangene Daten ein
    • 9.3.2.4.3.1.3.2 Dekrementiere RecvCredits
    • 9.3.2.4.4 Wenn wir eine Kreditantwort empfangen haben, dann fahre fort mit dem Senden dieses Pakets (Schritt 9.3.1).
    • 9.3.2.4.5 Ansonsten hebe Verriegelung der Empfangswarteschlange auf und fahre mit dem Warten auf eine Kreditantwort fort (9.3.2.4).
    • 9.4 Vervollständige alle ausstehenden Sendedeskriptoren. Wiederhole den folgenden Schritt für jeden ausstehenden Sendedeskriptor.
    • 9.4.1 Frage zyklisch nach einer Vervollständigung eines Sendedeskriptors (VipPostSend(..)) ab.
    • 9.4.2 wenn Sendewarteschlange leer ist, dann halte an (WSPSend(..) endet hier),
    • 9.4.3 Ansonsten, wenn der Sendedeskriptor erfolgreich vervollständigt ist, dann fahre mit der Verarbeitung fort (9.4.1),
    • 9.4.4 Ansonsten handle Fehler ab.
  • 10. Empfangsoperation des Dienstproviders (WSPRecv(..))
  • Wenn die Client-Anwendung Daten auf einem bestimmten Socket empfangen möchte, ruft sie WSARecv(..) (oder recv(..)) auf. Die WinSock2-DLL ruft dann WSPRecv(..) des Dienstproviders auf. Dann führt der Dienstprovider die folgenden Operationen durch.
    • 10.1 Überprüfe nach ungültigen Operationen.
    • 10.2 Wenn keine Daten an diesem Socket empfangen werden, führe die folgenden Operationen aus.
    • 10.2.1 Erlange Verriegelung der Empfangswarteschlange.
    • 10.2.2 Wenn wir Daten empfangen haben, dann ist Schritt 10.2 erledigt,
    • 10.2.3 Ansonsten warte auf die Vervollständigung eines Empfangsdeskriptors (VipRecvWait(..)) und handle etwaige Fehler ab.
    • 10.2.4 Wenn ein Empfangsdeskriptor erfolgreich vervollständigt ist, dann verarbeite ihn auf die folgende Weise.
    • 10.2.4.1 Wenn das empfangene Paket eine Kreditanforderung ist, dann
    • 10.2.4.1.1 Gebe den vervollständigten Empfangsdeskriptor in Empfangswarteschlange ein (VipPostRecv(..)) und handle etwaige Fehler ab.
    • 10.2.4.1.2 Lade einen freien Sendedeskriptor zum Senden einer Kreditantwort.
    • 10.2.4.1.3 Konfiguriere freie Empfangsdeskriptoren und gebe sie in Empfangswarteschlange ein (VipPostRecv(..)).
    • 10.2.4.1.4 Aktualisiere RecvCredits.
    • 10.2.4.1.5 Wenn RecvCredits ausreicht, dann
    • 10.2.4.1.5.1.1 Konfiguriere Sendedeskriptor für Kreditantwort.
    • 10.2.4.1.5.1.2 Gebe Sendedeskriptor in Sendewarteschlange ein (VipPostSend(..)) und handle etwaige Fehler ab.
    • 10.2.4.1.6 Ansonsten markiere Kreditantwort als ausstehend.
    • 10.2.4.2 Ansonsten, wenn das empfangene Paket eine Kreditantwort ist, dann
    • 10.2.4.2.1 Aktualisiere SendCredits.
    • 10.2.4.2.2 Gebe den Empfangsdeskriptor frei.
    • 10.2.4.2.3 Gebe den Empfangsdeskriptor zurück in die Empfangswarteschlange (VipPostRecv(..)) und handle etwaige Fehler ab.
    • 10.2.4.3 Ansonsten (es sind Daten)
    • 10.2.4.3.1 Reihe die empfangenen Daten ein und dekrementiere RecvCredits
    • 10.2.4.3.2 Polle nach weiteren vervollständigten Empfangsdeskriptoren (VipRecvDone(..)).
    • 10.2.4.3.2.1 Wenn kein vervollständigter Empfangsdeskriptor gefunden wurde, dann gehe zu Schritt 10.2.5.
    • 10.2.4.3.2.2 Ansonsten verarbeite den vervollständigten Empfangsdeskriptor auf die folgende Weise.
    • 10.2.4.3.2.2.1 Wenn das empfangene Paket eine Kreditanforderung ist, dann
    • 10.2.4.3.2.2.1.1 Gebe den vervollständigten Empfangsdeskriptor in Empfangswarteschlange ein (vipPostRecv(..)) und handle etwaige Fehler ab.
    • 10.2.4.3.2.2.1.2 Lade einen freien Sendedeskriptor zum Senden einer Kreditantwort.
    • 10.2.4.3.2.2.1.3 Konfiguriere freie Empfangsdeskriptoren und gebe sie in Empfangswarteschlange ein (VipPostRecv(..)).
    • 10.2.4.3.2.2.1.4 Aktualisiere RecvCredits.
    • 10.2.4.3.2.2.1.5 Wenn RecvCredits ausreicht, dann
    • 10.2.4.3.2.2.1.5.1 Konfiguriere Sendedeskriptor für Kreditantwort.
    • 10.2.4.3.2.2.1.5.2 Gebe Sendedeskriptor in Sendewarteschlange ein (VipPostSend(..)) und handle etwaige Fehler ab.
    • 10.2.4.3.2.2.1.6 Ansonsten markiere Kreditantwort als ausstehend.
    • 10.2.4.3.2.2.2 Ansonsten, wenn empfangenes Paket eine Kreditantwort ist, dann
    • 10.2.4.3.2.2.2.1 Aktualisiere SendCredits.
    • 10.2.4.3.2.2.2.2 Gebe den Empfangsdeskriptor frei.
    • 10.2.4.3.2.2.2.3 Gebe den Empfangsdeskriptor zurück in die Empfangswarteschlange (VipPostRecv(..)) und handle etwaige Fehler ab.
    • 10.2.4.3.2.2.3 Ansonsten reihe empfangene Daten ein.
    • 10.2.4.3.2.2.3.1 Reihe empfangene Daten ein und dekrementiere RecvCredits
    • 10.2.4.3.2.2.4 Fahre von Schritt
    • 10.2.4.3.2 fort.
    • 10.2.5 Hebe Verriegelung der Empfangswarteschlange auf.
    • 10.2.6 Kopiere empfangene Daten in Anwendungspuffer.
    • 10.2.7 Konfiguriere freie Empfangsdeskriptoren und gebe sie in die Empfangswarteschlange ein (VipPostRecv(..)).
    • 10.2.8 Wenn eine Kreditantwort aussteht und wenn wir ausreichend RecvCredits haben, dann sende eine Kreditantwort.
  • FIGURENLEGENDE
  • 1A
    • VI-ARCHITEKTURMODELL
    • 10 ANWENDUNG
    • 12 BETRIEBSSYSTEMS-KOMMUNIKATIONSEINRICHTUNG SOCKETS, MPI, CLUSTER, ANDERE
    • 14 VI-BENUTZERAGENT
    • 8 VI-KONSUMENT
    • ÖFFNE/VERBINDE/REGISTRIERE SPEICHER
    • SENDE/EMPFANGE/RDMA READ/RDMA WRITE
    • BENUTZER-MODUS
    • KERNEL-MODUS
    • 19 SENDEN
    • 21 EMPFANGEN
    • 22 VERVOLLSTÄNDIGUNG
    • 16 VI-KERNEL-AGENT
    • 24 VI-PROVIDER
    • PAKETE ZUM/VOM NETZWERK
  • 1B
    • 8 VI-KONSUMENT
    • 19 SENDE W DESKRIPTOR
    • 21 EMPFANG SW DESKRIPTOR
    • SENDE DOORBELL 25
    • EMPFANGE DOORBELL 27
    • 18 VI-NETZWERK-SCHNITTSTELLENSTEUERUNG
    • PAKETE ZUM/VOM NETZWERK
  • 2
    • 10 ANWENDUNG
    • 12 BETRIEBSSYSTEMS-KOMMUNIKATIONSEINRICHTUNG
    • 13 TRANSPORT-DIENSTPROVIDER
    • 14 VI-BENUTZERAGENT
    • 11 VI-KONSUMENT
    • ÖFFNE/VERBINDE/REGISTRIERE SPEICHER
    • SENDE/EMPFANGE/RDMA READ/RDMA WRITE
    • BENUTZER-MODUS
    • KERNEL-MODUS
    • 21 SENDEN
    • 19 EMPFANGEN
    • 22 VERVOLLSTÄNDIGUNG
    • 16 VI-KERNELAGENT
    • 24 VI-PROVIDER
    • PAKETE ZUM/VOM NETZWERK
  • 3
    • TRANSPORTDIENSTE
    • (linke Spalte)
    • VERBINDUNGSORIENTIERT
    • NACHRICHTENGRENZEN?
    • DATENPRÜFSUMME?
    • POSITIVE ACK?
    • ZEITÜBERWACHUNG UND WIEDERHOLUNGSÜBERTRAGUNG?
    • DUPLIKATDETEKTION?
    • SEQUENTIALISIERUNG?
    • FLUSSSTEUERUNG?
    • (mittlere Spalte):
    • JA NEIN
    • GLEITFENSTER (SCHLIEßT DAS OBIGE EIN)
    • (rechte Spalte):
    • TRANSPORT-DIENSTPROVIDER 13
    • BENUTZEREBENEN-STREAM SOCKETS ÜBER VI-ARCHITEKTUR
    • NEIN (VI NIC STELLT SIE BEREIT)
    • NEIN (TRANSPORTFEHLER SIND BEI VIS MIT ZUVERLÄSSIGER ÜBERGABE UND ZUVERLÄSSIGEM EMPFANGS SELTEN, UND DIE VERBINDUNG WIRD IM FALL EINES VERLORENEN PAKETS UNTERBROCHEN)
    • NEIN (BEI VIS MIT ZUVERLÄSSIGER ÜBERGABE UND ZUVERLÄSSIGEM EMPFANG SIND TRANSPORTFEHLER SELTEN, UND BEI TRANSPORTFEHLERN WIRD DIE VERBINDUNG UNTERBROCHEN)
    • NEIN (VIS MIT ZUVERLÄSSIGER ÜBERGABE UND ZUVERLÄSSIGEM EMPFANG GEWÄHRLEISTEN GENAU EINE ÜBERGABE)
    • NEIN (VIS MIT ZUVERLÄSSIGER ÜBERGABE UND ZUVERLÄSSIGEM EMPFANG GEWÄHRLEISTEN EINE ÜBERGABE IN DER RICHTIGEN REIHENFOLGE)
    • KREDITBASIERT (LEICHT, SENDER-INITIIERTE, SYNCHRONE KREDITAKTUALISIERUNGEN)
  • 4
    • WINSOCK 2-ANWENDUNG WINSOCK 2-API
    • TRANSPORTFUNKTIONEN/NAMENSRAUMFUNKTIONEN
    • WINSOCK 2-TRANSPORT-SPI WINSOCK 2-NAMENSRAUM-SPI
    • TRANSPORT-DIENSTPROVIDER NAMENSRAUM-DIENSTPROVIDER
    • WINDOWS SOCKETS 2-ARCHITEKTUR
  • 5
    • FÜR VI-ARCHITEKTUR OPTIMITIERTER BENUTZEREBENEN-STACK
    • 10 ANWENDUNG
    • 46 WINSOCK-DIENSTPROVIDER-SCHNITTSTELLE
    • !§ TRANSPORT-DIENSTPROVIDER
    • 15 FLUSSSTEUERUNGSDIENSTE
    • 14 VI-BENUTZERAGENT
    • BENUTZERMODUS
    • STEUEROPERATIONEN (Z.B. ÖFFNEN, VERBINDEN, REGISTRIEREN VON SPEICHER)
    • DATENÜBERTRAGUNGSOPERATIONEN (Z.B. SENDEN, EMPFANGEN, RDMA READ, RDMA WRITE)
    • KERNEL-MODUS
  • 6
    • URSPRÜNGLICHE VI-ARCHITEKTUR
    • STREAM SOCKETS ÜBER VI-ARCHITEKTUR
    • UMLAUFZEIT (IN MIKROSEKUNDEN)
    • ANWENDUNGSNACHRICHTENGRÖSSE (IN BYTES)
    • UMLAUFLATENZ
  • 7
    • VI-ARBEITSWARTESCHLANGEN
    • ANWENDUNGSSENDE- UND EMPFANGSPUFFER
    • SENDEWARTESCHLANGE
    • EMPFANGSWARTESCHLANGE
    • VERVOLLSTÄNDIGUNGSWARTESCHLANGE
    • SENDEPUFFER
    • EMPFANGSPUFFER
    • HOSTROZESSOR (CPU)
    • INTERNE PUFFER DES DIENSTPROVIDERS (CACHE)
    • HOSTSPEICHER
    • DATENWEG
    • PAKETE
    • NETZWERK
  • 8
    • 52 SERVERPROZESS
    • 54 CLIENTPROZESS
    • CONNECTWAIT MIT KRITERIEN FÜR CONNECTIONADDRESS AUSGEGEBEN
    • 55 ERZEUGE VI
    • ZEITÜBERSCHREITUNG CONNECTWAIT WARTEN
    • CONNECTREQUEST PASSEND ZU CONNECTIONADDRESS-KRITERIEN EMPFANGEN
    • CONNECTREQUEST AN CONNECTIONADDRESS AUSGEGEBEN
    • ATTRIBUTE NICHT AKZEPTABEL, CONNECTIONREJECT AUSGEGEBEN
    • ÜBERPRÜFEN VON VERBINDUNGSATTRIBUTEN
    • VERBINDUNGSATTRIBUTE AKZEPTABEL
    • 58 ERZEUGE VI, RUFE CONNECTACCEPT AUF
    • CONNECTACCEPT GIBT FEHLER ZURÜCK
    • CONNECTACCEPT AUF CONNECTIONID AUSGEGEBEN
    • WARTEN AUF ANTWORT
    • CONNECTIONREQUEST ZURÜCKGEWIESEN ODER ZEITÜBERSCHREITUNG
    • LÖSCHE VI
    • WARTEN AUF ZURÜCKGABE VON ACCEPT
    • CONNECTIONREQUEST AKZEPTIERT
    • CONNECTACCEPT ERFOLGREICH ZURÜCKGEGEBEN
    • CONNECTREJECT AUSGEGEBEN
    • 64 VI VERBUNDEN
  • 9
    • FLUSSDIAGRAMM FÜR SEND(S,BUF,LEN)
    • 104 ERLEDIGT
    • 108 BEREITE I-TES PAKET VOR GEBE I-TES PAKET EIN
    • 110 SENDE KREDITANFORDERUNG
    • 112 TRANSPORTFEHLER?
    • 114 VERBINDUNG UNTERBROCHEN. ABBRUCH
    • 120 WARTEN AUF KREDITANTWORT
    • JA
    • NEIN
  • 10
    • DETAILS DES WARTENS AUF EINE KREDITANTWORT EINTRITT
    • 130 ERLANGE VERRIEGELUNG DER EMPFANGSWARTESCHLANGE
    • 162,134 HEBE VERRIEGELUNG DER EMPFANGSWARTESCHLANGE AUF
    • 136 ERLEDIGT
    • 138 EMPFANGE EIN PAKET
    • 140 TRANSPORTFEHLER?
    • 142 VERBINDUNG UNTERBROCHEN. ABBRUCH
    • 144 IST ES EINE KREDITANFORDERUNG?
    • 153 IST ES EINE KREDITANTWORT?
    • 154 REIHE EMPFANGENE DATEN EIN. RECVCREDITS- -
    • 146 GEBE FREIE EMPFANGSDESKRIPTOREN EIN UND AKTUALISIERE RECVCREDITS
    • 156 AKTUALISIERE SENDCREDITS UND GEBE FREIEN EMPFANGSDESKRIPTOR EIN
    • 148 RECVCREDITS AUSREICHEND?
    • 150 SENDE KREDITANTWORT
    • 152 MARKIERE AUSSTEHENDE KREDITANTWORT
    • 160 HEBE VERRIEGELUNG DER EMPFANGSWARTESCHLANGE AUF. ERLEDIGT
    • JA
    • NEIN
  • 11
    • FLUSSDIAGRAMM VON RECV(S,BUF,LEN)
    • EINTRITT
    • 202 ERLANGE VERRIEGELUNG DER EMPFANGSWARTESCHLANGE
    • 234 HEBE VERRIEGELUNG DER EMPFANGSWARTESCHLANGE AUF
    • 204 SIND EMPFANGENE DATEN VORHANDEN?
    • 218 EMPFANGE EIN PAKET
    • 220 TRANSPORTFEHLER?
    • VERBINDUNG UNTERBROCHEN. ABBRUCH
    • 224 IST ES EINE KREDITANFORDERUNG?
    • 226 GEBE FREIE EMPFANGSDESKRIPTOREN EIN UND AKTUALISIERE RECVCREDITS
    • 228 RECVCREDITS AUSREICHEND?
    • 230 SENDE KREDITANTWORT
    • 232 MARKIERE AUSSTEHENDE KREDITANTWORT
    • 206 1. HEBE VERRIEGELUNG DER EMPFANGSWARTESCHLANGE AUF 2. KOPIERE BIS ZU LEN BYTES AN EMPFANGENEN DATEN IN ANWENDUNGSPUFFER (BUF) 3. GEBE VOLLSTÄNDIG KOPIERTE EMPFANGSPUFFER FREI UND GEBE IHRE ENTSPRECHENDEN EMPFANGSDESKRIPTOREN EIN 4. AKTUALISIERE RECVCREDITS
    • 208 STEHT KREDITANTWORT AUS?
    • 210 ERLEDIGT
    • 214 SENDE KREDITANTWORT
    • 212 RECVCREDITS AUSREICHEND?
    • 236 IST ES EINE KREDITANTWORT?
    • 242 AKTUALISIERE SENDCREDITS UND GEBE FREIEN EMPFANGSDESKRIPTOR EIN
    • 244 HEBE VERRIEGELUNG DER EMPFANGSWARTESCHLANGE AUF.
    • 246 WARTE AUF BEENDEN DER KREDITANFORDERUNG/ANTWORT DURCH DEN SENDERS
    • 238 REIHE EMPFANGENE DATEN EIN. RECV-CREDITS- -
    • 214 POLLEN NACH MEHR EMPFANGENEN PAKETEN
    • JA
    • NEIN
  • 12
    • DETAILS DES POLLENS NACH MEHR EMPFANGENEN PAKETEN EINTRITT
    • 260 MEHR EMPFANGENE PAKETE?
    • POLLING ERLEDIGT
    • TRANSPORTFEHLER?
    • VERBINDUNG UNTERBROCHEN. ABBRUCH
    • 262 IST ES EINE KREDITANFORDERUNG?
    • 278 IST ES EINE KREDITANTWORT?
    • 264 GEBE FREIE EMPFANGSDESKRIPTOREN EIN UND AKTUALISIERE RECVCREDITS
    • 274 AKTUALISIERE SENDCREDITS UND GEBE FREIEN EMPFANGSDESKRIPTOR EIN
    • 276 REIHE EMPFANGENE DATEN EIN. RECVCREDITS- -
    • 268 RECVCREDITS AUSREICHEND?
    • 270 SENDE KREDITANTWORT 272 MARKIERE AUSSTEHENDE KREDITANTWORT
    • JA
    • NEIN

Claims (20)

  1. Verfahren zum Senden von Daten von einem lokalen Endknotensystem zu einem entfernten Endknotensystem über ein Netzwerk, wobei das lokale Endknotensystem eine Vielzahl von Arbeits-Warteschlangen für das Eingeben von Datenübertragungsanforderungen umfasst und das Verfahren die folgenden Schritte umfasst: Ermitteln, ob eine ausreichende Anzahl von Sende-Krediten am lokalen Endknotensystem verfügbar ist, wobei die Kredite ein oder mehrere für das Empfangen und Speichern eines Datenpakets verfügbare Empfangsbuffer sind; Senden eines Datenpakets zum entfernten Endknotensystem von dem lokalen Endknotensystem über das Netzwerk, wenn eine ausreichende Anzahl von Sende-Krediten verfügbar ist; wobei das Verfahren dadurch gekennzeichnet ist, dass es die folgenden Schritte umfasst: andernfalls, wenn keine ausreichende Anzahl von Sende-Krediten am lokalen Endknotensystem verfügbar ist, Senden eines Kredit-Anforderungspakets vom lokalen Endknotensystem zum entfernten Endknotensystem, wobei ein Kredit-Anforderungspaket ein Paket ist, das Kredit vom Endknoten anfordert, und Warten auf ein Kredit-Antwortpaket vom entfernten Endknotensystem vor dem Senden eines Datenpakets, wobei das Kredit-Antwortpaket verfügbare Empfangsbuffer am entfernten Endknotensystem anzeigt.
  2. Verfahren nach Anspruch 1, das außerdem die folgenden Schritte umfasst: Ermitteln, ob die zu sendenden Daten größer als eine maximale Datenübertragungseinheit ist, die über das Netzwerk übertragen werden kann; Zerstückeln der zu sendenden Daten in eine Vielzahl von Datenpaketen, wenn die zu sendenden Daten größer als die maximale Datenübertragungseinheit ist; und Senden jedes Datenpakets vom lokalen Endknotensystem über das Netzwerk, wenn ausreichende Sende-Kredite verfügbar sind.
  3. Verfahren nach Anspruch 1, bei dem jeder der dem lokalen Endknotensystem bereitgestellten Sende-Kredite einen oder mehrere Empfangsbuffer repräsentiert, die am entfernten Endknotensystem zum Empfangen und Speichern eines Datenpakets zur Verfügung stehen.
  4. Verfahren nach Anspruch 1, bei dem der Schritt des Sendens eines Datenpakets die folgenden Schritte umfasst: Vorbereiten eines Deskriptors, der die auszuführende Sendeoperation beschreibt; und Eingeben des Deskriptors in eine der Arbeits-Warteschlangen.
  5. Verfahren nach Anspruch 4, bei dem das lokale Endknotensystem außerdem eine Vielzahl von Sendebuffern umfasst, welche die zu sendenden Daten speichern, wobei der Schritt des Sendens eines Datenpakets die folgenden Schritte umfasst: Vorbereiten eines Deskriptors, der die auszuführende Sende-Operation beschreibt; Eingeben des Sende-Deskriptors in eine der Arbeits-Warteschlangen; Verarbeiten des eingegebenen Sende-Deskriptors durch Übertragen der Daten aus einem der Sendebuffer zum Netzwerk.
  6. Verfahren nach Anspruch 1, bei dem das lokale Endknotensystem außerdem eine Vielzahl von Sende- und Empfangsbuffern umfasst, wobei der Schritt des Wartens auf ein Kredit-Antwortpaket die folgenden Schritte umfasst: Empfangen eines Pakets vom entfernten Endknotensystem; Ermitteln, ob das empfangene Paket ein Datenpaket, ein Kredit-Anforderungspaket oder ein Kredit-Antwortpaket ist; falls das empfangene Paket ein Kredit-Anforderungspaket ist, dann Senden eines Kredit-Antwortpakets zum entfernten Endknotensystem, wenn die Anzahl von verfügbaren oder freien Empfangsbuffern am lokalen Endknotensystem größer als der Schwellwert ist; Aktualisieren der Anzahl von Sende-Krediten am lokalen Endknotensystem, wenn das empfangene Paket eine Kredit-Antwort ist; und Verarbeiten der empfangenen Daten, wenn das empfangene Paket ein Datenpaket ist.
  7. Verfahren nach Anspruch 1, bei dem das lokale Endknotensystem außerdem eine Vielzahl von Sende- und Empfangsbuffern umfasst, wobei der Schritt des Wartens auf ein Kredit-Antwortpaket die folgenden Schritte umfasst: Empfangen eines Pakets vom entfernten Endknotensystem; Ermitteln, ob das empfangene Paket ein Datenpaket, ein Kredit-Anforderungspaket oder ein Kredit-Antwortpaket ist; falls das empfangene Paket ein Kredit-Anforderungspaket ist, dann Ausführen der folgenden Schritte: 1) Identifizieren der Anzahl von verfügbaren oder freien Empfangsbuffern am lokalen Endknotensystem; 2) Ermitteln, ob die Anzahl der freien Empfangsbuffer größer als ein Schwellwert ist; und 3) Senden eines Kredit-Antwortpakets zum entfernten Endknotensystem, falls die Anzahl der freien Empfangsbuffer Empfangsbuffern am lokalen Endknotensystem größer als der Schwellwert ist; Aktualisieren der Anzahl von Sende-Krediten am lokalen Endknotensystem, wenn das empfangene Paket eine Kredit-Antwort ist; und Verarbeiten der empfangenen Daten, wenn das empfangene Paket ein Datenpaket ist.
  8. Verfahren nach Anspruch 7, bei dem der Schritt des Verarbeitens der empfangenen Daten den Schritt des Einreihens der empfangenen Daten umfasst.
  9. Verfahren nach Anspruch 8, bei dem der Schritt des Einreihens den Schritt des Markierens der empfangenen Daten als von einer Anwendung ungelesen umfasst.
  10. Verfahren zum Empfangen von Daten an einem entfernten Endknotensystem von einem lokalen Endknotensystem über ein Netzwerk, wobei das entfernte Endknotensystem eine Vielzahl von Arbeits-Warteschlangen für das Eingeben von Datenübertragungsanforderungen, einen oder mehrere registrierte Sende- und Empfangsbuffer und einen oder mehrere Anwendungs-Empfangsbuffer umfasst, wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist: Empfangen eines Pakets vom lokalen Endknotensystem; Ermitteln, ob das Paket ein Datenpaket oder ein Kredit-Anforderungspaket ist, wobei das Kredit-Anforderungspaket ein Paket ist, das Kredit vom Endknoten anfordert; Ausführen der folgenden Schritte, wenn Daten vorliegen, die vom entfernten Endknotensystem empfangen und in den registrierten Empfangsbuffern gespeichert wurden: Kopieren der Daten aus den registrierten Empfangsbuffern in einen der Anwendungs-Emfangsbuffer; Verfügbarmachen oder Freigeben von beliebigen registrierten Empfangsbuffern, die in die Anwendungs-Empfangsbuffer kopiert wurden; Aktualisieren einer Anzahl von Empfangs-Krediten, basierend auf dem Schritt des Freigebens oder Verfügbarmachens von beliebigen registrierten Empfangsbuffern; und Ausführen der folgenden Schritte, wenn das empfangene Paket ein Kredit-Anforderungspaket ist: Ermitteln der Anzahl von verfügbaren oder freien registrierten Empfangsbuffern; Senden eines Kredit-Antwortpakets, wobei das Kredit-Antwortpaket verfügbare Empfangsbuffer am entfernten Endknotensystem anzeigt, an das lokale Endknotensystem, falls eine ausreichende Anzahl von freien registrierten Empfangsbuffern am entfernten Endknotensystem verfügbar ist, andernfalls Markieren einer ausstehenden Kredit-Antwort, wenn keine ausreichende Anzahl von freien Empfangsbuffern am entfernten Endknotensystem verfügbar ist.
  11. Verfahren nach Anspruch 10, das außerdem die folgenden Schritte umfasst: Ermitteln, ob eine Kredit-Antwort aussteht; und Ausführen der folgenden Schritte, wenn eine Kredit-Antwort aussteht: Ermitteln, ob die Anzahl freier Empfangsbuffer am entfernten Endknotensystem größer als ein Schwellwert ist; und Senden eines Kredit-Antwortpakets, wobei das Kredit-Antwortpaket verfügbare Empfangsbuffer am lokalen Endknotensystem anzeigt, an das lokale Endknotensystem, falls die Anzahl von freien Empfangsbuffern am entfernten Endknotensystem größer als der Schwellwert ist.
  12. Verfahren nach Anspruch 10, das außerdem die folgenden Schritte umfasst: Empfangen eines Pakets; Ermitteln, ob das Paket ein Datenpaket ist; Ausführen des folgenden zusätzlichen Schritts, wenn das Paket ein Datenpaket ist: Pollen nach zusätzlichen Paketen, die vom entfernten Endknotensystem empfangen worden sind.
  13. Verfahren nach Anspruch 10, das außerdem folgende Schritte umfasst: Empfangen eines Pakets an dem entfernten Endknotensystem; Entscheiden, ob das am entfernten Endknotensystem empfangene Paket ein Kredit-Antwortpaket ist, wobei das Kredit-Antwortpaket verfügbare Empfangsbuffer am entfernten Endknotensystem anzeigt; Aktualisieren der Anzahl von Sende-Krediten, wobei die Kredite ein oder mehrere für das Empfangen und Speichern eines Datenpakets verfügbare Empfangsbuffer sind, am entfernten Endknotensystem, falls das empfangene Paket ein Kredit-Antwortpaket ist.
  14. Verfahren nach Anspruch 13, das außerdem das Ausführen des folgenden Schritts umfasst, falls das empfangene Paket ein Kredit-Antwortpaket ist: Warten auf einen Sender zum Vervollständigen eines Kredit-Anforderungs-/Kredit-Antwort-Austauschs vor dem Empfangen zusätzlicher Pakete.
  15. Verfahren nach Anspruch 13, bei dem das Verfahren vor dem Empfangen des Pakets am entfernten Endknotensystem außerdem das Ermitteln umfasst, ob eine Anzahl von Sende-Krediten am entfernten Endknotensystem wenigstens eine vorgegebene Anzahl ist.
  16. Verfahren nach Anspruch 15, bei dem, falls die ermittelte Anzahl von Sende-Krediten weniger als die vorgegebene Anzahl ist, das Verfahren dann außerdem das Senden einer Kredit-Anforderung an das lokale Endknotensystem umfasst.
  17. Verfahren nach Anspruch 1, das außerdem die folgenden Schritte umfasst: Zerstückeln der zu sendenden Daten in zwei oder mehrere Datenpakete; und Dekrementieren der Anzahl von verfügbaren Sende-Krediten nach dem Senden des Datenpakets.
  18. Endknotensystem zum Ausführen aller Schritte der Verfahrensansprüche 1 oder 10, wobei das Endknotensystem umfasst einen Host-Prozessor (70); eine oder mehrere Arbeits-Warteschlangen (20) zum Eingeben von Datenübertragungsanforderungen; einen oder mehrere registrierte Sendebuffer (76); einen oder mehrere registrierte Empfangsbuffer (78); eine mit dem Host-Prozessor (70), den Arbeits-Warteschlangen (20), den Buffern (76, 78) und dem Netzwerk (80) gekoppelte Netzwerkschnittstellen-Steuerung (18), wobei die Netzwerkschnittstellen-Steuerung (18) die eingegebenen Datenübertragungsanforderungen durch das Übertragen von Daten zwischen den registrierten Buffern (76, 78) und dem Netzwerk (80) verarbeitet; und wobei der Host-Prozessor (70) zum Steuern der von der Netzwerkschnittstellen-Steuerung (18) ausgeführten Datenübertragung durch Implementieren eines kredit-basierten Ablaufsteuerungsschema programmiert ist.
  19. Endknotensystem nach Anspruch 18, bei dem der Hostprozessor (70) zum Auszuführen des Folgenden programmiert ist. Ermitteln, ob eine ausreichende Anzahl von Sende-Krediten am lokalen Endknotensystem verfügbar ist, wobei die Kredite ein oder mehrere für das Empfangen und Speichern eines Datenpakets verfügbare Empfangsbuffer sind; Senden eines Datenpakets vom lokalen Endknotensystem über das Netzwerk, falls eine ausreichende Anzahl von Sende-Krediten verfügbar ist; und andernfalls, wenn keine ausreichende Anzahl von Sende-Krediten am lokalen Endknotensystem verfügbar ist, Senden eines Kredit-Anforderungspakets vom lokalen Endknotensystem, das Kredite anfordert, zum entfernten Endknotensystem, und Warten auf ein Kredit-Antwortpaket vom entfernten Endknotensystem vor dem Senden eines Datenpakets, wobei das Kredit-Antwortpaket verfügbare Empfangsbuffer am entfernten Endknotensystem anzeigt.
  20. Verfahren zum Übertragen von Daten zwischen einem ersten und einem zweiten Endknotensystem über ein System-Netzwerk, wobei jedes Endknotensystem registrierte Sende- und Empfangsbuffer zum Senden und Empfangen von Daten umfasst, das umfasst: Ermitteln, ob eine ausreichende Anzahl von Sende-Krediten am ersten Endknotensystem verfügbar ist; Senden eines Datenpakets vom ersten Endknotensystem zum zweiten Endknotensystem über das Netzwerk, falls eine ausreichende Anzahl von Sende-Krediten am ersten Endknotensystem verfügbar ist; wobei das Verfahren gekennzeichnet ist durch andernfalls, wenn keine ausreichende Anzahl von Sende-Krediten am ersten Endknotensystem verfügbar ist, Senden ei nes Kredit-Anforderungspakets vom ersten Endknotensystem zum zweiten Endknotensystem, und Warten auf ein Kredit-Antwortpaket vom zweiten Endknotensystem vor dem Senden eines Datenpakets; und dadurch, dass das zweite Endknotensystem die Anzahl von verfügbaren Empfangsbuffern am zweiten Endknotensystem bestimmt, und dass das zweite Endknotensystem nur ein Kredit-Antwortpaket als Antwort auf das Kredit-Anforderungspaket zum ersten Endknotensystem sendet, wenn die Anzahl der verfügbaren Empfangsbuffer am zweiten Endknotensystem größer als ein Schwellwert ist.
DE60027404T 1999-01-08 2000-01-07 Kreditbasiertes flusskontrollverfahren Expired - Lifetime DE60027404T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US11539699P 1999-01-08 1999-01-08
US115396P 1999-01-08
US09/377,914 US6347337B1 (en) 1999-01-08 1999-08-20 Credit based flow control scheme over virtual interface architecture for system area networks
US377914 1999-08-20
PCT/US2000/000290 WO2000041358A2 (en) 1999-01-08 2000-01-07 A credit based flow control method

Publications (2)

Publication Number Publication Date
DE60027404D1 DE60027404D1 (de) 2006-05-24
DE60027404T2 true DE60027404T2 (de) 2007-02-01

Family

ID=26813150

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60027404T Expired - Lifetime DE60027404T2 (de) 1999-01-08 2000-01-07 Kreditbasiertes flusskontrollverfahren

Country Status (6)

Country Link
US (2) US6347337B1 (de)
EP (1) EP1142215B1 (de)
AT (1) ATE323989T1 (de)
AU (1) AU2492900A (de)
DE (1) DE60027404T2 (de)
WO (1) WO2000041358A2 (de)

Families Citing this family (161)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI970784A (fi) * 1997-02-25 1998-08-26 Nokia Telecommunications Oy Prosessien välinen vuonvalvonta hajautetussa moniprosessoriympäristössä
US6545981B1 (en) 1998-01-07 2003-04-08 Compaq Computer Corporation System and method for implementing error detection and recovery in a system area network
US6493343B1 (en) * 1998-01-07 2002-12-10 Compaq Information Technologies Group System and method for implementing multi-pathing data transfers in a system area network
US6978312B2 (en) * 1998-12-18 2005-12-20 Microsoft Corporation Adaptive flow control protocol
US6747949B1 (en) * 1999-05-21 2004-06-08 Intel Corporation Register based remote data flow control
US6529972B1 (en) * 1999-08-10 2003-03-04 Intel Corporation Message translation and data proxy service for remote data transport in a computer network
AU7060300A (en) 1999-08-16 2001-03-13 Iready Corporation Internet jack
US7281030B1 (en) * 1999-09-17 2007-10-09 Intel Corporation Method of reading a remote memory
US6791989B1 (en) * 1999-12-30 2004-09-14 Agilent Technologies, Inc. Fibre channel interface controller that performs non-blocking output and input of fibre channel data frames and acknowledgement frames to and from a fibre channel
US6718370B1 (en) * 2000-03-31 2004-04-06 Intel Corporation Completion queue management mechanism and method for checking on multiple completion queues and processing completion events
US6799220B1 (en) * 2000-04-13 2004-09-28 Intel Corporation Tunneling management messages over a channel architecture network
US6912576B1 (en) * 2000-05-04 2005-06-28 Broadcom Corporation System and method of processing data flow in multi-channel, multi-service environment by dynamically allocating a socket
US20020042763A1 (en) * 2000-06-16 2002-04-11 Ranjini Pillay Apparatus and method for providing trade credit information and/or trade credit insurance information
US6910063B1 (en) * 2000-06-28 2005-06-21 Microsoft Corporation System and method of enhancing web server throughput in single and multiple processor systems
US6879587B1 (en) * 2000-06-30 2005-04-12 Intel Corporation Packet processing in a router architecture
US7305486B2 (en) * 2000-06-30 2007-12-04 Kanad Ghose System and method for fast, reliable byte stream transport
US7213087B1 (en) * 2000-08-31 2007-05-01 Hewlett-Packard Development Company, L.P. Mechanism to control the allocation of an N-source shared buffer
US6725311B1 (en) * 2000-09-14 2004-04-20 Microsoft Corporation Method and apparatus for providing a connection-oriented network over a serial bus
US6820129B1 (en) * 2000-09-22 2004-11-16 Hewlett-Packard Development Company, L.P. System and method of managing network buffers
US7039717B2 (en) * 2000-11-10 2006-05-02 Nvidia Corporation Internet modem streaming socket method
US20020099851A1 (en) * 2001-01-22 2002-07-25 Shah Hemal V. Decoupling TCP/IP processing in system area networks
US7024479B2 (en) * 2001-01-22 2006-04-04 Intel Corporation Filtering calls in system area networks
US6977939B2 (en) * 2001-01-26 2005-12-20 Microsoft Corporation Method and apparatus for emulating ethernet functionality over a serial bus
US7379475B2 (en) * 2002-01-25 2008-05-27 Nvidia Corporation Communications processor
US6975593B2 (en) * 2001-04-03 2005-12-13 Sun Microsystems, Inc. Method for triggering flow control packets
US6820150B1 (en) * 2001-04-11 2004-11-16 Microsoft Corporation Method and apparatus for providing quality-of-service delivery facilities over a bus
US7190667B2 (en) * 2001-04-26 2007-03-13 Intel Corporation Link level packet flow control mechanism
US20030046474A1 (en) * 2001-06-21 2003-03-06 International Business Machines Corporation Mixed semantic storage I/O
US7155542B2 (en) * 2001-06-27 2006-12-26 Intel Corporation Dynamic network interface with zero-copy frames
US7110360B1 (en) * 2001-11-05 2006-09-19 Juniper Networks, Inc. Credit-based flow control over unreliable links
US7290277B1 (en) * 2002-01-24 2007-10-30 Avago Technologies General Ip Pte Ltd Control of authentication data residing in a network device
BR0215746B1 (pt) * 2002-06-19 2015-02-10 Ericsson Telefon Ab L M Arquitetura de acionador de dispositivo de rede, sistema e método para habilitar acesso de espaço de núcleo de sistema operacional como também acesso de espaço de usuário para um controlador de interface de rede (nic), e, método para habilitar acesso entre o espaço de núcleo de sistema operacional e um controlador de interface de rede (nic) como também entre o espaço de usuário e o dito nic
US20040027989A1 (en) * 2002-07-29 2004-02-12 Brocade Communications Systems, Inc. Cascade credit sharing for fibre channel links
US6760793B2 (en) * 2002-07-29 2004-07-06 Isys Technologies, Inc. Transaction credit control for serial I/O systems
US8015303B2 (en) * 2002-08-02 2011-09-06 Astute Networks Inc. High data rate stateful protocol processing
US7457845B2 (en) * 2002-08-23 2008-11-25 Broadcom Corporation Method and system for TCP/IP using generic buffers for non-posting TCP applications
US7346701B2 (en) * 2002-08-30 2008-03-18 Broadcom Corporation System and method for TCP offload
US8151278B1 (en) 2002-10-17 2012-04-03 Astute Networks, Inc. System and method for timer management in a stateful protocol processing system
US7814218B1 (en) 2002-10-17 2010-10-12 Astute Networks, Inc. Multi-protocol and multi-format stateful processing
US7596621B1 (en) 2002-10-17 2009-09-29 Astute Networks, Inc. System and method for managing shared state using multiple programmed processors
WO2004036387A2 (en) * 2002-10-18 2004-04-29 Broadcom Corporation System and method for receive queue provisioning
US7802001B1 (en) 2002-10-18 2010-09-21 Astute Networks, Inc. System and method for flow control within a stateful protocol processing system
US7953876B1 (en) * 2002-10-24 2011-05-31 Emulex Design & Manufacturing Corporation Virtual interface over a transport protocol
US7911994B2 (en) * 2003-02-28 2011-03-22 Openwave Systems Inc. Confirmation of delivery of content to an HTTP/TCP device
US7593996B2 (en) * 2003-07-18 2009-09-22 Netapp, Inc. System and method for establishing a peer connection using reliable RDMA primitives
DE602004011623T2 (de) * 2003-08-29 2009-01-29 Koninklijke Philips Electronics N.V. Elektronische Schaltungsanordnung mit über ein Kommunikationsnetzwerk gekoppelten Verarbeitungseinheiten
US7539760B1 (en) 2003-09-12 2009-05-26 Astute Networks, Inc. System and method for facilitating failover of stateful connections
US20050091334A1 (en) * 2003-09-29 2005-04-28 Weiyi Chen System and method for high performance message passing
US7581033B2 (en) * 2003-12-05 2009-08-25 Unisys Corporation Intelligent network interface card (NIC) optimizations
US7912979B2 (en) * 2003-12-11 2011-03-22 International Business Machines Corporation In-order delivery of plurality of RDMA messages
US8549170B2 (en) 2003-12-19 2013-10-01 Nvidia Corporation Retransmission system and method for a transport offload engine
US8065439B1 (en) 2003-12-19 2011-11-22 Nvidia Corporation System and method for using metadata in the context of a transport offload engine
US8176545B1 (en) 2003-12-19 2012-05-08 Nvidia Corporation Integrated policy checking system and method
US7899913B2 (en) 2003-12-19 2011-03-01 Nvidia Corporation Connection management system and method for a transport offload engine
US7653754B2 (en) * 2004-01-05 2010-01-26 Mellanox Technologies Ltd. Method, system and protocol that enable unrestricted user-level access to a network interface adapter
US7206872B2 (en) * 2004-02-20 2007-04-17 Nvidia Corporation System and method for insertion of markers into a data stream
US7249306B2 (en) * 2004-02-20 2007-07-24 Nvidia Corporation System and method for generating 128-bit cyclic redundancy check values with 32-bit granularity
US7698413B1 (en) 2004-04-12 2010-04-13 Nvidia Corporation Method and apparatus for accessing and maintaining socket control information for high speed network connections
US8621029B1 (en) * 2004-04-28 2013-12-31 Netapp, Inc. System and method for providing remote direct memory access over a transport medium that does not natively support remote direct memory access operations
US7328144B1 (en) 2004-04-28 2008-02-05 Network Appliance, Inc. System and method for simulating a software protocol stack using an emulated protocol over an emulated network
US20060034167A1 (en) * 2004-07-30 2006-02-16 International Business Machines Corporation Communication resource reservation system for improved messaging performance
US7957379B2 (en) 2004-10-19 2011-06-07 Nvidia Corporation System and method for processing RX packets in high speed network applications using an RX FIFO buffer
JP2006189937A (ja) * 2004-12-28 2006-07-20 Toshiba Corp 受信装置、送受信装置、受信方法及び送受信方法
JP2006186921A (ja) * 2004-12-28 2006-07-13 Toshiba Corp 電子機器及びその制御方法
US7672323B2 (en) * 2005-01-14 2010-03-02 Cisco Technology, Inc. Dynamic and intelligent buffer management for SAN extension
US20070005553A1 (en) * 2005-06-30 2007-01-04 Ravi Sahita System for composite instrumented resource data
US7643477B2 (en) * 2005-08-24 2010-01-05 Intel Corporation Buffering data packets according to multiple flow control schemes
US8325768B2 (en) * 2005-08-24 2012-12-04 Intel Corporation Interleaving data packets in a packet-based communication system
US7660306B1 (en) 2006-01-12 2010-02-09 Chelsio Communications, Inc. Virtualizing the operation of intelligent network interface circuitry
US7724658B1 (en) 2005-08-31 2010-05-25 Chelsio Communications, Inc. Protocol offload transmit traffic management
US7616563B1 (en) 2005-08-31 2009-11-10 Chelsio Communications, Inc. Method to implement an L4-L7 switch using split connections and an offloading NIC
US7660264B1 (en) 2005-12-19 2010-02-09 Chelsio Communications, Inc. Method for traffic schedulign in intelligent network interface circuitry
US7895329B2 (en) * 2006-01-12 2011-02-22 Hewlett-Packard Development Company, L.P. Protocol flow control
US7738495B2 (en) * 2006-01-23 2010-06-15 Cisco Technology, Inc. Method of determining a maximum transmission unit value of a network path using transport layer feedback
US20070294498A1 (en) * 2006-06-14 2007-12-20 International Business Machines Corporation Storage Allocation Management in Switches Utilizing a Flow Control
US20080201547A1 (en) * 2006-06-14 2008-08-21 Atherton William E Structure for storage allocation management in switches utilizing flow control
US9686117B2 (en) 2006-07-10 2017-06-20 Solarflare Communications, Inc. Chimney onload implementation of network protocol stack
EP2552081B1 (de) * 2006-07-10 2015-06-17 Solarflare Communications Inc Unterbrechungsverwaltung
US9948533B2 (en) 2006-07-10 2018-04-17 Solarflare Communitations, Inc. Interrupt management
FR2904445B1 (fr) * 2006-07-26 2008-10-10 Arteris Sa Systeme de gestion de messages transmis dans un reseau d'interconnexions sur puce
US8194547B1 (en) * 2006-08-07 2012-06-05 Emc Corporation Configuring flow control settings
US8683000B1 (en) 2006-10-27 2014-03-25 Hewlett-Packard Development Company, L.P. Virtual network interface system with memory management
US8935406B1 (en) 2007-04-16 2015-01-13 Chelsio Communications, Inc. Network adaptor configured for connection establishment offload
US8060644B1 (en) * 2007-05-11 2011-11-15 Chelsio Communications, Inc. Intelligent network adaptor with end-to-end flow control
US8589587B1 (en) 2007-05-11 2013-11-19 Chelsio Communications, Inc. Protocol offload in intelligent network adaptor, including application level signalling
US7920489B1 (en) * 2007-09-14 2011-04-05 Net App, Inc. Simultaneous receiving and transmitting of data over a network
US20090213735A1 (en) * 2008-02-25 2009-08-27 Check Mark A System to improve data packet routing in a data processing device and associated methods
US8935336B2 (en) * 2008-06-18 2015-01-13 Cisco Technology, Inc. Optimizing program requests over a wide area network
US7855954B2 (en) * 2008-07-21 2010-12-21 International Business Machines Corporation Speculative credit data flow control
GB2465595B (en) * 2008-11-21 2010-12-08 Nokia Corp A method and an apparatus for a gateway
US8880696B1 (en) 2009-01-16 2014-11-04 F5 Networks, Inc. Methods for sharing bandwidth across a packetized bus and systems thereof
US8112491B1 (en) 2009-01-16 2012-02-07 F5 Networks, Inc. Methods and systems for providing direct DMA
US9152483B2 (en) 2009-01-16 2015-10-06 F5 Networks, Inc. Network devices with multiple fully isolated and independently resettable direct memory access channels and methods thereof
US8688798B1 (en) 2009-04-03 2014-04-01 Netapp, Inc. System and method for a shared write address protocol over a remote direct memory access connection
US9313047B2 (en) 2009-11-06 2016-04-12 F5 Networks, Inc. Handling high throughput and low latency network data packets in a traffic management device
US8671265B2 (en) 2010-03-05 2014-03-11 Solidfire, Inc. Distributed data storage system providing de-duplication of data using block identifiers
US8675683B2 (en) * 2010-04-21 2014-03-18 International Business Machines Corporation Implementing end-to-end credit management for enhanced large packet reassembly
US9338074B2 (en) 2010-12-08 2016-05-10 At&T Intellectual Property I, L.P. Method and apparatus for wireless network performance diagnostics via user equipment
US8670450B2 (en) 2011-05-13 2014-03-11 International Business Machines Corporation Efficient software-based private VLAN solution for distributed virtual switches
US9276953B2 (en) 2011-05-13 2016-03-01 International Business Machines Corporation Method and apparatus to detect and block unauthorized MAC address by virtual machine aware network switches
US20120287785A1 (en) 2011-05-14 2012-11-15 International Business Machines Corporation Data traffic handling in a distributed fabric protocol (dfp) switching network architecture
US20120291034A1 (en) 2011-05-14 2012-11-15 International Business Machines Corporation Techniques for executing threads in a computing environment
US8837499B2 (en) 2011-05-14 2014-09-16 International Business Machines Corporation Distributed fabric protocol (DFP) switching network architecture
US9497073B2 (en) 2011-06-17 2016-11-15 International Business Machines Corporation Distributed link aggregation group (LAG) for a layer 2 fabric
US9331955B2 (en) * 2011-06-29 2016-05-03 Microsoft Technology Licensing, Llc Transporting operations of arbitrary size over remote direct memory access
US20130067095A1 (en) 2011-09-09 2013-03-14 Microsoft Corporation Smb2 scaleout
US8767529B2 (en) 2011-09-12 2014-07-01 International Business Machines Corporation High availability distributed fabric protocol (DFP) switching network architecture
US20130064066A1 (en) 2011-09-12 2013-03-14 International Business Machines Corporation Updating a switch software image in a distributed fabric protocol (dfp) switching network
US9473596B2 (en) 2011-09-27 2016-10-18 International Business Machines Corporation Using transmission control protocol/internet protocol (TCP/IP) to setup high speed out of band data communication connections
US8750129B2 (en) 2011-10-06 2014-06-10 International Business Machines Corporation Credit-based network congestion management
US9065745B2 (en) 2011-10-06 2015-06-23 International Business Machines Corporation Network traffic distribution
US8694701B2 (en) 2011-12-15 2014-04-08 Mellanox Technologies Ltd. Recovering dropped instructions in a network interface controller
US9054992B2 (en) 2011-12-27 2015-06-09 Solidfire, Inc. Quality of service policy sets
US9003021B2 (en) * 2011-12-27 2015-04-07 Solidfire, Inc. Management of storage system access based on client performance and cluser health
US9838269B2 (en) 2011-12-27 2017-12-05 Netapp, Inc. Proportional quality of service based on client usage and system metrics
US9396101B2 (en) 2012-06-12 2016-07-19 International Business Machines Corporation Shared physical memory protocol
US9612877B1 (en) * 2012-07-12 2017-04-04 Cisco Technology, Inc. High performance computing in a virtualized environment
US9270602B1 (en) * 2012-12-31 2016-02-23 F5 Networks, Inc. Transmit rate pacing of large network traffic bursts to reduce jitter, buffer overrun, wasted bandwidth, and retransmissions
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
US9836418B2 (en) 2013-03-13 2017-12-05 Dornerworks, Ltd. System and method for deterministic time partitioning of asynchronous tasks in a computing environment
US8989011B2 (en) 2013-03-14 2015-03-24 Mellanox Technologies Ltd. Communication over multiple virtual lanes using a shared buffer
US9160678B2 (en) 2013-04-15 2015-10-13 International Business Machines Corporation Flow control credits for priority in lossless ethernet
US9864606B2 (en) 2013-09-05 2018-01-09 F5 Networks, Inc. Methods for configurable hardware logic device reloading and devices thereof
US9378168B2 (en) 2013-09-18 2016-06-28 International Business Machines Corporation Shared receive queue allocation for network on a chip communication
US9473415B2 (en) * 2014-02-20 2016-10-18 Netspeed Systems QoS in a system with end-to-end flow control and QoS aware buffer allocation
US20150244795A1 (en) 2014-02-21 2015-08-27 Solidfire, Inc. Data syncing in a distributed system
US9325641B2 (en) 2014-03-13 2016-04-26 Mellanox Technologies Ltd. Buffering schemes for communication over long haul links
US9584429B2 (en) 2014-07-21 2017-02-28 Mellanox Technologies Ltd. Credit based flow control for long-haul links
US9798728B2 (en) 2014-07-24 2017-10-24 Netapp, Inc. System performing data deduplication using a dense tree data structure
US10133511B2 (en) 2014-09-12 2018-11-20 Netapp, Inc Optimized segment cleaning technique
US9671960B2 (en) 2014-09-12 2017-06-06 Netapp, Inc. Rate matching technique for balancing segment cleaning and I/O workload
US9836229B2 (en) 2014-11-18 2017-12-05 Netapp, Inc. N-way merge technique for updating volume metadata in a storage I/O stack
US9720601B2 (en) 2015-02-11 2017-08-01 Netapp, Inc. Load balancing technique for a storage array
US9571408B2 (en) * 2015-03-04 2017-02-14 Oracle International Corporation Dynamic flow control using credit sharing
US9606245B1 (en) 2015-03-24 2017-03-28 The Research Foundation For The State University Of New York Autonomous gamma, X-ray, and particle detector
US9762460B2 (en) 2015-03-24 2017-09-12 Netapp, Inc. Providing continuous context for operational information of a storage system
US9710317B2 (en) 2015-03-30 2017-07-18 Netapp, Inc. Methods to identify, handle and recover from suspect SSDS in a clustered flash array
US9740566B2 (en) 2015-07-31 2017-08-22 Netapp, Inc. Snapshot creation workflow
JP6466279B2 (ja) * 2015-08-05 2019-02-06 アラクサラネットワークス株式会社 通信装置
US10250530B2 (en) 2016-03-08 2019-04-02 Mellanox Technologies Tlv Ltd. Flexible buffer allocation in a network switch
US10205683B2 (en) 2016-03-28 2019-02-12 Mellanox Technologies Tlv Ltd. Optimizing buffer allocation for network flow control
US10929022B2 (en) 2016-04-25 2021-02-23 Netapp. Inc. Space savings reporting for storage system supporting snapshot and clones
US10387074B2 (en) 2016-05-23 2019-08-20 Mellanox Technologies Tlv Ltd. Efficient use of buffer space in a network switch
US10601714B2 (en) 2016-06-28 2020-03-24 Mellanox Technologies Tlv Ltd. Adaptive flow prioritization
US10642763B2 (en) 2016-09-20 2020-05-05 Netapp, Inc. Quality of service policy sets
US10389646B2 (en) 2017-02-15 2019-08-20 Mellanox Technologies Tlv Ltd. Evading congestion spreading for victim flows
US10645033B2 (en) * 2017-03-27 2020-05-05 Mellanox Technologies Tlv Ltd. Buffer optimization in modular switches
US10560373B2 (en) * 2017-04-06 2020-02-11 Gvbb Holdings S.A.R.L. System and method for timely and uniform distribution for real-time packet transmission
CN110011933B (zh) * 2018-01-05 2021-05-18 华为技术有限公司 发送数据包的方法、装置及计算机可读存储介质
US11855898B1 (en) 2018-03-14 2023-12-26 F5, Inc. Methods for traffic dependent direct memory access optimization and devices thereof
US11537716B1 (en) 2018-11-13 2022-12-27 F5, Inc. Methods for detecting changes to a firmware and devices thereof
CN111416776B (zh) * 2019-01-07 2024-07-09 华为技术有限公司 传输数据的方法和网络设备
US10951549B2 (en) 2019-03-07 2021-03-16 Mellanox Technologies Tlv Ltd. Reusing switch ports for external buffer network
US11005770B2 (en) 2019-06-16 2021-05-11 Mellanox Technologies Tlv Ltd. Listing congestion notification packet generation by switch
US10999221B2 (en) 2019-07-02 2021-05-04 Mellanox Technologies Tlv Ltd. Transaction based scheduling
US11470010B2 (en) 2020-02-06 2022-10-11 Mellanox Technologies, Ltd. Head-of-queue blocking for multiple lossless queues
CN112260955B (zh) * 2020-09-18 2022-11-11 苏州浪潮智能科技有限公司 一种混合读写流量控制方法和装置
JP2022076620A (ja) * 2020-11-10 2022-05-20 キオクシア株式会社 メモリシステムおよび制御方法
US11558316B2 (en) 2021-02-15 2023-01-17 Mellanox Technologies, Ltd. Zero-copy buffering of traffic of long-haul links
EP4064628A1 (de) 2021-03-24 2022-09-28 Bull SAS Verfahren zur interprozesskommunikation zwischen mindestens zwei prozessen
US11973696B2 (en) 2022-01-31 2024-04-30 Mellanox Technologies, Ltd. Allocation of shared reserve memory to queues in a network device

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4449182A (en) * 1981-10-05 1984-05-15 Digital Equipment Corporation Interface between a pair of processors, such as host and peripheral-controlling processors in data processing systems
US4475192A (en) * 1982-02-16 1984-10-02 At&T Bell Laboratories Data packet flow control scheme for switching networks
US4703475A (en) 1985-12-04 1987-10-27 American Telephone And Telegraph Company At&T Bell Laboratories Data communication method and apparatus using multiple physical data links
JP3314438B2 (ja) * 1993-02-22 2002-08-12 株式会社日立製作所 データ通信装置
US5432784A (en) * 1993-07-26 1995-07-11 Digital Equipment Corporation Flow control method and apparatus for systems with long distance links
US5617409A (en) * 1994-01-28 1997-04-01 Digital Equipment Corporation Flow control with smooth limit setting for multiple virtual circuits
US5633867A (en) * 1994-07-01 1997-05-27 Digital Equipment Corporation Local memory buffers management for an ATM adapter implementing credit based flow control
US5483526A (en) * 1994-07-20 1996-01-09 Digital Equipment Corporation Resynchronization method and apparatus for local memory buffers management for an ATM adapter implementing credit based flow control
US5453982A (en) * 1994-08-29 1995-09-26 Hewlett-Packard Company Packet control procedure between a host processor and a peripheral unit
US5636371A (en) * 1995-06-07 1997-06-03 Bull Hn Information Systems Inc. Virtual network mechanism to access well known port application programs running on a single host system
US5737535A (en) * 1995-06-07 1998-04-07 Emc Corporation Flow control circuit for networked communications system including arrangement for reducing overhead at the beginning of a communications session by enabling message transmission before receiving flow control information
US5610745A (en) * 1995-10-26 1997-03-11 Hewlett-Packard Co. Method and apparatus for tracking buffer availability
JP2929991B2 (ja) * 1996-01-29 1999-08-03 日本電気株式会社 最適化クレジット制御方法
US5748613A (en) 1996-03-29 1998-05-05 Hewlett-Packard Company Communication pacing method
WO1998025378A1 (en) * 1996-12-06 1998-06-11 Fujitsu Network Communications, Inc. Method for flow controlling atm traffic
US6044406A (en) * 1997-04-08 2000-03-28 International Business Machines Corporation Credit-based flow control checking and correction method
US5825748A (en) * 1997-04-08 1998-10-20 International Business Machines Corporation Credit-based flow control checking and correction system
US6163834A (en) * 1998-01-07 2000-12-19 Tandem Computers Incorporated Two level address translation and memory registration system and method
US6092108A (en) * 1998-03-19 2000-07-18 Diplacido; Bruno Dynamic threshold packet filtering of application processor frames
US6134617A (en) * 1998-04-03 2000-10-17 Lsi Logic Corporation Method and apparatus for managing access to a loop in a data processing system
US6360220B1 (en) * 1998-08-04 2002-03-19 Microsoft Corporation Lock-free methods and systems for accessing and storing information in an indexed computer data structure having modifiable entries
US6321276B1 (en) * 1998-08-04 2001-11-20 Microsoft Corporation Recoverable methods and systems for processing input/output requests including virtual memory addresses

Also Published As

Publication number Publication date
AU2492900A (en) 2000-07-24
WO2000041358A3 (en) 2000-11-30
EP1142215B1 (de) 2006-04-19
US6347337B1 (en) 2002-02-12
WO2000041358A2 (en) 2000-07-13
ATE323989T1 (de) 2006-05-15
DE60027404D1 (de) 2006-05-24
US6460080B1 (en) 2002-10-01
US20020055993A1 (en) 2002-05-09
EP1142215A2 (de) 2001-10-10

Similar Documents

Publication Publication Date Title
DE60027404T2 (de) Kreditbasiertes flusskontrollverfahren
DE112020002498T5 (de) System und verfahren zur erleichterung einer effizienten paketweiterleitung in einer netzwerkschnittstellensteuerung (nic)
DE69928408T2 (de) Virtuelle transportschicht-schnittstelle und nachrichten untersystem für hochgeschwindigkeit-datenübertragung zwischen heterogenen computersystemen
DE69826930T2 (de) System und Verfahren zur wirksamen Fernplatte Ein-/Ausgabe
DE60305378T2 (de) Verfahren zum Weitergeben von einem Netzwerkstapel
DE602005003142T2 (de) Vorrichtung und verfahren zur unterstützung von verbindungsherstellung in einem offload der netzwerkprotokollverarbeitung
US9729664B2 (en) System and method for managing connections between a client and a server
DE60212626T2 (de) Endknotenunterteilung mittels lokaler identifikatoren
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE10054923B4 (de) Verfahren zum Auffangen von Netzwerkpaketen in einem Computersystem, Computersystem zum Handhaben von Netzwerkpaketen sowie Paketauffängermodul zum Auffangen von Netzwerkpaketen in einem Computersystem
DE60201682T2 (de) Anordnung zur erzeugung mehrerer virtueller warteschlangenpaare aus einer komprimierten warteschlange auf der basis gemeinsamer attribute
DE69922693T2 (de) Systemem und verfahren für netzwerkvorrichtung und ein-ausgabegerätetreiber
DE69531410T2 (de) Mehrrechnerumgebungen
US6308238B1 (en) System and method for managing connections between clients and a server with independent connection and data buffers
EP1129412B1 (de) Internet-klient-server-multiplexer
US5253342A (en) Intermachine communication services
DE60038448T2 (de) Vorrichtung und verfahren zur hardware-ausführung oder hardware-beschleunigung von betriebssystemfunktionen
DE112011106016T5 (de) Gemeinsame Sendeschlange
DE112013000839B4 (de) Datenübertragungsprotokoll für verteilte Informationstechnologie-Architekturen
US20040190557A1 (en) Signaling packet
US8539089B2 (en) System and method for vertical perimeter protection
DE19924922A1 (de) System und Verfahren für Nachrichtenübermittlung zwisfchen Netzwerkknoten, die durch parallele Verbindungen verbunden sind
DE112011102415T5 (de) Registerzugriff in einer verteilten virtuellen Brückenumgebung
US8566833B1 (en) Combined network and application processing in a multiprocessing environment
DE60318252T2 (de) Verfahren und vorrichtungen zur datenübertragung zwischen speichernetzwerken

Legal Events

Date Code Title Description
8332 No legal effect for de
8370 Indication related to discontinuation of the patent is to be deleted
8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Ref document number: 1142215

Country of ref document: EP

R074 Re-establishment allowed

Ref document number: 1142215

Country of ref document: EP