JP6942609B2 - Communication equipment, communication methods, and programs - Google Patents

Description

The present invention relates to a technique for transmitting data from a server device to a client device via a communication device.

In recent years, a push service for transmitting push-type data from a server device to a client device has been considered. In the push service, data for notifying the occurrence of an event or the like is transmitted from the server device to the client device regardless of the timing of the request from the client device to the server device. In the IETF (Internet Engineering Task Force), the WebPush protocol has been proposed as a method for realizing a push service using Web technology.

In the communication according to the WebPush protocol, the communication device (PS: PushService) transfers the data transmitted from the server device (AS: Application Server) to the client device (UA: UserAgent). As a result, push-type data transmission from AS to UA is realized. Further, when the data is delivered from the PS to the UA, the PS sends a message (receipt) notifying the confirmation of the delivery to the AS.

On the other hand, Patent Document 1 discloses that a server device is connected to a plurality of client devices and pushes data to each client device.

Japanese Unexamined Patent Publication No. 2012-83924

In the prior art, when data is transmitted from a server device to a plurality of client devices via a communication device, the communication device appropriately notifies the server device that the data has been delivered to the destination client device. It wasn't considered. For example, in communication according to the WebPush protocol, consider a case where data is transmitted from AS to a plurality of UAs via PS. In this case, if the receipt is sent from PS to AS only when the data is first served to any UA, it is difficult for AS to determine if the data has been served to all UAs.

In view of the above problems, when data is transmitted from the server device to a plurality of client devices via the communication device, the communication device appropriately notifies the server device that the data has been delivered to the destination client device. The purpose is to be able to do it.

In order to solve the above problems, the communication device according to the present invention has, for example, the following configuration. That is, the first receiving means for receiving data from the server device, the first transmitting means for transmitting the data received by the first receiving means to the client device, and the data transmitted by the first transmitting means are The second receiving means for receiving an acknowledgment indicating that the data has been received by the client device from the client device, and the second receiving means when the data is transmitted to a plurality of client devices by the first transmitting means. After receiving the confirmation response from the plurality of client devices, a delivery confirmation notification indicating that the data transmitted by the first transmission means has been received by the plurality of client devices is sent by push-type data transmission. It has a second transmission means for transmitting to the server device.

According to the present invention, when data is transmitted from a server device to a plurality of client devices via a communication device, the communication device can appropriately notify the server device that the data has been delivered to the destination client device. become.

It is a figure which shows the configuration example of the communication system 100. It is a figure which shows the hardware configuration example of a relay device 101. It is a figure which shows the example of the operation sequence of the communication system 100. It is a flowchart for demonstrating operation about the generation of an identifier by a relay device 101. It is a flowchart for demonstrating the operation concerning the reception of the transfer request by the relay device 101. It is a flowchart for demonstrating operation about transmission of a push message and a receipt by a relay device 101. It is a flowchart for demonstrating operation about reception and transmission of an identifier by a client apparatus 102. It is a flowchart for demonstrating operation about acquisition of an identifier by a client apparatus 103. It is a flowchart for demonstrating operation about receiving a push message by a client apparatus 102. It is a flowchart for demonstrating operation about transmission of a message by a server apparatus 104. It is a flowchart for demonstrating operation about the pre-processing for receipt transmission by a relay device 101. It is a figure which shows the example of the list managed by the relay device 101.

[Example 1]
[System configuration]
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing a configuration of a communication system 100 according to the present embodiment. The communication system 100 of the present embodiment includes a relay device 101, a client device 102, a client device 103, and a server device 104. The client device 102 and the client device 103 are connected to the server device 104 by wire or wirelessly via the relay device 101, communicate with each other, and transmit / receive content data such as still images and moving images, event notification commands, and the like. Although there are two client devices in the communication system 100 shown in FIG. 1, the number of client devices connected to the relay device 101 is not limited to this, and may be three or more. Further, the number of server devices 104 connected to the relay device 101 may be two or more.

In the present embodiment, the client device 102 and the client device 103 operate as a client defined in HTTP / 2 (Hypertext Transfer Protocol version 2). On the other hand, the relay device 101 operates as a server defined by HTTP / 2. That is, the client device 102 and the client device 103 transmit an HTTP request to the relay device 101, and the relay device 101 transmits an HTTP response to the client device 102 and the client device 103 in response to the received HTTP request.

The server device 104 provides a push service to the client device 102 and the client device 103 by transmitting data via the relay device 101. In order to realize the push service, a push-type data transmission method such as server push as a function of HTTP / 2 is used for transferring data from the relay device 101 to the client device 102 and the client device 103. The server device 104 operates as a client specified in HTTP / 1.1 (Hypertext Transfer Protocol version 1.1) in communication with the relay device 101. Then, the relay device 101 operates as a server specified in HTTP / 1.1 in communication with the server device 104. Specifically, the server device 104 transmits a request such as a POST method to the relay device 101, and uploads data to be transmitted by push to the relay device 101.

Specifically, the relay device 101 is a communication device such as a PC, a network switch, and a router. Specifically, the client device 102 and the client device 103 are client devices such as digital cameras, network cameras, printers, multifunction devices, televisions, projectors, mobile phones, smartphones, and PCs. Further, the specific example of the server device 104 is the same as that of the client device 102 and the client device 103. However, the form of each device in the communication system 100 is not limited to these.

