Protocoles de communication Service Broker

S’applique à :SQL ServerAzure SQL Managed Instance

Service Broker utilise un protocole propre aux brokers pour communiquer avec des brokers distants. Le broker gère les connexions séparément depuis un pool classique de connexions clientes. Pour que deux instances SQL Server échangent des messages Service Broker, chacune d’elles doit pouvoir envoyer du trafic TCP/IP sur le port utilisé par l’autre instance pour les communications Service Broker. Par convention, Service Broker utilise souvent le port 4022 pour les communications broker à broker. Toutefois, le port exact est spécifié à la création du point de terminaison.

Couches de protocole

Service Broker utilise une approche en couches pour la communication. Chaque couche est élaborée à partir de la couche sous-jacente afin de garantir une remise de messages fiable. Cette solution permet à une application de fonctionner connaître l'emplacement du service distant ou du transport physique que le broker utilise pour communiquer. Dans la majorité des cas, ces protocoles sont transparents pour une application. Toutefois, la compréhension du rôle joué par chaque couche de protocole peut aider à résoudre les problèmes liés à une application.

Le niveau le plus élevé du protocole utilisé par le broker se nomme le protocole de dialogue. La couche du protocole de dialogue gère la transmission séquencée et fiable des messages. Elle génère des numéros de séquence pour les messages, génère des messages d’accusé de réception, remet les messages aux files d’attente appropriées, et fragmente et reconstitue les messages. Le protocole de dialogue gère l'authentification et le chiffrement d'un dialogue.

Ce protocole utilise également le protocole de broker adjacent pour transmettre les fragments de message. Le protocole de broker adjacent gère les transmissions réseau qui sont échangées entre les deux instances de broker.

Le protocole de broker adjacent utilise un protocole de transport, tel que TCP/IP, pour déplacer les messages d'un broker à l'autre.

Protocole de boîte de dialogue

Le protocole de dialogue gère le modèle de remise EOIO (Exactly-Once-In-Order) pour les messages d'une conversation. Ce protocole ne décrit pas le format utilisé par les messages Service Broker sur le réseau. Il spécifie plutôt les étapes logiques qui sont requises pour assurer une conversation fiable. Le protocole de dialogue traite les tâches nécessaires pour assurer une remise fiable, notamment la génération et le traitement des messages d’accusé de réception.

Chaque côté d’une conversation est un point de terminaison dans la couche de protocole de dialogue. La vue sys.conversation_endpoints catalogue affiche des informations sur les points de terminaison de protocole de dialogue. Un point de terminaison de conversation existe le temps que dure une conversation.

Protocole broker adjacent

La couche de protocole de broker adjacente traite le mécanisme de communication entre deux instances SQL Server. Cette couche encode chaque fragment de message dans un format standard en vue de sa transmission sur le réseau. Contrairement à la couche du protocole de dialogue, la couche du protocole adjacent a connaissance du transport réseau utilisé et adapte les fragments de message en conséquence. En effet, la couche du protocole de broker adjacent fournit une couche d'abstraction entre la couche du protocole de dialogue et la couche du protocole de transport.

Chaque connexion réseau Service Broker est un point de terminaison dans la couche de protocole adjacente. La vue sys.dm_broker_connections de gestion dynamique affiche des informations sur les connexions réseau Service Broker. Service Broker gère la connexion réseau pendant l’échange actif des messages. Service Broker ferme la connexion réseau quand aucun message n’est envoyé ou reçu sur la connexion réseau pendant un instant.

Protocole de transport

La couche du protocole de transport gère la transmission réseau réelle. Cette couche est extérieure à Service Broker. Par exemple, les messages adressés à un broker s’exécutant dans une autre instance de SQL Server utilisent le protocole TCP/IP comme couche de protocole de transport.

Les points de terminaison Service Broker définissent des options pour le protocole de transport. SQL Server ne contient pas de points de terminaison Service Broker par défaut. Pour plus d’informations sur la création d’un point de terminaison Service Broker, consultez Guide pratique pour activer la mise en réseau Service Broker.

Traitement des messages Service Broker

