Protocol-Independent Out-of-Band-Daten

Die Stream-Socket-Abstraktion umfasst das Konzept von Out-of-Band-Daten (OOB). Viele Protokolle ermöglichen es, Teile der eingehenden Daten in irgendeiner Weise als speziell zu markieren, und diese speziellen Datenblöcke können dem Benutzer außerhalb der normalen Sequenz übermittelt werden. Beispiele hierfür sind beschleunigte Daten in X.25 und anderen OSI-Protokollen sowie dringende Daten in der TCP-Verwendung von BSD UNIX. Im folgenden Abschnitt wird die protokollunabhängige OOB-Datenverarbeitung beschrieben. Eine Erläuterung der OOB-Daten, die mithilfe von TCP-Dringenden Daten implementiert wurden, folgt der protokollunabhängigen Erklärung. In jeder Diskussion impliziert die Verwendung von recv auch recvfrom, WSARecv und WSARecvFrom, und Verweise auf WSAAsyncSelect gelten auch für WSAEventSelect.

Protokollunabhängige OOB-Daten

OOB-Daten sind ein logisch unabhängiger Übertragungskanal, der jedem Paar verbundener Datenstromsockets zugeordnet ist. OOB-Daten können unabhängig von normalen Daten an den Benutzer übermittelt werden. Die Abstraktion definiert, dass die OOB-Dateneinrichtungen die zuverlässige Bereitstellung von mindestens einem OOB-Datenblock gleichzeitig unterstützen müssen. Dieser Datenblock kann mindestens ein Byte von Daten enthalten, und mindestens ein OOB-Datenblock kann die Übermittlung an den Benutzer gleichzeitig ausstehen. Bei Kommunikationsprotokollen, die In-Band-Signalisierung unterstützen (z. B. TCP, bei dem die dringenden Daten nacheinander mit den normalen Daten übermittelt werden), extrahiert das System normalerweise die OOB-Daten aus dem normalen Datenstrom und speichert sie separat (wobei eine Lücke im normalen Datenstrom bleibt). Auf diese Weise können Benutzer wählen, ob die OOB-Daten in der Reihenfolge empfangen und in der Reihenfolge empfangen werden, ohne alle dazwischen liegenden Daten puffern zu müssen. Es ist möglich, Out-of-Band-Daten (OOB) einzusehen.

Ein Benutzer kann mithilfe der Funktion ioctlsocket oder WSAIoctl mit der SIOCATMARK-IOCTL bestimmen, ob OOB-Daten auf das Lesen warten. Für Protokolle, bei denen das Konzept der Position des OOB-Datenblocks innerhalb des normalen Datenstroms sinnvoll ist, z. B. TCP, verwaltet ein Windows Sockets-Dienstanbieter einen konzeptionellen Marker, der die Position des letzten Byte von OOB-Daten innerhalb des normalen Datenstroms angibt. Dies ist für die Implementierung der Funktionen ioctlsocket oder WSAIoctl , die SIOCATMARK unterstützen, nicht erforderlich. Das Vorhandensein oder Fehlen von OOB-Daten ist nur erforderlich.

Bei Protokollen, bei denen das Konzept der Position des OOB-Datenblocks innerhalb des normalen Datenstroms sinnvoll ist, kann eine Anwendung Out-of-Band-Daten als Teil des normalen Datenstroms inline verarbeiten. Dies wird erreicht, indem die Socketoption SO_OOBINLINE mit der setockopt-Funktion festgelegt wird. Bei anderen Protokollen, bei denen die OOB-Datenblöcke wirklich unabhängig vom normalen Datenstrom sind, führt der Versuch, SO_OOBINLINE festzulegen, zu einem Fehler. Eine Anwendung kann die Funktion ioctlsocket oder WSAIoctl mit der SIOCATMARK IOCTL verwenden, um zu bestimmen, ob der Markierung ungelesene OOB-Daten vorangehen. Beispielsweise kann er diese Informationen verwenden, um eine erneute Synchronisierung mit seinem Peer zu erstellen, indem sichergestellt wird, dass alle Daten bis zur Markierung im Datenstrom bei Bedarf verworfen werden.

Bei deaktivierter SO_OOBINLINE (Standardeinstellung):

• Windows Sockets benachrichtigt eine Anwendung über ein FD_OOB-Ereignis, wenn die Anwendung für die Benachrichtigung bei WSAAsyncSelect registriert ist, genau auf die gleiche Weise, wie FD_READ verwendet wird, um über das Vorhandensein normaler Daten zu informieren. Das heißt, FD_OOB wird gepostet, wenn OOB-Daten ohne zuvor in die Warteschlange eingereihte OOB-Daten eingehen. Die FD_OOB wird auch bereitgestellt, wenn Daten mithilfe des MSG_OOB-Flags gelesen werden, während einige OOB-Daten nach der Rückgabe des Lesevorgangs in der Warteschlange verbleiben. FD_READ Nachrichten werden nicht für OOB-Daten gepostet.
• Windows Sockets gibt von select mit dem entsprechenden außerfds-Socketsatz zurück, wenn OOB-Daten im Socket in die Warteschlange eingereiht werden.
• Die Anwendung kann recv mit MSG_OOB aufrufen, um den dringenden Datenblock jederzeit zu lesen. Der Block der OOB-Daten springt in die Warteschlange.
• Die Anwendung kann recv ohne MSG_OOB aufrufen, um den normalen Datenstrom zu lesen. Der OOB-Datenblock wird nicht im Datenstrom mit normalen Daten angezeigt. Wenn OOB-Daten nach einem Aufruf von recv verbleiben, benachrichtigt Windows Sockets die Anwendung mit FD_OOB oder mit exceptfds , wenn select verwendet wird.
• Bei Protokollen, bei denen die OOB-Daten eine Position innerhalb des normalen Datenstroms haben, erstreckt sich ein einzelner recv-Vorgang nicht über diese Position. Ein Recv gibt die normalen Daten vor der Markierung zurück, und ein zweiter Recv ist erforderlich, um mit dem Lesen von Daten nach der Markierung zu beginnen.