The client device 102, the client device 103, and the server device 104 and the relay device 101 are connected by, for example, a LAN (Local Area Network), a WAN (Wide Area Network), or a combination thereof. As the LAN, a wired LAN conforming to Ethernet (registered trademark), a wireless LAN conforming to the IEEE (Institute of Electrical and Electronics Engineers) 802.11 series, and the like are used. As the WAN, for example, the Internet or the like is used. Further, the connection may be made based on other communication methods such as Bluetooth (registered trademark) and Zigbee (registered trademark).

Data is also exchanged between the client device 102 and the client device 103, and between the client device 102 and the server device 104. In the present embodiment, the case where this data exchange is performed by communication via LAN or WAN will be mainly described, but the method of data exchange is not limited to this. For example, data may be exchanged by reading an image or QR code (registered trademark) displayed on one device by the other device, or the user inputs information displayed on one device to the other device. You may. Further, the client device 102, the server device 104, and the like may exchange data via the information management device by registering, deleting, and updating the data in the information management device (not shown). The information management device may be, for example, software managed on a cloud or a server. When data is exchanged via the information management device, an identifier or key information for accessing the information management device may be exchanged between the client device 102 and the server device 104.

In the present embodiment, the relay device 101 has a PS (Push Service) function defined in the WebPush protocol. Further, the client device 102 and the client device 103 have a UA (User Agent) function defined in the WebPush protocol. The server device 104 has an AS (Application Service) function defined in the WebPush protocol.

The basic operation of the communication system 100 is as follows. That is, the client device 102 and the client device 103 make a data transfer request to the relay device 101, and the server device 104 transmits the data to be transmitted by push to the relay device 101. Then, the relay device 101 transfers the data to the relay device that made the transfer request at the timing corresponding to the reception of the data from the server device 104. Further, when the relay device 101 receives the confirmation response indicating that the transferred data has been received from the client device 102 and the client device 103, the relay device 101 transmits a notification of delivery confirmation to the server device 104. In the present embodiment, the notification of delivery confirmation is transmitted as a push message receipt (hereinafter referred to as a receipt) specified in the WebPush protocol. However, the format of the notification is not limited to this, and the notification may be performed by a method that allows the server device 104 to know that the data has been correctly delivered to the client device. The detailed operation of each device will be described later.

Specific examples of the communication system 100 include the following. The client device 102 is a smartphone, and the server device 104 is a network camera. The client device 102 makes a transfer request to the relay device 101, and waits for the transmission of the captured image from the server device 104. The server device 104 photographs the monitoring area with a camera, and when an abnormality in the monitoring area is detected, the server device 104 transmits the captured image to the relay device 101. Then, the relay device 101 transfers the captured image transmitted from the server device 104 to the client device 102. As a result, the user of the client device 102 can know the abnormality detected in the monitoring area and confirm the captured image in the monitoring area.

Here, when the transfer destination of the data from the relay device 101 is only the client device 102, the relay device 101 may send a receipt to the server device 104 when receiving the confirmation response from the client device 102. On the other hand, there may be a case where the data is transferred from the relay device 101 to a plurality of destinations such as the client device 102 and the client device 103. In this case, if the receipt is transmitted to the server device 104 only when the relay device 101 first receives the acknowledgment, it is difficult for the server device 104 to determine whether or not the data has been delivered to all the transfer destinations. Is. Therefore, in the present embodiment, data is delivered to the plurality of transfer destinations by transmitting a notification of delivery confirmation to the server device 104 after the relay device 101 receives confirmation responses from the plurality of transfer destinations. Can be determined by the server device 104.

It is also conceivable that the relay device 101 sends a similar receipt to the server device 104 each time it receives an acknowledgment from each of the plurality of client devices. However, even in this case, if the server device 104 does not know the number of transfer destination client devices managed by the relay device 101, the server device 104 determines whether the data has been delivered to all the transfer destinations. It is difficult. Therefore, as described in the present embodiment, after the relay device 101 receives the confirmation response from the plurality of transfer destinations, the data is transmitted to the plurality of transfer destinations by transmitting the notification of the specific delivery confirmation to the server device 104. It can be easily determined by the server device 104 whether it has been delivered.

Then, when the server device 104 receives the notification of the delivery confirmation from the relay device 101, the server device 104 transmits, for example, the next data to be transmitted to the client device 102 and the client device 103 to the relay device 101. On the other hand, if the notification of delivery confirmation is not received from the relay device 101 within a predetermined period, or if an error response is received from the relay device 101, error processing such as data retransmission is performed. Further, when the cause of the data delivery failure is notified from the relay device 101 to the server device 104 together with the error response, the server device 104 determines the cause of the notified failure of the transmitted data so as to be eliminated. You may control the type and size.

[Device configuration]
FIG. 2 is a block diagram showing a hardware configuration of the relay device 101. The client device 102, the client device 103, and the server device 104 also have the same configuration as the relay device 101. The relay device 101 includes a CPU 201, a ROM 202, a RAM 203, an auxiliary storage device 204, a display unit 205, an operation unit 206, a communication unit 207, and a bus 208.

The CPU 201 controls the entire relay device 101 using computer programs and data stored in the ROM 202 and the RAM 203. The ROM 202 stores programs and parameters that do not need to be changed. The RAM 203 temporarily stores programs and data supplied from the auxiliary storage device 204, data supplied from the outside via the communication unit 207, and the like. The auxiliary storage device 204 is composed of, for example, a hard disk drive or the like, and stores content data such as still images and moving images.

