Protocolos de comunicación de Service Broker
Service Broker usa un protocolo específico del broker para comunicarse con los brokers remotos. El broker administra las conexiones independientemente del grupo normal de conexiones de cliente. Para que dos instancias de SQL Server intercambien mensajes de Service Broker, cada instancia debe poder enviar tráfico TCP/IP al puerto que usa la otra instancia para las comunicaciones de Service Broker. Por convención, Service Broker suele usar el puerto 4022 para la comunicación entre brokers. Sin embargo, el puerto exacto se especifica cuando se crea el extremo.
Capas del protocolo
Service Broker establece un método por capas para la comunicación. Cada capa se genera sobre la capa subyacente para asegurar una entrega confiable. Este método permite a una aplicación operar sin saber la ubicación del servicio remoto o el transporte físico que utiliza el broker para comunicarse. En la mayoría de los casos, estos protocolos resultan transparentes para una aplicación. Sin embargo, resulta útil conocer el papel que desempeña cada capa del protocolo para solucionar los problemas con una aplicación.
El protocolo del nivel más alto que utiliza el broker es el protocolo de diálogo. La capa del protocolo de diálogo controla la transmisión de mensajes confiable y secuencial. Esta capa genera números de secuencia para los mensajes, genera mensajes de reconocimiento, entrega mensajes a las colas adecuadas y fragmenta y vuelve a componer los mensajes. El protocolo de diálogo controla la autenticación y el cifrado de un diálogo.
El protocolo de diálogo utiliza el protocolo del broker adyacente para transmitir fragmentos de mensaje. El protocolo del broker adyacente controla las transmisiones de red intercambiadas entre dos instancias de broker.
El protocolo del broker adyacente utiliza un protocolo de transporte, como TCP/IP, para mover mensajes de broker a broker.
Protocolo de diálogo
El protocolo de diálogo aplica el patrón de entrega exactamente una vez por orden (EOIO) en los mensajes de una conversación. Este protocolo no describe el formato que usan los mensajes de Service Broker en la red. En su lugar, especifica los pasos lógicos necesarios para una conversación confiable. El protocolo de diálogo controla las tareas necesarias para la entrega confiable, incluida la generación y el procesamiento de mensajes de reconocimiento.
Cada extremo de una conversación es un extremo en la capa del protocolo de diálogo. La vista de catálogo sys.conversation_endpoints muestra información sobre los extremos del protocolo de diálogo. Un extremo de una conversación existe mientras existe la conversación.
Protocolo del broker adyacente
El protocolo del broker adyacente controla los mecanismos de comunicación entre dos instancias de SQL Server. Esta capa codifica cada fragmento de mensaje en un formato estándar adecuado para la transmisión a través de la red. A diferencia de la capa del protocolo de diálogo, la capa del protocolo adyacente reconoce el transporte de red utilizado y da formato a los fragmentos del mensaje de forma adecuada. De hecho, la capa del protocolo del broker adyacente proporciona una capa de abstracción entre la capa del protocolo de diálogo y la capa del protocolo de transporte.
Cada conexión de red de Service Broker es un extremo de la capa del protocolo adyacente. La vista de administración dinámica sys.dm_broker_connections muestra información sobre las conexiones de red de Service Broker. Service Broker mantiene la conexión de red mientras se intercambian los mensajes activamente. Service Broker cierra la conexión de red cuando no se ha enviado ni recibido ningún mensaje sobre la conexión de red durante un período breve de tiempo.
Protocolo de transporte
La capa del protocolo de transporte controla la transmisión de red real. Esta capa se encuentra fuera de Service Broker. Por ejemplo, los mensajes a un broker que se ejecuta en una instancia distinta de SQL Server utilizan TCP/IP como capa del protocolo de transporte.
Los extremos de Service Broker establecen opciones para el protocolo de transporte. De forma predeterminada, SQL Server no contiene extremos de Service Broker. Para obtener más información acerca de la creación de un extremo de Service Broker, vea Cómo activar las funciones de red de Service Broker (Transact-SQL).
Procesamiento de mensajes de Service Broker
Service Broker usa dos categorías de mensaje distintas. Un mensaje en secuencia es un mensaje que debe entregarse a una aplicación exactamente una vez, en orden. Un mensaje sin secuencia es un mensaje que puede procesarse de forma inmediata, independientemente de la secuencia en la que llega el mensaje.
Service Broker usa mensajes en secuencia para todos los tipos de mensajes definidos por el usuario, los mensajes de fin de diálogo y los mensajes de error creados por una aplicación. Cada mensaje en secuencia tiene un número de secuencia. La instancia que origina el mensaje crea el número de secuencia de mensaje y lo asigna al mensaje. El broker receptor utiliza el número de secuencia de mensaje para ordenar los mensajes que proporciona a la aplicación. Para un diálogo determinado, la aplicación recibe siempre primero el mensaje con el número de secuencia inferior. Service Broker también usa el número de secuencia de mensaje para detectar mensajes duplicados. Cuando una capa del protocolo de diálogo recibe dos mensajes en el mismo diálogo con el mismo número de secuencia, considera que los mensajes están duplicados y descarta uno.
Service Broker usa mensajes sin secuencia para mensajes de confirmación dedicados y mensajes de error creados por Service Broker. Service Broker no tiene precauciones especiales para entregar un mensaje sin secuencia. Sin embargo, tenga en cuenta que Service Broker crea mensajes sin secuencia como respuesta a mensajes entrantes. Por tanto, si el mensaje sin secuencia se pierde, el remitente volverá a intentar enviar el mensaje original; a continuación, el destinatario generará otro mensaje sin secuencia.
Fragmentación de mensajes
Service Broker divide los mensajes salientes en fragmentos y combina los fragmentos entrantes en el mensaje original. En el caso de mensajes pequeños, el mensaje completo se incluye en un fragmento. En los mensajes grandes, Service Broker crea muchos fragmentos.
La fragmentación de mensajes tiene varias ventajas. El envío de un mensaje grande en pequeños fragmentos mejora la velocidad y la confiabilidad globales en la comunicación a través de redes relativamente lentas y poco confiables como las redes de área extensa (WAN). Si se pierde un fragmento del mensaje, el protocolo retransmite únicamente un fragmento en lugar del mensaje completo. La fragmentación de los mensajes grandes también puede reducir el tiempo necesario para que un mensaje pequeño alcance el destino. Service Broker pueden enviar un fragmento que contenga un mensaje pequeño completo entre los fragmentos de un mensaje grande. Esto ralentiza ligeramente el mensaje grande para reducir el tiempo que el mensaje pequeño espera para ser transmitido.
Mientras se vuelve a ensamblar un mensaje, el mensaje parcial se almacena en la cola de destino. Si la cola de destino no está disponible, se almacena en la cola de transmisión. Una aplicación no puede recibir un mensaje parcial. La columna de estado de un mensaje parcial se establece en 2 (deshabilitada). Este valor también se utiliza para los mensajes recibidos sin orden.
Reconocimiento de mensajes
Service Broker confirma cada mensaje recibido. Un reconocimiento puede reconocer uno o varios fragmentos de mensajes. Si es posible, se incluye un reconocimiento en el encabezado de un mensaje devuelto en la misma conversación. Si no hay ningún otro mensaje listo para enviar, Service Broker devuelve un mensaje de reconocimiento dedicado. El reconocimiento de mensajes está controlado íntegramente por Service Broker; las aplicaciones que usan Service Broker no reciben estos mensajes.
Un remitente retiene los fragmentos del mensaje que el destinatario no ha reconocido. Si no se recibe ningún reconocimiento en un tiempo de espera definido por el sistema, el remitente vuelve a enviar el fragmento del mensaje. Si no se recibe ningún reconocimiento en el tiempo de espera, Service Broker incrementa de forma exponencial la cantidad de tiempo antes del siguiente reintento, hasta un tiempo de espera máximo. El tiempo de espera inicial para un reintento es de algunos segundos. El tiempo de espera máximo es de aproximadamente un minuto. Observe que no está previsto que el tiempo de espera sea preciso; dependiendo del tráfico de la red y de las demás actividades en la instancia de SQL Server, puede que se vuelva a intentar enviar el fragmento de mensaje unos segundos después de que finalice el tiempo de espera.
Si un reconocimiento se pierde o se retrasa, el destinatario puede recibir mensajes duplicados. En este caso, el destinatario confirma la recepción del mensaje duplicado pero no entrega el mensaje duplicado a la cola.
Service Broker usa el reconocimiento de mensajes para proporcionar mensajería confiable sin transacciones distribuidas. Un destinatario envía un reconocimiento sólo después de agregar el mensaje o el fragmento de mensaje a la cola. El remitente aloja el mensaje en la cola de transmisión hasta que llega su reconocimiento. Aunque el remitente y el destinatario nunca comparten una transacción, el protocolo garantiza que el remitente no quita el mensaje de la cola de transmisión hasta que el destinatario ha recibido el mensaje correctamente.
Comprobación de integridad del mensaje
El formato que usa Service Broker para transmitir mensajes incluye una comprobación de integridad del mensaje para determinar si un mensaje dado se ha modificado o dañado durante el transporte.
La comprobación de integridad de mensaje es una firma MD5 para el contenido del mensaje. SQL Server cifra la firma con la clave de sesión para el mensaje e incluye la firma en los encabezados de mensaje.
El destino del mensaje descifra el mensaje y, a continuación, compara la firma del mensaje con una nueva firma calculada en función del contenido real recibido. Si las firmas no coinciden, el mensaje se habrá dañado o modificado durante la transmisión. El mensaje genera un error de comprobación de integridad de mensajes. SQL Server descarta el mensaje y no envía un reconocimiento del mensaje al remitente. La clase de evento Broker:Corrupted Message proporciona información cuando un mensaje genera un error en la comprobación de integridad de mensajes.
Objetos de transmisión de Service Broker
Un objeto de transmisión de Service Broker es un objeto en la memoria que administra y graba el estado de las transmisiones de mensaje para un diálogo. Todos los extremos de la conversación tienen un objeto de transmisión.
Un diálogo solicita un objeto de transmisión cuando hace lo siguiente:
Envía un mensaje a través de la cola de transmisión. Incluye lo siguiente:
Todos los mensajes enviados a una instancia remota de Database Engine (Motor de base de datos)
Mensajes para enviar colas en la instancia local si el mensaje no se puede insertar directamente en la cola de destino
Recibe un mensaje remoto o un mensaje que procede de una cola de transmisión local.
Un objeto de transmisión se crea la primera vez que un diálogo solicita uno. Service Broker usa el mismo objeto de transmisión para las solicitudes posteriores de ese diálogo. Los objetos de transmisión se modifican cada vez que Service Broker tiene que grabar un cambio en el estado de transmisiones para el diálogo. Los objetos de transmisión tienen un tamaño aproximado de 1 KB.
Para liberar memoria, Service Broker almacena periódicamente lotes de objetos de transmisión inactivos en tablas de trabajo de tempdb. Cuando un objeto de transmisión se modifica en memoria por primera vez, se marca como modificado. El objeto de transmisión permanece marcado como modificado hasta que se vacía en una tabla de trabajo.
Los objetos de transmisión no se usan para enviar o recibir mensajes locales que se pueden insertar directamente en la cola de destino.
Flujo de comunicación de red
En la siguiente ilustración se presenta una vista general de la comunicación de red de Service Broker entre dos instancias de SQL Server.
.gif "Comunicación de red de broker entre dos instancias")
Observe que la conversación es una conexión lógica y persistente. La conversación puede producirse a lo largo de cualquier período de tiempo; durante ese período de tiempo, la conversación puede usar cualquier número de conexiones de red.
Las conexiones de red se producen entre dos extremos de Service Broker. Estas conexiones utilizan TCP/IP. Si la conexión está inactiva durante poco tiempo, SQL Server cierra la conexión de red.
Para entregar un mensaje, Service Broker aloja el mensaje en la cola de transmisión de la base de datos que ha enviado el mensaje. El destinatario entrega el mensaje directamente a la cola para el servicio de destino. Si esa cola está desactivada, el mensaje se mantiene temporalmente en la cola de transmisión de la base de datos de recepción. La cola para el servicio de envío no está implicada en la operación. La cola de transmisión para la base de datos que hospeda el servicio receptor sólo está implicada si la cola de destino está apagada.