Bei aktivierter SO_OOBINLINE:

• FD_OOB Nachrichten werden nicht für OOB-Daten gepostet. OOB-Daten werden für die Zwecke der Select - und WSAAsyncSelect-Funktionen normal behandelt und durch Festlegen des Sockets in readfds bzw. durch Senden einer FD_READ Nachricht angegeben.
• Die Anwendung kann recv nicht aufrufen, wobei das flag MSG_OOB festgelegt ist, um den OOB-Datenblock zu lesen. Der Fehlercode WSAEINVAL wird zurückgegeben.
• Die Anwendung kann recv aufrufen, ohne dass das flag MSG_OOB festgelegt ist. Alle OOB-Daten werden in der richtigen Reihenfolge innerhalb des normalen Datenstroms übermittelt. OOB-Daten werden nie mit normalen Daten gemischt. Es müssen drei Leseanforderungen vorhanden sein, um die OOB-Daten zu übersteigen. Die erste gibt die normalen Daten vor dem OOB-Datenblock zurück, der zweite gibt die OOB-Daten zurück, die dritte gibt die normalen Daten nach den OOB-Daten zurück. Anders ausgedrückt: Die OOB-Datenblockgrenzen bleiben erhalten.

Die WSAAsyncSelect-Routine eignet sich besonders gut für die Verarbeitung von Benachrichtigungen über das Vorhandensein von Out-of-Band-Daten, wenn SO_OOBINLINE deaktiviert ist.

OOB-Daten in TCP

Wichtig

Die folgende Diskussion über Out-of-Band-Daten (OOB), die mithilfe von TCP-Dringenden Daten implementiert wurden, folgt dem Modell, das in der Berkeley-Softwareverteilung verwendet wird. Benutzer und Implementierer sollten folgendes beachten:

 

• Es gibt derzeit zwei widersprüchliche Interpretationen von RFC 793 (wo das Konzept eingeführt wird).

• Die Implementierung von OOB-Daten in Berkeley Software Distribution (BSD) entspricht nicht den in RFC 1122 angegebenen Hostanforderungen.

  Insbesondere zeigt der TCP-dringende Zeiger in BSD auf das Byte nach dem dringenden Datenbyte, und ein RFC-konformer TCP-dringender Zeiger verweist auf das dringende Datenbyte. Wenn eine Anwendung daher dringende Daten von einer BSD-kompatiblen Implementierung an eine implementierung sendet, die mit RFC 1122 kompatibel ist, liest der Empfänger das falsche dringende Datenbyte (er liest das Byte nach dem richtigen Byte im Datenstrom als dringendes Datenbyte).

  Um Interoperabilitätsprobleme zu minimieren, wird Anwendungsautoren empfohlen, keine OOB-Daten zu verwenden, es sei denn, dies ist für die Zusammenarbeit mit einem vorhandenen Dienst erforderlich. Windows Sockets-Lieferanten werden dringend aufgefordert, die OOB-Semantik (BSD oder RFC 1122) zu dokumentieren, die ihr Produkt implementiert.

Die Ankunft eines TCP-Segments mit dem URG-Flag (für dringend) gibt an, dass ein einzelnes Byte von OOB-Daten innerhalb des TCP-Datenstroms vorhanden ist. Der OOB-Datenblock ist ein Byte groß. Der dringende Zeiger ist ein positiver Offset von der aktuellen Sequenznummer im TCP-Header, der die Position des OOB-Datenblocks angibt (mehrdeutig, wie im Vorherigen angegeben). Es kann daher auf Daten verweisen, die noch nicht empfangen wurden.

Wenn SO_OOBINLINE deaktiviert ist (Standard), wenn das TCP-Segment mit dem Byte eintrifft, auf das der dringende Zeiger verweist, wird der OOB-Datenblock (ein Byte) aus dem Datenstrom entfernt und gepuffert. Wenn ein nachfolgendes TCP-Segment mit festgelegtem dringendem Flag (und einem neuen dringenden Zeiger) eintrifft, kann das in der Warteschlange befindliche OOB-Byte verloren gehen, da es durch den neuen OOB-Datenblock ersetzt wird (wie in Berkeley Software Distribution). Sie wird jedoch nie im Datenstrom ersetzt.

Wenn SO_OOBINLINE aktiviert ist, verbleiben die dringenden Daten im Datenstrom. Daher geht der OOB-Datenblock nie verloren, wenn ein neues TCP-Segment eintrifft, das dringende Daten enthält. Das vorhandene OOB-Datenzeichen wird auf die neue Position aktualisiert.

Hinweis

Wenn die Option SO_OOBINLINE Socket festgelegt ist, gibt die SIOCATMARK-IOCTL immer TRUE zurück, und OOB-Daten werden als normale Daten an den Benutzer zurückgegeben.