ES2894900T3 - Selección del procedimiento de transporte para la entrega de notificaciones del servidor - Google Patents

Selección del procedimiento de transporte para la entrega de notificaciones del servidor Download PDF

Info

Publication number
ES2894900T3
ES2894900T3 ES17755350T ES17755350T ES2894900T3 ES 2894900 T3 ES2894900 T3 ES 2894900T3 ES 17755350 T ES17755350 T ES 17755350T ES 17755350 T ES17755350 T ES 17755350T ES 2894900 T3 ES2894900 T3 ES 2894900T3
Authority
ES
Spain
Prior art keywords
server
transport
client
transport procedure
transfer protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17755350T
Other languages
English (en)
Inventor
Uwe Rauschenbach
Thomas Belling
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Application granted granted Critical
Publication of ES2894900T3 publication Critical patent/ES2894900T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un procedimiento (500) que comprende: enviar (510), por un cliente (110), una solicitud de protocolo de transferencia de hipertexto para que al menos una notificación asíncrona sea enviada por un servidor (112) al cliente, incluyendo la solicitud de protocolo de transferencia de hipertexto al menos un procedimiento de transporte propuesto para llevar la al menos una notificación asíncrona, caracterizado porque comprende, además: determinar (520), por el cliente (110), si un primer procedimiento de transporte seleccionado por el servidor (112) del al menos un procedimiento de transporte propuesto se ha establecido con éxito, en el que se determina que el primer procedimiento de transporte se ha establecido con éxito basándose en un mensaje para sondear el establecimiento del primer procedimiento de transporte que se recibe del servidor (112); y cuando la determinación es que el primer procedimiento de transporte no se establece con éxito, enviar (530), por el cliente (110), otra solicitud de protocolo de transferencia de hipertexto al servidor (112), incluyendo la otra solicitud de protocolo de transferencia de hipertexto al menos otro procedimiento de transporte propuesto.

Description