The display unit 205 is composed of, for example, a liquid crystal display, an LED, or the like, and displays a GUI (Graphical User Interface) for the user to operate the relay device 101, error information, and the like. The operation unit 206 is composed of, for example, a keyboard, a mouse, a touch panel, or the like, and inputs various instructions to the CPU 201 in response to an operation by the user. The communication unit 207 communicates with an external device such as the client device 102, the client device 103, and the server device 104. When the relay device 101 is connected to an external device by wire, for example, a LAN cable or the like is connected to the communication unit 207. Further, when the relay device 101 has a function of wirelessly communicating with an external device, the communication unit 207 includes an antenna or the like. The bus 208 connects each part of the relay device 101 to transmit information.

In the present embodiment, the CPU 201 controls the communication between the relay device 101 and the external device via the communication unit 207 by executing the program, but at least a part of the communication between the relay device 101 and the external device is performed. The communication unit 207 may be controlled by hardware processing. Further, in the present embodiment, the display unit 205 and the operation unit 206 exist inside the relay device 101, but even if at least one of the display unit 205 and the operation unit 206 exists as another device outside the relay device 101. good. In this case, the CPU 201 operates as a display control unit that controls the display unit 205 and an operation control unit that controls the operation unit 206.

[Communication sequence]
Hereinafter, the sequence of communication in the communication system 100 in the present embodiment will be described in detail. FIG. 3 is a sequence in which the server device 104 pushes data to the client device 102 and the client device 103 via the relay device 101. The sequence shown in FIG. 3 is started at the timing when the connection between each of the client device 102, the client device 103, and the server device 104 and the relay device 101 is established. However, the start timing of the process of FIG. 3 is not limited to the above timing. Each communication process shown in FIG. 3 is executed by the CPU 201 of each device in the communication system 100 controlling the communication unit 207 and the like.

In M1301, the client device 102 subscribes to the relay device 101 (identifier information request). The relay device 101 accepts the subscription from the client device 102, and generates a push URI specified in the WebPush protocol and a corresponding push message subscription URI (hereinafter, subscription URI). The generated push URI and subscription URI are stored in the RAM 203 of the relay device 101 in the form of the identifier list shown in FIG. 12 (a).

The push URI and the subscription URI are identifiers used by the relay device 101 to specify the transfer destination of the data transmitted from the server device 104, and are issue information generated (issued) by the relay device 101 in response to a request. be. Note that these identifiers are not limited to those generated according to the subscription, and may be determined according to the subscription from the identifiers previously held by the relay device 101. In the present embodiment, the identifier is URI (Uniform Resource Identifier), but it may be an identifier of another form such as UUID (UniversallyUniqueIdentifer). Further, in the present embodiment, the case where two types of information of push URI and subscription URI are used will be mainly described, but the present invention is not limited to this, and the data to be transferred and the transfer destination are specified by using one type of information. You may. That is, the push URI and the subscription URI in the following description may be the same information.

In this embodiment, subscription is performed using the POST method of HTTP / 1.1, but another method such as the GET method may be used, or other communication standards such as FTP and Websocket may be used. Communication according to may be used. Further, in the present embodiment, the case where two identifiers, the push URI and the subscription URI, are generated by the relay device 101 in response to the subscription from the client device 102 will be described, but the present invention is not limited to this. For example, only push URIs may be generated, or in addition to push URIs and subscription URIs, push message subscription set URIs specified in the Webpush protocol may be generated.

In the M1302, the relay device 101 transmits a response including the push URI and the subscription URI generated in the M1301 in response to the request from the client device 102 in the M1301. The client device 102 receives the response, and stores the push URI and the subscription URI included in the received response in the RAM 203 or the like. In the present embodiment, the status code in this response is 201Created, but the status code is not limited to this.

In M1303, the client device 102 transmits the push URI and the subscription URI received in the M1302 to the client device 103. The client device 103 receives the push URI and the subscription URI, and stores the push URI and the subscription URI in the RAM 203 or the like.

In M1304, the client device 102 transmits a push URI to the server device 104. The server device 104 receives the push URI and stores the push URI in the RAM 203 or the like. In the example of FIG. 3, the push URI is transferred from the client device 102 to the server device 104 using the communication according to HTTP / 1.1, but as described above, the data transfer method is limited to this. Not done. For example, the server device 104 may receive the push URI using another communication protocol, may receive the push URI using the image or QR code displayed on the display unit 205 of the client device 102, or may manage information. It may be received via the device. Further, the user may operate the operation unit 206 of the server device 104 to input the push URI. The same applies to the data transfer in M1303.

In M1305, the client device 102 transmits to the relay device 101 a transfer request including the subscription URI received from the relay device 101 in the M1302. By transmitting this transfer request, the client device 102 requests the push-type data transmission by the relay device 101. The relay device 101 receives the transfer request and confirms that the subscription URI included in the received transfer request matches the subscription URI stored in the identifier list in the RAM 203. Then, the relay device 101 transmits the push URI corresponding to the subscription URI and the device information of the client device 102 that is the source of the transfer request to the RAM 203 in the form of the push distribution list shown in FIG. 12 (b). save. In M1306, the client device 103 transmits to the relay device 101 a transfer request including the subscription URI received from the client device 102 in the M1303. Similar to the processing of M1305, the relay device 101 receives the transfer request and stores the push URI and the device information in the push distribution list.

That is, in M1305 and M1306, the relay device 101 receives two transfer requests including the same subscription URI from the two devices, the client device 102 and the client device 103. Then, in the push distribution list held by the relay device 101, as shown in FIG. 12B, a plurality of device information are associated with the same push URI.

