Protocol-Independent Out-of-Band-Daten

Die Datenstromsocket-Abstraktion umfasst den Begriff der Out-of-Band-Daten (Out of Band, OOB). Viele Protokolle ermöglichen es, teile von eingehenden Daten auf irgendeine Weise als sonderlich gekennzeichnet zu werden, und diese speziellen Datenblöcke können dem Benutzer aus der normalen Sequenz übermittelt werden. Beispiele hierfür sind beschleunigte Daten in X.25 und anderen OSI-Protokollen sowie dringende Daten in BSD UNIXs Verwendung von TCP. Im folgenden Abschnitt werden die OOB-Datenverarbeitung protokollunabhängig beschrieben. Eine Diskussion über OOB-Daten, die mithilfe von TCP-Dringenden Daten implementiert werden, folgt der protokollunabhängigen Erklärung. In jeder Diskussion impliziert die Verwendung von recv auch recvfrom, WSARecvund 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 Lieferung 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 jederzeit ausstehen. Bei Kommunikationsprotokollen, die die In-Band-Signalisierung unterstützen (z. B. TCP, bei denen die dringenden Daten in Sequenz mit den normalen Daten übermittelt werden), extrahiert das System normalerweise die OOB-Daten aus dem normalen Datenstrom und speichert sie separat (Lücke im normalen Datenstrom). Auf diese Weise können Benutzer zwischen dem Empfangen der OOB-Daten in der Reihenfolge und dem Empfang der Daten aus der Sequenz wählen, ohne alle dazwischen liegenden Daten zu puffern. Es ist möglich, Out-of-Band-Daten (Out-of-Band, OOB) anzuzeigen.

Ein Benutzer kann ermitteln, ob OOB-Daten mit dem ioctlsocket- oder WSAIoctl--Funktion mit der SIOCATMARK IOCTL gelesen werden. 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 eine konzeptionelle Markierung, die die Position des letzten Byte von OOB-Daten innerhalb des normalen Datenstroms angibt. Dies ist nicht für die Implementierung des ioctlsocket oder WSAIoctl Funktionen erforderlich, die SIOCATMARKunterstützen. Das Vorhandensein oder Fehlen von OOB-Daten ist 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 inline verarbeiten, als Teil des normalen Datenstroms. Dies wird durch Festlegen der Socketoption SO_OOBINLINE mit der setockopt--Funktion erreicht. 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 ioctlsocket oder WSAIoctl- funktion mit der SIOCATMARK IOCTL verwenden, um zu bestimmen, ob ungelesene OOB-Daten vor der Markierung vorhanden sind. Beispielsweise kann diese Information verwendet werden, um die Synchronisierung mit dem Peer zu verwenden, indem sichergestellt wird, dass alle Daten bis zur Markierung im Datenstrom bei Bedarf verworfen werden.

Wenn SO_OOBINLINE deaktiviert ist (standardeinstellung):

• Windows Sockets benachrichtigt eine Anwendung eines FD_OOB-Ereignisses, wenn die Anwendung, die für die Benachrichtigung mit WSAAsyncSelectregistriert ist, genau auf die gleiche Weise wie FD_READ verwendet wird, um das Vorhandensein normaler Daten zu benachrichtigen. Das heißt, FD_OOB wird veröffentlicht, wenn OOB-Daten ohne zuvor in die Warteschlange eingereihte OOB-Daten eintreffen. Die FD_OOB wird auch gepostet, wenn Daten mithilfe des MSG_OOB-Flags gelesen werden, während einige OOB-Daten nach der Rückgabe des Lesevorgangs in die Warteschlange verschoben werden. FD_READ Nachrichten werden nicht für OOB-Daten gepostet.
• Windows Sockets gibt von wählen Sie mit der entsprechenden mit Ausnahme von Socketsatz aus, wenn OOB-Daten im Socket in die Warteschlange gestellt werden.
• Die Anwendung kann recv- mit MSG_OOB aufrufen, um den dringenden Datenblock jederzeit zu lesen. Der Block von OOB-Daten springt in die Warteschlange.
• Die Anwendung kann recv aufrufen, ohne MSG_OOB den normalen Datenstrom zu lesen. Der OOB-Datenblock wird nicht im Datenstrom mit normalen Daten angezeigt. Wenn OOB-Daten nach einem Aufruf von recvverbleiben, benachrichtigt Windows Sockets die Anwendung mit FD_OOB oder mit mit Ausnahme von, wenn auswählen.
• Bei Protokollen, in denen die OOB-Daten eine Position innerhalb des normalen Datenstroms haben, erstreckt sich ein einzelner recv- Vorgang nicht über diese Position. Ein recv die normalen Daten vor der Markierung zurückgibt, und ein zweites recv ist erforderlich, um mit dem Lesen von Daten nach dem Zeichen zu beginnen.

