-
Technisches Gebiet
-
Diese
Beschreibung bezieht sich im Allgemeinen auf Kommunikationsnetze
und speziell auf eine Bestimmung einer Umlaufzeit.
-
Querverweis auf verwandte
Anwendungen
-
Diese
Anmeldung steht in Beziehung zu der europäischen Patentanmeldung mit
dem Titel „Control
of Background Transfers",
eingereicht am 15. Juli 2005, ebenfalls im Namen der Microsoft Corporation, und
die hier durch Verweis einbezogen ist.
-
Hintergrund
-
Auf
dem Gebiet der Vernetzung von Computer ist es oft nützlich,
zu wissen, wie lang ein Signal benötigt, um von seiner Quelle
zu seinem Bestimmungsort und wieder zurück übertragen zu werden. Dies ist
bekannt als die Umlaufzeit (Round Trip Time) oder RTT. Typischerweise
schätzt
der Urheber einer Nachricht die RTT für Zwecke wie Zeitüberschreitung oder
erneutes Übertragen,
um verlorene oder beschädigte Übertragungen
erneut zu versuchen, durch einen Vergleich der Zeit, bei der eine
spezifische Übertragung
gemacht wurde, mit der Zeit, bei der eine Art von Bestätigung für einen
erfolgreichen Erhalt der Übertragung
von der Gegenseite erhalten wird. Solche Techniken werden verbreitet
eingesetzt, z. B. im IETF-Übertragungskontrollprotokoll
(TCP). TCP stellt z. B. eine Zeitstempeloption zur Verfügung, die
es einem Sender erlaubt, einen Zeitstempelwert in jedes Segment
zu platzieren. Der Empfänger
gibt diesen Wert in den Empfangsbestätigungsnachrichten wieder,
was dem Sender erlaubt, eine RTT für jede empfangene Empfangsbestätigungsnachricht (ACK)
zu berechnen. TCP ist ein verbindungsorientiertes, zustellungssicheres
(reliable-delivery) Bytestream-Transportlayer-Kommunikationsprotokoll, das
aktuell im IETF Requests for Comments (RFC) 793 dokumentiert ist.
-
Die
US-Patentanmeldung, veröffentlicht
als US 2005/0071451 A1, offenbart einen Hintergrund-Transportservice,
in dem ein Empfängerknoten
die verfügbare
Netzkapazität
zwischen sich selbst und einem Senderknoten über einem Kontrollintervall
ableitet. Basierend auf der abgeleiteten verfügbaren Netzkapazität passt
der Empfängerknoten
seine Receive-Window-Größe entsprechend
an, um die von einer Hintergrundübertragung
genutzte Bandbreite konservativ zu optimieren, ohne die Leistungsfähigkeit
anderer Vordergrundübertragungen im
Netz zu verschlechtern.
-
Abriss
-
Bekannte
Methoden zur Bestimmung von RTT sind im Allgemeinen für die Benutzung
durch einen Simplex-Empfänger
nicht geeignet. Der Begriff „Simplex-Empfänger" wird hier benutzt,
um auf einen Empfänger
oder Bestimmungsknoten zu verweisen, der keine Daten an einen zugehörigen Sender
oder Quellknoten zurücksendet.
Das Verfahren kann ebenfalls zur Abschätzung der RTT durch einen nicht Simplex-Empfänger genutzt
werden. Bekannte Verfahren schließen typischerweise das Senden
spezifischer Datenübertragungen
ein, und dies ist von einem Simplex-Empfänger aus nicht möglich. Dieses Problem
wird durch die Verwendung von Flusssteuerungsmechanismen in Kommunikationsprotokollen angesprochen.
Durch die Verwendung von Flusssteuerungsmechanismen waren wir in
der Lage, einen Simplex-Empfänger zu
aktivieren, die RTT ohne die Notwendigkeit des Sendens spezifischer
Datenübertragungen
vom Simplex-Empfänger
aus zu schätzen.
Dies kann vorteilhafter Weise für
einen Simplex-Empfänger
erreicht werden, der als eine Software-Anwendung zur Verfügung gestellt
ist, die auf einem Prozessor, wie z. B. einem PC, bereitsteht, der ein
herkömmliches
Betriebssystem benutzt. Keine Änderung
am Kommunikationsprotokoll selbst ist notwendig. Die Methoden sind
ebenfalls geeignet, einen nicht simplex (einen aktiven) Empfänger zu
aktivieren, eine RTT zu schätzen,
und die Erfindung ist dazu bestimmt, diese Situation in einigen
Ausführungsformen
zu umfassen.
-
Entsprechend
einem ersten Aspekt der vorliegenden Erfindung ist dort ein Verfahren
zum Aktivieren eines Empfängers,
eine Umlaufzeit zwischen sich selbst und einem Sender in einem Kommunikationsnetz
zu schätzen,
zur Verfügung
gestellt, wobei die Umlaufzeit eine Zeit ist, die für das Zurücklegen einer
Strecke von einem von dem Empfänger
und Sender zu dem anderen und zurück unter Verwendung eines Kommunikationsprotokolls
benötigt
wird, das einen Flusssteuerungsmechanismus umfasst, wobei das Verfahren
die Schritte aufweist:
- – Verwenden des Flusssteuerungsmechanismus zur
Unterbrechung einer Datenübertragung
vom Sender zum Empfänger;
- – Verwenden
des Flusssteuerungsmechanismus zur Wiederaufnahme einer Datenübertragung vom
Sender zum Empfänger;
und
- – Abschätzen der
Umlaufzeit auf der Basis von Informationen über die den Daten zugeordnete
Zeit, die vom Sender am Empfänger
nach der Wiederaufnahme ankommen.
-
Bevorzugt
weist das Verfahren des Weiteren eine Klassifizierung der Daten
auf, die vom Sender am Empfänger
ankommen, ob sie kausal dem Sender folgten, der der Wiederaufnahme
gewahr wurde; und ein Ignorieren der Daten zugeordneten Zeit, die nicht
kausal gesendet wurden.
-
Bevorzugt
weist das Verfahren eine Klassifizierung von Zero-Window-Prüfpaketen
als nicht kausale Daten auf.
-
Bevorzugt
weist die Klassifizierung das Vergleichen der am Empfänger empfangenen
Datenmenge mit der erwarteten Übertragungsgröße des Kommunikationsprotokolls
nach einer Wiederaufnahme auf.
-
Entsprechend
einem weiteren Aspekt der vorliegenden Erfindung ist dort ein Empfänger zur Verfügung gestellt,
der eingerichtet ist, eine Umlaufzeit zwischen sich selbst und einem
Sender in einem Kommunikationsnetz zu schätzen, wobei die Umlaufzeit
eine Zeit ist, die für
das Zurücklegen
einer Strecke von einem von dem Empfänger und Sender zu dem anderen
und zurück
unter Verwendung eines Kommunikationsprotokolls benötigt wird,
das einen Flusssteuerungsmechanismus umfasst, wobei der Empfänger aufweist:
- – einen
Prozessor, der eingerichtet ist, den Flusssteuerungsmechanismus
zu verwenden, um eine Datenübertragung
vom Sender zum Empfänger zu
unterbrechen;
- – wobei
der Prozessor des Weiteren eingerichtet ist, den Flusssteuerungsmechanismus
zu verwenden, um eine Datenübertragung
vom Sender zum Empfänger
wieder aufzunehmen; und
- – einen
Schätzer,
der eingerichtet ist, die Umlaufzeit auf der Basis von Informationen über die
der Ankunft der Daten nach der Wiederaufnahme zugeordnete Zeit zu
schätzen.
-
Bevorzugt
ist der Empfänger
mit einer kleinen Anzahl von Puffer konfiguriert, so dass diese Puffer
schneller und regelmäßiger voll
werden.
-
Bevorzugt
enthält
das teilweise Entleeren der Puffer das Lesen einer Datenmenge, die
zum Steuern des Kommunikationsprotokolls ausreicht, um schnell den
normalen Arbeitsablauf wieder aufzunehmen. Z. B. ist das Kommunikationsprotokoll
das IETF, TCP, und die Datenmenge, die zum Steuern des Kommunikationsprotokolls
ausreicht, ist ein Vielfaches der maximalen Segmentlänge des
TCP.
-
Bevorzugt
weist der Schritt der Einholung einer den Daten zugeordneten Zeit,
die vom Sender am Empfänger
nach einer Wiederaufnahme ankommen, des Weiteren das Ermitteln des
Zuwachses der Datenmenge in den Puffer auf. Dies weist z. B. das Notieren
der Zeit auf, bei der das Kommunikationsprotokoll den zur Verfügung stehenden
Pufferplatz neu berechnet.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung ist dort ein Computerprogramm zur
Verfügung
gestellt, das auf einem computerlesbaren Medium gespeichert ist
und eingerichtet ist, einen Empfänger
zu steuern, um eine Umlaufzeit zwischen sich selbst und einem Sender
in einem Kommunikationsnetz zu schätzen, wobei die Umlaufzeit eine
Zeit ist, die für
das Zurücklegen
einer Strecke von einem von dem Empfänger und Sender zu dem anderen
und zurück
unter Verwendung eines Kommunikationsprotokolls benötigt wird,
das einen Flusssteuerungsmechanismus umfasst, wobei das Computerprogramm
eingerichtet ist, den Empfänger
so zu steuern, dass er:
- – den Flusssteuerungsmechanismus
verwendet, um eine Datenübertragung
vom Sender zum Empfänger
zu unterbrechen;
- – den
Flusssteuerungsmechanismus verwendet, um eine Datenübertragung
vom Sender zum Empfänger
wiederaufzunehmen; und
- – die
Umlaufzeit auf der Basis von Informationen über die der Ankunft der Daten
nach der Wiederaufnahme zugeordnete Zeit schätzt.
-
Viele
der begleitenden Merkmale sind einfacher zu würdigen, da sie unter Verweis
auf die folgende detaillierte Beschreibung, die in Verbindung mit den
begleitenden Zeichnungen betrachtet wird, besser verständlich werden.
-
Beschreibung der Zeichnungen
-
Die
vorliegende Beschreibung wird durch das Lesen der folgenden detaillierten
Beschreibung angesichts der begleitenden Zeichnungen besser verständlich,
wobei:
-
1 ist
ein schematisches Diagramm auf hoher Ebene eines Empfängers in
einem Kommunikationsnetz;
-
2 ist
ein Flussdiagramm eines Verfahrens, das vom Empfänger aus 1 zur
Abschätzung
der Umlaufzeit ausgeführt
wird;
-
3 ist
ein ausführlicheres
Flussdiagramm des Verfahrens aus 2;
-
4 ist
ein Flussdiagramm eines Verfahrens zur Verwendung eines Empfängers zum
Bestimmen der Umlaufzeit in dem Fall, dass das verwendete Kommunikationsprotokoll
TCP ist.
-
Detaillierte Beschreibung
-
Die
nachstehend zur Verfügung
gestellte detaillierte Beschreibung in Verbindung mit den beigefügten Zeichnungen
ist als Beschreibung der vorliegenden Beispiele bestimmt und ist
nicht dazu bestimmt, die einzigen Ausführungsformen zu repräsentieren,
in denen das vorliegende Beispiel konstruiert oder genutzt werden
kann. Die Beschreibung legt die Funktionsweise des Beispiels und
die Abfolge der Schritte zum Herstellen und Betreiben des Beispiels dar.
Jedoch können
die gleichen oder äquivalenten Funktionsweisen
und Abfolgen durch andere Beispiele erreicht werden.
-
Die
vorliegende Erfindung erkennt an, dass obwohl zahlreiche Methoden
zum Abschätzen
einer Umlaufzeit existieren, diese typischerweise alle für die Nutzung
durch einen Sender oder eine Quelle eingerichtet sind. Durch Abschätzen der
RTT ist diese Quelle oder dieser Sender dann in der Lage, mit einer
Zeitüberschreitung
und einem erneutem Übertragen
und anderen ähnlichen
Situationen umzugehen. Jedoch wurde bisher nicht berücksichtigt,
dass der Zielort oder Empfänger
selbst eine Bestimmung der RTT in dem Fall benötigt, dass es sich um einen Simplex-Empfänger handelt.
Wie oben erwähnt,
wird hier der Ausdruck „Simplex-Empfänger" als Verweis auf
einen Empfänger
oder Bestimmungsknoten verwendet, der keine Daten zurück an einen
zugeordneten Sender oder Quellenknoten schicken wird. Da der Empfänger simplex
ist, wird er erneute Übertragungen
nicht durchführen
und benötigt
so typischerweise keine Abschätzung
der RTT, um z. B. zu entscheiden, ob eine erneute Übertragung notwendig
ist. Somit sind bekannte Verfahren für eine Abschätzung der RTT
für die
Nutzung durch einen Simplex-Empfänger generell
ungeeignet. In ähnlicher
Weise sind Verfahren, die das Senden eines bestimmten Datenpakets umfassen,
für die
Nutzung durch einen Simplex-Empfänger nicht
angebracht.
-
Die
vorliegende Erfindung spricht dieses Problem durch die Verwendung
von Flusssteuerungsmechanismen in Kommunikationsprotokollen an.
Der Begriff „Flusssteuerungsmechanismus" wird hier als Verweis
auf Verfahren von Kommunikationsprotokollen genutzt, die zum Zweck
haben, einen Empfänger
davor zu bewahren, mit Daten überlaufen zu
werden, wenn der zugeordnete Sender in der Lage ist, Daten schneller
oder in einer größeren Menge
zu senden, als der Empfänger
sie konsumieren kann. Durch die Verwendung von Flusssteuerungsmechanismen
waren wir in der Lage, einen Simplex-Empfänger zu aktivieren, die RTT
ohne die Notwendigkeit des Sendens spezifischer Datenübertragungen
vom Simplex-Empfänger aus
zu schätzen.
-
Eine
Zusammenfassung des Flusssteuerungsmechanismus von TCP wird nun
zur Vereinfachung der Verweise angegeben, obwohl die vollständigen Details
dieses Flusssteuerungsmechanismus dem Durchschnittsfachmann bekannt
sind und in der oben erwähnten
IETF RFC verfügbar
sind.
-
Wie
oben erwähnt,
ist TCP ein verbindungsorientiertes Protokoll; d. h., dass zwei
Knoten in einem Kommunikationsnetz eine TCP-Verbindung miteinander
aufbauen müssen,
bevor sie Daten mittels TCP austauschen können. Jedes Ende einer TCP-Verbindung
hat eine begrenzte Anzahl an Pufferplatz. Ein empfangendes TCP erlaubt
der anderen Seite, nur so viele Daten zu senden, für die der
Empfänger
Puffer hat. Dies verhindert, dass ein schneller Host die Puffer
in einem langsamen Host überfüllen kann.
Die Flusssteuerung von TCP wird durch jedes Ende durch das Ankündigen einer
Window-Größe bereitgestellt.
Dies ist die Anzahl von Bytes, die mit der im Bestätigungsnummerfeld
angegebenen beginnt, die der Empfänger willens ist, zu akzeptieren. Ein
Sliding-Window-Verfahren wird zum Aktivieren des Flusssteuerungsmechanismus
genutzt. Auf einer hohen Begriffsebene kann dieses Window als schließend betrachtet
werden, wenn Daten gesendet werden. Das Window wird als sich öffnend betrachtet, wenn
der Empfangsprozess bestätigte
Daten liest, die Platz in seinem TCP-Empfangspuffer freimachen. Das ermöglicht,
dass mehr Daten gesendet werden können. Das Window kann ebenfalls
als schrumpfend betrachtet werden. Wenn das Window schrumpft und
zu einem Zero Window wird, dann wird der Sender am Senden jeglicher
Daten gehindert. In diesem Fall sind die Puffer des Empfängers voll;
der Empfänger
kündigt
ein Zero Window an und der Sender stoppt die Übertragung weiterer Daten. Wenn
der Empfänger
später
seine Puffer (zumindest teilweise) leert, wird ein Window-Update
(das eine Art von ACK-Nachricht
ist) gesendet, das ankündigt, dass
der Empfänger
nun eine bestimmte Anzahl an Bytes empfangen kann. Diese Window-Update-Nachricht
braucht keine neuen Daten zu bestätigen, sie öffnet nur das Window.
-
1 ist
ein schematisches Diagramm auf hoher Ebene eines Empfängers 11 (der
aktiv oder simplex sein kann) in einem Kommunikationsnetz 10. Aus
Gründen
der Klarheit wird der Empfänger 11 im Folgenden
als simplex bezeichnet, obwohl er ebenfalls aktiv sein könnte. Das
Kommunikationsnetz 10 kann jedes geeignete Netz sein, wie
das Internet, ein Local Area Network, Wide Area Network, Intraet
oder ein anderes Netz. Ein mit dem Netz verbundener Sender 12 ist
ebenfalls gezeigt und in den hier diskutierten Beispielen wird vorausgesetzt,
dass eine Kommunikationssitzung zwischen dem Simplex-Empfänger 11 und
dem Sender 12 unter Benutzung eines Kommunikationsprotokolls
aufgebaut werden kann, das einen Flusssteuerungsmechanismus aufweist.
Dieses Kommunikationsprotokoll kann z. B. TCP oder das Stream Control
Transmission Control Protocol (SCTP, RFC296) oder jedes andere geeignete
verbindungsorientierte Kommunikationsprotokoll sein, das einen Flusssteuerungsmechanismus
aufweist.
-
Der
Simplex-Empfänger
ist ein beliebiger geeigneter Netzknoten, der in der Lage ist, Daten
von einem Sender 12 unter Verwendung des Kommunikationsprotokolls
zu empfangen. In einer Ausführungsform
wird er durch eine Softwareanwendung auf einem PC zur Verfügung gestellt,
wobei dieser Computer durch ein herkömmliches Betriebssystem gesteuert
wird, das einen oder mehrere Treiber zum Treiben eines Kommunikationsprotokollempfangsstapels
aufweist. Dies wird hier als eine „Benutzermodus"-Implementierung
bezeichnet. Es ist ebenfalls möglich,
den Simplex-Empfänger
dermaßen
anzuordnen, dass er in den Kommunikationsprotokolltreiber integriert
ist. Dies wird hier als „Kernel-Level"-Implementierung
bezeichnet. Der Simplex-Empfänger weist
einen Prozessor 13 auf, der zur Nutzung eines Flusssteuerungsmechanismus 15 eines
Kommunikationsprotokolls zur Unterbrechung einer Datenübertragung
vom Sender zum Empfänger
aufgebaut ist. In der Benutzermodus-Implementierung wird dies durch die
Verwendung einer Schnittstelle zwischen dem Betriebssystem und den
Treibern für
den Kommunikationsprotokollstapel erreicht. In der Kernel- Level-Implementierung
wird dies durch das Bereitstellen eines neuen Moduls in den Treibern
für den
Kommunikationsprotokollstapel erreicht.
-
Der
Simplex-Empfänger
weist ebenfalls einen Schätzer 14 auf,
der aufgebaut ist, die Umlaufzeit auf der Basis von Informationen über die
der Wiederaufnahme einer Übertragung
zugeordnete Zeit zu schätzen.
Dieser Schätzer 14 kann
je nach Bedarf in einem Prozessor integriert sein.
-
Sowohl
die Benutzer-Level- als auch die Kernel-Level-Implementierung umfassen
spezielle Probleme. Im Fall der Benutzer-Level-Implementierung überwindet
die vorliegende Erfindung Einschränkungen herkömmlicher
existierender Schnittstellen zu den Kommunikationsprotokolltreibern.
Sie benötigt ebenfalls
keine spezielle Unterstützung
durch das Kommunikationsprotokoll oder Änderungen am Kommunikationsprotokoll
selbst.
-
2 ist
ein Flussdiagramm auf hoher Ebene eines Verfahrens zum Aktivieren
des Simplex-Empfängers aus 1 zum
Bestimmen einer Umlaufzeit. Der Simplex-Empfänger ist für die Nutzung des Flusssteuerungsmechanismus
des Kommunikationsprotokolls zur Unterbrechung der Datenübertragung
vom Sender 12 zum Empfänger 11 aufgebaut
(siehe Schritt 20 in 2). Er schätzt danach die
Umlaufzeit auf der Basis von Informationen über die der Wiederaufnahme
der Übertragung
zugeordnete Zeit, wenn die Unterbrechung beseitigt wird (siehe Box 22 der 2).
-
3 zeigt
ausführlicher
das Verfahren aus 2. Der Simplex-Empfänger nutzt
den Flusssteuerungsmechanismus des Kommunikationsprotokolls, um
den Sender 12 anzuhalten (siehe Box 30 der 3).
Der Simplex-Empfänger 11 nutzt
seinen Prozessor 13, um den Sender 12 mittels
des Flusssteuerungsmechanismus 15 des Kommunikationsprotokolls
freizugeben. Unmittelbar bevor dies gemacht wird, notiert der Simplex-Empfänger 11 die
aktuelle Zeit als eine erste Zeit (siehe Box 31 der 3).
Als Teil dieses Prozesses wird eine Nachricht vom Simplex-Empfänger 11 zum
Sender 12 gesendet, die anzeigt, dass die Übertragung
wiederaufgenommen werden kann (siehe Box 32 der 3).
Der Simplex-Empfänger 11 hält nun wartend
auf neue Daten vom Sender 12 an. Er notiert eine zweite
Zeit, die die Zeit ist, wenn Daten vom Sender 12 zum ersten
Mal nach der Unterbrechung der Übertragung
empfangen werden (siehe Box 33 der 3). Der
Schätzer 14 am
Simplex-Empfänger 11 schätzt daraufhin
die Umlaufzeit auf der Basis des Intervalls zwischen der ersten
und der zweiten Zeit (siehe Box 34 der 4). Dies
liefert effektiv eine Schätzung
der Umlaufzeit, da das Zeitintervall die Zeit, die die Nachricht
aus Schritt 32 zum Senden vom Empfänger zum Sender benötigt, plus
die Zeit, die ein Datenpaket zum Senden vom Sender zum Empfänger benötigt, enthält.
-
4 ist
ein Flussdiagramm eines Verfahrens auf Benutzer-Level zum Aktivieren
des Simplex-Empfängers 11,
eine Umlaufzeit in dem Fall zu bestimmen, dass das Kommunikationsprotokoll
TCP ist. Eine empfangende Anwendung am Simplex-Empfänger 11 (das
ist eine Software, die den Simplex-Empfänger, wie oben erwähnt, implementiert)
detektiert, oder bestimmt optional die Datenmenge, die lokal gepuffert
werden kann. Dies wird z. B. durch die Standard-IETF-getsockopt (setsockopt)-Socket-API-Funktion
oder Ähnliches
erreicht (siehe Box 40 der 4). Der
TCP-Flusssteuerungsmechanismus am Empfänger benachrichtigt ebenfalls
den TCP-Flusssteuerungsmechanismus am Sender über die verfügbare Puffergröße in Form einer „Receive
Window"-Größe, die
in seinen an den Sender gesendeten Bestätigungen des erfolgreichen Datenempfangs
kodiert ist, wie im TCP bekannt ist. Dies ist für die empfangende Anwendung
zur Detektion oder Bestimmung der Datenmenge, die lokal gepuffert
werden kann, nicht wesentlich, da der TCP-Flusssteuerungsmechanismus
in der Lage ist, dies zu detektieren und eine Receive-Window-Größe anzukündigen,
wie es aus dem Stand der Technik bekannt ist. Jedoch wird der Schritt 40 des
Verwendens der empfangenden Anwendung zum Detektieren oder Bestimmen
der lokal gepufferten Datenmenge in einigen Ausführungsformen genutzt, um die
Datenmenge zu verringern, die lokal gepuffert werden kann.
-
Die
empfangende Anwendung hört
als nächstes
auf (siehe Box 41 der 4), Daten
von ihren lokalen Puffer zu lesen. Daten kommen weiterhin vom Sender,
verursachen, dass der zur Verfügung stehende
Pufferplatz erschöpft
wird. Die empfangende Anwendung überwacht
die verfügbare
Kapazität der
Puffer, z. B. durch die Verwendung einer oder beider der Standard-IETF-receive(MSG_PEEK)-
oder der Windows-WSAloctl()-API-Funktionen, bis der ganze zur Verfügung stehende
Pufferplatz verbraucht ist (siehe Boxen 42 und 43 der 4).
An diesem Punkt kann die empfangende Anwendung vernünftigerweise
annehmen, dass das sendende TCP-Modul gewahr ist, dass kein weiterer
Pufferplatz am Empfänger
zur Verfügung
steht und deshalb die Übertragung
bis zur Verfügbarkeit
von Pufferplatz beim Empfänger
einstellt. Da dies eine Benutzer-Level-Implementierung ist, überwacht
die empfangende Anwendung, wie oben beschrieben, die verfügbare Pufferkapazität, ignoriert
Zero-Size-Window-Prüfer. Der
Simplex-Empfänger
liest nun die gepufferten Daten mit der Absicht, den Puffer platz
freizugeben und das TCP-Modul des Empfängers dazu zu veranlassen,
eine unverzügliche
Anzeige an das TCP-Modul des Senders zu senden, dass die Übertragungen wieder
aufgenommen werden können
(siehe Box 45 der 4). Unmittelbar
bevor dies gemacht wird, notiert der Simplex-Empfänger die
aktuelle Zeit (erste Zeit), wie in Box 44 der 4 dargestellt.
Praktisch ist es für
die empfangende Anwendung wichtig, eine ausreichende Zahl gepufferter
Daten zu lesen, um eine unverzügliche
Reaktion sowohl des empfangenden als auch des sendenden TCP-Moduls
zu verursachen (typischerweise in der Größenordnung von einem oder zwei
Vielfachen des Maximum Segment Size (MSS) Parameters, der zwischen
den beiden TCP-Modulen ausgehandelt wird, wie aus dem Stand der
Technik bekannt). Sobald genug Platz im Empfangspuffer erzeugt worden
ist, wird eine Window-Update-Nachricht vom Simplex-Empfänger zum Sender
gesendet. Dies zeigt dem Sender an, dass er in der Lage ist, eine
festgelegte Datenmenge an den Empfänger zu senden.
-
Aus
Gründen
der Einfachheit, aber ohne Beschränkung der Allgemeinheit, werden
wir annehmen, dass die empfangende Anwendung alle zur Verfügung stehenden
Daten aus den lokalen Puffer liest, so dass in diesem Fall die Puffer
leer sind, und die empfangende Anwendung die eigene Ausführung bis
zur Verfügbarkeit
von neuen Daten in den lokalen Puffer aussetzen kann;
Der Simplex-Empfänger 11 erwacht,
wenn neue Daten vom Sender in den Puffer des Empfängers angekommen
sind (siehe Box 47 der 4), wobei
er an diesem Punkt unmittelbar ein Sample der RTT als die aktuelle
Zeit (auf die hier ebenfalls als zweite Zeit verwiesen wird) abzüglich der
ersten Zeit berechnet (siehe Box 48 der 4).
-
4 zeigt
ebenfalls einen Schritt 46, in dem der Simplex-Empfänger den
verfügbaren
Pufferplatz notiert. Dies ist optional und wird ausgeführt, nachdem
der Empfangspuffer zumindest teilweise geleert ist, so dass eine Übertragung
wieder begonnen werden kann. Dieser optionale Schritt unterstützt den Simplex-Empfänger darin,
neue Datenpakete vom Sender von One-Byte-Prüfpaketen zu unterscheiden. Wir
ignorieren Zero-Window-Prüfer,
da diese die RTT-Abschätzung
verschlechtern würden.
-
In
der Praxis trifft man oft an unterschiedlichen Stellen der obigen
Prozedur einige Verzögerungen
an, so z. B. bei der Zeitplanung und dem Senden von Flusssteuerungsnachrichten
oder in der Zeitplanung und der Bekanntgabe von Anfragen an das
Betriebssystem. Solche Verzö gerungen
sind typisch für Mehrzweckbetriebssysteme
und für
die Netzsoftware, die sie enthalten. Diese Verzögerungen können das erhaltene RTT-Sample
stören.
Wir erhalten deshalb mehrere RTT-Samples durch einfaches Wiederholen
der oben beschriebenen Verfahren. Wir wenden eine passende Glättangs-
oder Filtertechnik auf die RTT-Samples an.
-
Als
Beispiel einer Glättungstechnik
kann der Empfänger
einfach einen Durchschnitt der RTT-Schätzungen
entsprechend einem Gewichtungsfaktor berechnen, der ausgewählt wurde,
um ein akzeptables Gleichgewicht zwischen Robustheit in Bezug auf
Varianz der RTT-Samples und Anforderungen für eine schnelle Erkennung einer
sich ändernden
RTT auf dem zugrunde liegenden Netz zur Verfügung zu stellen.
-
Als
Beispiel einer Filtertechnik kann der Empfänger eine Schätzung der
minimal zulässigen RTT
aufrechterhalten, die dazu genutzt wird, außerhalb liegende RTT-Samples
zu filtern. Die minimale RTT-Abschätzung wird selbst kontinuierlich
durch RTT-Samples aktualisiert, die in einen zulässigen Bereich fallen, der
durch die minimale RTT selbst und einen Kontrollparameter definiert
ist. Der Kontrollparameter kann angepasst werden, um das gewünschte Gleichgewicht
zwischen Stabilität
im Hinblick auf variable RTT-Samples und Reaktionen auf Änderungen
in dem zugrunde liegenden Verhalten des Netzes zu erreichen.
-
Weitere
Details im Hinblick auf eine spezifische Benutzer-Level-Implementierung
unter Verwendung von TCP werden nun aufgeführt.
-
Eine
Benutzer-Level-Implementierung zeigt einige Herausforderungen: Die
empfangende Anwendung muss das Verhalten der empfangenden und sendenden
TCP-Stapel mit ausreichender Finesse erfühlen und kontrollieren, um
RTT-Samples für
individuelle TCP-Pakete zu erhalten, die nur wenige Millisekunden
betragen können.
Weder die Socket-Bibliotheken noch die diesen zugrunde liegenden
Mechanismen wurden mit einem solchen Hintergedanken entworfen; so
können
z. B. Receive Calls blockieren, während sie die Ankunft von zusätzlichen Daten über das
Netz hinweg erwarten, wenn dort weniger Daten gepuffert sind, als
bei dem Call angefragt wurden. Unsere Implementierung meidet zahlreiche solcher
Fallgruben.
-
Beim
Eintritt in die Leseschleife (Box 47 der 4)
testen wir auf einen stabilen Zustand, in dem RcvWnd = 0 ist. Die
recv(2·MSS)-Operation öffnet RcvWnd
um exakt 2·MSS
(Maximum Segment Size), wodurch eine schnelle Reaktion sowohl des
empfangenden als auch sen denden TCP-Treibers gewährleistet ist. Die 2·MSS RcvWnd
erlaubt es dem Sender, zwei Segmente zu übermitteln, aber um eine präzise RTT-Abschätzung zu
erhalten, sind wir nur an der Ankunftszeit des ersten dieser Segmente
interessiert: folglich können
wir nicht einfach einen recv(2·MSS)-Aufruf
herausgeben.
-
Als
nächstes
müssen
wir alle überschüssigen Daten
außerhalb
der erwarteten 2·MSS
behandeln, die bereits in dem Stapel gepuffert sein können. Der
Entwurf des Protokollstapels räumt
einen Grad an Asynchronität
ein, der typischerweise zum Vorhandensein von mehr gepufferten Daten
im Stapel führt
als erwartet. Diese überschüssigen Daten
werden geleert, bevor wir versuchen, die RTT abzutasten. Ein Hinweis
auf ihr Vorhandensein kann durch den Vergleich der Resultate der
recv(MSG_PEEK)- und WSAloctl(FIONREAD)-Routinen erhalten werden,
wobei beide für
sich beanspruchen, die Menge der in einem Socket eingereihten Daten
zurück
zu geben, wobei der Unterschied darin besteht, dass der recv(MSG_PEEK)-Aufruf
zusätzliche
Daten berichtet, die im TCP eingereiht sind und auf Pufferplatz warten.
Allerdings sollte im Allgemeinen die empfangende Anwendung dafür Sorge
tragen, dass der Stapel von überschüssigen Daten
geleert wird, wenn die RTT abgetastet wird. Zu dem Zeitpunkt, wenn
die Daten aus dem Empfangsstapel geleert werden, unterbrechen wir
das Socket-Ereignis, bis Daten am Socket ankommen. Eine hierbei
auftretende Komplikation ist, dass der sendende TCP-Treiber periodisch
ein Zero-Size RcvWnd mit einem One-Byte-Paket prüfen wird, um zu testen, ob
das RcvWnd erhöht
wurde. Der Empfänger
sollte keinen dieser Zero-Window Prüfer mit dem ersten Segment
einer 2·MSS-Leseoperation
verwechseln, da dies die RTT-Abschätzung verschlechtern
würde.
-
Wir
erhalten eine RTT-Abschätzung
aus der Ankunftszeit des ersten Segments, und warten auf die Ankunft
des zweiten Segments, bevor die Schleife wiederholt wird.
-
Weitere
Details im Hinblick auf eine spezielle Kernel-Level-Implementierung
unter Verwendung von TCP werden nun aufgeführt.
-
Um
RTT-Samples für
den Rate-Limiting-Modus zu erhalten, müssen wir unverzüglich benachrichtigt
werden, wenn das erste Segment eines 2·MSS-Paars an einer BaTS-Verbindung
ankommt. Wir erreichen dies, indem die Routine, die RcvWnd neu berechnet,
wenn das nächste
erwartete Segment an einer Verbindung ankommt, so modifiziert wird,
dass sie einen Aufruf einer von unseren Prozeduren umfasst.
-
Ein
abschließender
Punkt im Hinblick auf die Kernel-Implementierung betrifft die rechtzeitige Übersendung
von Acks. Es gibt Mechanismen im TCP-Treiber für das Anfragen und Senden von
Acks, indem auf eine timerbasierte Routine gewartet wird, die ein
Paket sendet, wenn keine Segmente vor dem Auftreten der Zeitüberschreitung
gesendet wurden. Da die Latenz dieser Timer unsere Zeitberechnungen beeinträchtigen
würde,
vermeiden wir sie durch das direkte Senden von Out-of-Band-Acks
direkt im BaTS-Code; dies erfordert eine moderate Anzahl von zusätzlichen
Mechanismen, nämlich
eine neue Arbeitswarteschlange für
ausstehende Acks, aufgrund der involvierten Locking-Systeme (locking
regimes) und Interrupt-Anfrage-Ebenen.
-
Der
Durchschnittsfachmann wird begreifen, dass zum Speichern von Programminstruktionen
genutzte Speichergeräte über ein
Netz verteilt werden können.
Ein entfernter Computer kann z. B. ein Beispiel eines beschriebenen
Prozesses als Software speichern. Ein lokaler Computer oder ein
Terminal kann auf den entfernten Computer zugreifen und einen Abschnitt
oder die gesamte Software herunterladen, um das Programm auszuführen. Alternativ
kann der lokale Computer nach Bedarf Teile der Software herunterladen
oder einige Softwareanweisungen an dem lokalen Terminal und einige
auf dem entfernten Computer (oder Computernetz) ausführen. Der Durchschnittsfachmann
wird ebenfalls begreifen, dass durch die Verwendung von herkömmlichen
dem Durchschnittsfachmann bekannten Techniken alle oder ein Teil
der Softwareinstruktionen durch eine zweckbestimmte Schaltung ausgeführt werden
können,
wie z. B. durch ein DSP, durch programmierbare logische Arrays oder Ähnliches.
-
Das
oben beschriebene Verfahren kann durch eine Software in maschinenlesbarer
Form auf einem Speichermedium ausgeführt werden. Dies berücksichtigt,
dass Software ein wertvolles, eigenständig handelbares Gebrauchsgut
sein kann. Es ist beabsichtigt, dass Software umfasst ist, die auf „dummer" oder Standard-Hardware
ausgeführt
wird oder diese kontrolliert, um die gewünschten Funktionen auszuführen (und
folglich definiert grundsätzlich
die Software die Funktionen der Register und kann deshalb als ein
Register bezeichnet werden, sogar bevor sie mit ihrer Standard-Hardware
kombiniert wird). Aus ähnlichen
Gründen
ist ebenfalls beabsichtigt, dass Software umfasst ist, die die Konfiguration
von Hardware „beschreibt" oder definiert,
wie HDL(hardware description language)-Software, die für den Entwurf
von Siliziumchips oder für
das Konfigurieren universell programmierbarer Chips genutzt wird,
um die gewünschten
Funktionen auszuführen.
Jeder hier aufgeführte
Bereich oder Gerätewert
kann erweitert oder geändert
werden, ohne dass der gewünschte Effekt
verloren geht, wie dem Durchschnittsfachmann verständlich ist.
-
Es
ist verständlich,
dass die obige Beschreibung einer bevorzugten Ausführungsform
nur als Beispiel angegeben wird und dass verschiedenartige Änderungen
durch den Durchschnittsfachmann vorgenommen werden können.