In M1307, the server device 104 requests the relay device 101 to notify the relay device 101 of the delivery confirmation corresponding to the data subsequently transmitted from the server device 104 (for example, the delivery message transmitted in M1311). In M1308, the relay device 101 generates a receipt subscription URI and a push message URI in response to the notification request received in M1307. Then, the relay device 101 transmits the generated receipt subscription URI and push message URI together with the status code of HTTP (for example, 200 Accented) to the server device 104 as a response to the notification request. However, the information transmitted from the relay device 101 to the server device 104 as a response to the notification request is not limited to these, and only the push message URI may be transmitted, or another identifier may be transmitted. If the relay device 101 refuses to notify the delivery confirmation, it transmits another status code (for example, 400 or 404).

In M1309, the server device 104 makes a receipt request for receiving the receipt from the relay device 101 by push-type data transmission. This receipt request is transmitted from the server device 104 to the relay device 101 by, for example, the GET method of HTTP, and the receipt request includes a push URI corresponding to the data to be confirmed for delivery by the receipt. Further, the receipt request transmitted from the server device 104 includes the receipt subscription URI acquired from the relay device 101 in the M1308 and the push policy. The push policy is designated information for designating the number of client devices to which the relay device 101 should transfer the data received from the server device 104. The push policy may be described, for example, in the field of the HTTP header of the receipt request in the form of PUSH-MODE: all, or may be described in the body portion. Here, PUSH-MODE is an extended HTTP header for indicating a push method, and all indicates that data is pushed to all subscribing client devices.

When the relay device 101 receives the receipt request from the server device 104, the relay device 101 generates a push policy list as shown in FIG. 12 (c). Using the push URI included in the receipt request as a key, the device information of the server device 104 that is the source of the receipt request, the receipt subscription URI included in the receipt request, and the push policy are associated as the same entry and saved in the list. NS. Also, the push message URI generated with the receipt subscription URI in M1308 is stored in the same entry. The details of the push policy will be discussed later.

In M1310, the relay device 101 transmits to the server device 104 a push reservation including a push URI corresponding to the receipt subscription URI included in the receipt request received in M1309. By transmitting the push reservation, it is notified that the receipt will be pushed to the server device 104 later. In the example of FIG. 3, a PUSH_PROMISE frame for reserving a receipt to be pushed using a stream with a stream number of 82 is transmitted using the stream with a stream number of 13. Standards specify that streams and PUSH_PROMISE frames are used in HTTP / 2 compliant communications.

In M1311, the server device 104 transmits to the relay device 101 a delivery message including the push URI received from the client device 102 in M1304. The relay device 101 receives the delivery message including the push URI from the server device 104, and confirms that the push URI included in the received delivery message matches the push URI stored in the identifier list in the RAM 203. If there is a match, the delivery message is data to be transferred to the client device that is the source of the transfer request including the push URI and the corresponding subscription URI. In M1312, the relay device 101 transmits a delivery response indicating that the push request has been received to the server device 104, and the server device 104 receives the delivery response.

In the M1313, the relay device 101 searches the push distribution list stored in the RAM 203 for the device information corresponding to the push URI included in the distribution message received in the M1311. Then, the relay device 101 transmits a push reservation including the push URI to the client device 102 specified from the corresponding device information. Sending a push reservation notifies the destination that the message will be sent later by push notification. The client device 102 receives the push reservation and waits until the push message is received from the relay device 101.

In M1314, the relay device 101 transmits a push message to the client device 102. The client device 102 receives the push message. This push message is a message transmitted by pushing from the relay device 101 to the client device 102 in response to the transfer request in the M1305. That is, the push message is transmitted from the relay device 101 at a timing that does not depend on the request from the client device 102. However, instead of the push-type data transmission in the M1314, the relay device 101 may wait for a request from the client device 102 and transmit the message.

Here, the push message transmitted from the relay device 101 is information corresponding to the delivery message transmitted from the server device 104 in S1311. The push message is also information transferred by the relay device 101 in response to a transfer request in the M1305 including the subscription URI corresponding to the push URI included in the delivery message. The delivery message and the push message may contain the same data or may contain different data. In M1315, the client device 102 transmits a push response as an acknowledgment indicating that the push message has been received to the relay device 101. The relay device 101 receives the push response.

In M1316, the relay device 101 transmits a receipt having a status code of 100 CONTINUE to the server device 104 by push-type data transmission using the stream reserved in M1310. The receipt whose status code is 100 CONTINUE transmitted here is a provisional response indicating that the push message has been delivered to only one of the client device 102 and the client device 103, which are the transfer destinations. The receipt transmitted here may include information for identifying the client device 102 to which the push message has been delivered. As a result, the server device 104 can grasp to which client device the data has been delivered.

In M1317, similarly to M1313, the relay device 101 transmits a push reservation including the push URI to the client device 103 specified from the device information corresponding to the push URI included in the delivery message received in M1311. The client device 103 receives the push reservation and waits until the push message is received from the relay device 101.

In M1318, the relay device 101 transmits a push message to the client device 103, and the client device 103 receives the push message. The push message transmitted here is information corresponding to the delivery message transmitted from the server device 104 in S1311. The push message transmitted in S1318 and the push message transmitted in M1314 may be the same, or may include different data depending on the destination. In M1319, the client device 103 transmits a push response as an acknowledgment to the relay device 101, and the relay device 101 receives the push response.

In M1320, the relay device 101 transmits a receipt having a status code of 204 NoConent to the server device 104 by push-type data transmission using the stream reserved in M1310. The receipt whose status code is 204NoConent transmitted here is a delivery confirmation notice indicating that the push message has been delivered to both the client device 102 and the client device 103, which are the transfer destinations. The receipt transmitted here may include information for identifying all the transfer destinations (client device 102 and client device 103) to which the push message has been delivered. As a result, the server device 104 can grasp to which client device the data is finally delivered.

