Service Broker-Kommunikationsprotokolle
Service Broker verwendet ein brokerspezifisches Protokoll, um mit Remotebrokern zu kommunizieren. Der Broker verwaltet Verbindungen getrennt vom normalen Pool von Clientverbindungen. Damit zwei SQL Server-Instanzen Service Broker-Nachrichten austauschen können, muss jede Instanz in der Lage sein, TCP/IP-Datenverkehr an den Port zu senden, den die andere Instanz für die Service Broker-Kommunikation verwendet. Gemäß der Konvention verwendet Service Broker Port 4022 für die Broker-zu-Broker-Kommunikation. Der genaue Anschluss wird angegeben, wenn der Endpunkt erstellt wird.
Protokollebenen
Der Service Broker-Ansatz basiert auf Kommunikationsebenen. Jede Ebene basiert auf der zugrunde liegende Ebene, um eine zuverlässige Übermittlung sicherzustellen. Dieser Ansatz ermöglicht den Betrieb einer Anwendung ohne Kenntnis des Speicherortes des Remotedienstes oder des vom Broker für die Kommunikation verwendeten physikalischen Transportprotokolls. In den meisten Fällen sind diese Protokolle für eine Anwendung transparent. Das Verständnis der Rolle, die jede Protokollebene spielt, kann jedoch bei der Behandlung von Problemen mit einer Anwendung helfen.
Das Protokoll der höchsten Ebene, das der Broker verwendet, ist das Dialogprotokoll. Die Dialogprotokollebene ist für eine zuverlässige, sequenzielle Nachrichtenübertragung zuständig. Auf der Dialogprotokollebene werden Sequenznummern für Nachrichten und Bestätigungsnachrichten generiert. Darüber hinaus werden Nachrichten den richtigen Warteschlangen übermittelt, und Nachrichten werden fragmentiert und wieder zusammengesetzt. Das Dialogprotokoll ist für die Authentifizierung und Verschlüsselung für einen Dialog zuständig.
Das Dialogprotokoll verwendet das Protokoll des angrenzenden Brokers, um Nachrichtenfragmente zu senden. Das Protokoll des angrenzenden Brokers dient zur Verarbeitung der Netzwerkübertragungen zwischen zwei Brokerinstanzen.
Das Protokoll des angrenzenden Brokers verwendet ein Transportprotokoll, wie TCP/IP, um Nachrichten von Broker zu Broker zu übertragen.
Dialogprotokoll
Das Dialogprotokoll verwaltet das Übermittlungsmuster, bei dem Nachrichten in einer Konversation genau einmal übermittelt werden, und zwar an der Reihenfolgeposition, an der sie gesendet werden. Dieses Protokoll beschreibt nicht das Format, das Service Broker-Nachrichten im Netzwerk verwenden. Stattdessen gibt das Protokoll die für eine zuverlässige Konversation erforderlichen logischen Schritte an. Das Dialogprotokoll übernimmt die Aufgaben, die für eine zuverlässige Übermittlung erforderlich sind. Dazu zählen das Generieren und Verarbeiten von Bestätigungsnachrichten.
Jede Seite einer Konversation ist ein Endpunkt der Dialogprotokollebene. Die Katalogsicht sys.conversation_endpoints zeigt Informationen zu Dialogprotokoll-Endpunkte an. Ein Konversationsendpunkt ist für die Dauer der Konversation vorhanden.
Protokoll des angrenzenden Brokers
Die Ebene des Protokolls des angrenzenden Brokers ist für die Kommunikationsmechanismen zwischen zwei SQL Server-Instanzen zuständig. Auf dieser Ebene wird jedes Nachrichtenfragment in ein Standardformat codiert, das zur Übertragung im Netzwerk geeignet ist. Im Gegensatz zur Dialogprotokollebene kennt die Ebene des Protokolls des angrenzenden Brokers den verwendeten Netzwerktransport und formatiert die Nachrichtenfragmente entsprechend. Die Ebene des Protokolls des angrenzenden Brokers stellt eine Abstraktionsebene zwischen der Dialogprotokollebene und der Transportprotokollebene bereit.
Jede Service Broker-Netzwerkverbindung ist ein Endpunkt auf der Ebene des Protokolls des angrenzenden Brokers. Die dynamische Verwaltungssicht sys.dm_broker_connections zeigt Informationen zu Service Broker-Netzwerkverbindungen an. Service Broker behält die Netzwerkverbindung bei, während Nachrichten aktiv ausgetauscht werden. Service Broker schließt die Netzwerkverbindung, wenn für einen kurzen Zeitraum keine Nachrichten über die Netzwerkverbindung gesendet oder empfangen wurden.
Transportprotokoll
Die Transportprotokollebene verarbeitet die eigentliche Netzwerkübertragung. Diese Ebene liegt außerhalb von Service Broker. Beispielsweise wird für Nachrichten an einen Broker, der in einer anderen Instanz von SQL Server ausgeführt wird, TCP/IP als Transportprotokollebene verwendet.
Service Broker-Endpunkte legen Optionen für das Transportprotokoll fest. SQL Server enthält standardmäßig keine Service Broker-Endpunkte. Weitere Informationen zum Erstellen eines Service Broker-Endpunktes finden Sie unter Vorgehensweise: Aktivieren des Service Broker-Netzwerks (Transact-SQL).
Service Broker-Kommunikation
Service Broker verwendet zwei unterschiedliche Nachrichtenkategorien. Eine sequenzielle Nachricht ist eine Nachricht, die einer Anwendung genau einmal in der richtigen Reihenfolge übermittelt werden muss. Eine nicht sequenzielle Nachricht ist eine Nachricht, die sofort, unabhängig von der Reihenfolge des Nachrichteneingangs, verarbeitet werden kann.
Service Broker verwendet sequenzielle Nachrichten für alle benutzerdefinierten Nachrichtentypen, Dialogbeendigungsnachrichten und Fehlermeldungen, die von einer Anwendung erstellt werden. Jede sequenzielle Nachricht besitzt eine Sequenznummer. Die Instanz, von der die Nachricht stammt, erstellt die Nachrichtensequenznummer und weist diese der Nachricht zu. Der die Nachricht empfangende Broker verwendet die Sequenznummer, um die Nachrichten zu sortieren, die er einer Anwendung übermittelt. Bei einem gegebenen Dialog empfängt die Anwendung immer die Nachricht mit der niedrigsten Sequenznummer zuerst. Service Broker verwendet die Nachrichtensequenznummer auch, um doppelte Nachrichten zu erkennen. Wenn auf Dialogprotokollebene zwei Nachrichten in demselben Dialog mit derselben Sequenznummer empfangen werden, werden die Nachrichten auf dieser Ebene als Duplikate gewertet, sodass eine der Nachrichten gelöscht wird.
Service Broker verwendet nicht sequenzielle Nachrichten für dedizierte Bestätigungsnachrichten und Fehlermeldungen, die von Service Broker erstellt werden. Service Broker trifft keine speziellen Vorkehrungen, um eine nicht sequenzielle Nachricht zu übermitteln. Beachten Sie dabei, dass Service Broker nicht sequenzielle Nachrichten als Antwort auf eingehende Nachrichten erstellt. Wenn die nicht sequenzielle Nachricht verloren geht, sendet der Absender die ursprüngliche Nachricht erneut. Der Empfänger generiert dann eine weitere nicht sequenzielle Nachricht.
Nachrichtenfragmentierung
Service Broker unterteilt ausgehende Nachrichten in Fragmente und kombiniert eingehende Fragmente zu der ursprünglichen Nachricht. Bei kleinen Nachrichten ist die vollständige Nachricht in einem Fragment enthalten. Bei großen Nachrichten erstellt Service Broker viele Fragmente.
Das Fragmentieren von Nachrichten bietet mehrere Vorteile. Durch Senden einer großen Nachricht in kleinen Fragmenten wird die Gesamtgeschwindigkeit und -zuverlässigkeit bei der Kommunikation über relativ langsame und unzuverlässige Netzwerke wie WANs verbessert. Sollte ein Fragment der Nachricht verloren gehen, wird nur ein Fragment statt der gesamten Nachricht erneut übertragen. Durch das Fragmentieren großer Nachrichten können kleine Nachrichten ihr Ziel schneller erreichen. Service Broker kann ein Fragment, das eine vollständige kleine Nachricht enthält, zwischen Fragmenten einer großen Nachricht senden. Dies verlangsamt die große Nachricht geringfügig, damit die kleine Nachricht schneller gesendet werden kann.
Während eine Nachricht wieder zusammengesetzt wird, wird die Teilnachricht in der Zielwarteschlange bzw. der Übertragungswarteschlange der Datenbank gespeichert, die als Host für die Zielwarteschlange dient, wenn die Zielwarteschlange nicht verfügbar ist. Eine Teilnachricht kann nicht von einer Anwendung empfangen werden. Die status-Spalte einer Teilnachricht wird auf 2 (deaktiviert) festgelegt. Dieser Wert wird auch für nicht sequenziell empfangene Nachrichten verwendet.
Nachrichtenbestätigung
Service Broker bestätigt jede empfangene Nachricht. Mit einer Bestätigung kann mindestens ein Nachrichtenfragment bestätigt werden. Eine Bestätigung wird gegebenenfalls in den Header einer in derselben Konversation zurückgegebenen Nachricht eingeschlossen. Wenn keine weiteren Nachrichten sendebereit sind, gibt Service Broker eine dedizierte Bestätigungsnachricht zurück. Die Nachrichtenbestätigung wird ausschließlich von Service Broker verarbeitet. Eine Anwendung, die Service Broker verwendet, empfängt diese Nachrichten nicht.
Beim Absender werden Nachrichtenfragmente beibehalten, die der Empfänger nicht bestätigt hat. Wenn keine Bestätigung innerhalb einer systemdefinierten Wartezeit empfangen wird, sendet der Absender das Nachrichtenfragment erneut. Wenn keine Bestätigung während der Wartezeit empfangen wird, wird der Zeitraum vor der nächsten Wiederholung von Service Broker zunehmend vergrößert, bis zum Erreichen einer maximalen Wartezeit. Die anfängliche Wartezeit für Wiederholungen liegt bei einigen Sekunden. Die maximale Wartezeit beträgt etwa eine Minute. Beachten Sie, dass die Wartezeit nicht genau sein soll. Je nach Netzwerkverkehr und sonstigen Aktivitäten in der SQL Server-Instanz wird ein Nachrichtenfragment auch nach Ablauf der Wartezeit möglicherweise ein paar Sekunden lang nicht erneut übertragen.
Wenn eine Bestätigung verloren geht oder verzögert wird, kann der Empfänger doppelte Nachrichten empfangen. In diesem Fall bestätigt der Empfänger den Erhalt der doppelten Nachricht, übermittelt die doppelte Nachricht aber nicht der Warteschlange.
Service Broker verwendet die Nachrichtenbestätigung, um zuverlässiges Messaging ohne verteilte Transaktionen zu ermöglichen. Ein Empfänger sendet eine Bestätigung erst, nachdem die Nachricht oder das Nachrichtenfragment der Warteschlange hinzugefügt wurde. Der Absender belässt die Nachricht in der Übertragungswarteschlange, bis die Bestätigung für diese Nachricht eingeht. Obwohl der Absender und der Empfänger nie eine Transaktion gemeinsam nutzen, wird durch das Protokoll sichergestellt, dass der Absender die Nachricht nicht aus der Übertragungswarteschlange entfernt, bis der Empfänger die Nachricht erfolgreich empfangen hat.
Nachrichtenintegritätsprüfung
Das von Service Broker zum Senden von Nachrichten verwendete Format schließt eine Überprüfung der Nachrichtenintegrität ein, um zu ermitteln, ob eine gegebene Nachricht während der Übertragung geändert oder beschädigt wurde.
Die Nachrichtenintegritätsprüfung umfasst eine MD5-Signatur für den Inhalt der Nachricht. SQL Server verschlüsselt die Signatur mit dem Sitzungsschlüssel für die Nachricht und schließt die Signatur in die Nachrichtenheader ein.
Am Nachrichtenziel wird die Nachricht entschlüsselt, und anschließend wird die Signatur in der Nachricht mit einer anhand des empfangenen Inhaltes berechneten neuen Signatur verglichen. Wenn die Signaturen nicht übereinstimmen, wurde die Nachricht bei der Übertragung beschädigt oder modifiziert. Die Integritätsprüfung der Nachricht erzeugt einen Fehler. SQL Server verwirft die Nachricht, deren Empfang gegenüber dem Absender nicht bestätigt wird. Bei der Broker:Corrupted Message-Ereignisklasse werden Informationen aufgezeichnet, wenn eine Nachricht die Integritätsprüfung nicht besteht.
Netzwerkkommunikationsfluss
In der folgenden Abbildung wird die Service Broker-Netzwerkkommunikation zwischen zwei SQL Server-Instanzen auf oberster Ebene dargestellt.
.gif "Broker-Netzwerkkommunikation zwischen zwei Instanzen")
Beachten Sie, dass die Konversation eine permanente, logische Verbindung darstellt. Die Konversation kann beliebig lange dauern, und während dieser Zeit kann von der Konversation eine beliebige Anzahl von Netzwerkverbindungen verwendet werden.
Netzwerkverbindungen bestehen zwischen zwei Service Broker-Endpunkten. Bei diesen Verbindungen wird TCP/IP verwendet. Wenn die Verbindung kurze Zeit inaktiv ist, schließt SQL Server die Netzwerkverbindung.
Zum Übermitteln einer Nachricht speichert Service Broker die Nachricht in der Übertragungswarteschlange der Datenbank, von der die Nachricht gesendet wurde. Der Empfänger übermittelt die Nachricht direkt der Warteschlange des Zieldienstes. Wenn diese Warteschlange auf OFF festgelegt ist, wird die Nachricht temporär in der Übertragungswarteschlange der empfangenden Datenbank gespeichert. Beachten Sie, dass die Warteschlange des sendenden Dienstes nicht an diesem Vorgang beteiligt ist und dass die Übertragungswarteschlange der Datenbank, die als Host für den empfangenden Dienst dient, nur beteiligt ist, wenn die Zielwarteschlange auf OFF festgelegt ist.