Service Broker utilise deux catégories distinctes de message. Un message séquencé est un message dont la remise à une application doit être effectuée une seule et unique fois, dans l'ordre défini. Un message non séquencé est un message pouvant être traité immédiatement, sans tenir compte de la séquence suivant laquelle il arrive.

Service Broker utilise des messages séquencés pour tous les types de message définis par l’utilisateur, les messages de fin de dialogue et les messages d’erreur créés par une application. Chaque message séquencé est pourvu d'un numéro de séquence. L'instance se trouvant à l'origine du message crée un numéro de séquence qu'elle attribue au message. Le broker récepteur du message utilise ce numéro de séquence pour ordonner les messages qu'il présente à une application. Pour un dialogue donné, l’application reçoit toujours en premier le message qui a le plus petit numéro de séquence. Service Broker utilise également le numéro de séquence de message pour détecter les messages en double. Lorsque la couche du protocole de dialogue reçoit deux messages avec des numéros de séquence identiques sur le même dialogue, elle estime qu'il s'agit du même message en double exemplaire et en ignore un.

Service Broker utilise des messages non séquencés pour les messages d’accusé de réception dédiés et les messages d’erreur créés par Service Broker. Service Broker ne prend aucune précaution particulière pour remettre un message non séquencé. Toutefois, Service Broker crée des messages non mis en file d’attente en réponse aux messages entrants. Par conséquent, en cas de perte d'un message non séquencé, l'expéditeur effectue une nouvelle tentative avec le message original et le destinataire crée un autre message non séquencé.

Fragmentation des messages

Service Broker divise les messages sortants en fragments et combine les fragments entrants pour former le message d’origine. Un message entier est contenu dans un seul fragment lorsqu'il est de petite taille, Pour les grands messages, Service Broker crée plusieurs fragments.

La fragmentation des messages présente certains avantages. L'envoi d'un message volumineux en petits fragments améliore la vitesse globale et accroît la fiabilité lorsque la communication s'effectue sur des réseaux relativement lents et peu sûrs tels que les réseaux WAN (Wide-Area Networks). Si un fragment du message est perdu, le protocole retransmet uniquement un fragment plutôt que le message en entier. La fragmentation des messages peut aussi réduire le délai pour qu’un petit message atteigne la destination. Service Broker peut envoyer un fragment qui contient un petit message complet entre les fragments d’un grand message. Cela ralentit légèrement le message de taille importante, afin de diminuer la durée d'attente avant transmission du message de petite taille.

Un message en cours de reconstitution est stocké dans la file d'attente de destination. Si la file d’attente de destination n’est pas disponible, elle est stockée dans la file d’attente de transmission. Un message partiel ne peut pas être reçu par une application. La status colonne d’un message partiel est définie 2 sur (Désactivé). Cette valeur est également utilisée pour les messages reçus dans le désordre.

Accusé de réception de message

Service Broker accuse réception de chaque message reçu. Un accusé de réception peut notifier la réception d’un ou de plusieurs fragments de message. Si possible, l’accusé de réception est ajouté à l’en-tête d’un message renvoyé dans la même conversation. Si aucun autre message n’est prêt pour l’envoi, Service Broker retourne un message d’accusé de réception dédié. L’accusé de réception de message est entièrement géré par Service Broker ; une application qui utilise Service Broker ne reçoit pas ces messages.

Un expéditeur conserve les fragments de message que le destinataire n’a pas reconnu. Si aucun accusé de réception n’est reçu dans le délai d’attente défini par le système, l’expéditeur renvoie le fragment de message. Si aucun accusé de réception n’est reçu pendant le délai d’attente, Service Broker augmente ce délai de façon exponentielle (jusqu’à une valeur maximale) avant la prochaine tentative. La durée d'attente initiale entre deux tentatives est de quelques secondes mais elle peut atteindre une minute environ. Le temps d’attente n’est pas destiné à être précis ; selon le trafic réseau et l’autre activité de l’instance SQL Server, un fragment de message peut ne pas être retenté pendant quelques secondes après l’expiration du délai d’attente.