This completes a series of communications in the communication system 100. The main points of the sequence described with reference to FIG. 3 can be summarized as follows. The server device 104 transmits data to be transferred to the client device 102 and the client device 103 to the relay device 101 (M1311). The relay device 101 transfers the data received from the server device 104 to the client device 102 and the client device 103 (M1314 and M1318). Then, the relay device 101 receives a confirmation response indicating that the reception of the transferred data is completed from both the client device 102 and the client device 103, and then transmits a notification of data delivery confirmation to the server device 104 (M1320). ).

As described above, according to the communication system 100 of the present embodiment, after the relay device 101 receives the confirmation response from the plurality of client devices to which the data is transferred, the notification of the delivery confirmation of the data is transmitted to the server device 104. Will be done. As a result, the server device 104 can determine whether the data has been delivered to all the transfer destinations.

Further, the relay device 101 may transmit the provisional response to the server device 104 after receiving the confirmation response from some of the client devices among the plurality of client devices that are the transfer destinations, such as M1316. In this way, by transmitting the provisional response, which is a notification different from the notification of delivery confirmation, the server device 104 can determine that the data has been delivered to some transfer destinations. That is, the server device 104 can determine that the delivery of the data to all the transfer destinations is incomplete when the provisional response is transmitted. The relay device 101 may transmit only the notification of delivery confirmation without transmitting the provisional response. By doing so, the amount of communication between the relay device 101 and the server device 104 can be reduced as compared with the case where the relay device 101 transmits a provisional response each time the confirmation response is received from the transfer destination.

Further, the relay device 101 is not limited to transmitting two types of notifications, that is, a provisional response and a notification of delivery confirmation, depending on the type of client device of the data transfer destination, the number of transfer destinations for which delivery has been completed, and the like. Three or more types of notifications may be transmitted to the server device 104. Further, the relay device 101 may transmit the same notification to the server device 104 each time the confirmation response is received from each of the transfer destination client devices. In the example of FIG. 3, the provisional response transmitted by M1316 and the notification of delivery confirmation transmitted by M1320 may be similar messages. Also in this method, particularly when the server device 104 knows the number of transfer destination client devices, the server device 104 determines the number of notifications received from the relay device 101, thereby all the transfer destination client devices. It can be determined whether the data has been delivered to.

As a method for the server device 104 to grasp the number of transfer destination client devices, for example, the relay device 101 may transmit the number of received transfer requests to the server device 104, or receive the transfer request from the client device. The server device 104 may be notified each time. Then, when the client device unsubscribes (cancels the transfer request) from the relay device 101, the relay device 101 may notify the server device 104 to that effect. Further, for example, when the server device 104 acquires the push URI from the client device 102, the number of other client devices (client device 103 in the example of FIG. 3) in which the client device 102 shares an identifier may also be acquired. good.

Further, in the sequence of FIG. 3, the case where all the transmission sources of the transfer request received by the relay device 101 (client device 102 and client device 103) are the data transfer destinations is shown. However, the present invention is not limited to this, and the relay device 101 may transfer data only to a part of the transmission sources of the transfer request. Then, the server device 104 may specify by a push policy whether the relay device 101 transfers the data to all the transmission sources of the transfer request or only a part of the data.

For example, in the push policy list shown in FIG. 12 (c), the push policy corresponding to the server device 104 is all. In this case, the relay device 101 searches the push distribution list of FIG. 12B for the client device that has made the transfer request, and transmits a push message to all the corresponding client devices.

On the other hand, consider a case where the relay device 101 receives a receipt request for which any is specified as a push policy from a server device 105 different from the server device 104. In this case, the relay device 101 transmits the push message to only one of the client devices that have made the transfer request for the data transmitted from the server device 105. Then, the relay device 101 transmits a notification of delivery confirmation to the server device 105 after receiving the confirmation response from the client device to which the push message is transmitted. According to this method, when the push notification needs to be delivered to only one of the devices that made the transfer request, the communication amount related to the push message and the processing load of the relay device 101 can be reduced. For example, when a transfer request is made from a plurality of devices such as a smartphone, a smart watch, and a tablet owned by the same user, if a push notification arrives at one of them, the user can confirm the notification. In this case, the priority may be set for a plurality of devices, and the relay device 101 may transfer the data to the set device with a high priority.

Further, the content of the push policy is not limited to these, and for example, the number of client devices to which data is transferred may be specified among the client devices that have made the transfer request. Further, for example, data is transferred to a plurality of client devices that have made a transfer request, and a delivery confirmation notification is transmitted after the relay device 101 receives a confirmation response from some of the transfer destination client devices. May be specified. Then, the relay device 101 transmits a delivery confirmation notification after receiving the confirmation response from all of the plurality of client devices that are the transfer destinations, or transmits a delivery confirmation notification after receiving the confirmation response from some of the client devices. It may be decided based on the push policy. In this case, the relay device 101 transmits a delivery confirmation notification to the server device 104 at a timing corresponding to the decision based on the push policy. Further, the server device 104 may specify whether or not the relay device 101 transmits a provisional response before the notification of delivery confirmation. For example, the server device 104 may request a provisional response by including an Output: 100-Continue in the header of the receipt request in M1309.

Further, information other than the push policy may be used to determine to which client device the relay device 101 transfers data. For example, when the push policy is any, if the relay device 101 knows that the plurality of client devices that have made the transfer request are in a state where data can be received, any of the above-mentioned ones. Send data to the client device of. On the other hand, when it is unknown whether or not the plurality of client devices that have made the transfer request can receive the data, the relay device 101 transfers the data to the plurality of client devices and requests confirmation from one of the client devices. A notice of delivery confirmation may be sent according to the receipt. As a result, more appropriate data transfer processing can be realized according to the state of the client device.