DESCRIPCIÓN
Selección del procedimiento de transporte para la entrega de notificaciones del servidor
Campo
El tema que se describe en la presente memoria se refiere a la entrega de notificaciones del servidor, que pueden comprender notificaciones asíncronas.
Antecedentes
El Protocolo de Transferencia de Hipertexto (HTTP) se refiere a un protocolo de solicitud-respuesta comúnmente usado para el transporte en un marco de trabajo cliente-servidor. HTTP es comúnmente usado en la red informática mundial (WWW). Por ejemplo, una aplicación cliente, como un navegador web, puede enviar un mensaje de solicitud HTTP a un servidor, como un sitio web acoplado a Internet. En este ejemplo, la solicitud al servidor puede permitir al cliente obtener datos del servidor, enviar datos al servidor, eliminar datos almacenados en el servidor, y/o realizar otras acciones. El servidor del sitio web puede devolver a la aplicación del cliente una respuesta que incluya un estado de terminación de la solicitud del cliente, el contenido solicitado por el cliente, y/u algo similar. HTTP puede estar de acuerdo con uno o más estándares, tales como el Grupo de Trabajo de Ingeniería de Internet (IETF), Solicitud de Comentarios (RFC) 1945 (HTTP versión 1.0), RFC 7230-7235 (HTTP versión 1.1), RFC 7540 (HTTP versión 2.0), y/u otros estándares. Además de la WWW, HTTP puede usarse también para el transporte en otras aplicaciones. El Proyecto de Asociación de Tercera Generación (3GPP), por ejemplo, incluye en algunos estándares usar HTTP (véase, por ejemplo, 3GPPP TS 29.122, "T8 reference point for Northbound APIs").
Se conoce la técnica relacionada del documento US 2016/150027 A1 relativo a un procedimiento de gestión de la desconexión del canal de notificación, en el que se envía una solicitud HTTP para al menos una notificación asíncrona desde un cliente a un servidor, siendo la solicitud HTTP para transportar la al menos una notificación asíncrona desde el servidor al cliente mediante el uso de un procedimiento de transporte específico, es decir, Sondeo largo. Se conoce otra técnica relacionada del documento US 8117322 B1 relacionados con la reducción de la latencia en los servidores HTTP, y el documento US 6 965 917 B1 relativo a una técnica para notificar a un suscriptor de la ocurrencia de un evento.
Sumario
En la presente divulgación, se proporcionan procedimientos y aparatos, incluidos productos de programas de computadoras, para la selección del procedimiento de transporte de las notificaciones asíncronas.
De acuerdo con la presente invención, se proporcionan procedimientos, aparatos y medios legibles por ordenador no transitorios, como se define en las reivindicaciones.
En algunas realizaciones de ejemplo, se puede proporcionar un procedimiento que incluye el envío, por parte de un cliente, de una solicitud de protocolo de transferencia de hipertexto para que al menos una notificación asíncrona sea enviada por un servidor al cliente, la solicitud de protocolo de transferencia de hipertexto incluye al menos un procedimiento de transporte propuesto para llevar la al menos una notificación asíncrona; determinar, por el cliente, si un primer procedimiento de transporte seleccionado por el servidor de entre el al menos un procedimiento de transporte propuesto se ha establecido con éxito, en el que se determina que el primer procedimiento de transporte se ha establecido con éxito basándose en un mensaje para sondear el establecimiento del primer procedimiento de transporte que se recibe del servidor, y cuando la determinación es que el primer procedimiento de transporte no se ha establecido con éxito, enviar, por el cliente, otra solicitud de protocolo de transferencia de hipertexto al servidor, la otra solicitud de protocolo de transferencia de hipertexto incluyendo al menos otro procedimiento de transporte propuesto.
En algunas variaciones, una o más de las características divulgadas en la presente memoria, incluyendo las siguientes características, pueden incluirse opcionalmente en cualquier combinación factible. La solicitud del protocolo de transferencia de hipertexto puede incluir un identificador de recursos uniforme de devolución de llamada en el cliente para permitir una devolución de llamada del protocolo de transporte de hipertexto inverso al cliente. La solicitud de protocolo de transferencia de hipertexto puede incluir una solicitud para que el servidor sondee, mediante un mensaje de notificación de prueba, si el primer procedimiento de transporte se ha establecido con éxito. El al menos un procedimiento de transporte propuesto puede incluir un protocolo de transferencia de hipertexto inverso, un WebSocket y/o un Sondeo Largo. Se puede determinar que el primer procedimiento de transporte se ha establecido con éxito basándose en al menos un mensaje recibido del servidor antes de un tiempo de espera, una notificación de prueba recibida del servidor antes del tiempo de espera, un ping recibido del servidor antes del tiempo de espera, un mensaje recibido del servidor lleva un identificador de recursos uniforme de WebSocket en el servidor, y/o una respuesta a un ping enviado por el cliente recibido del servidor antes del tiempo de espera. El cliente puede recibir la al menos una notificación asíncrona transportada a través del primer procedimiento de transporte, cuando la determinación es que el primer procedimiento de transporte se establece con éxito. El primer procedimiento de transporte seleccionado por el servidor puede recibirse por el cliente en una respuesta a la solicitud de protocolo de transferencia de hipertexto y se indica mediante un parámetro explícito. La respuesta puede incluir un identificador de recursos uniforme de WebSocket. La respuesta puede incluir un identificador de recursos uniforme del protocolo de transferencia de hipertexto para usar con sondeos largos. El al menos un procedimiento de transporte propuesto puede indicarse en la solicitud del protocolo de transferencia de hipertexto mediante el parámetro explícito. La solicitud puede incluir un identificador de recursos uniforme de devolución de llamada. El primer procedimiento de transporte puede incluir el protocolo de transferencia de hipertexto inverso. El otro procedimiento de transporte puede incluir el WebSocket. El Sondeo Largo puede representar un procedimiento de transporte predeterminado cuando el primer procedimiento de transporte y el otro procedimiento de transporte no se establecen correctamente. El cliente y el servidor pueden usar el protocolo de transferencia de hipertexto para el transporte de otros tipos de datos.
En algunas realizaciones de ejemplo, se puede proporcionar un procedimiento que incluye recibir, por un servidor, una solicitud de protocolo de transferencia de hipertexto para que el servidor envíe al menos una notificación asíncrona, la solicitud de protocolo de transferencia de hipertexto incluye al menos un procedimiento de transporte propuesto para llevar la al menos una notificación asíncrona; enviar, por el servidor, una indicación de si un primer procedimiento de transporte seleccionado por el servidor de entre el al menos un procedimiento de transporte propuesto se acepta para su establecimiento; enviar, por el servidor, un mensaje para sondear el establecimiento del primer procedimiento de transporte; y recibir, por el servidor, otra solicitud de protocolo de transferencia de hipertexto que incluya al menos otro procedimiento de transporte propuesto, cuando el primer transporte no sea aceptado para su establecimiento y/o no se establezca con éxito.
En algunas variaciones, una o más de las características divulgadas en la presente memoria, incluyendo las siguientes características, pueden incluirse opcionalmente en cualquier combinación factible. La solicitud del protocolo de transferencia de hipertexto puede incluir un identificador de recursos uniforme de devolución de llamada en el cliente para permitir una devolución de llamada del protocolo de transporte de hipertexto inverso al cliente. La solicitud de protocolo de transferencia de hipertexto puede incluir una solicitud para que el servidor sondee el establecimiento a través de un mensaje de notificación de prueba. La indicación puede incluir un mensaje enviado al cliente antes del tiempo de espera, una notificación de prueba enviada al cliente antes del tiempo de espera, un ping enviado al cliente antes del tiempo de espera. El mensaje puede incluir un identificador de recursos uniforme en el servidor. El servidor puede enviar la al menos una notificación asíncrona transportada a través del primer procedimiento de transporte, cuando el primer transporte se acepta para su establecimiento por el servidor y/o es establecido con éxito. El primer procedimiento de transporte seleccionado por el servidor puede recibirse por el cliente en una respuesta a la solicitud de protocolo de transferencia de hipertexto y se indica mediante un parámetro explícito. La respuesta puede incluir un identificador de recursos uniforme de WebSocket. La respuesta puede incluir un identificador de recursos uniforme del protocolo de transferencia de hipertexto para usar en el Sondeo Largo. El al menos un procedimiento de transporte propuesto puede indicarse en la solicitud del protocolo de transferencia de hipertexto mediante el parámetro explícito. La solicitud puede incluir un identificador de recursos uniforme de devolución de llamada. El primer procedimiento de transporte puede incluir el protocolo de transferencia de hipertexto inverso. El otro procedimiento de transporte puede incluir el WebSocket. El Sondeo Largo puede representar un procedimiento de transporte predeterminado cuando el primer procedimiento de transporte y el otro procedimiento de transporte no se establecen correctamente. El cliente y el servidor pueden usar el protocolo de transferencia de hipertexto para el transporte de otros tipos de datos.
Los aspectos y características mencionados anteriormente pueden implementarse en sistemas, aparatos, procedimientos y/o artículos en función de la configuración deseada. Los detalles de una o más variaciones de la materia descrita en la presente memoria se exponen en los dibujos adjuntos y en la descripción más abajo. Las características y ventajas de la materia descrita en la presente memoria serán evidentes de la descripción y los dibujos, así como de las reivindicaciones.
Descripción de los dibujos
En los dibujos,
La Figura 1A representa un ejemplo de cliente y servidor, de acuerdo con algunas realizaciones de ejemplo;
La Figura 1B representa un ejemplo de un procedimiento para negociar un procedimiento de transporte para la notificación del servidor, de acuerdo con algunas realizaciones de ejemplo;
La Figura 2 representa un ejemplo de un procedimiento para crear el procedimiento de transporte HTTP inverso para notificaciones de servidor enviadas de forma asíncrona a un cliente, de acuerdo con algunas realizaciones de ejemplo;
La Figura 3 representa un ejemplo de un procedimiento para crear el transporte WebSocket para las notificaciones del servidor enviadas de forma asíncrona a un cliente, de acuerdo con algunas realizaciones de ejemplo;
La Figura 4 representa un ejemplo de un procedimiento para crear el transporte de Sondeo Largo para las notificaciones del servidor enviadas de forma asíncrona a un cliente, de acuerdo con algunas realizaciones de ejemplo;
Las Figuras 5A-5B representan ejemplos de procedimientos, de acuerdo con algunas realizaciones de ejemplo; y La Figura 6 representa un ejemplo de un aparato, de acuerdo con algunas realizaciones de ejemplo.
Las etiquetas similares se usan para hacer referencia a elementos iguales o similares En los dibujos acompañantes, los cuales ilustran una o más realizaciones ilustrativas.
Descripción detallada
Muchas aplicaciones tienen requisitos para enviar notificaciones asíncronas desde un servidor de interfaz de programación de aplicaciones (API) a un cliente API. Sin embargo, en HTTP al cliente típicamente sólo se le permite enviar peticiones HTTP, mientras que el servidor sólo puede responder a las peticiones del cliente. Como tal, el envío de la notificación asíncrona por parte del servidor en un marco de trabajo HTTP puede considerarse problemático. La "notificación asíncrona" puede referirse a un mensaje enviado por el servidor de forma no solicitada (por ejemplo, de forma asíncrona) en el sentido de que el mensaje de notificación asíncrona no es en respuesta a la solicitud del cliente API.
Dado el problema de notificación asíncrona señalado, una solución puede ser usar un procedimiento de conexión denominado "HTTP inverso". Este procedimiento de conexión HTTP inverso puede incluir una segunda conexión HTTP separada con los roles de cliente y servidor invertidos para permitir la transmisión de notificaciones como solicitudes HTTP enviadas por el servidor API al cliente API. En esta segunda conexión, el cliente API funciona como un servidor HTTP, mientras que el servidor API funciona como un cliente HTTP capaz de enviar solicitudes como notificaciones, incluidas notificaciones asíncronas. En la segunda conexión, si el cliente API reside detrás de un cortafuegos, el cortafuegos puede bloquear las solicitudes enviadas hacia ese cliente API.
La Figura 1A representa un ejemplo del cliente API 1101 y el servidor API 1121 que incluye la primera conexión HTTP 192 y la segunda conexión HTTP separada 194, que es invertida en el sentido de que el servidor 1121 actúa, para la conexión 194, como un cliente HTTP ("C") mientras que el cliente 1101 actúa como un servidor HTTP ("S") para la segunda conexión 194. El cliente 1101 y/o el servidor 1121 pueden implementarse en una computadora, tableta, teléfono inteligente y/u otro dispositivo basado en procesador. El cliente 1101 y/o el servidor 1121 pueden establecer las conexiones HTTP 192 y 194 a través de una o más redes que incluyen Internet, redes celulares y/o similares. Además, las conexiones HTTP 192 y/o 194 pueden establecerse mediante enlaces por cable y/o inalámbricos. Para ilustrar más, un primer ordenador puede incluir un cliente API 1101 que puede establecer, a través de enlaces cableados y/o inalámbricos, una conexión HTTP 192 a un segundo ordenador tal como un servidor de sitio web que incluye el servidor API 1121.
Otra solución al problema de notificación asíncrona señalado es el protocolo WebSocket, que puede proporcionar canales de transporte dúplex completos a través del protocolo de control de transporte (TCP). Por tanto, el protocolo WebSocket puede proporcionar una forma para que el servidor envíe contenido al cliente de forma asíncrona (por ejemplo, sin que el cliente lo solicite). El protocolo WebSocket puede estar de acuerdo con IETF RFC 6455, "The WebSocket Protocol, noviembre de 2011."
Con el protocolo WebSocket de acuerdo con el RFC 6455, HTTP se usa inicialmente como parte del intercambio de información cliente-servidor para configurar la(s) conexión(es) de transporte, y después de esta configuración, la transferencia subsiguiente se convierte en transporte WebSocket totalmente-dúplex realizado de acuerdo con el protocolo WebSocket (por lo que ciertas características de HTTP como el encuadre y similares pueden no estar disponibles después de la conversión). Sin embargo, el protocolo WebSocket funciona a través de la mayoría de los cortafuegos modernos configurados para permitir el cruce por HTTP (lo que supone que los cortafuegos también permiten la actualización de la conexión HTTP a WebSocket).
Otra solución al problema de notificación asíncrona señalado es el "Sondeo largo" basado en el protocolo HTTP (consulte, por ejemplo, RFC 6202, "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", abril de 2011). En el transporte HTTP, el servidor no puede iniciar una conexión con el cliente o enviar una respuesta HTTP no solicitada a un cliente, por lo que el servidor no puede enviar notificaciones asíncronas al cliente. Con Sondeo Largo, el servidor intenta mantener abierto (por ejemplo, no responder inmediatamente) cada solicitud HTTP, por lo que el servidor puede responder al cliente cuando hay eventos para suministrar. Como tal, el servidor tiene una solicitud de cliente pendiente a la que el servidor puede responder con el fin de entregar eventos, como las notificaciones/notificaciones asíncronas a medida que ocurren.
El Sondeo Largo puede funcionar a través de la mayoría de los cortafuegos que pueden atravesar HTTP, y es posible que el Sondeo Largo no requiera el desarrollo de marcos adicionales y/o similares, como es el caso del protocolo WebSocket. Sin embargo, se puede considerar que el Sondeo Largo tiene un menor rendimiento, en comparación con el protocolo WebSocket o el procedimiento HTTP inverso.
Las tres soluciones mencionadas anteriormente para el problema de la notificación asíncrona dejan en claro que no existe una solución única para todos. En algunas realizaciones de ejemplo, se proporciona una forma de seleccionar, a través de una negociación, qué mecanismo de transporte se va a usar entre un cliente y un servidor. En algunas realizaciones de ejemplo, se puede proporcionar una forma de seleccionar a través de una negociación entre una pluralidad de procedimientos de transporte HTTP. En algunas realizaciones de ejemplo, la pluralidad de procedimientos de transporte HTTP puede incluir el procedimiento HTTP inverso, el procedimiento WebSocket y/o el procedimiento de Sondeo Largo. El procedimiento seleccionado puede, de acuerdo con algunas realizaciones de ejemplo, probarse para determinar si el procedimiento seleccionado puede implementarse con éxito (por ejemplo, establecerse y/o operar a través de un cortafuegos). En algunas realizaciones de ejemplo, el procedimiento de transporte seleccionado puede usarse por el servidor para enviar notificaciones incluyendo notificaciones asíncronas al cliente, sin embargo, HTTP puede seguir siendo usado para otros tipos de transporte.
Si un cliente, como un cliente API, necesita recibir notificaciones asíncronas de un servidor, como un servidor API, el cliente puede enviar una solicitud, como un mensaje, al servidor para indicarle que envíe las notificaciones, como notificaciones asíncronas. Dentro de esa solicitud, el cliente puede indicar al servidor qué procedimiento(s) de transporte soporta o permite el cliente para las notificaciones del servidor, como las notificaciones asíncronas, de acuerdo con algunas realizaciones de ejemplo.
En algunas realizaciones de ejemplo, el cliente puede enviar una solicitud proponiendo, como parte de una negociación, al servidor un único procedimiento de transporte, como el procedimiento de conexión HTTP inverso. Si este procedimiento de transporte único se acepta por el servidor y/o configurado/establecido con éxito, el servidor puede comenzar a enviar notificaciones, como las notificaciones asíncronas, al cliente a través del procedimiento de transporte seleccionado de acuerdo con algunas realizaciones de ejemplo. Si este único procedimiento de transporte no se acepta por el servidor y/o la configuración/establecimiento no tiene éxito, el cliente puede proponer, como parte de la negociación, otra solicitud de transporte, de acuerdo con algunas realizaciones de ejemplo. Por ejemplo, si el cliente solicita al servidor usar el HTTP inverso para las notificaciones asíncronas pero el servidor no soporta el HTTP inverso propuesto, el servidor puede rechazar la solicitud.
En algunas realizaciones de ejemplo, el cliente puede enviar una solicitud proponiendo, como parte de una negociación, al servidor una pluralidad de procedimientos de transporte. Cuando este es el caso, el servidor puede responder con una indicación del procedimiento de transporte seleccionado. Si el procedimiento de transporte seleccionado se puede configurar/establecer con éxito, el servidor puede comenzar a enviar notificaciones, como las notificaciones asíncronas, al cliente a través del procedimiento de transporte seleccionado, de acuerdo con algunas realizaciones de ejemplo. Si el procedimiento de transporte seleccionado no se configura/establece con éxito, se puede proponer y/o seleccionar otra solicitud de transporte para usar por el servidor, de acuerdo con algunas realizaciones de ejemplo.
Además, cuando el cliente envía una solicitud proponiendo, como parte de una negociación, al servidor una pluralidad de procedimientos de transporte, por ejemplo, el servidor puede seleccionar uno de los procedimientos de transporte y puede responder al cliente con el procedimiento de transporte seleccionado. Alternativa o adicionalmente, el cliente puede enviar una solicitud proponiendo, como parte de una negociación, al servidor un procedimiento de transporte único, por ejemplo, el servidor puede aceptar ese procedimiento de transporte y puede responder al cliente con el procedimiento de transporte seleccionado. Subsecuentemente, el servidor y el cliente pueden intercambiar mensajes a través del procedimiento de transporte seleccionado (por ejemplo, aceptado) para sondear la viabilidad del procedimiento de transporte seleccionado. Si el sondeo tiene éxito, el cliente y el servidor pueden usar el procedimiento de transporte negociado para la entrega de notificaciones, incluidas las notificaciones asíncronas del servidor. Sin embargo, si el sondeo falla (por ejemplo, debido a que no puede atravesar un cortafuegos o por otras razones), el cliente puede enviar otro mensaje de solicitud proponiendo, como parte de una negociación, al servidor otro procedimiento de transporte, en cuyo caso el sondeo de viabilidad se repite hasta que se selecciona un procedimiento de transporte viable. Si el sondeo de un procedimiento de transporte falla (por ejemplo, HTTP inverso), el cliente puede enviar una solicitud al servidor proponiendo otro procedimiento de transporte (por ejemplo, WebSocket). Si el servidor acepta el otro procedimiento de transporte, se puede volver a realizar un sondeo para determinar la viabilidad del procedimiento de transporte seleccionado. Este procedimiento puede repetirse hasta que se acepte un procedimiento de transporte y se considere viable para usar a través de la sonda.
En algunas realizaciones de ejemplo, el cliente, como el cliente API, puede ofrecer inicialmente un procedimiento de transporte, como el HTTP inverso. Si el sondeo del procedimiento de transporte seleccionado falla (por ejemplo, no se acepta, se rechaza o no se puede establecer ninguna conexión debido al bloqueo por parte de un cortafuegos), el cliente API puede ofrecer otro procedimiento de transporte, como el procedimiento WebSocket o el procedimiento de Sondeo Largo. Durante la configuración y el establecimiento del transporte WebSocket o el transporte de Sondeo Largo, un cortafuegos puede provocar una falla, por ejemplo. Aunque la posibilidad de que e1HTTP inverso falle es mayor, en comparación con WebSocket o el Sondeo Largo, el HTTP inverso puede ser propuesto inicialmente por el cliente API al servidor API antes que los otros dos procedimientos, ya que e1HTTP inverso puede considerarse el más simple o eficiente de los tres procedimientos de transporte a implementar.
Aunque algunos de los ejemplos se refieren a la propuesta de HTTP inverso en primer lugar en la negociación entre el cliente API y el servidor API, se pueden proponer primero otros procedimientos. Además, aunque algunos de los ejemplos se refieren a la selección entre HTTP inverso, WebSocket y Sondeo Largo, la selección puede incluir otros procedimientos de transporte, así como la transmisión HTTP y/o similares. Además, entre el grupo de selección de procedimientos de transporte también puede haber menos o más de 3 procedimientos de transporte.
En HTTP inverso, el cliente API puede proporcionar al servidor API un identificador de recursos uniforme (URI) de devolución de llamada. Este URI de devolución de llamada puede identificar al servidor una dirección IP y/o recursos en el cliente API, aunque el URI puede identificar otro nodo al que el servidor API debería realizar la devolución de llamada para mensajes de notificación. El servidor API puede establecer una conexión HTTP hacia el URI de devolución de llamada antes de enviar una notificación asíncrona inicial al cliente API. El aprovisionamiento de URI de devolución de llamada del cliente API en el servidor API también puede indicar que el cliente API admite la recepción de conexiones HTTP separadas a través de HTTP inverso.
El envío de la notificación desde el servidor API al cliente API puede fallar, como se ha señalado, debido al cortafuegos (o al fracaso en el establecimiento de la conexión HTTP inverso, y/o por otras razones). En algunas realizaciones de ejemplo, puede usarse el sondeo para probar la capacidad de las conexiones HTTP para atravesar con éxito los cortafuegos (si están presentes). A continuación, se ilustran dos ejemplos de técnicas de sondeo, de acuerdo con algunas realizaciones de ejemplo.
La primera técnica de sondeo puede incluir el envío de una notificación de prueba. Por ejemplo, el marco de trabajo de la aplicación (que se proporciona por el servidor API y accedido por el cliente API) puede definir un mensaje de notificación de prueba que puede usarse para sondear, de acuerdo con algunas realizaciones de ejemplo. El servidor API puede enviar el mensaje de notificación de prueba al URI de devolución de llamada proporcionado por el cliente API. En algunas realizaciones de ejemplo, el cliente API puede solicitar una notificación de prueba en el mismo mensaje que lleva el URI de devolución de llamada al servidor API, aunque la solicitud del mensaje de notificación de prueba también puede llevarse o señalarse al servidor API de otras maneras. Si el cliente API recibe la notificación de prueba del servidor antes de un tiempo de espera (por ejemplo, la expiración de un temporizador), el cliente API sabe que el HTTP inverso funciona correctamente.
Cuando el URI de devolución de llamada apunta a otro nodo (por ejemplo, un nodo separado del cliente API), el otro nodo puede informar al cliente API de la recepción de la notificación de prueba enviada por el servidor API. Si al cliente API se le informa de la recepción de la notificación de prueba del otro nodo antes de un tiempo de espera, el cliente API sabe que el procedimiento HTTP inverso funciona con éxito.
Si el servidor API recibe, antes de que expire el tiempo de espera, una confirmación de que la notificación de prueba se ha recibido en la ubicación de devolución de llamada URI (por ejemplo, en el cliente API o en el nodo separado), el servidor API sabe que el transporte HTTP inverso funciona con éxito, en cuyo caso el servidor API puede empezar a utilizar el HTTP inverso para enviar mensajes de notificación, incluyendo notificaciones asíncronas al cliente API, de acuerdo con algunas realizaciones de ejemplo.
También puede implementarse una segunda técnica de sondeo de acuerdo con algunas realizaciones de ejemplo. En la segunda técnica de sondeo, el servidor API puede enviar una solicitud HTTP GET (u otro tipo de solicitud como HEAD, POST vacía y/o similar) al URI de devolución de llamada. Si el cliente API recibe la solicitud HTTP GET del servidor API antes de que expire el tiempo de espera, el cliente API sabe que e1HTTP inverso funciona correctamente. Si el servidor API recibe una respuesta de éxito HTTP antes de que expire el tiempo de espera, el sondeo puede considerarse exitoso, en cuyo caso el servidor API puede empezar a utilizar el procedimiento de transporte HTTP inverso para enviar mensajes de notificación, incluyendo notificaciones asíncronas al cliente API, de acuerdo con algunas realizaciones de ejemplo. El cliente y el servidor pueden continuar usando HTTP para otros tipos de transporte de datos.
Algunos de los ejemplos en la presente descripción se refieren a un tiempo de espera. El tiempo de espera se puede implementar como un temporizador. El valor del tiempo de espera se puede configurar en el cliente API y/o en el servidor API. Alternativa o adicionalmente, los valores de tiempo de espera se pueden negociar mediante un intercambio de mensajes entre el cliente API y el servidor API. Por ejemplo, el cliente API puede enviar al servidor API un mensaje que incluye el URI de devolución de llamada y un valor de tiempo de espera propuesto (que puede aceptarse por el servidor API o modificado como parte de una negociación).
Cuando el cliente API soporta la recepción de notificaciones/asíncronas desde el servidor API a través del procedimiento de transporte WebSocket, el cliente API puede indicar el soporte de WebSocket en el mensaje de solicitud HTTP inicial enviado al servidor API, de acuerdo con algunas realizaciones de ejemplo. En respuesta a un mensaje de solicitud inicial, el servidor API puede responder al cliente API con un URI de WebSocket (que puede incluir, además, de acuerdo con el protocolo WebSocket, "ws" o "wss", un nombre de host, un puerto opcional, y/o una trayectoria opcional). La respuesta del servidor API (que puede incluir el URI del WebSocket) puede indicar que el servidor API selecciona, como parte de la negociación, el procedimiento de transporte del WebSocket.
Al recibir este URI de WebSocket, el cliente API puede establecer una conexión HTTP independiente hacia el URI de WebSocket. A continuación, el cliente API puede usar el mecanismo de actualización HTTP para convertir la conexión HTTP en una conexión WebSocket de acuerdo con el IETF RFC 6455. Alternativa o adicionalmente, el cliente API puede, al recibir el URI del WebSocket, solicitar a otro nodo que establezca una conexión HTTP hacia ese URI del WebSocket, en cuyo caso el otro nodo puede usar el mecanismo de actualización HTTP para convertir esa conexión HTTP en una conexión WebSocket de acuerdo con el IETF RFC 6455.
Como se ha señalado, la configuración de una conexión WebSocket puede fallar debido a un cortafuegos. Para sondear si un cortafuegos puede causar un fallo con respecto al uso del procedimiento de transporte WebSocket seleccionado, se puede realizar un sondeo, de acuerdo con algunas realizaciones de ejemplo.
Una forma de sondear la conectividad del WebSocket puede ser evaluar el establecimiento del propio WebSocket. Si la conexión WebSocket se establece con éxito mediante el uso del procedimiento del RFC 6455 antes de que se produzca un tiempo de espera, entonces el sondeo puede considerarse exitoso. Debido al diseño del protocolo WebSocket, esto se puede determinar tanto en el cliente como en el servidor. Si el cliente API solicita otro nodo para configurar la conexión WebSocket, el otro nodo puede informar al cliente API cuando se completa la configuración de la conexión WebSocket. Si se informa al cliente API sobre la terminación de la configuración de la conexión WebSocket antes de que se agote el tiempo de espera, el cliente API puede saber que el transporte de WebSocket funciona correctamente.
Otra forma de sondear la conectividad del WebSocket es mediante el uso de una notificación de prueba. Por ejemplo, si el marco de trabajo de la aplicación implementa un mensaje de notificación de prueba, el servidor API puede enviar el mensaje de notificación de prueba para sondear la conectividad del WebSocket tras el establecimiento de la conexión del WebSocket. En algunas realizaciones de ejemplo, el cliente API puede solicitar al servidor API usar el mensaje de notificación de prueba en el mismo mensaje que solicita el uso de WebSocket. Si el cliente API recibe la notificación de prueba antes de que se produzca un tiempo de espera, el cliente API sabe que el WebSocket funciona correctamente. Si el cliente API solicitó a otro nodo que estableciera la conexión WebSocket, el otro nodo puede informar al cliente API cuando se reciba la notificación de prueba. Si al cliente API se le informa de la recepción de la notificación de prueba antes de que se produzca un tiempo de espera, el cliente API sabe que el WebSocket funciona correctamente. Si el servidor API recibe la confirmación de la notificación de prueba antes de que se produzca un tiempo de espera, el servidor API sabe que el WebSocket funciona correctamente, en cuyo caso el servidor API puede comenzar a usar el procedimiento HTTP inverso para enviar mensajes de notificación, incluyendo notificaciones asíncronas al cliente API, de acuerdo con algunas realizaciones de ejemplo.
Otra forma más de probar el WebSocket es mediante el uso de un procedimiento de ping-pong de acuerdo con IETF RFC 6455 después del establecimiento de la conexión WebSocket. Si se completa el procedimiento de ping-pong, el iniciador del procedimiento (que puede ser el cliente API o el servidor API) sabe que el WebSocket funciona bidireccionalmente y el iniciador puede usar el procedimiento WebSocket. Si el cliente API solicitó a otro nodo para configurar la conexión WebSocket, el otro nodo puede iniciar el procedimiento de ping-pong. El otro nodo puede informar al cliente API cuando se ha completado el procedimiento de ping-pong. Si al cliente API se informa de la terminación del procedimiento de ping-pong antes de que se produzca un tiempo de espera, el cliente API sabe que el WebSocket funciona correctamente. Si se agota el tiempo de espera, pero el cliente API no ha sido informado sobre la terminación del procedimiento de ping-pong, el cliente API puede ofrecer otro procedimiento de transporte al servidor API.
En algunas realizaciones de ejemplo, el procedimiento de Sondeo Largo puede considerarse una alternativa universal en el sentido de que el procedimiento de transporte de Sondeo Largo puede seleccionarse, o negociarse, para usar entre el cliente API y el servidor API si el procedimiento HTTP inverso y el procedimiento WebSocket mencionados anteriormente no pueden utilizarse (por ejemplo, si el establecimiento del transporte o el sondeo no tienen éxito).
Si el cliente API admite el uso de Sondeo Largo para notificaciones como notificaciones asíncronas del servidor API, el cliente API puede enviar al servidor API una solicitud para configurar el Sondeo Largo, de acuerdo con algunas realizaciones de ejemplo. Cuando el cliente API solicita al servidor API el establecimiento del Sondeo Largo para la entrega de notificaciones, el servidor API puede incluir un URI de Sondeo Largo en la respuesta a la solicitud. Este URI de Sondeo Largo puede indicar desde qué URI el cliente API puede obtener subsecuentemente notificaciones, incluidas las asíncronas, a través del Sondeo Largo. La inclusión del URI de Sondeo Largo en la respuesta del servidor API también puede indicar al cliente API que el servidor API selecciona el procedimiento de Sondeo Largo para usarse. El cliente API puede, cuando recibe este URI de Sondeo Largo, establecer una conexión HTTP separada hacia el URI de Sondeo Largo en el servidor, y el cliente API puede entonces enviar la primera solicitud de Sondeo Largo al URI de Sondeo Largo en el servidor API. Alternativa o adicionalmente, al recibir este URI de Sondeo Largo, el cliente API puede solicitar que otro nodo establezca una conexión HTTP hacia el URI de Sondeo Largo, y este otro nodo puede enviar la primera solicitud de Sondeo Largo al servidor API.
La conectividad de Sondeo Largo se puede probar enviando un mensaje de notificación de prueba. Si el marco de trabajo de la aplicación admite usar un mensaje de notificación de prueba para sondear, el servidor API puede enviar un mensaje de notificación de prueba a través de la conexión de Sondeo Largo después de recibir la primera solicitud de sondeo del cliente API. El cliente API puede solicitar usar la notificación de prueba en el mensaje de solicitud inicial enviado al servidor API proponiendo usar el Sondeo Largo. Si el servidor API recibe la solicitud de sondeo (que en este ejemplo es una notificación de prueba) antes de que se produzca un tiempo de espera, el servidor API puede saber que el Sondeo Largo funciona correctamente, en cuyo caso el servidor API puede comenzar a usar el Sondeo Largo para las notificaciones, incluyendo las notificaciones asíncronas al cliente API. Si el cliente API recibe esa notificación de prueba antes de que se produzca un tiempo de espera, el cliente API puede saber que el Sondeo Largo funciona correctamente. Si el cliente API solicitó a otro nodo que estableciera la conexión de Sondeo Largo, el otro nodo puede informar al cliente API que la notificación ha sido recibida por el otro nodo antes de que se produzca un tiempo de espera, en cuyo caso el cliente API sabe que el Sondeo Largo funciona con éxito.
Aunque el ejemplo anterior se refiere a sondear el Sondeo Largo, en algunas realizaciones de ejemplo, se puede omitir el sondeo de la conexión de Sondeo Largo, ya que la posibilidad de que se establezca una conexión de Sondeo Largo con éxito (incluso a través de cortafuegos) es muy alta, en comparación con otros procedimientos de transporte.
La Figura 1B representa un ejemplo de un procedimiento 100 para seleccionar un procedimiento de transporte para la notificación del servidor enviada de forma asíncrona a un cliente, de acuerdo con algunas realizaciones de ejemplo.
En 115, se puede crear una suscripción para indicar que puede usarse HTTP inverso para el transporte en una conexión entre el cliente API 110 y el servidor API 112 para habilitar mensajes de notificación del servidor, tales como mensajes de notificación asíncronos, de acuerdo con algunas realizaciones de ejemplo. El cliente API 110 puede proponer el procedimiento de transporte HTTP inverso para una conexión para transportar sólo notificaciones, como notificaciones asíncronas, enviadas por el servidor API al cliente API, de modo que otros tipos de transporte entre el cliente 110 y el servidor 112 pueden permanecer de acuerdo con HTTP, por ejemplo. La suscripción se refiere a un registro de datos que define la intención de un cliente de informarse sobre eventos en un servidor, por lo que la suscripción puede definir los eventos para los que el cliente desea recibir notificaciones, como las notificaciones asíncronas, del servidor. Por ejemplo, la suscripción puede restringir el ámbito a eventos específicos (por ejemplo, definiendo filtros que sólo coincidan con estos eventos específicos) o puede aplicarse a todas las notificaciones que un servidor pueda emitir al cliente. La suscripción también puede incluir información relacionada con la entrega de las notificaciones, como los procedimientos de transporte, los parámetros como el URI, la técnica de sondeo que será usada, y/o similares. Además, la suscripción puede incluir información sobre cuánto tiempo es válida la suscripción.
Si la propuesta de usar HTTP inverso se acepta por el servidor API 112 y/o el sondeo indica que e1HTTP inverso funciona con éxito en 116, el servidor API puede utilizar, en 118, HTTP inverso para las notificaciones asíncronas enviadas por el servidor API al cliente API. El cliente API puede seguir utilizando HTTP, en lugar de HTTP inverso, para otros tipos de transferencias de datos al servidor API.
Si la negociación que propone usar el HTTP inverso no tiene éxito en 120 (por ejemplo, no se acepta por el servidor API 112 y/o el sondeo indica que el HTTP inverso no funciona con éxito debido, por ejemplo, a un cortafuegos), el cliente API 110 puede proponer, en 122, el procedimiento de transporte WebSocket para una conexión que lleve notificaciones enviadas por el servidor API al cliente API. Esta propuesta puede tomar la forma de una actualización de suscripción.
Si la propuesta de usar el procedimiento de transporte WebSocket se acepta por el servidor API 112 y/o el sondeo indica que el WebSocket funciona con éxito en 124, el servidor API puede utilizar, en 126, el transporte WebSocket para las notificaciones asíncronas enviadas por el servidor API al cliente API. El cliente API y el servidor pueden seguir utilizando HTTP, en lugar de WebSocket, para otros tipos de transporte de datos.
Si usar el procedimiento WebSocket propuesto no tiene éxito en 130 (por ejemplo, no se acepta por el servidor API y/o el sondeo indica que el WebSocket no funciona correctamente debido, por ejemplo, a un cortafuegos), el cliente API 110 puede proponer, en 132, el procedimiento de transporte Sondeo Largo para una conexión que lleve notificaciones asíncronas enviadas por el servidor API al cliente API.
Si el servidor API acepta usar el procedimiento propuesto de Sondeo Largo y/o el sondeo indica que el Sondeo Largo funciona correctamente en 140, el servidor a Pi 112 puede usar, en 142, el procedimiento de transporte de Sondeo Largo para las notificaciones proporcionadas por el Servidor API al cliente API. El cliente API y/o el servidor API pueden seguir utilizando HTTP, en lugar de Sondeo Largo, para otros tipos de transporte de datos.
Si usar el Sondeo Largo propuesto no tiene éxito en 150 (por ejemplo, no se acepta por el servidor API y/o el sondeo indica que el Sondeo Largo no funciona correctamente debido, por ejemplo, a un cortafuegos), se puede generar un error.
La Figura 2 representa un procedimiento de ejemplo 200 para crear la suscripción al procedimiento de transporte HTTP inverso para una conexión que transporta notificaciones tales como notificaciones asíncronas desde el servidor 112 al cliente 110, de acuerdo con algunas realizaciones de ejemplo.
En 202, el cliente API 110 puede enviar una solicitud HTTP, como un POST, al servidor API 112, y esta solicitud HTTP puede incluir un recurso de suscripción (conjunto de datos de suscripción) que incluye el URI de devolución de llamada, de acuerdo con algunas realizaciones de ejemplo. En respuesta a recibir la solicitud HTTP que incluye el URI de devolución de llamada, el servidor API 112 puede crear, en 204, un recurso de suscripción en un estado "no confirmado", de acuerdo con algunas realizaciones de ejemplo. El servidor API puede enviar, en 206, una copia de la suscripción creada, incluyendo datos como el URI de devolución de llamada y/o un valor de tiempo de espera, de acuerdo con algunas realizaciones de ejemplo.
En 210, el servidor API 112 puede sondear el HTTP inverso, de acuerdo con algunas realizaciones de ejemplo. Con ese fin, el servidor API 112 puede enviar, en 212, una solicitud HTTP POST que incluye la notificación de prueba al URI de devolución de llamada, de acuerdo con algunas realizaciones de ejemplo. El servidor API 112 también puede comprobar si el URI de devolución de llamada es accesible en 214 enviando un HTTP GET (o HEAD, POSt y/o similar) al URI de devolución de llamada, de acuerdo con algunas realizaciones de ejemplo. El sondeo y/o la comprobación de alcanzabilidad pueden indicar si el transporte HTTP inverso se puede usar con éxito entre el servidor API 112 y el cliente API 110.
Si el URI de devolución de llamada 110 del cliente API es alcanzable por el servidor API 112 a través de HTTP (220), el servidor API puede establecer, en 222, el estado de la suscripción como "confirmado" y comenzar a usar, en 224, el procedimiento HTTP inverso para las notificaciones, como las notificaciones asíncronas enviadas por el servidor a Pi al cliente API. El cliente API y/o el servidor API pueden seguir utilizando HTTP, en lugar de HTTP inverso, para otros tipos de transporte de datos.
Si el URI de devolución de llamada 110 del cliente API no es accesible por el servidor API 112 a través de HTTP (230), el resultado puede considerarse fallido (236), por lo que el cliente API puede proponer otro procedimiento de transporte, de acuerdo con algunas realizaciones de ejemplo. Si el cliente API 110 no recibe una notificación de prueba y/o recibe una solicitud HTTP al URI de devolución de llamada dentro de un tiempo de espera (232), el cliente API puede considerar el uso de HTTP inverso como fallido en 236, de acuerdo con algunas realizaciones de ejemplo. Alternativa o adicionalmente, si el servidor API 112 no recibe una respuesta a la notificación de prueba y/o una respuesta a la solicitud HTTP al URI de devolución de llamada (234), el servidor API 123 puede considerar el uso de HTTP inverso como fallido en 236, de acuerdo con algunas realizaciones de ejemplo.
La Figura 3 representa un procedimiento de ejemplo 300 para actualizar una suscripción 122 para proponer el transporte de WebSocket para las notificaciones del servidor enviadas de forma asíncrona a un cliente, de acuerdo con algunas realizaciones de ejemplo.
En 302, el cliente API 110 puede enviar una solicitud HTTP como PUT, PATCH, y/o similar incluyendo una indicación de que la suscripción debe actualizarse al procedimiento de transporte WebSocket, de acuerdo con algunas realizaciones de ejemplo. La solicitud enviada en 302 puede indicar al servidor API 112 que el cliente API 110 soporta, como parte de una negociación con el servidor API, el transporte WebSocket. En 304, el servidor API 112 puede actualizar la suscripción para mostrar la suscripción de WebSocket como "no confirmada" y puede crear un URI de WebSocket, de acuerdo con algunas realizaciones de ejemplo. En 306, el servidor APl 112 puede devolver al cliente APl 110 una copia de la suscripción actualizada que incluye el URI de WebSocket y/o un valor de tiempo de espera, de acuerdo con algunas realizaciones de ejemplo. En 308, se abre una conexión WebSocket al URI de WebSocket con el fin de manejar notificaciones tales como las notificaciones asíncronas desde el servidor 112 al cliente 110, de acuerdo con algunas realizaciones de ejemplo.
En 312, si el servidor APl 112 recibe satisfactoriamente los mensajes de configuración de la conexión WebSocket, entonces el servidor APl 112 puede considerar que la conexión WebSocket ha sido satisfactoria. Sin embargo, puede ser necesario seguir sondeando en 314/316 y/o 318/319 para confirmar el funcionamiento. Para sondear, el servidor APl 112 puede enviar, en 314, un mensaje de notificación de prueba al cliente APl 110. Si el cliente APl 110 confirma la recepción del mensaje de notificación de prueba, por ejemplo, enviando el mensaje 316 antes del valor de tiempo de espera, el servidor APl 112 puede considerar que la conexión WebSocket ha sido exitosa. Alternativa o adicionalmente, el servidor APl 112 puede, en 318, enviar un mensaje de ping al cliente APl 110. Si el cliente APl 110 confirma la recepción del mensaje ping, por ejemplo, enviando un mensaje como pong 319 antes del valor de tiempo de espera, el servidor APl 112 puede considerar que la conexión WebSocket es exitosa.
Si la conexión WebSocket se considera establecida con éxito, el servidor API puede, en 332, actualizar el estado de la suscripción a "confirmado" y comenzar a usar, en 334, la conexión WebSocket para notificaciones, como notificaciones asíncronas enviadas por el servidor APl al cliente APl. El cliente APl y el servidor pueden seguir utilizando HTTP, en lugar de WebSocket, para otros tipos de transporte de datos.
En 342 y 344, si los mensajes de configuración de la conexión WebSocket y/o el sondeo en 314/316 y/o 318/319 fallaron, el cliente APl 110 y el servidor APl 112 pueden considerar el uso de Websockets como fallido en 348, en cuyo caso se puede proponer otro procedimiento.
La Figura 4 representa un procedimiento de ejemplo 400 para actualizar una suscripción 132 para proponer transporte de Sondeo Largo para notificaciones de servidor enviadas de forma asíncrona a un cliente, de acuerdo con algunas realizaciones de ejemplo.
En 402, el cliente API 110 puede enviar al servidor API 112 una solicitud HTTP tal como PUT, PATCH y/o similar, que incluye una indicación de que la suscripción debe actualizarse a los procedimientos de transporte Sondeo Largo, de acuerdo con algunas realizaciones de ejemplo. La solicitud enviada en 402 puede indicar al servidor API 112 que el cliente API soporta el procedimiento de transporte Sondeo Largo y propone, como parte de una negociación, usar el Sondeo Largo. En 404, el servidor API 112 puede actualizar la suscripción para mostrar la suscripción de Sondeo Largo como "no confirmada" y puede crear un URI de Sondeo Largo, de acuerdo con algunas realizaciones de ejemplo. En 406, el servidor API 112 puede devolver al cliente API 110 una copia de la suscripción actualizada incluyendo el URI de Sondeo Largo y/o un valor de tiempo de espera, de acuerdo con algunas realizaciones de ejemplo.
En 408, el servidor API 112 puede proporcionar una notificación de prueba que el cliente API 110 obtiene mediante Sondeo Largo, de acuerdo con algunas realizaciones de ejemplo. Si el Sondeo Largo tiene éxito (es decir, el cliente 110 ha obtenido la notificación de prueba con éxito), el servidor API 112 puede, en 410, actualizar el estado de la suscripción a "confirmado" y comenzar a usar, en 412, a usar el transporte de Sondeo Largo para la notificación, como las notificaciones asíncronas proporcionadas por el servidor API al cliente API. El cliente y el servidor API pueden seguir utilizando HTTP, en lugar de Sondeo Largo, para otros tipos de transporte de datos.
Sin embargo, si el Sondeo Largo no tiene éxito (es decir, la notificación de prueba no se obtuvo con éxito dentro de un tiempo de espera 414/416), el cliente API 110 y el servidor API 112 pueden considerar el uso del Sondeo Largo como fallido en 450, en cuyo caso un error puede generarse.
La Figura 5A representa un ejemplo de procedimiento 500, de acuerdo con algunas realizaciones de ejemplo.
En algunas realizaciones de ejemplo, un cliente, como el cliente API 110, puede solicitar, en 510, que el servidor 112 envíe notificaciones asíncronas al cliente 110, de acuerdo con algunas realizaciones de ejemplo. La solicitud puede incluir al menos un procedimiento de transporte propuesto, como HTTP inverso, WebSocket y/o sondeo largo, para transportar la(s) notificación(es) asíncrona(s). Como se señaló, la solicitud puede incluir un conjunto de procedimientos de transporte o puede incluir un único procedimiento de transporte. La solicitud puede incluir otros parámetros, como un URI de devolución de llamada para HTTP inverso, una solicitud de sondeo (y/o qué tipo de sondeo) y/o similares. Además, la solicitud puede comprender una solicitud HTTP. Además, la solicitud HTTP puede incluir un identificador de recursos uniforme de devolución de llamada en el cliente para permitir una llamada devuelta del protocolo de transporte de hipertexto inverso al cliente. Alternativa o adicionalmente, la solicitud HTTP puede incluir una solicitud para que el servidor sondee, por ejemplo, a través de un mensaje de notificación de prueba, si el primer procedimiento de transporte se ha establecido con éxito.
En 520, el cliente 110 puede determinar si se establece satisfactoriamente un primer procedimiento de transporte seleccionado por el servidor 112 del al menos un procedimiento de transporte propuesto, de acuerdo con algunas realizaciones de ejemplo. Por ejemplo, el establecimiento exitoso del primer procedimiento de transporte seleccionado puede ser el resultado del establecimiento y/o sondeo del primer procedimiento de transporte entre el cliente y el servidor.
En 530, el cliente 110 puede enviar, de acuerdo con algunas realizaciones de ejemplo, al servidor 112 otra solicitud de protocolo de transferencia de hipertexto que incluye al menos otro procedimiento de transporte propuesto, cuando la determinación es que el primer procedimiento de transporte no se ha establecido con éxito. Por ejemplo, si el primer procedimiento de transporte no se establece con éxito, el cliente 110 puede enviar otra propuesta para el procedimiento de transporte para permitir que el servidor seleccione otro procedimiento de transporte para llevar las notificaciones asíncronas.
La Figura 5B representa un procedimiento de ejemplo 599, de acuerdo con algunas realizaciones de ejemplo.
En 560, un servidor, tal como el servidor 112, puede recibir, del cliente 110, una solicitud de protocolo de transferencia de hipertexto para que el servidor envíe al menos una notificación asíncrona, de acuerdo con algunas realizaciones de ejemplo. La solicitud del protocolo de transferencia de hipertexto puede incluir al menos un procedimiento de transporte propuesto para transportar la al menos una notificación asíncrona.
En 565, el servidor 112 puede enviar al cliente una indicación de si se acepta para el establecimiento un primer procedimiento de transporte seleccionado por el servidor del al menos un procedimiento de transporte propuesto, de acuerdo con algunas realizaciones de ejemplo. Por ejemplo, el servidor puede, basándose en sus capacidades, seleccionar, del al menos un procedimiento de transporte propuesto, el primer procedimiento de transporte.
En 568, el servidor 112 puede enviar un mensaje para sondear el establecimiento del primer procedimiento de transporte, de acuerdo con algunas realizaciones de ejemplo. Como se ha señalado, el mensaje puede sondear el primer procedimiento de transporte, como HTTP inverso, WebSocket, y/o similares. El mensaje puede comprender un mensaje de notificación de prueba, un ping/mensaje, y/u otros tipos de mensajes, incluyendo mensajes de respuesta a una solicitud del cliente 110.
De acuerdo con algunas realizaciones de ejemplo, el servidor 112 puede, en 570, recibir, del cliente 110, otra solicitud de protocolo de transferencia de hipertexto que incluya al menos otro procedimiento de transporte propuesto, cuando el primer transporte no se acepta para el establecimiento y/o no se establece con éxito. Como se señaló, si el cliente propone inicialmente HTTP inverso, la otra solicitud al servidor 112 puede proponer WebSocket o Sondeo Largo, por ejemplo.
La Figura 6 ilustra un diagrama de bloques de un aparato 10, de acuerdo con algunas realizaciones de ejemplo. En algunas realizaciones de ejemplo, el aparato 10 puede proporcionar un dispositivo basado en un procesador, como un ordenador, una tableta, un teléfono inteligente, un teléfono móvil, un dispositivo del Internet de las Cosas (IoT), un servidor de sitios web y/o similares. El aparato puede incluir una interfaz cableada y/o inalámbrica para permitir el establecimiento de enlaces cableados y/o inalámbricos. Por ejemplo, un primer aparato 10 puede incluir un cliente API 110, mientras que un segundo aparato 10 puede incluir un servidor 112. Cuando este es el caso, se puede seleccionar y probar un procedimiento de transporte como se describe en la presente memoria, de acuerdo con algunas realizaciones de ejemplo.
En algunas realizaciones de ejemplo, el cliente y/o el servidor pueden implementarse en un aparato, como el aparato 10. En algunas realizaciones de ejemplo, el aparato 10 puede acoplarse (mediante conexión(es) cableada(s) y/o inalámbrica(s) a Internet, al subsistema multimedia IP (IMS), y/o a otros nodos y/o redes.
Además, el aparato 10 puede implementarse como un sensor dedicado, un sensor IoT y/o algo similar. Por ejemplo, el sensor de IoT puede implementarse como una cámara de tráfico, un sensor de temperatura y/u otro tipo de sensor conectado fijamente a un edificio o semáforo, aunque el sensor de IoT también puede ser móvil. En el caso del sensor de IoT, el aparato 10 puede incluir un procesador menos potente y/o menos memoria, en comparación con, por ejemplo, un teléfono inteligente. Además, el sensor de IoT puede acceder a la red celular a través de otro dispositivo. Por ejemplo, el sensor de IoT puede acoplarse a la red celular a través de una primera interfaz, como Bluetooth o WiFi, a otro aparato que tenga una segunda interfaz a la red celular.
El aparato 10 puede incluir al menos una antena 12 en comunicación con un transmisor 14 y un receptor 16. Alternativamente, las antenas de transmisión y recepción pueden separarse. El aparato 10 también puede incluir un procesador 20 configurado para proporcionar señales y recibir señales del transmisor y receptor, respectivamente, y para controlar el funcionamiento del aparato. El procesador 20 puede configurarse para controlar el funcionamiento del transmisor y el receptor efectuando una señalización de control a través de cables eléctricos al transmisor y al receptor. Igualmente, el procesador 20 puede configurarse para controlar otros elementos del aparato 10 mediante la señalización de control a través de los cables eléctricos que conectan el procesador 20 a los otros elementos, como una pantalla o una memoria. El procesador 20 puede, por ejemplo, incorporarse en una variedad de formas que incluyen circuitos, al menos un núcleo de procesamiento, uno o más microprocesadores con procesador(es) de señal digital acompañante(s), uno o más procesador(es) sin un procesador de señal digital acompañante, uno o más coprocesadores, uno o más procesadores multinúcleo, uno o más controladores, circuitos de procesamiento, uno o más ordenadores, otros elementos de procesamiento que incluyen circuitos integrados (por ejemplo, un circuito integrado de aplicación específica (ASIC), una serie de puertas programables en campo (FPGA), y/o similares), o alguna combinación de los mismos. En consecuencia, aunque se ilustra en la Figura 6 como un solo procesador, en algunas realizaciones de ejemplo el procesador 20 puede comprender una pluralidad de procesadores o núcleos de procesamiento.
El aparato 10 puede ser capaz de operar con uno o más estándares de interfaz aire, protocolos de comunicación, tipos de modulación, tipos de acceso, y/o similares. Las señales enviadas y recibidas por el procesador 20 pueden incluir información de señalización de acuerdo con un estándar de interfaz aire de un sistema celular aplicable, y/o cualquier número de diferentes técnicas de redes de cable conductor o inalámbricas, que comprende, pero no se limitan a WiFi, técnicas de red de acceso local inalámbrico (WLAN), como El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) 802.11, 802.16, 802.3, ADSL, DOCSIS, y/o similares. Además, estas señales pueden incluir datos de voz, datos generados por el usuario, datos solicitados por el usuario, y/o similares.
Por ejemplo, el aparato 10 y/o un módem celular del mismo pueden ser capaces de operar de acuerdo con varios protocolos de comunicación de primera generación (1G), protocolos de comunicación de segunda generación (2G o 2,5G), protocolos de comunicación de tercera generación (3G), protocolos de comunicación de cuarta generación (4G), protocolos de comunicación de quinta generación (5G), protocolos de comunicación del Subsistema Multimedia del Protocolo de Internet (IMS) (por ejemplo, el protocolo de inicio de sesión (SIP) y/o similares. Por ejemplo, el aparato 10 puede ser capaz de operar de acuerdo con los protocolos de comunicación inalámbrica 2G iS-136, Acceso Múltiple por División de Tiempo TDMA, Sistema Global para Comunicaciones Móviles, GSM, IS-95, Acceso Múltiple por División de Código, CDMA, y/o similares. Además, por ejemplo, el aparato 10 puede ser capaz de operar de acuerdo con los protocolos de comunicación inalámbrica 2.5G Servicio general de paquetes vía radio (GPRS), Tasas de Datos Mejoradas para la Evolución del GSM (EDGE), y/o similares. Además, por ejemplo, el aparato 10 puede funcionar de acuerdo con los protocolos de comunicación inalámbrica 3G, tales como el Sistema Universal de Telecomunicaciones Móviles (UMTS), Acceso Múltiple por División de Código 2000 (CDMA2000), Acceso Múltiple por División de Código de Banda Ancha (WCDMA), Acceso múltiple por división de código sincrónico por división (TD-SCDMA) y/o similares. El aparato 10 puede ser capaz de operar adicionalmente de acuerdo con protocolos de comunicación inalámbrica de 3,9G, tales como Evolución a Largo Plazo (LTE), Red Universal de Acceso Radioeléctrico Terrestre Evolucionado (E-UTRAN), y/o similares. Adicionalmente, por ejemplo, el aparato 10 puede ser capaz de operar de acuerdo con los protocolos de comunicación inalámbrica 4G, como LTE Avanzado, 5G, y/o similares, así como también protocolos de comunicación inalámbrica similares que puedan desarrollarse subsecuentemente.
Se entiende que el procesador 20 puede incluir circuitos para implementar funciones lógicas y de audio/video del aparato 10. Por ejemplo, el procesador 20 puede comprender un dispositivo procesador de señales digitales, un dispositivo microprocesador, un convertidor de analógico a digital, un convertidor de digital a analógico y/o similares. Las funciones de control y procesamiento de señales del aparato 10 pueden repartirse entre estos dispositivos de acuerdo con sus respectivas capacidades. El procesador 20 puede comprender adicionalmente, un codificador de voz interno (VC) 20a, un módem de datos interno (DM) 20b, y/o similares. Además, el procesador 20 puede incluir funcionalidad para operar uno o más programas de software, que pueden almacenarse en la memoria. En general, el procesador 20 y las instrucciones de software almacenadas pueden configurarse para hacer que el aparato 10 realice acciones. Por ejemplo, el procesador 20 puede ser capaz de operar un programa de conectividad, como un navegador web. El programa de conectividad puede permitir que el aparato 10 transmita y reciba contenido web, como el contenido basado en la ubicación, de acuerdo con un protocolo, como el protocolo de aplicación inalámbrica, WAP, el protocolo de transferencia de hipertexto, HTTP, Websockets, y/o similares.
El aparato 10 también puede comprender una interfaz del usuario que incluya, por ejemplo, un auricular o altavoz 24, un timbre 22, un micrófono 26, una pantalla 28, una interfaz de entrada de usuario, y/o similares, que pueden acoplarse operativamente al procesador 20. La pantalla 28 puede, como indicó anteriormente, incluir una pantalla sensible al tacto, en la que un usuario puede tocar y/o gesticular para fabricar selecciones, introducir valores, y/o similares. El procesador 20 también puede incluir circuitos de interfaz del usuario configurados para controlar al menos algunas funciones de uno o más elementos de la interfaz de usuario, como el altavoz 24, el timbre 22, el micrófono 26, la pantalla 28, y/o similares. El procesador 20 y/o los circuitos de la interfaz del usuario que comprenden el procesador 20 pueden configurarse para controlar una o más funciones de uno o más elementos de la interfaz de usuario a través de instrucciones de programas de computadoras, por ejemplo, software y/o microprogramas, almacenados en una memoria accesible. al procesador 20, por ejemplo, memoria volátil 40, memoria no volátil 42 y/o similares. El aparato 10 puede incluir una batería para alimentar varios circuitos relacionados con el terminal móvil, por ejemplo, un circuito para proporcionar vibración mecánica como salida detectable. La interfaz de entrada de usuario puede comprender dispositivos que permitan al aparato 20 recibir datos, tales como un teclado 30 (que puede ser un teclado virtual presentado en la pantalla 28 o un teclado acoplado externamente) y/u otros dispositivos de entrada.
Como se muestra en la Figura 6, el aparato 10 también puede incluir uno o más mecanismos para compartir y/u obtener datos. Por ejemplo, el aparato 10 puede incluir un transceptor y/o interrogador 64 de frecuencia (RF) de corto alcance, por lo que los datos se pueden compartir y/u obtener de dispositivos electrónicos de acuerdo con técnicas de RF. El aparato 10 puede incluir otros transceptores de corto alcance, como un transceptor de infrarrojos (IR) 66, un transceptor Bluetooth TM (BT) 68 que funcione mediante el uso de tecnología inalámbrica Bluetooth TM, un transceptor inalámbrico de bus serie universal (USB) 70, un transceptor Bluetooth TM de baja energía, un transceptor ZigBee, un transceptor ANT, un transceptor celular de dispositivo a dispositivo, un transceptor de enlace de área local inalámbrica, y/o cualquier otra tecnología de radio de corto alcance. El aparato 10 y, en particular, el transceptor de corto alcance puede ser capaces de transmitir datos a y/o recibir datos de dispositivos electrónicos dentro de la proximidad del aparato, como por ejemplo dentro de 10 metros. El aparato 10 que incluye el módem WiFi o de red de área local inalámbrica también puede ser capaz de transmitir y/o recibir datos de dispositivos electrónicos de acuerdo con diversas técnicas de red inalámbrica, incluyendo 6LoWpan, WiFi, WiFi de baja energía, técnicas WLAN como las técnicas IEEE 802.11, técnicas IEEE 802.15, técnicas IEEE 802.16, y/o similares.
El aparato 10 puede comprender una memoria, como un módulo de identidad de abonado (SIM) 38, un módulo de identidad de usuario extraíble (R-UIM), un eUICC, un UICC, y/o similares, que pueden almacenar elementos de información relacionados con un abonado móvil. Además de la SIM, el aparato 10 puede incluir otra memoria extraíble y/o fija. El aparato 10 puede incluir una memoria volátil 40 y/o una memoria no volátil 42. Por ejemplo, la memoria volátil 40 puede incluir la memoria de acceso aleatorio (RAM), incluyendo la RAM dinámica y/o estática, la memoria caché en el chip o fuera del chip, y/o similares. La memoria no volátil 42, que puede ser integrada y/o extraíble, puede incluir, por ejemplo, memoria de sólo lectura, memoria flash, dispositivos de almacenamiento magnético, por ejemplo, discos duros, unidades de disquete, cinta magnética, unidades y/o medios de disco óptico, memoria de acceso aleatorio no volátil (NVRAM), y/o similares. Al igual que la memoria volátil 40, la memoria no volátil 42 puede incluir un área de caché para el almacenamiento temporal de datos. Al menos parte de la memoria volátil y/o no volátil puede integrarse en el procesador 20. Las memorias pueden almacenar uno o más programas de software, instrucciones, piezas de información, datos y/o similares que pueden usarse por el aparato para realizar las operaciones divulgadas en la presente memoria, incluyendo, por ejemplo, el envío, por parte de un cliente, de una solicitud de protocolo de transferencia de hipertexto para al menos una notificación asíncrona a ser enviada por un servidor al cliente, la solicitud de protocolo de transferencia de hipertexto incluyendo al menos un procedimiento de transporte propuesto para llevar la al menos una notificación asíncrona; determinar, por el cliente, si un primer procedimiento de transporte seleccionado por el servidor de entre el al menos un procedimiento de transporte propuesto se establece con éxito; y cuando la determinación es que el primer procedimiento de transporte no se establece con éxito, enviar, por el cliente, otra solicitud de protocolo de transferencia de hipertexto al servidor, la otra solicitud de protocolo de transferencia de hipertexto incluyendo al menos otro procedimiento de transporte propuesto. Alternativa o adicionalmente, las memorias pueden almacenar uno o más programas de software, instrucciones, piezas de información, datos, y/o similares que pueden usarse por el aparato para realizar las operaciones divulgadas en la presente memoria, incluyendo, por ejemplo, recibir, por un servidor, de una solicitud de protocolo de transferencia de hipertexto para que el servidor envíe al menos una notificación asíncrona, la solicitud de protocolo de transferencia de hipertexto incluyendo al menos un procedimiento de transporte propuesto para llevar la al menos una notificación asíncrona; enviar, por el servidor, una indicación de si un primer procedimiento de transporte seleccionado por el servidor de entre el al menos un procedimiento de transporte propuesto se acepta para su establecimiento; enviar, por el servidor, un mensaje para sondear el establecimiento del primer procedimiento de transporte; y recibir, por el servidor, otra solicitud de protocolo de transferencia de hipertexto que incluya al menos otro procedimiento de transporte propuesto, cuando el primer transporte no sea aceptado para su establecimiento y/o no se haya establecido con éxito.
Las memorias pueden comprender un identificador, tal como un código de identificación de equipo móvil internacional (IMEI), capaz de identificar de forma única el aparato 10. Las memorias pueden comprender un identificador, tal como un código de identificación de equipo móvil internacional (IMEI), capaz de identificar de forma única el aparato 10. En la modalidad de ejemplo, el procesador 20 puede configurarse mediante el uso de código informático almacenado en la memoria 40 y/o 42 para controlar y/o proporcionar uno o más aspectos divulgados en la presente memoria (véase, por ejemplo, el procedimiento 100, 200, 300, 400, 500, 599, y/u otras operaciones divulgadas en la presente memoria). Por ejemplo, el procesador 20 puede configurarse mediante el uso de un código informático almacenado en la memoria 40 y/o 42 para al menos incluir, por ejemplo, realizar una o más de las operaciones divulgadas en la presente memoria, incluyendo en el procedimiento 100, 200, 300, 400, 500, 599, y/o similares.
Algunas de las realizaciones divulgadas en la presente memoria pueden implementarse en software, hardware, lógica de aplicación o una combinación de software, hardware y lógica de aplicación. El software, la lógica de la aplicación y/o el hardware pueden residir en la memoria 40, el aparato de control 20 o los componentes electrónicos, por ejemplo. En algunas realizaciones de ejemplo, la lógica de aplicación, el software o un conjunto de instrucciones se mantiene en cualquiera de los diversos medios convencionales legibles por ordenador. En el contexto de este documento, un "medio legible por ordenador" puede ser cualquier medio no transitorio que pueda contener, almacenar, comunicar, propagar o transportar las instrucciones para usar por o en relación con un sistema de ejecución de instrucciones, aparato o dispositivo, como un ordenador o un circuito procesador de datos, con ejemplos representados en la Figura 6, el medio legible por ordenador puede comprender un medio de almacenamiento no transitorio legible por ordenador que puede ser cualquier medio que pueda contener o almacenar las instrucciones para usar por o en relación con un sistema, aparato o dispositivo de ejecución de instrucciones, como un ordenador.
Sin limitar en modo alguno el ámbito, la interpretación o la aplicación de las reivindicaciones que aparecen más abajo, un efecto técnico de una o más de las realizaciones de ejemplo divulgadas en la presente memoria puede ser la mejora del control de la selección del procedimiento de transporte para las notificaciones asíncronas del servidor al permitir una negociación entre el cliente y el servidor para la selección del procedimiento de transporte.
La materia descrita en la presente memoria puede llevarse a la práctica en sistemas, aparatos, procedimientos y/o artículos en función de la configuración deseada. Por ejemplo, las estaciones base y los equipos de usuario (o uno o más componentes de los mismos) y/o los procedimientos descritos en la presente memoria pueden implementarse mediante el uso de uno o más de los siguientes: un procesador que ejecuta código de programa, un circuito integrado de aplicación específica (ASIC), un procesador de señal digital (DSP), un procesador integrado, una serie de puertas programables en campo (FPGA), y/o sus combinaciones. Estas diversas implementaciones pueden incluir la implementación en uno o más programas de computadora que son ejecutables y/o interpretables en un sistema programable que incluye al menos un procesador programable, que puede ser de propósito especial o general, acoplado para recibir datos e instrucciones de y para transmitir datos. e instrucciones para un sistema de almacenamiento, al menos un dispositivo de entrada y al menos un dispositivo de salida. Estos programas informáticos (también conocidos como programas, software, aplicaciones de software, aplicaciones, componentes, código de programa o código) incluyen instrucciones de máquina para un procesador programable, y pueden implementarse en un lenguaje de programación de alto nivel procedimental y/u orientado a objetos, y/o en lenguaje ensamblador/máquina. Como se usa en la presente memoria, el término "medio legible por ordenador" se refiere a cualquier producto de programa de computadora, medio legible por máquina, medio de almacenamiento legible por ordenador, aparato y/o dispositivo (por ejemplo, discos magnéticos, discos ópticos, memoria, dispositivos lógicos programables (PLD)) usado para proporcionar instrucciones de máquina y/o datos a un procesador programable, incluyendo un medio legible por máquina que recibe instrucciones de máquina. De manera similar, también se describen en la presente memoria sistemas que pueden incluir un procesador y una memoria acoplados al procesador. La memoria puede incluir uno o más programas que hacen que el procesador realice una o más de las operaciones descritas en la presente memoria.
Aunque se han descrito detalladamente algunas variaciones, son posibles otras modificaciones o adiciones. En particular, se pueden proporcionar características y/o variaciones adicionales además de las establecidas en la presente memoria. Además, las implementaciones descritas anteriormente pueden estar dirigidas a diversas combinaciones y subcombinaciones de las características divulgadas y/o combinaciones y subcombinaciones de varias características adicionales divulgadas anteriormente. Otras realizaciones pueden estar dentro del ámbito de las siguientes reivindicaciones.
Si se desea, las diferentes funciones discutidas en la presente memoria pueden realizarse en un orden diferente y/o simultáneamente entre sí. Además, si se desea, una o más de las funciones descritas anteriormente pueden ser opcionales o pueden combinarse. Aunque varios aspectos de algunas de las realizaciones se exponen en las reivindicaciones independientes, otros aspectos de algunas de las realizaciones comprenden otras combinaciones de características de las realizaciones descritas y/o de las reivindicaciones dependientes con las características de las reivindicaciones independientes, y no únicamente las combinaciones expuestas explícitamente en las reivindicaciones. También se indica en la presente memoria que, si bien lo anterior describe realizaciones de ejemplo, estas descripciones no deben verse en un sentido limitante. Más bien, existen diversas variaciones y modificaciones que pueden realizarse sin apartarse del ámbito de algunas de las realizaciones definidas en las reivindicaciones adjuntas. Otras realizaciones pueden estar dentro del ámbito de las siguientes reivindicaciones. El término "basado en" incluye "basado en al menos." Usar la frase "como" significa "como por ejemplo" a menos que se indique de otra forma.

Claims (20)

REIVINDICACIONES
1. Un procedimiento (500) que comprende:
enviar (510), por un cliente (110), una solicitud de protocolo de transferencia de hipertexto para que al menos una notificación asíncrona sea enviada por un servidor (112) al cliente, incluyendo la solicitud de protocolo de transferencia de hipertexto al menos un procedimiento de transporte propuesto para llevar la al menos una notificación asíncrona,
caracterizado porque comprende, además:
determinar (520), por el cliente (110), si un primer procedimiento de transporte seleccionado por el servidor (112) del al menos un procedimiento de transporte propuesto se ha establecido con éxito, en el que se determina que el primer procedimiento de transporte se ha establecido con éxito basándose en un mensaje para sondear el establecimiento del primer procedimiento de transporte que se recibe del servidor (112); y
cuando la determinación es que el primer procedimiento de transporte no se establece con éxito, enviar (530), por el cliente (110), otra solicitud de protocolo de transferencia de hipertexto al servidor (112), incluyendo la otra solicitud de protocolo de transferencia de hipertexto al menos otro procedimiento de transporte propuesto.
2. El procedimiento de la reivindicación 1, en el que la solicitud de protocolo de transferencia de hipertexto incluye un identificador de recursos uniforme de devolución de llamada en el cliente para permitir una devolución de llamada del protocolo de transporte de hipertexto inverso al cliente, y/o en el que la solicitud de protocolo de transferencia de hipertexto incluye además una solicitud para que el servidor sondee, mediante un mensaje de notificación de prueba, si el primer procedimiento de transporte se ha establecido con éxito.
3. El procedimiento de cualquiera de las reivindicaciones 1-2, en el que al menos un procedimiento de transporte propuesto comprende un protocolo de transferencia de hipertexto inverso, un WebSocket, y/o un sondeo largo.
4. El procedimiento de cualquiera de las reivindicaciones 1-3, en el que se determina que el primer procedimiento de transporte se ha establecido con éxito basándose en al menos un mensaje recibido del servidor antes de un tiempo de espera, una notificación de prueba recibida del servidor antes del tiempo de espera, un ping recibido del servidor antes del tiempo de espera, y/o una respuesta a un ping enviado por el cliente recibido del servidor antes del tiempo de espera.
5. El procedimiento de cualquiera de las reivindicaciones 1-4, en el que el primer procedimiento de transporte seleccionado por el servidor es recibido por el cliente en una respuesta a la solicitud de protocolo de transferencia de hipertexto y se indica mediante un parámetro explícito, en el que la respuesta incluye un identificador de recursos uniforme de WebSocket, y/o en el que la respuesta incluye un identificador de recursos uniforme de protocolo de transferencia de hipertexto para usar con sondeo largo.
6. El procedimiento de cualquiera de las reivindicaciones 1-5, en el que el al menos un procedimiento de transporte propuesto se indica en la solicitud del protocolo de transferencia de hipertexto mediante el parámetro explícito y/o la solicitud que contiene un identificador de recursos uniforme de devolución de llamada.
7. El procedimiento de cualquiera de las reivindicaciones 1-6 que comprende, además:
recibir, por parte del cliente (110), la al menos una notificación asíncrona transportada a través del primer procedimiento de transporte, cuando la determinación es que el primer procedimiento de transporte se establece con éxito.
8. El procedimiento de cualquiera de las reivindicaciones 1-7, en el que el primer procedimiento de transporte comprende el protocolo de transferencia de hipertexto inverso, en el que el al menos otro procedimiento de transporte comprende el WebSocket, en el que el sondeo largo representa un procedimiento de transporte por defecto cuando el primer procedimiento de transporte y el otro procedimiento de transporte no se establecen con éxito, y/o en el que el cliente y el servidor utilizan el protocolo de transferencia de hipertexto para el transporte de otros tipos de datos.
9. Un procedimiento (599) que comprende:
recibir (560), por parte de un servidor (112), una solicitud de protocolo de transferencia de hipertexto para que el servidor envíe al menos una notificación asíncrona, incluyendo la solicitud de protocolo de transferencia de hipertexto al menos un procedimiento de transporte propuesto para transportar la al menos una notificación asíncrona,
caracterizado porque comprende, además:
enviar (565), por el servidor (112), una indicación de si un primer procedimiento de transporte seleccionado por el servidor de entre al menos un procedimiento de transporte propuesto se acepta para su establecimiento;
enviar (568), por el servidor (112), un mensaje para sondear el establecimiento del primer procedimiento de transporte; y
recibir (570), por parte del servidor (112), otra solicitud de protocolo de transferencia de hipertexto que incluya al menos otro procedimiento de transporte propuesto, cuando el primer procedimiento de transporte no se acepta para su establecimiento y/o no se establece con éxito.
10. El procedimiento de la reivindicación 9, en el que la solicitud de protocolo de transferencia de hipertexto incluye un identificador de recursos uniforme de devolución de llamada en el cliente para permitir una devolución de llamada del protocolo de transporte de hipertexto inverso al cliente, y/o en el que la solicitud de protocolo de transferencia de hipertexto incluye además una solicitud para que el servidor sondee el establecimiento a través de un mensaje de notificación de prueba.
11. El procedimiento de cualquiera de las reivindicaciones 9-10, en el que la indicación comprende una respuesta a la solicitud de protocolo de transferencia de hipertexto aceptando o rechazando la solicitud, en el que el primer procedimiento de transporte se indica mediante un parámetro explícito, en el que la respuesta incluye un identificador de recursos uniforme de WebSocket, y/o en el que la respuesta incluye un identificador de recursos uniforme de protocolo de transferencia de hipertexto para usar con sondeo largo.
12. El procedimiento de cualquiera de las reivindicaciones 9-11, en el que el al menos un procedimiento de transporte propuesto se indica en la solicitud del protocolo de transferencia de hipertexto mediante el parámetro explícito y/o la solicitud que contiene un identificador de recursos uniforme de devolución de llamada.
13. El procedimiento de cualquiera de las reivindicaciones 9-12, que comprende, además:
enviar, por el servidor (112), la al menos una notificación asíncrona transportada a través del primer procedimiento de transporte, cuando el primer procedimiento de transporte se acepta para su establecimiento por el servidor y/o es establecido con éxito.
14. El procedimiento de cualquiera de las reivindicaciones 9-13, en el que el primer procedimiento de transporte comprende el protocolo de transferencia de hipertexto inverso, en el que el al menos otro procedimiento de transporte comprende el WebSocket, en el que el sondeo largo representa un procedimiento de transporte por defecto cuando el primer procedimiento de transporte y el otro procedimiento de transporte no se establecen con éxito, y/o en el que el cliente y el servidor usan el protocolo de transferencia de hipertexto para el transporte de otros tipos de datos.
15. Un medio no transitorio legible por ordenador que incluye un código de programa que, cuando se ejecuta, provoca operaciones que comprenden:
enviar (510), por un cliente (110), una solicitud de protocolo de transferencia de hipertexto para que al menos una notificación asíncrona sea enviada por un servidor (112) al cliente, incluyendo la solicitud de protocolo de transferencia de hipertexto al menos un procedimiento de transporte propuesto para llevar la al menos una notificación asíncrona,
caracterizado porque el código del programa cuando se ejecuta provoca operaciones adicionales que comprenden: determinar (520), por el cliente (110), si un primer procedimiento de transporte seleccionado por el servidor (112) del al menos un procedimiento de transporte propuesto se ha establecido con éxito, en el que se determina que el primer procedimiento de transporte se ha establecido con éxito basándose en un mensaje para sondear el establecimiento del primer procedimiento de transporte que se recibe del servidor (112); y
cuando la determinación es que el primer procedimiento de transporte no se establece con éxito, enviar (530), por el cliente (110), otra solicitud de protocolo de transferencia de hipertexto al servidor (112), incluyendo la otra solicitud de protocolo de transferencia de hipertexto al menos otro procedimiento de transporte propuesto.
16. Un medio no transitorio legible por ordenador que incluye un código de programa que, cuando se ejecuta, provoca operaciones que comprenden:
recibir (560), por parte de un servidor (112), una solicitud de protocolo de transferencia de hipertexto para que el servidor envíe al menos una notificación asíncrona, incluyendo la solicitud de protocolo de transferencia de hipertexto al menos un procedimiento de transporte propuesto para transportar la al menos una notificación asíncrona,
caracterizado porque el código del programa cuando se ejecuta provoca operaciones adicionales que comprenden: enviar (565), por el servidor (112), una indicación de si un primer procedimiento de transporte seleccionado por el servidor de entre al menos un procedimiento de transporte propuesto se acepta para su establecimiento; enviar (568), por el servidor (112), un mensaje para sondear el establecimiento del primer procedimiento de transporte; y
recibir (570), por parte del servidor (112), otra solicitud de protocolo de transferencia de hipertexto que incluya al menos otro procedimiento de transporte propuesto, cuando el primer procedimiento de transporte no se acepta para su establecimiento y/o no se establece con éxito.
17. Un aparato (10) que comprende:
medios para enviar (12, 14, 20), por parte de un cliente (110), una solicitud de protocolo de transferencia de hipertexto para que al menos una notificación asíncrona sea enviada por un servidor al cliente, incluyendo la solicitud de protocolo de transferencia de hipertexto al menos un procedimiento de transporte propuesto para transportar la al menos una notificación asíncrona,
caracterizado porque comprende, además:
medios para determinar (20), por parte del cliente (110), si un primer procedimiento de transporte seleccionado por el servidor de entre el al menos un procedimiento de transporte propuesto se ha establecido con éxito, en el que se determina que el primer procedimiento de transporte se ha establecido con éxito basándose en un mensaje para sondear el establecimiento del primer procedimiento de transporte que se recibe del servidor (112); y
medios para enviar (12, 14, 20), por el cliente (110), otra solicitud de protocolo de transferencia de hipertexto al servidor, incluyendo la otra solicitud de protocolo de transferencia de hipertexto al menos otro procedimiento de transporte propuesto, cuando la determinación es que el primer procedimiento de transporte no se establece con éxito.
18. El aparato de acuerdo con la reivindicación 17, que comprende además medios para realizar un procedimiento de cualquiera de las reivindicaciones 2-8.
19. Un aparato (10) que comprende:
medios para recibir (12, 16, 20), por parte de un servidor (112), una solicitud de protocolo de transferencia de hipertexto para que el servidor envíe al menos una notificación asíncrona, incluyendo la solicitud de protocolo de transferencia de hipertexto al menos un procedimiento de transporte propuesto para transportar la al menos una notificación asíncrona;
medios para enviar (12, 14, 20), por el servidor (112), una indicación de si un primer procedimiento de transporte seleccionado por el servidor de entre el al menos un procedimiento de transporte propuesto se acepta para su establecimiento;
medios para enviar (12, 14, 20), por el servidor (112), un mensaje para sondear el establecimiento del primer procedimiento de transporte; y
medios para recibir (12, 16, 20), por parte del servidor (112), otra solicitud de protocolo de transferencia de hipertexto que incluya al menos otro procedimiento de transporte propuesto, cuando el primer procedimiento de transporte no se acepta para su establecimiento y/o no se establece con éxito.
20. El aparato de acuerdo con la reivindicación 19, que comprende además medios para realizar un procedimiento de cualquiera de las reivindicaciones 10-14.
ES17755350T 2017-08-04 2017-08-04 Selección del procedimiento de transporte para la entrega de notificaciones del servidor Active ES2894900T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2017/045621 WO2019027480A1 (en) 2017-08-04 2017-08-04 TRANSPORT METHOD SELECTION FOR DISTRIBUTING SERVER NOTIFICATIONS

Publications (1)

Publication Number Publication Date
ES2894900T3 true ES2894900T3 (es) 2022-02-16

Family

ID=59684059

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17755350T Active ES2894900T3 (es) 2017-08-04 2017-08-04 Selección del procedimiento de transporte para la entrega de notificaciones del servidor

Country Status (5)

Country Link
US (1) US11323502B2 (es)
EP (1) EP3662638B1 (es)
CN (1) CN110999257B (es)
ES (1) ES2894900T3 (es)
WO (1) WO2019027480A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019192593A1 (en) * 2018-04-05 2019-10-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for notification subscription
EP3648502B1 (en) * 2018-10-29 2022-02-23 Giesecke+Devrient Mobile Security GmbH Polling from device to ota core system via ota edge system
US11936638B2 (en) * 2019-06-28 2024-03-19 Salesforce Inc. Link protocol agents for inter-application communications
WO2021184216A1 (zh) * 2020-03-17 2021-09-23 Oppo广东移动通信有限公司 物联网通信方法及装置
JP2022021379A (ja) * 2020-07-22 2022-02-03 株式会社リコー 情報機器、方法およびプログラム
WO2022064096A1 (en) * 2020-09-22 2022-03-31 Nokia Technologies Oy Error handling of responses
CN112822237B (zh) * 2020-12-28 2022-07-15 北京奇艺世纪科技有限公司 网络请求传输方法及装置
CN112788144A (zh) * 2021-01-19 2021-05-11 深圳市位元领航科技有限公司 一种通信方式的实现方法、服务器以及客户端

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6965917B1 (en) * 1999-09-07 2005-11-15 Comverse Ltd. System and method for notification of an event
US20080208959A1 (en) * 2007-02-22 2008-08-28 St John Sean Hanging request system and method for client/server communication
US20100281108A1 (en) * 2009-05-01 2010-11-04 Cohen Ronald H Provision of Content Correlated with Events
CN101610183B (zh) * 2009-07-21 2011-05-11 杭州华三通信技术有限公司 一种探测超文本传输协议服务器处理能力的方法及设备
US8117322B1 (en) * 2009-12-10 2012-02-14 Google Inc. Latency reduction on HTTP servers
WO2011155945A1 (en) * 2010-06-11 2011-12-15 Hewlett-Packard Development Company, L.P. Http-based client-server communication system and method
US9521174B2 (en) * 2010-10-19 2016-12-13 Paul Matthew Davidge Video script interpreter platform with cooperating client and server
US9282135B2 (en) * 2010-10-29 2016-03-08 Israel L'Heureux Enhanced computer networking via multi-connection object retrieval
US8356100B2 (en) * 2010-11-08 2013-01-15 Google Inc. Full-duplex bi-directional communication over a remote procedure call based communications protocol, and applications thereof
CN102573111A (zh) * 2012-01-10 2012-07-11 中兴通讯股份有限公司 传输控制协议资源的释放方法及装置
US20130212227A1 (en) * 2012-02-09 2013-08-15 Cogent Real-Time Systems Inc. System and method for streaming data via http
CN102624570B (zh) * 2012-04-27 2015-04-15 杭州东信北邮信息技术有限公司 实现对web服务器可用性进行检测的监控系统和方法
GB2513344B (en) * 2013-04-23 2017-03-15 Gurulogic Microsystems Oy Communication system utilizing HTTP
CN103312807B (zh) * 2013-06-20 2016-12-28 华为技术有限公司 数据传输方法、装置及系统
US20160150027A1 (en) * 2014-11-25 2016-05-26 Futurewei Technologies, Inc. Method Of Handling Notification Channel Disconnection
CN104539510B (zh) * 2014-12-02 2018-09-21 百纳（武汉）信息技术有限公司 一种基于多协议的信息推送系统及方法
US10445153B2 (en) * 2017-06-30 2019-10-15 Ingram Micro, Inc. Technologies for managing web notifications in client-server systems

Also Published As

Publication number Publication date
US20200267201A1 (en) 2020-08-20
CN110999257A (zh) 2020-04-10
EP3662638A1 (en) 2020-06-10
US11323502B2 (en) 2022-05-03
EP3662638B1 (en) 2021-09-22
WO2019027480A1 (en) 2019-02-07
CN110999257B (zh) 2022-05-10

Similar Documents

Publication Publication Date Title
ES2894900T3 (es) Selección del procedimiento de transporte para la entrega de notificaciones del servidor
TWI694702B (zh) 用於與核心網路通訊的方法和使用者設備及電腦可讀介質
US10313449B2 (en) Online signup provisioning techniques for hotspot connections
EP3576379B1 (en) Service layer interworking using mqtt protocol
US20220095210A1 (en) Handling a ue that is in the idle state
WO2020068765A1 (en) 3gpp private lans
WO2019196817A1 (zh) 一种定位方法及相关设备
KR20210044831A (ko) 사용자 그룹에 대한 세션 관리 방법 및 장치
US10034173B2 (en) MTC service management using NFV
WO2014182674A1 (en) Machine-to-machine bootstrapping
KR102136037B1 (ko) 차세대 시스템을 위한 인증
US11310658B2 (en) Method and apparatus for determining status of terminal device, and device
WO2021134446A1 (zh) 一种信息处理方法和通信装置以及通信系统
BR112017003431B1 (pt) Meio não-transitório legível por computador, nó b evoluído, equipamento de usuário e aparelho para construção de padrões de transmissão de dados para comunicação d2d com base em padrões de recursos predefinidos
WO2019024744A1 (zh) 获取终端设备的身份标识的方法及装置
WO2018196463A1 (zh) 网络接入方法、装置、存储介质及处理器
US20230146343A1 (en) Partial support of access network information
WO2018019030A1 (zh) 一种数据传输方法、第一设备及第二设备
EP4037368A1 (en) Communication method and communication device
KR102215389B1 (ko) 통신 방법, 보안 노드 네트워크 엘리먼트, 및 단말
US11522962B2 (en) Methods and apparatuses for IP and non-IP data communication using a unified interface
EP3172891A1 (en) Reliable transfer of data from an image capturing device to a remote data storage
CN112469043B (zh) 一种鉴权的方法及装置
RU2776911C2 (ru) Способ позиционирования и соответствующее устройство
JP2019071573A (ja) ＩｏＴ機器とのデータの送受信を行うための装置、方法及びプログラム