Si un accusé de réception est perdu ou retardé, le destinataire peut recevoir des messages en double. Dans ce cas, le destinataire accuse réception du message en double, mais ne remet pas le message en double à la file d’attente.

Service Broker utilise les accusés de réception de message pour assurer une messagerie fiable sans transactions distribuées. Un destinataire envoie un accusé de réception uniquement après avoir ajouté le message ou le fragment de message à la file d’attente. L’expéditeur conserve le message dans la file d’attente de transmission jusqu’à l’arrivée du message d’accusé de réception. Bien que l’expéditeur et le destinataire ne partagent jamais une transaction, le protocole garantit que l’expéditeur ne supprime pas le message de la file d’attente de transmission tant que le destinataire n’a pas reçu le message.

Vérification de l’intégrité des messages

Le format que Service Broker utilise pour transmettre les messages comprend une vérification d’intégrité du message pour déterminer si un message donné a été endommagé ou modifié pendant le transport.

La vérification d’intégrité du message est une signature MD5 du contenu du message. SQL Server chiffre la signature avec la clé de session du message et ajoute la signature dans l’en-tête du message.

Le message arrivé à destination est déchiffré, puis sa signature est comparée à la nouvelle signature calculée sur le contenu réellement reçu. Si les signatures ne correspondent pas, le message a été endommagé ou falsifié pendant la transmission. Le message échoue à la vérification d’intégrité. SQL Server ignore le message et ne reconnaît pas le message à l’expéditeur. La classe d’événements Broker:Corrupted Message rapporte des informations quand un message échoue à la vérification d’intégrité.

Objets de transmission Service Broker

Un objet de transmission Service Broker est un objet en mémoire qui gère et enregistre l’état des transmissions de message pour un dialogue. Chaque point de terminaison de conversation a un objet de transmission.

Un dialogue demande un objet de transmission lorsqu'il effectue les opérations suivantes :

• Envoi d'un message par le biais de la file d'attente de transmission. Notamment :

  • Tous les messages envoyés à une instance distante du moteur de base de données

  • Messages à envoyer des files d’attente dans l’instance locale si le message ne peut pas être directement inséré dans la file d’attente de destination

• Réception d'un message distant ou d'un message qui provient d'une file d'attente de transmission locale.

Un objet de transmission est créé la première fois qu’un dialogue en demande un. Service Broker utilise le même objet de transmission pour les demandes suivantes de cette boîte de dialogue. Les objets de transmission sont modifiés chaque fois que Service Broker doit enregistrer un changement d’état des transmissions pour le dialogue. La taille des objets de transmission est d'environ 1 Ko.

Pour libérer de la mémoire, Service Broker stocke régulièrement des lots d’objets de transmission inactifs dans tempdb des tables de travail. Lorsqu’un objet de transmission est modifié en mémoire, il est marqué comme sale. L’objet de transmission reste marqué comme sale jusqu’à ce qu’il soit vidé dans une table de travail.

Les objets de transmission ne sont pas utilisés pour l’envoi ou la réception de messages locaux qui peuvent être insérés directement dans la file d’attente de destination.

Flux de communication réseau

L’illustration suivante présente une vue générale des communications réseau Service Broker entre deux instances SQL Server.

La conversation est une connexion permanente et logique. Sa durée n'est pas limitée et elle peut utiliser le nombre de connexions réseau qui lui sont nécessaires le temps de son déroulement.

Les connexions réseau se produisent entre deux points de terminaison Service Broker. et utilisent le protocole TCP/IP. Si la connexion est inactive pendant un instant, SQL Server ferme la connexion réseau.

Pour remettre un message, Service Broker conserve le message dans la file d’attente de transmission de la base de données qui a envoyé le message. Le destinataire remet le message directement dans la file d'attente du service de destination. Si cette file d’attente est OFF, le message est conservé temporairement dans la file d’attente de transmission pour la base de données de réception. La file d’attente du service d’envoi n’est pas impliquée dans l’opération. La file d’attente de transmission de la base de données qui héberge le service de réception n’est impliquée que si la file d’attente de destination est OFF.

Contenu connexe

• Routage du Service Broker