[Device operation flow]
Next, the operation flow of each device in the communication system 100 will be described. The process described below with reference to FIGS. 4 to 11 is realized by the CPU 201 of each device expanding the program stored in the ROM 202 into the RAM 203 and executing the program. However, at least a part of the processing described below may be realized by dedicated hardware different from the CPU 201.

FIG. 4 is a flowchart for explaining a process when the relay device 101 generates an identifier. The process shown in FIG. 4 is started at the timing when the relay device 101 receives the identifier request (subscribe) from the client device 102 or the client device 103. In S501, the relay device 101 receives the identifier request from the client device 102 or the client device 103. In S502, the relay device 101 generates a subscription URI and a push URI as identifiers. In S503, the relay device 101 transmits the identifier to the client device 102 or the client device 103, which is the source of the identifier request in S501. In S504, the relay device 101 stores the identifier generated in S502 in the identifier list in the RAM 203 shown in FIG. 12 (a).

FIG. 5 is a flowchart for explaining the process when the relay device 101 receives the transfer request. The process shown in FIG. 5 is started at the timing when the relay device receives the transfer request from the client device 102 or the client device 103. In S601, the relay device 101 receives a transfer request including an identifier from the client device 102 or the client device 103. In S602, the relay device 101 compares the identifier received in S601 with the identifier stored in the identifier list in S504, proceeds to S603 if the received identifier is included in the identifier list, and proceeds to S604 if it is not included. Proceed to.

In S603, the relay device 101 stores the device information of the client device, which is the source of the transfer request received in S601, in the push distribution list in the RAM 203 shown in FIG. 12B. The device information in the present embodiment is information that allows the relay device 101 to uniquely identify the client device. Specifically, it is the device ID and MAC address of the client device, or the identification information of the connection between the client device and the relay device. In S604, the relay device 101 transmits an error response to the client device 102 or the client device 103, which is the source of the transfer request in S601.

FIG. 6 is a flowchart for explaining a process in which the relay device 101 transmits a push message to the client device 102 and the client device 103. The process shown in FIG. 6 is started at the timing when the relay device 101 receives the delivery message from the server device 104. In S701, the relay device 101 receives the delivery message including the identifier from the server device 104. In S702, the relay device 101 compares the identifier received in S701 with the identifier stored in the identifier list in S504, proceeds to S703 if the received identifier is included in the identifier list, and proceeds to S704 if it is not included. Proceed to.

In S703, the relay device 101 confirms the push policy corresponding to the push URI of the delivery message received in S701 from the push policy list shown in FIG. 12 (c). Then, in S705, the relay device 101 transmits a delivery response to the server device 104. On the other hand, in S704, the relay device 101 transmits an error response to the server device 104, and ends the process of FIG.

In S706, the relay device 101 determines the transfer destination of the push message according to the push policy confirmed in S703. For example, when the push policy is all and the relay device 101 receives a transfer request corresponding to the delivery message received in S701 from a plurality of client devices, all of the plurality of client devices are determined as transfer destinations. On the other hand, when the push policy is any, the relay device 101 determines one of the plurality of client devices that is the source of the received transfer request as the transfer destination. If the number of forwarding destinations is specified by the push policy, the number of client devices corresponding to the designation is determined as the forwarding destination.

In S707, the relay device 101 performs the processes of S708 to S711 for each of the transfer destinations determined in S705 among the device information corresponding to the identifier received in S701 in the push distribution list saved in S603. In S708, the relay device 101 transmits a push reservation to the client device corresponding to the target device information. In S709, the relay device 101 transmits a push message to the client device corresponding to the target device information. In S710, the relay device 101 receives the push response from the client device to which the push message is transferred in S709. In S711, the relay device 101 transmits a provisional response (HTTP 100Continue) to the server device 104. This provisional response may include information from which client device the push response was received, using, for example, an FQDN (Fully Qualified Domain Name), an IP address, or other identifier.

When a plurality of device information corresponding to the push URI received in S701 is determined as the transfer destination, the relay device 101 in S708 to S711 transmits the delivery message received in S701 to the plurality of clients according to the determination of the transfer destination. Transfer to the device. Here, when a plurality of device information corresponding to the same push URI is the transfer destination, that is, a plurality of client devices in which the relay device 101 determines the transfer request based on the same subscription URI as the transfer destination. When it was received from.

When the processing from S708 to S711 for all the forwarding destinations is completed, the relay device 101 sends a delivery confirmation notification indicating that the push message has been delivered to all the forwarding destinations to the server device 104 in S712, and ends the processing. .. Further, when the relay device 101 fails to deliver the push message matching the specified push policy, or when the time-out occurs before the delivery is completed, the relay device 101 transmits an error response instead of the delivery confirmation notification in S712. do. The error response may include identification information of the client device to which the data has been delivered, identification information of the client device that could not deliver the data, information indicating the cause of the failure in the delivery of the data, and the like. The provisional response in S711 may be transmitted only to some forwarding destinations. For example, when the relay device 101 receives the last push response among the push responses transmitted from the plurality of transfer destinations, the relay device 101 transmits the delivery confirmation notification in S712 without transmitting the provisional response in S711. You may go. Further, when the server device 104 knows the number of transfer destination client devices, the relay device 101 does not transmit the delivery confirmation notification in S712, but only transmits the provisional response in S711. May be good.