Mit aktivierter SO_OOBINLINE:

• FD_OOB Nachrichten werden nicht für OOB-Daten gepostet. OOB-Daten werden für den Zweck der Auswählen 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 MSG_OOB Flag festgelegt ist, um den OOB-Datenblock zu lesen. Der Fehlercode WSAEINVAL wird zurückgegeben.
• Die Anwendung kann recv- aufrufen, ohne dass das MSG_OOB Flag festgelegt ist. Alle OOB-Daten werden in der richtigen Reihenfolge innerhalb des normalen Datenstroms übermittelt. OOB-Daten werden niemals mit normalen Daten gemischt. Es müssen drei Leseanforderungen vorhanden sein, um über die OOB-Daten hinauszugehen. The first returns the normal data prior to the OOB data block, the second returns the OOB data, the third returns the normal data following the OOB data. Mit anderen Worten, die OOB-Datenblockgrenzen bleiben erhalten.

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

OOB-Daten in TCP

Wichtig

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

 

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

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

  Insbesondere verweist der TCP-dringende Zeiger in BSD auf das Byte nach dem dringenden Datenbyte, und ein RFC-kompatibler TCP-konformer TCP-Zeiger verweist auf das dringende Datenbyte. Wenn eine Anwendung daher dringende Daten aus einer BSD-kompatiblen Implementierung an eine mit RFC 1122 kompatible Implementierung sendet, liest der Empfänger das falsche dringende Datenbyte (es liest das Byte nach dem richtigen Byte im Datenstrom als dringendes Datenbyte vor).

  Um Interoperabilitätsprobleme zu minimieren, sollten Anwendungsautoren nicht OOB-Daten verwenden, es sei denn, dies ist erforderlich, um mit einem vorhandenen Dienst zu arbeiten. Windows Sockets-Lieferanten werden aufgefordert, die OOB-Semantik (BSD oder RFC 1122) zu dokumentieren, die ihr Produkt implementiert.

Die Ankunft eines TCP-Segments mit dem Flag URG (für dringend) gibt an, dass ein einzelnes Byte von OOB-Daten innerhalb des TCP-Datenstroms vorhanden ist. Der OOB-Datenblock hat eine Bytegröße. 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 Abschnitt erwähnt). Es kann daher auf Daten verweisen, die noch nicht empfangen wurden.

Wenn SO_OOBINLINE deaktiviert ist (standard), wenn das TCP-Segment, auf das das Byte verweist, durch den dringenden Zeiger verweist, deaktiviert ist, wird der OOB-Datenblock (ein Byte) aus dem Datenstrom entfernt und gepuffert. Wenn ein nachfolgendes TCP-Segment mit dem dringenden Kennzeichensatz (und einem neuen dringenden Zeiger) eingeht, kann das derzeit in der Warteschlange befindliche OOB-Byte verloren gehen, da es durch den neuen OOB-Datenblock ersetzt wird (wie in Berkeley Software Distribution). Es 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 mit dringenden Daten eingeht. Das vorhandene OOB-Datenzeichen wird an die neue Position aktualisiert.

Anmerkung

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