Further, when the push policy specifies to notify the delivery confirmation when the push message is delivered to a part (n) of the plurality of forwarding destinations, the relay device 101 is used for all of the forwarding devices 101. The processes from S708 to S711 are processed in parallel for the transfer destination. Then, the number of push responses received in S710 is confirmed, and when the number reaches n, the loop is exited and a notification of delivery confirmation is transmitted in S712. Even when the transfer destination client device is specified by the push policy, it is possible to send a push message according to the push policy by performing the same processing.

FIG. 7 is a flowchart for explaining a process in which the client device 102 receives an identifier from the relay device 101 and transmits the identifier to the client device 103 and the server device 104. The process shown in FIG. 7 is started at the timing when an identifier request is instructed to the client device 102, for example, by a user operation or the like. However, the start timing of the process shown in FIG. 7 is not limited to the above timing.

In S801, the client device 102 transmits an identifier request to the relay device 101. In S802, the client device 102 receives the identifier from the relay device 101. In S803, the client device 102 stores the identifier received in S802 in the identifier list in the RAM 203 of the own device. In S804, the client device 102 performs the process of S805 for each of the transmission target devices. The transmission target device in the present embodiment refers to, but is not limited to, the client device 103 and the server device 104. For example, an information management device (not shown) for managing identifiers may be used as a transmission target device, and the client device 102 may exchange identifiers with other devices via the information management device. In S805, the client device 102 transmits the identifier to the transmission target device.

FIG. 8 is a flowchart for explaining a process in which the client device 103 acquires an identifier from the client device 102. The process shown in FIG. 8 is started at the timing when the client device 103 receives the identifier from the client device 102. In S901, the client device 103 receives an identifier from the client device 102. In S902, the client device 103 stores the identifier received in S901 in the identifier list in the RAM 203 of the own device. The process of the server device 104 acquiring the identifier from the client device 102 is the same as the process described with reference to FIG.

FIG. 9 is a flowchart for explaining a process in which the client device 102 receives a push message from the relay device 101. The process shown in FIG. 9 is started at the timing when a transfer request is instructed to the client device 102, for example, by a user operation or the like. However, the start timing of the process shown in FIG. 10 is not limited to the above timing. In S1001, the client device 102 transmits a transfer request to the relay device 101. In S1002, the client device 102 repeats the processes of S1003 to S1006 until the transfer from the relay device 101 is completed. When the transfer ends in the present embodiment, for example, when the client device 102 is instructed to end the reception of the push message by a user operation or the like, or the client device 102 receives a message indicating the end of the transfer from the relay device 101. If you do. The conditions for ending the transfer are not limited to this.

In S1003, the client device 102 receives the push reservation including the identifier from the relay device 101. In S1004, the client device 102 waits until the push message is received from the relay device 101. In S1005, the client device 102 receives the push message from the relay device 101. In S1006, the client device 102 transmits a push response to the relay device 101. The process of receiving the push message from the relay device 101 by the client device 103 is the same as the process described with reference to FIG.

FIG. 10 is a flowchart for explaining a process in which the server device 104 transmits a delivery message to the relay device 101. The process shown in FIG. 10 is started at the timing when the server device 104 is instructed to transmit data by a user operation or the like, or when the server device 104 detects a predetermined event by a sensor or the like. However, the start timing of the process shown in FIG. 10 is not limited to the above timing.

In S1101, the server device 104 transmits a delivery message to the relay device 101. In S1102, the server device 104 receives the provisional response from the relay device 101. The interim response indicates that the delivered message has been delivered to some of the destination client devices. As a result, the server device 104 can grasp the reception status of the message in each client device. In S1103, the server device 104 receives the delivery confirmation notification from the relay device 101.

FIG. 11 is a flowchart for explaining the preprocessing performed by the relay device 101 for transmitting and receiving the receipt to and from the server device 104. The process shown in FIG. 11 is started, for example, at the timing when the server device 104 acquires the push URI from the client device 102. However, the start timing of the process shown in FIG. 11 is not limited to the above timing.

In S1201, the relay device 101 receives a notification request for requesting a notification of delivery confirmation from the server device 104. In S1202, the relay device 101 transmits a response to the notification request to the server device 104. In S1203, the relay device 101 receives a receipt request for requesting a notification of delivery confirmation, a provisional response, or the like from the server device 104. In S1204, the relay device 101 transmits a push reservation for transmitting the receipt to the server device 104 by push-type data transmission.

[Modification example]
The above-described embodiment can be modified in various ways without departing from the spirit of the present embodiment. In the present embodiment, the case where two devices, the client device 102 and the client device 103, receive a push message from the relay device 101 using the same identifier has been mainly described. However, the present invention is not limited to this, and three or more client devices may receive the push message from the relay device 101 using the same identifier. Further, the client device 102 and the client device 103 may receive data pushed from a plurality of server devices. In this case, a different identifier may be used for each server device. In the present embodiment, it is assumed that the transfer request or data to be transmitted includes an identifier, but the transfer request or data based on the identifier may be transmitted. For example, the data associated with the transfer request and the identifier may be transmitted separately from the transfer request.

Further, in the present embodiment, the communication between the relay device 101 and the client device 102 or the client device 103 is performed using the connection and stream defined in HTTP / 2. On the other hand, the communication between the relay device 101 and the server device 104 is based on HTTP / 1.1. However, the communication method performed in the communication system 100 is not limited to these. For example, the communication between the relay device 101 and the server device 104 may also be communication according to HTTP / 2. Further, the communication is not limited to HTTP / 1.1 and HTTP / 2, and communication may be performed according to other communication standards such as WebSocket and QUIC (Quick UDP Internet Connections). In this case, communication is performed using a message or a logical connection in a format corresponding to each standard. Further, in the present embodiment, an example in which push-type data transmission is performed based on the WebPush protocol has been described, but the present embodiment is not limited to this, and the present embodiment can be applied to other protocols for transmitting and receiving push notifications. .. Furthermore, it can be applied to protocols that do not use push.

Further, in the present embodiment, the case where the push policy is included in the receipt request transmitted by the server device 104 to the relay device 101 has been mainly described. As a result, the relay device 101 can perform data transfer processing in response to the request of the server device 104. The push policy may be included in the delivery message transmitted from the server device 104 to the relay device 101, or may be transmitted separately from the receipt request and the delivery message. Further, the relay device 101, the client device 102, or the like may determine the push policy and notify the server device 104 of the determined push policy. Further, the push policy may be determined by negotiation between a plurality of devices. Further, the client device 102 and the client device 103 may determine a push message reception policy, and may determine whether or not to receive the push message transmitted from the relay device 101 according to this reception policy.

<Other Embodiments>
The present invention supplies a program that realizes one or more functions of the above-described embodiment to a system or device via a network or storage medium, and one or more processors in the computer of the system or device reads and executes the program. It can also be realized by the processing to be performed. It can also be realized by a circuit (for example, ASIC or the like) that realizes one or more functions. Further, the program may be recorded and provided on a computer-readable recording medium.

100 Communication system 101 Relay device 102 Client device 103 Client device 104 Server device

Claims (13)

The first receiving means for receiving data from the server device,
A first transmitting means for transmitting the data received by the first receiving means to the client device, and
A second receiving means for receiving an acknowledgment indicating that the data transmitted by the first transmitting means has been received by the client device from the client device, and a second receiving means.
When the data is transmitted to a plurality of client devices by the first transmission means , the confirmation response is received from the plurality of client devices, and then the data is transmitted by the first transmission means. A communication device comprising a second transmission means for transmitting a delivery confirmation notification indicating that data has been received by the plurality of client devices to the server device by push-type data transmission. It has a third receiving means for receiving a data transfer request from a client device, and has a third receiving means.
When the third receiving means receives a transfer request corresponding to the data received by the first receiving means from a plurality of client devices, the first transmitting means transmits the data to the plurality of client devices. The communication device according to claim 1, wherein the communication device is characterized by the above. A third receiving means for receiving a data transfer request from the client device,
When the third receiving means receives a transfer request corresponding to the data received by the first receiving means from a plurality of client devices, the client device to be the transmission destination of the data among the plurality of client devices. Has a decision-making means to determine
The communication device according to claim 1 or 2, wherein the first transmission means transmits the data to the client device according to the determination by the determination means. It has a fourth receiving means for receiving designated information regarding the number of client devices to be transmitted to the data received by the first receiving means from the server device.
The communication device according to claim 3, wherein the determination means determines a client device to be a transmission destination of the data based on the designated information received by the fourth receiving means. It has a third transmission means for transmitting issuance information to the client device in response to an information request from the client device.
In the first transmitting means, the third receiving means has a plurality of transfer requests including the issuing information transmitted by the third transmitting means and the issuing information corresponding to the data received by the first receiving means. The communication device according to any one of claims 2 to 4, wherein when received from a client device, the data is transmitted to one or more client devices among the plurality of client devices. The communication device according to claim 5, wherein the issuance information transmitted by the third transmission means is a subscription URI defined in the WebPush protocol. The communication device according to any one of claims 1 to 6, wherein the delivery confirmation notification transmitted by the second transmission means is a push message receipt defined in the WebPush protocol. In the second transmitting means, when the data is transmitted to a plurality of client devices by the first transmitting means, the second receiving means receives the confirmation response from some of the client devices among the plurality of client devices. The invention according to any one of claims 1 to 7, wherein after receiving the data, a notification indicating that the delivery of the data to the plurality of client devices is incomplete is transmitted to the server device. Communication device. When the data is transmitted to a plurality of client devices by the first transmitting means, the second receiving means transmits the confirmation response after receiving the confirmation response from the plurality of client devices, or transmits the notification of the delivery confirmation. The second receiving means has a deciding means for determining whether to transmit the delivery confirmation notification after receiving the confirmation response from some of the client devices among the plurality of client devices.
The communication device according to any one of claims 1 to 8, wherein the second transmission means transmits a notification of delivery confirmation to the server device at a timing corresponding to a decision by the determination means. The determining means either transmits the delivery confirmation notification after the second receiving means receives the confirmation response from the plurality of client devices, or the second receiving means is a part of the plurality of client devices. 9. The communication device according to claim 9, wherein after receiving the confirmation response from the client device, it is determined whether to transmit the delivery confirmation notification based on the information received from the server device. The first receiving process in which the communication device receives data from the server device,
A first transmission step of transmitting the data received in the first reception step from the communication device to the client device, and
A second receiving step in which the communication device receives an acknowledgment indicating that the data transmitted in the first transmitting step has been received by the client device from the client device.
When the data is transmitted to a plurality of client devices in the first transmission step, after the communication device receives the confirmation response from the plurality of client devices in the second reception step, in the first transmission step. It is characterized by having a second transmission step of transmitting a delivery confirmation notification indicating that the transmitted data has been received by the plurality of client devices from the communication device to the server device by push-type data transmission. Communication method. The communication device has a third reception step of receiving a data transfer request from the client device.
In the first transmission step, when the communication device receives a transfer request corresponding to the data received in the first reception step from a plurality of client devices in the third reception step, the plurality of client devices. The communication method according to claim 11, wherein the data is transmitted to the client. A program for operating a computer as a communication device according to any one of claims 1 to 10.

Images